tbh, if my suspicion is correct [that this has nothing to do with Qt and everything to do with the HAL], then both issues will be the same.
1 Like
Ah, I was thinking it had something to do with QT, but HAL, > 3.4 could be the culprit. However, I believe, the tint in html image in richtext Labels was also present in 3.4. The issue with paint was/is not. I’m uncertain since there are some issues on the Vollaphone, so I’d appreciate if people tested the build of ‘Paint’ that I’ve made available on chum and open repos.
In 3.4 (on Volla) the images in Labels (richtext) are rendered tinted. But the images loadaed and drawn to a canvas are not tinted.
@attah just confirmed that the compositing issue reported here does not appear on official sony devices. If anyone with other ports could try the paint app at Paint | OpenRepos.net — Community Repository System (also on chum) to share if importing image and compositing leads to a tint, that would be really helpful.
Thanks! So it looks like it’s more general a problem.
Seems like “negatived”.
Blue → Orange
Orange → Blue
Not exactly. Inverted / negative would be more dramatic 
If you take the blue highway and run the RGB-BRG swap it’s almost normal. @attah had showed QML Label dispays images with a blue-ish tint - #13 by attah a method for get back swapping Red and Green, I believe. I’ll implement a filter in paint!
1 Like
So some part of Qt is reading rgb data as grb?
Ok, I’ve implemented all the channel swaps and it is not that. It’s a swap, apply bgra (blue green red alpha) and the image is back to normal.
void main(void)
{
if (texture2D(mask, qt_TexCoord0.st).a > 0.5)
gl_FragColor = texture2D(source, qt_TexCoord0.st).bgra * qt_Opacity;
else
gl_FragColor = texture2D(source, qt_TexCoord0.st) * qt_Opacity;
}
Does the trick.
1 Like
Actually you’re more or less right blue swapped with red. close enough 
1 Like
On a tip from @attah I implemented a format conversion which works for me. I’d appreciate feedback. Is this a fix for an original ‘error’ in implementation?
@attah 's concise version:
works. solved. but why!
1 Like
If I was to guess what’s happening, since the QML Canvas.loadImage has neither the correct Orientation from meta, nor the correct order of color channels, it looks like Autotransform/Autocolor are not being used? I haven’t been able to find the code, but on simplifying my above fix, I did a dead simple test.
I removed all nemo meta orientation code and did:
QImageReader ir(filename);
ir.setAutoTransform(true);
Compiled for 3.4, this ImageProvider gives canvas the correct RGB order AND the correct orientation. So QImage magic does work.
On 4.4, the ImageProvider winds up with the correct orientation but not Color.
So, it looks like a regression.Does not answer the question of what’s happening with html images loaded as richttext in labels though.
1 Like
Given the following:
class ImageProvider : public QQuickImageProvider
...
QImage requestImage(const QString &id, QSize *size, const QSize &requestedSize)
{
Q_UNUSED(requestedSize)
QString filename = QUrl(id).toString(QUrl::RemoveScheme);
QImage img;
QSize originalSize;
QByteArray format;
QImageReader ir(filename);
ir.setAutoTransform(true);
if (!ir.canRead())
return img;
originalSize = ir.size();
format = ir.format();
if (size)
*size = originalSize;
img = ir.read();
if (requestedSize.isValid())
return img.scaled(requestedSize.width(), requestedSize.height(), Qt::KeepAspectRatio);
else
return img;
}
passed to canvas with: “image://paintImage/” …
in Volla/GS290 number one.
SailfishOS_3_4_0_24_armv7hl_in_Sailfish_SDK_Build_Engine-Debug
this yields correct orientation and color
in Volla/GS290 number two, and Xperia 10ii
SailfishOS_4_4_0_58_aarch64_in_Sailfish_SDK_Build_Engine-Debug
orientation is correct, color is Red swapped with Blue.
As reported in Todays Community meeting, the Color issue is fixed:
4 Likes
I wonder, if there’s some confusion in RGBA vs ARGB in some components of Qt/Lipsick/Silica, would that maybe also explain the high CPU usage for “rgba” elements found and documented by @leszek?
Or rather, are these copy operations particularly expensive?
In theory, one could just remove qtscenegraph-adaptation to test, I think?
Just to save people the trip to video land: direct link Nextcloud
Changes the Page type qml to drop transparency.
Although there ‘might’ be efficiency issues with the implementation, it could also be issues with older QT, openGL, drivers. The effect is opacity + blur, so it’s going to be a hit much of the time.
For rendering animations, I drop a black background in place to deal with it, but maybe there is a more effective way?
Just to keep things clean and in order, I’ve tagged this as “fixed”.
1 Like