Details
-
Bug
-
Resolution: Duplicate
-
P1: Critical
-
5.5.0
-
None
-
Reproduced with offline (the one big download ones) installs of Qt5.5.0 on both Linux (Debian Wheezy amd64) and Mac OSX 10.10.4. Demonstrable via qmlscene and a trivial .qml file (will attach).
Description
I have an application which has been happily displaying a bunch of JPEGs since the Qt4.8 days, all through Qt5.4.1 (not tried 5.4.2), without any problems. Then when I tried to upgrade to 5.5... some of the JPEGs stopped displaying. I observe QImage using a problem one as a source now fails with
...<file & line info>: QML Image: Invalid image data: <filename.jpg>
No other SW has ever given a hint these might have something wrong with them, except for Gimp which, for the problem ones, outputs some warning about
lcms: skipping conversion because profiles seem to be equal: sRGB IEC61966-2.1 sRGB built-in
However a closer look at the files using exiftool (on Debian) reveals the working ones have a minimal amount of metadata... while the problem ones have a lot of Adobe themed extra cruft, and apparently a photoshop origin. (Although not obviously anything to do with EXIF orientation, which is what makes me think this may well be a separate issue from QTBUG-47052 & QTBUG-47174 & QTBUG-47147 and the orientation specific fix at https://codereview.qt-project.org/#/c/120743/ ; sorry, I've yet to master building Qt from sources though else I'd see if that patch fixed this myself first).
I'll attach a couple of them (good.jpg and bad.jpg; yes the coloured map overlays are supposed to look different), and there's a qmlscene-able file crazyjpg.qml. Displaying the qml file with qmlscene from 5.4.1, both images display fine, but with the 5.5.0 qmlscene the bad.jpg fails to display.
Now maybe my problem JPEG files really are badly busted, corrupt and deserve to fail to load... however I've heard talk elsewhere that "standards compliant" JPEG reading code and pedantry might be all very well in theory, in practice real world applications do have to deal with the de-facto standard set by Adobe (hey, I note even this websites' thumbnailer is happily creating a preview of both).
There is a workround for 5.5: I can clean up my problem JPEGs easily enough using ImageMagick's mogrify -strip... but I predict if things are left like this it'll cause a lot of trouble (and engineer vs. graphic designer friction; horrors!) when JPEGs which load everywhere else fail in Qt apps.
Attachments
Issue Links
- duplicates
-
QTBUG-46870 [REG 5.4.2 -> 5.5.0] JPEG-compressed images cannot be rendered correctly.
- Closed