Exif orientation settings reversed for full view and thumbnails

[barjac]

"Edit -> Preferences -> Viewer Tab -> Rotate image according to Exif orientation" when this box is checked the Exif rotation info is ignored. When the box is NOT checked the Exif data is used.

Likewise for: "Edit -> Preferences -> Thumbnails Tab -> Rotate thumbnails according to Exif orientation"

[oferkv]

Hey barjac, I tried to reproduce this but could not... I even deleted my config by doing rm ~/.config/phototonic/phototonic_103.conf Are you sure this reproduces?

[barjac]

Oh that's odd :\ Let me explain how I tested it. I used a Lumix DMC-TZ3 and took a series of images in portrait and one in landscape. I copied them with a file manager to a folder (from the SD card) I viewed one or two in GIMP which informed me that Exif had orientation data and asked if I wanted to use it, which worked correctly. (I did not 'save' anything in gimp) I then viewed them in Gwenview, where they all displayed correctly according to the Exif. I then viewed them in Phototonic (which was configured with the check boxes checked to use Exif) and all the portrait images were shown in landscape. It was simply by a chance thought that I tried un-checking the boxes, and hey presto all was correct! This was with Phototonic v1.5.29

[barjac]

Here are the thumbnail views with and without the checkbox checked: http://mtf.no-ip.co.uk/pub/linux/barjac/tests/pt_checked.png http://mtf.no-ip.co.uk/pub/linux/barjac/tests/pt_unchecked.png Here is one portrait image file: http://mtf.no-ip.co.uk/pub/linux/barjac/tests/P1030408.JPG

[barjac]

... and for good measure here is the config : http://mtf.no-ip.co.uk/pub/linux/barjac/tests/phototonic_103.conf I hope you can figure out what's going on. ;)

[barjac]

I have checked this again with versions: 1.5.10 1.5.31 1.5.32 All exhibit the same problem (after deleting the config file in each case).

[oferkv]

Thanks. This is interesting, it seems that your image is using a "Rotation" Exif tag which Phototonic completely ignores, this tag is an extra for some companies like Panasonic and others.. Note for fix: also read the "Rotation" tag if available when rotating images/thumbs and rotate image accordingly.

[barjac]

OK I believe you :)
But why does this cause the inverted behaviour?

[oferkv]

Well actually now I am not 100% sure... I should look at other implementations like Gimp's. I think this is the case because I am comparing your image to my image, and both with orientation tag "6", and mine is rotated OK in Phototonic, and the difference between the images is that yours has a "Rotation" tag, which mine does not...

[barjac]

Any further news on this?

[oferkv]

Hi barjac; Unfortunatelly Phototonic development is at a halt (on my part) in the last few months. Hopefully full time development can continue soon. Will update as soon I have any news. Regards, Ofer

[oferkv]

Hi barjac; OK, back in business :) can you please test that image with the new release 1.6.2? Strangely it seems OK now?

[oferkv]

Please reopen if reproduces on latest version, thanks!

[barjac]

No change that I can see. Using Phototonic v1.6.4 with a new ~/.config/phototonic/phototonic_103.conf, the default "Rotate according to exif info" is checked for viewer but not for thumbnails, so at first sight when looking at only thumbnails it seems to be fixed. However the issue is unchanged. This is for images from the Panasonic camera as linked to earlier and I have just tested with a Sony DSC-T2 with exactly the same issue. The action of the check boxes is still reversed.

I don't see how to re-open this bug :\

[oferkv]

This is what I get with your image, which seems fine, with all modes of set orientation, is this not what you get?

[barjac]

Without seeing the checkbox state I can't tell. This is with both boxes checked.

[barjac]

This is with both boxes unchecked.

[oferkv]

Not possible... I just downloaded the original horse pic from this thread and retested, all modes are fine. Can you try deleting or renaming your settings and try again? Exit Phototonic mv ~/.config/phototonic/phototonic_103.conf ~/.config/phototonic/phototonic_103.conf.old Start Phototonic, and check.

[barjac]

I had already done that, but I have just done it again and the result is exactly as above. It works fine - just the inverse action of what both check boxes say :\ However note that the defaults for both boxes are different with a new .conf - the Viewer one is checked, but the thumb is unchecked.

[oferkv]

What is the output of this command on your end: ldd ./phototonic | grep exiv This is mine: libexiv2.so.13 => /usr/lib/libexiv2.so.13 (0x00007fc3f3694000)

[barjac]

[baz@jackodesktop ~]$ ldd $(which phototonic) | grep exiv libexiv2.so.13 => /lib64/libexiv2.so.13 (0x00007f9b1b4f5000)

[oferkv]

It just doesn't reproduce on my end... Here even in KDE while both rotating image and thumbs... As you can see all is well:

[barjac]

I just checked this in the VM that I have been using for the other bug and the result is the same, so it's not just down to settings on my local machine:

[barjac]

The above is using 1.6.5

[barjac]

Maybe you could install Mageia 5 in a VM? https://wiki.mageia.org/en/Installation_Media#DVD_ISO I can point you to my 1.6.5 rpm if required. If you think it may help, I can give you a link to all the build logs and the build chroot 'installed package list' etc. for the 1.6.5 build.

[oferkv]

Ok, thats a good idea. I will first add some debugging info to the exif orientation code and let you run it... If it wont show whats going on then I will install it :)

[barjac]

I have tested in another Mageia 5 installation with Mate DE (no KDE installed) and the problem is the same, so this is not KDE related.

[JHooverman]

Although it will possibly not help barjac, I would like to let you know, that I am not able to reproduce this issue. Phototonic works for me as expected.

Programversions used: phototonic-1.6.6 qt-5.4.2 libexiv2.so.14 => /usr/lib/libexiv2.so.14 (0xb7459000)

Might this be a qt related issue?

[oferkv]

Hey Jonathan, you always have the newest versions of everything :) barjac, it will be interesting to see you try it on a different distro if you can :) Hope I will have time soon to insert some debugging info to give you a custom release, or install Mageia.

[barjac]

Mageia 5 is at qt-5.4.0 so should be the same API. Jonathan, what's your distro?

[JHooverman]

My distro is openSUSE Tumbleweed.

[barjac]

I have an installation of openSUSE-13.2, but I could not find phototonic in the repos when I checked using the package manager. I'm not at all familiar with OpenSUSE as I have only installed it to check that our bootloader detects and boots it in UEFI mode ;)

[barjac]

Installing the Mageia 5 phototonic-1.6.5 rpm in openSUSE-13.2 produces the same issue, so it seems that something in the Mageia build is causing this. The package build runs in a chroot using a minimal install that only has a base system, build tools and the package BuildRequires. Here is the full versioned package list from the chroot: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/5/x86_64/log/phototonic-1.6.5-1.mga5.src.rpm/rpm_qa.0.20150704142644.log Here is the build log: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/5/x86_64/log/phototonic-1.6.5-1.mga5.src.rpm/build.0.20150704142644.log

Any ideas?

[oferkv]

Wow interesting... I see something crazy thats going on: the qmake runs with a billion parameters: /usr/lib64/qt5/bin/qmake libsuff=64 'QMAKE_CFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC' 'QMAKE_CXXFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC' 'QMAKE_LFLAGS= -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags' QMAKE_STRIP=

Pretty crazy... might be it, while on Arch Linux its really simple: qmake-qt5 PREFIX="/usr" \ QMAKE_CFLAGS_RELEASE="$CPPFLAGS $CFLAGS" \ QMAKE_CXXFLAGS_RELEASE="$CPPFLAGS $CXXFLAGS" \ QMAKE_LFLAGS_RELEASE="$LDFLAGS"

I will try to reproduce on my end with thos params.

[oferkv]

Ok, it did not reproduce even with that qmake. I just committed some debug info, if you can build and run it and open the horse image, it will show what orientation it has (should be 6), to the shell.

[barjac]

OK - here it is: Trying to read image metadata for; "/home/baz/BLD_Mga6_5/phototonic/P1030408.JPG" Read orientation for this image: 6

[barjac]

Just to explain, we use a Mageia (rpm) macro for building with qmake which for qt5 evaluates as follows: [baz@jackodesktop ~]$ rpm --eval %qmake_qt5

/usr/lib64/qt5/bin/qmake \ %if "lib64" != "lib" libsuff=64 \ %endif QMAKE_CFLAGS="${CFLAGS:--O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC}" \ QMAKE_CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC}" \ QMAKE_LFLAGS=" -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags" \ QMAKE_STRIP=

[oferkv]

Thanks, so it seems that the right kind of rotation is being performed, but still the image is displayed incorrectly, unfortunately it seems like an upstream issue... Closing.

[barjac]

Err... If I understand correctly, the correct information is being read from exif data, but is being inverted somewhere. I was expecting more debugging steps to follow to see just where this is happening. Who is upstream in this instance? Can you suggest a standalone CLI test case to report this somewhere?

[oferkv]

Phototonic just does QTransform.rotate(90) (Qt call) when it gets orientation 6. It seems that it does not work correctly in some versions, and not much can be done about it... As we saw Arch and openSUSE are OK running the same code.

[barjac]

So what does phototonic do with 'orientation 6' images when exif is supposed to be ignored? Is QTransform.rotate() called in that case? If not, why are these being rotated correctly?

[oferkv]

Phototonic does nothing when EXIF orientation is ignored... So the image being displayed correctly in this case is also an upstream bug.

[barjac]

Yes. I have tested builds for Mageia 4, Mageia 5 and Mageia 6 (current development branch), in their respective releases. Only in Mageia 5 does phototonic fail, which is using QT 5.4.0. Mageia 4 uses 5.2.0 which is OK Mageia 6 uses 5.5.0 which is OK OpenSUSE was using 5.4.2 which seemed OK so maybe we can update Mageia 5 to QT 5.4.2 if it's deemed worthwile ;) Thanks for your help.