Home | Software Map | Motif Forums | Bug Home sponsored by ICS 
Full Text Bug Listing
 
XmGetPixmap fails on PNG images, if libjpeg-turbo is used instead of libjpeg (fix provided)
Bug#: 1546 Product: OpenMotif Version: 2.3.1 Platform: All
OS/Version: Linux Status: NEW Severity: normal Priority: Medium
Resolution: Assigned To: openmotif-devel@motifzone.net Reported By: arahne@arahne.si
Component: MotifCode Target milestone:2.3.0
URL: http://sourceforge.net/projects/libjpeg-turbo/
Summary: XmGetPixmap fails on PNG images, if libjpeg-turbo is used instead of libjpeg (fix provided)
Description:
libjpeg-turbo is an optimized version of jpeg library, which uses assembler and
simd to speed up jpeg compression/decompression two times and more.

Library is supposed to be binary compatible with libjpeg, but in case of
OpenMotif, it is not.
There is a bug in error handling in loading of JPEG images in OpenMotif, since
libjpeg-turbo uses more error codes than libjpeg, and this breaks loading of PNG
images.
The correction needs to be done in
Xm/ImageCache.c
the line 961 with
if (rc == 1) { /* not a jpeg file */
needs to be changed in
if (rc) { /* not a jpeg file */

libjpeg-turbo returns error 2 in case of PNG files, and this confuses the
OpenMotif into not trying the PNG format for the pixmap cache image.


------- Additional Comments From Igor Gala 2011-11-02 04:43 -------
We have faced with this issue earlier in bug#1539
(http://bugs.motifzone.net/show_bug.cgi?id=1539). Also you can find the
description of this issue here: 
http://sourceforge.net/projects/libjpeg-turbo/forums/forum/1086868/topic/4552848

Anyway on my Fedora 14 and 15 with the latest libjpeg-turbo-1.1.1 everything
works fine, so I guess they have already fixed this issue.


------- Additional Comments From arahne@arahne.si 2011-11-02 12:01 -------
I have used libjpeg turbo 1.1.90 and problem is still there.
As mentioned in my initial report, bug is in OpenMotif, which checks for JPEG
loading error with equality to 1, instead of different from 0 (success).

Believe me, latest OpenMotif from CVS and latest libjpeg-turbo do not work
together well, since PNG images are not loaded.


------- Additional Comments From Igor Gala 2011-11-03 10:01 -------
Return code with value 1 indicates that this is not a JPEG file. This value is
returned by _XmJpegErrorExit function but not a libjpeg or libjpeg-turbo in case
jpeg_destroy_decompress call was not successful with return code JERR_NO_SOI
which means "Not a JPEG file". Return value 2 in your case means that when you
try to load PNG image jpeg_destroy_decompress call was not successful with the
return code different than JERR_NO_SOI or JERR_OUT_OF_MEMORY (please look at the
_XmJpegErrorExit function from openmotif/lib/Xm/Jpeg.c). In this case we are not
sure that you are trying to load PNG image instead of JPEG. In bug#1539 we have
faced the same situation after the libjpeg-turbo update to 1.1.0 they added new
return codes that broke binary compatibility between libjpeg and libjpeg-turbo.
I beleive that in your case it is the same situation. 

Besides, I have tried to run a test application with the libjpeg-turbo 1.1.90
that was downloaded from their website. I used precompiled library for my RedHat
x86_64 system and I did manage to load PNG files as well as JPEG. I have not
tried to to compile libjpeg-turbo from sources but some compile flags could
exist for the binary compatibility with the libjpeg that must be set.


------- Additional Comments From arahne@arahne.si 2011-11-03 18:06 -------
Thank you for investigating this.
If you don't like my fix, or prefer that libjpeg-turbo be fixed (or compiled in
strict compatibility mode, assuming this exists, or whoever compiled it will
always do it), I have another idea to solve this problem.

The function XmGetPixmap actually loads JPEG, PNG, XBM and XPM files.
It is not efficient that the function always first tries JPEG, then PNG, then XBM...
It should examine the filename suffix, and try loading it as .PNG if file ends
in .png, or as JPEG, if it ends as .jpeg or .jpg and so on.
This would almost always work. But if you wanted 100% compatibility with
existing OpenMotif behavior, you could first try filename heuristics, and then
try the remaining loaders.

For example, my program loads 400 PNG icons on startup, and it bears the penalty
of 400 JPEG failures, since XmGetPixmap first tries to load it as JPEG, and only
then as PNG.

Would you consider making such fix, or if not, accept a patch from me? Since I
don't want to work on it, if it is not going to be used.


------- Additional Comments From Igor Gala 2011-11-09 09:33 -------
Since I cannot reproduce your issue with my environment could you please provide
some additional information about your OS and architecture? 
Also I would like to know if you use libjpeg-turbo that was built from sources
or precompiled library. 

I believe that it is not a bug in OpenMotif code. My opinion is based on the
testing results on Fedora 13 and 14 with libjpeg-turbo provided by Fedora
updates and the latest 1.1.90 precompiled libjpeg-turbo for this platform. 

But for now I can tell you that your first fix couldn't be accepted. Assuming
that all Jpeg errors but not only the error with wrong image type should lead to
loading Png image as a result would cause unnecessary libpng calls in the case
of failed or corrupted Jpeg images. Also I am not sure about your solution with
the file extension checking. It is not the safest way to find out the image type
the better way is to check header of the file like it does now. It is fast and
safe. 

Also I would like to add that strict compatibility options for libjpeg-turbo
should be used if you try to use OpenMotif that was built with the libjpeg but
used with libjpeg-turbo. You can try to rebuild OpenMotif with the libjpeg-turbo
headers and I suppose it will not cause any issues since they are API compatible.



------- Additional Comments From arahne@arahne.si 2011-11-09 18:12 -------
I am using OpenSUSE 10.3 32 bit, gcc 4.2.1 and icc 12.0.4
I have compiled both OpenMotif and libjpeg-turbo from source, since the provided
rpms either don't exist or are out of date.
I need to use relatively old Linux to keep binary compatibility with my customers.
I have used default build instructions without any modifications, for both
libraries (autoconf.sh / configure, make).
I think many Linux distributions use defaults for compilation, and fail to do
any real cross dependency checking (like compilation of one library breaking
functions in other library or programs). Most of that is left for the user to
discover.

As for the suggested filename suffix heuristics, it should be used for default
loader, and if that fails, the current trial and error file header loading
should be used. Current solution may be fast for a couple of images, but not for
thousands. But if you don't like the idea, I am fine with that.


------- Additional Comments From Oleksiy Chernyavskyy 2011-11-28 03:39 -------
Please try to configure libjpeg-turbo with 'configure --without-arith-enc
--without-arith-dec'.

According to developer from libjpeg-turbo:
"... to achieve full ABI compatibility with jpeg-6b, you have to build without
arithmetic coding support (configure --without-arith-enc --without-arith-dec on
Unix systems.)
"
see http://sourceforge.net/projects/libjpeg-turbo/forums/forum/1086868/topic/4552848


Update this bug

Submit a Patch for this bug

Note: All patches are submitted under the MIT License.