Created attachment 295041 [details] Screenshot JPEG images don't seem to render properly. Attaching a screenshot. I can't reproduce this in the same version of google-chrome. I'm thinking this may be triggered by using the system libjpeg. Does anyone else have this problem?
I should probably mention that I have libjpeg-turbo-1.1.1 installed.
libjpeg-turbo could be the culprit indeed. I don't have this problem neither with chromium-17.0.963.0 nor chromium-9999 but I don't use libjpeg-turbo.
Bundled jpeg works. I also played with various combinations of system jpeg for building and running chromium. jpeg-8b(build)/jpeg-8b(run) works. jpeg-8b(build)/jpeg-turbo-1.1.1(run) works. jpeg-turbo-1.1.1(build)/jpeg-turbo-1.1.1(run) produces weird rendering. jpeg-turbo-1.1.1(build)/jpeg-8b(run) causes jpeg images to be dropped entirely.
More testing: jpeg-turbo-1.1.1(build)/jpeg-turbo-1.1.90(run) works. jpeg-turbo-1.1.90(build)/jpeg-turbo-1.1.90(run) works. jpeg-turbo-1.1.90(build)/jpeg-turbo-1.1.1(run) works. jpeg-turbo-1.1.90(build)/jpeg-8b(run) drops jpeg images. So, libjpeg-turbo-1.1.90 is an improvement, but still breaks binary compatibility with jpeg-8. I would be good if anyone else could confirm the libjpeg-turbo failures. I'm not quite sure where to go from here. Do we try to push this upstream?
I have this issue as well. libjpeg-turbo 1.1.1 is installed.
Issue disappeared when libjpeg-turbo 1.1.90 emerged.
(In reply to comment #6) Are you running amd64 or x86? Actually, if you could attache emerge --info that would be great.
Portage 2.1.10.11 (default/linux/amd64/10.0, gcc-4.6.1, glibc-2.13-r4, 3.1.4 x86_64) ================================================================= System uname: Linux-3.1.4-x86_64-Intel-R-_Core-TM-_i7-2630QM_CPU_@_2.00GHz-with-gentoo-2.0.3 Timestamp of tree: Fri, 09 Dec 2011 00:00:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.1.4-r3 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.9.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.6.1-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.13-r4 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=corei7-avx -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CPPFLAGS="-march=corei7-avx -O2 -pipe" CXXFLAGS="-march=corei7-avx -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://gentoo.cities.uiuc.edu/pub/gentoo/ http://chi-10g-1-mirror.fastsoft.net/pub/linux/gentoo/gentoo-distfiles/ http://gentoo.osuosl.org/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa amd64 berkdb bzip2 cdio cli consolekit cracklib crypt cups cxx dbus dri dvd dvdnav encode fortran gdbm gpm iconv ipv6 java jpeg lock mmx modules mp3 mudflap multilib ncurses nls nptl nptlonly opengl openmp osdmenu pam pcre png pppd private-headers pulseaudio qt3support quicktime readline session smp sse sse2 sse3 ssl ssse3 startup-notification sysfs tcpd thunar udev unicode vorbis xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I can reproduce on stable x86 system with media-libs/libjpeg-turbo-1.1.1 CC-ed libjpeg-turbo maintainers, any ideas?
Ah, note http://codereview.chromium.org/8745002, Chromium upstream might know something more.
I noticed an interesting thing: When opening images themselves in the browser ("Open image in new tab") they're displayed correctly on my system. However, when displayed on a webpage (like http://openssl.org) the rendering is broken.
(In reply to comment #4) > More testing: > > jpeg-turbo-1.1.1(build)/jpeg-turbo-1.1.90(run) works. > > jpeg-turbo-1.1.90(build)/jpeg-turbo-1.1.90(run) works. > jpeg-turbo-1.1.90(build)/jpeg-turbo-1.1.1(run) works. This looks good. > jpeg-turbo-1.1.90(build)/jpeg-8b(run) drops jpeg images. > > So, libjpeg-turbo-1.1.90 is an improvement, but still breaks binary > compatibility with jpeg-8. This likely happens because libjpeg-turbo headers provide JCS_EXTENSIONS define and Chromium code is compiled to make use of JCS extensions. But jpeg-8b lacks this feature and fails at runtime. You can have a look at "chromium-15.0.874.121/ui/gfx/codec/jpeg_codec.cc" code for more details. Moreover, jpeg_codec.cc contains the following comment: // Choose an output colorspace and return if it is an unsupported one. // Same as JPEGCodec::Encode(), libjpeg-turbo supports all input formats // used by Chromium (i.e. RGB, RGBA, and BGRA) and we just map the input // parameters to a colorspace. But RGBA and BGRA formats are fully supported in libjpeg-turbo only since SVN revision 699 ("When decompressing to a 4-byte RGB buffer, set the unused byte to 0xFF so it can be interpreted as an opaque alpha channel"): http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=699 This is a new feature of libjpeg-turbo 1.1.90 release. Previously the value of the filler byte was undefined, so it could not be interpreted as valid alpha. Looks like Chromium was a little bit hasty: http://codereview.chromium.org/6603010 And then then upgraded libjpeg-turbo to match its expectations: http://codereview.chromium.org/8745002
(In reply to comment #12) > This likely happens because libjpeg-turbo headers provide JCS_EXTENSIONS define > and Chromium code is compiled to make use of JCS extensions. But jpeg-8b lacks > this feature and fails at runtime. Ah ha. That makes sense. > ... > This is a new feature of libjpeg-turbo 1.1.90 release. Previously the value of > the filler byte was undefined, so it could not be interpreted as valid alpha. > Looks like Chromium was a little bit hasty: > http://codereview.chromium.org/6603010 > And then then upgraded libjpeg-turbo to match its expectations: > http://codereview.chromium.org/8745002 The first changeset (the hasty one) was from 9 months ago, but I did not see this problem until the latest dev channel release (17.0.963.0). Perhaps there was some related change more recently? Thanks for shedding some light on this.
Found an upstream bug about this. Also started a discussion to see if we can get it to work again.
Reported this issue to libjpeg-turbo: https://sourceforge.net/tracker/?func=detail&aid=3461513&group_id=303195&atid=1278161
Several comments: -- Regarding compatibility with jpeg-8, libjpeg-turbo can be built with jpeg-8 API/ABI compatibility, but the JPEG images it generates are still bitwise compatible with jpeg-6b, not jpeg-8. jpeg-8 has numerous enhancements and modifications to the forward and inverse DCT routines, and these cause the JPEG images it generates to not be bitwise identical to those generated by jpeg-6b. I am not a DCT expert myself, so I have to trust others' opinions on this, but I am given to understand that the algorithmic changes in jpeg-8 are meant to boost performance, but libjpeg-turbo boosts performance in other ways (using SIMD instructions), so those changes aren't necessarily relevant to us. Implementing them would require a full rewrite of our SIMD routines and, quite likely, changes to the tree structure and build system such that the rewritten routines were only included if jpeg-8 support was enabled (this basically would create a fork of the SIMD routines, which is a maintenance nightmare.) In short, the JPEG images we generate should, under all circumstances, be bitwise equal to those generated by jpeg-6b, and I don't see that changing anytime soon. I'm not sure why it would be a problem, unless there is a measurable image quality/accuracy difference (which there shouldn't be.) -- Regarding the alpha channel: Prior to 1.1.90, the alpha channel wasn't an alpha channel. It was undefined, so any application that expected it to be set a certain way was behaving incorrectly. Thus, the only real issue would arise if a new application expects the new libjpeg-turbo behavior (setting the alpha channel to 0xFF), and someone dynamically links it with libjpeg-turbo and then tries to run it with an older libjpeg-turbo DSO. Adding a new #define won't correct for that situation. The application would really need a way of performing a check at run time. What I could do is add both a new #define as well as a new set of colorspace constants: JCS_EXT_RGBA, JCS_EXT_BGRA, JCS_EXT_ABGR, JCS_EXT_ARGB. The new colorspace constants allow for the app to perform a run-time check, since if it passes those to an older version of libjpeg-turbo, LJT will return JERR_BAD_IN_COLORSPACE. The new #define would allow for a compile-time check as well. It would be understood that, if JCS_EXT_RGBA/BGRA/ABGR/ARGB exist, then they are the same as JCS_EXT_RGBX/BGRX/XBGR/XRGB and that both sets of constants set the alpha channel to 0xFF. If JCS_EXT_RGBA/BGRA/ABGR/ARGB don't exist, then the alpha channel is undefined. 1.1.90 would be orphaned, in the sense that it would not provide the #define or the new colorspace constants, even though it provides the "new" behavior.
(In reply to comment #16) > What I could do is add both a new #define as well as a new set of colorspace > constants: JCS_EXT_RGBA, JCS_EXT_BGRA, JCS_EXT_ABGR, JCS_EXT_ARGB. The new > colorspace constants allow for the app to perform a run-time check, since if it > passes those to an older version of libjpeg-turbo, LJT will return > JERR_BAD_IN_COLORSPACE. The new #define would allow for a compile-time check > as well. Sounds good to me, I also suggest consulting chromium/webkit developers, see https://bugs.webkit.org/show_bug.cgi?id=74286 and http://code.google.com/p/chromium/issues/detail?id=106954 I'm not sure how the above would work with "vanilla" libjpeg compatibility (e.g. compile-time check returning "available" when compiled against recent enough libjpeg-turbo, and run-time check failing in some weird way when running against "vanilla" libjpeg).
(In reply to comment #17) > Sounds good to me, I also suggest consulting chromium/webkit developers, see > https://bugs.webkit.org/show_bug.cgi?id=74286 and > http://code.google.com/p/chromium/issues/detail?id=106954 > > I'm not sure how the above would work with "vanilla" libjpeg compatibility > (e.g. compile-time check returning "available" when compiled against recent > enough libjpeg-turbo, and run-time check failing in some weird way when running > against "vanilla" libjpeg). The app would need to gracefully catch that error and fall back accordingly. Any app that is using the colorspace extensions and expects that it could ever be dynamically linked with a non-turbo libjpeg should already be performing such checks at run time. Upon further consideration of this problem, adding new colorspace extensions creates all sorts of mess, since the colorspace conversion routines are included once for each separate colorspace extension. Basically, in order to implement the additional colorspaces the "right" way, I'd have to make them first-class citizens, which means that each one would get its own independent colorspace conversion routine. That requires modifications to the code that are deep enough to make me nervous, since the code is in beta. Also, if I'm going to go to that trouble, it seems like it would be better to just make the alpha channel opaque only if RGBA/BGRA/ABGR/ARGB are specified and to leave RGBX/BGRX/XBGR/XRGB with the legacy behavior (the issue there is that the ARM code sets the alpha channel to 0xFF always and can't be configured otherwise.) Also, if I'm going to make the "X" extensions behave differently from the "A" extensions, then the question of what to do in the higher-level TurboJPEG APIs (both C and Java) comes up. I'd probably have to add new colorspace constants for those as well. Ugh. What a mess. The more hackish approach, which doesn't require deep modifications, would be to simply have libjpeg-turbo internally modify out_color_space such that, if it is set to RGBA/BGRA/ABGR/ARGB, it will be changed to RGBX/BGRX/XBGR/XRGB within the body of jpeg_start_[de]compress(). That doesn't seem like the right thing to do, though. Unfortunately, I can't come up with any other ideas regarding how to do a run-time check for "proper" alpha channel support. Let's drop back for a minute. Can someone give me a better idea of why Chromium requires an opaque alpha channel? It is actually doing compositing/blending? Apart from that, I'm not sure why you would ever care what's in the alpha channel. If you're using, for instance, X[Shm]PutImage() on Unix or BitBlt() on Windows to draw the image to the screen, the alpha channel is ignored. If it does in fact require "proper" alpha support, then is it sufficient to just check for this at compile time (that is, would there ever be a significant risk that the app would be compiled against libjpeg-turbo 1.2 and then linked dynamically with an older version of libjpeg-turbo?) Just trying to figure out how to reduce the scope on this to make it manageable.
(In reply to comment #18) > Let's drop back for a minute. Can someone give me a better idea of why > Chromium requires an opaque alpha channel? It is actually doing > compositing/blending? Please rather ask those questions in places that Chromium developers read, i.e. referenced upstream bug reports and https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/571bc73228177c63# Thank you for taking a look at this issue.
Actually, never mind about the "legacy behavior." Since the legacy behavior was for "X" to be undefined, it is perfectly valid for it to be 0xFF, and applications that were expecting it to be 0 prior to libjpeg-turbo 1.1.90 were erroneous. So, that reduces the scope at least slightly, since we don't actually have to make the "X" extensions behave differently from the "A" extensions. But it would still be nice to be able to somehow map the "A" extensions internally to the "X" extensions.
(In reply to comment #19) > Please rather ask those questions in places that Chromium developers read, i.e. > referenced upstream bug reports and > https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/571bc73228177c63# > > Thank you for taking a look at this issue. I don't have time to converse on every bug tracker in the world. There are lots of applications using libjpeg-turbo. I got onto this tracker because it was linked to an issue on the libjpeg-turbo tracker, and I felt it a more efficient place to discuss the issue than on SourceForge. I need people on this list to summarize the downstream issues for me and liaise with that project. I really don't need to know why Chromium requires alpha compositing. Upon reading the Chromium bug reports, I established that, yes, it does, so that's good enough. So, my best understanding of the issue is that: Gentoo ships libjpeg-turbo as a dynamic library, and it's desirable for builds of Chromium on Gentoo to use that dynamic library rather than to use Chromium's in-tree version of libjpeg-turbo, but since Chromium requires the opaque alpha behavior, it's desirable to verify whether that behavior is available at run time. If that's the case, then I see no other way than to implement the new RGBA/BGRA/ABGR/ARGB colorspace extensions.
Sorry about all the ramblings. I wasn't thinking straight, apparently. It isn't necessary to include a new colorspace conversion routine for each of the "A" extensions. It's just necessary to handle each of those constants everywhere that the "X" constants are handled and map the "A" extensions to the existing colorspace conversion routines (duh. I knew that.) I'm proceeding with implementing the new constants and will post here when they're ready for evaluation.
libjpeg-turbo trunk now contains the new colorspace extensions (JCS_EXT_RGBA/BGRA/ABGR/ARGB) as well as corresponding pixel formats in the TurboJPEG C and Java APIs. Here's how this works: If an application requires the alpha channel to be set to 0xFF, it should always specify these new colorspace extensions when decompressing (when compressing, these are no different from RGBX/BGRX/XBGR/XRGB.) If backward compatibility with older versions of libjpeg-turbo or libjpeg is not a concern, then the application need do nothing more than this. Attempting to run it against an older version of libjpeg-turbo or libjpeg will generate a "Bogus input colorspace error". If backward compatibility is required, then applications can catch this run-time error and fall back to a slower path (for instance, iterating through each pixel after decompression and setting the alpha channel to 0xFF.) jcstest.c in the libjpeg-turbo source demonstrates how applications can check for the existence of both the "regular" colorspace extensions and the "alpha" colorspace extensions at both compile time and run time. If someone could communicate this information to the Chromium developers, I'd appreciate it.
(In reply to comment #23) > If someone could communicate this information to the Chromium developers, I'd > appreciate it. I plan to do that in early January (most people are on vacation), just a quick status update for now: I added a patch for Gentoo chromium package to revert the breaking WebKit change (http://trac.webkit.org/changeset/101286), I just expect a beta channel release soon and don't want to ship broken browser to ~arch Thank you for good description what happened and changes on the libjpeg-turbo side; it's greatly appreciated!
DRC, there is a discussion on gentoo-dev about this (the initial idea to make the fix on WebKit side failed, at least for now): http://archives.gentoo.org/gentoo-dev/msg_a1abdea87d28c72e19daef15bca9c949.xml If you have any comments or feedback about the discussion, I can forward them from here if needed. Your input is very much welcome.
(In reply to comment #25) > DRC, there is a discussion on gentoo-dev about this (the initial idea to make > the fix on WebKit side failed, at least for now): > http://archives.gentoo.org/gentoo-dev/msg_a1abdea87d28c72e19daef15bca9c949.xml > > If you have any comments or feedback about the discussion, I can forward them > from here if needed. Your input is very much welcome. Please note that, in general, I have *nothing* to do with the contents of libjpeg.txt. That file was written in the 90's and has undergone few changes in the upstream libjpeg. The text regarding shared linkage exists in the upstream libjpeg.txt as well. What it's cautioning you of is that, because the parameter structs in libjpeg are exposed, if a new version of the library adds to the parameter structs, it will not be ABI-compatible with the previous version of the library. That is exactly what happened between jpeg-6b and jpeg-7, and between jpeg-7 and jpeg-8. This is precisely why libjpeg-turbo can be configured to use either the jpeg-6b, jpeg-7, or jpeg-8 API/ABI's. It is incumbent upon the distro maintainer to pick one. Fedora, for instance, has standardized around the jpeg-6b API/ABI. Other distros use jpeg-7 or jpeg-8. On Linux, the libjpeg .so is built with a map file, so the symbols are versioned. Thus, it shouldn't be possible for an application built against the jpeg-8 ABI to load a version of the .so that uses the jpeg-6b ABI. In short, if this is truly a problem, then it is a problem that also exists with the upstream libjpeg. I include libjpeg.txt for the purposes of compatibility with upstream libjpeg, so please don't hang me with my own rope.
Fixed in 19.x by depending on >=libjpeg-turbo-1.2.0.
*** Bug 412031 has been marked as a duplicate of this bug. ***
