Recent media-libs/jpeg-8 update broke JPEG lossless transformations for at least two programs: media-gfx/feh-1.3.4 media-gfx/gthumb-2.10.11 You can open any JPG image in feh, then right-click -> File -> Edit in Place -> Rotate 90 CW. This will close feh and print "Bogus virtual array access" at the terminal. The expected behavior is the JPG image being correctly rotated. Feh worked fine with jpeg-7 (or 6). With gthumb, you can use the "rotate" button at the interface (the last one at the toolbar). With jpeg-8, a progress dialog is briefly shown, and nothing happens. With jpeg-7 (and probably earlier too), everything works as expected. Maybe other programs are also affected, but right now I've noticed only these two. Because of this, I'm masking jpeg-8 on my system (which is stable amd64, by the way).
I'm not convinced this is a problem with jpeg, but with feh and gthumb because following command is working fine: jpegtran -rotate 90 input.jpg > output.jpg Please open a new bug for gthumb (clone of this). Also, http://bbs.archlinux.org/viewtopic.php?pid=707556
The problem here is that feh is shipping copies of jpegint.h, transupp.c and transupp.h in it's source directory (src/ in tarball) and then is linking against system jpeg. Those files are from jpeg-6b and are incompatible with jpeg-8.
I've mailed the new upstream about this (Daniel Friesel <derf AT chaosdorf.de>) and bumped feh to 1.3.5 (doesn't solve this issue)
(In reply to comment #1) > Please open a new bug for gthumb (clone of this). Done: bug 306341
(In reply to comment #4) > (In reply to comment #1) > > Please open a new bug for gthumb (clone of this). > > Done: bug 306341 > Thanks. Got a update from upstream today, <quote> Yeah... I've already gone through quite a lot of debugging with this. The problem is that feh uses options from libjpeg which the library deliberately does not make available to external programs; the corresponding source file (transupp.h) actually encourages software authors to copy transupp.c into their source tree. This makes things rather fragile of course, when compiled with libjpeg6b everything works but it is incompatible with other versions. There are two solutions to this, either use separate branches or defines for libjpeg6 / libjpeg8 (which still doesn't fix the main problem) or remove the rotation support completely and call the jpegtran binary for that instead. Currently I'm favoring the latter one, but have not yet had the time to think through that or implement it. I hope to have a solution in the next release, though. Thanks for the mail, Daniel </quote>
This is now fixed in upstream trunk, and will be in next release. It doesn't include internal jpeg files anymore, instead it's calling the jpegtran binary. git clone git://github.com/derf/feh.git
+*feh-1.3.5_p20100301 (01 Mar 2010) + + 01 Mar 2010; Samuli Suominen <ssuominen@gentoo.org> + +feh-1.3.5_p20100301.ebuild: + Version bump (snapshot) wrt #306297, thanks to Denilson for reporting. + This will fix >= jpeg 8 image rotation.
