Bug#718604: libjpeg-progs: djpeg broken for some jpegs
On Sat, Aug 03, 2013 at 12:48:24AM +, Alan Curry wrote: Package: libjpeg-progs Version: 8d-1 Severity: normal Tags: patch upstream This report will mostly be a duplicate of #74087, closed almost 13 years ago, without any explanation that I can find in the bug log, and without actually fixing it as far as I can tell from the packages from that era on archive.debian.org. The problem now is as it was then: djpeg can't handle all jpegs. The ones it doesn't handle are the ones encoded as YCCK or CMYK. The bug log for #74087 doesn't mention YCCK or CMYK, so it's possible that the problem just wasn't understood back then. But the sample included in the original bug report is a YCCK jpeg. Yes this is my fault. I closed it because it was not Debian specific in anyway, so I assumed the JPEG image was invalid. This time, there's a patch. The patch has been seen before too, in a slightly different form, targeted at libjpeg-turbo. It adds a couple of conversion functions to the library, allowing clients like djpeg to get RGB output regardless of the input. http://sourceforge.net/p/libjpeg-turbo/patches/15/ It was rejected there, but I hope history won't repeat itself here. It makes no sense that djpeg (the Decode JPEG program from the de facto JPEG reference implementation!) can't decode all jpegs. The people in the libjpeg-turbo discussion didn't even seem to realize they were deciding to keep their version of djpeg crippled forever. The conversion code could be moved into djpeg, leaving the library untouched, but djpeg isn't the only place something like this is needed. I'd also like to see xli not choke on these jpegs. If the conversion is supported by the library, then adding YCCK-jpeg support to djpeg and xli is a 3-line patch for each program. If the conversion function is banned from the library like the libjpeg-turbo people seem to want, xli and djpeg both need the same big mess of pixel-shuffling code inserted into them, and so will the next program. That's just a stupid way to do it. Dear Alan, I have forwarded your bug report to the upstream maintainer. Thanks for taking the time to work on this. However, I have a question: how do you generate such JPEG images ? Would there be benefit for libjpeg to be able to do that ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Bill I received the following bug report, and I very much appreciated your opinion about it. http://bugs.debian.org/718604 I'm very thankful that this subject is brought up now, because there have been clarifications in the color support department in recent IJG JPEG development, and I'll use the chance here to report about them. First, djpeg handles INTERCHANGE JPEG streams, it does not claim to support anything else! The term JPEG FILE INTERCHANGE FORMAT (JFIF) primarily refers to the range of supported color space encodings, and it will be redefined by IJG in the upcoming IJG JPEG 9a release, see http://www.infai.org/jpeg/ This is the major new feature of that new libjpeg version! (Interestingly, http://www.w3.org/Graphics/JPEG/ claims that JFIF was invented by IJG anyway, although http://www.jpeg.org/jpeg/ tells a bit different...) The YCCK/CMYK color space encodings are actually NOT part of JFIF! The new redefined JFIF version 2 refers ONLY to the IEC 61966-2-1 (aka sRGB) standard which contains unambiguous definitions for various RGB and YCC color space encodings, which are therefore suitable for common image interchange and which are therefore all supported by libjpeg 9a. See the new jccolor.c/jdcolor.c modules in new version as given above (and cjpeg got a corresponding new -bgycc switch, see also usage.txt for description). Note that this version is the first REAL SOURCE code regarding this subject, because it contains exact mathematical derivations for the conversions, which are lacking in prior versions and in all other so-called source codes! It is interesting that with this approach we can support ALL color with ANY gamut without going into complicated color management issues! We want to do IMAGE CODING and COMMON INTERCHANGE here, not device-specific COLOR MANAGEMENT! The IEC 61966-2-1 standard allows us to separate these different issues, so that we can constrain our attention on image coding and interchange, and not need to open up Pandora's box with all kinds of issues regarding color management functions. These are different subjects. The YCCK/CMYK color spaces, while NOT part of the current JFIF, are supported to SOME EXTENT by the JPEG library. A full support would need to include some sort of color management functions (see later), and we actually don't want to do that here. So what we actually do is to provide a PARTIAL support for YCCK/CMYK handling, as far as it fits in our constraints, and leave the other part to do for the application interface. This works well if you understand this division of labor. I have done this in the Jpegcrop sample application, see: http://jpegclub.org/jpegcrop.txt Release history === 2013.07: - IJG JPEG 9a develop version code base. 2013.06: - Add approximate CMYK/YCCK display support. Note here that it says APPROXIMATE support! It uses a code for the conversion which is similar to your suggested patch version, find it here in the application interface modules for the JPEG library in the Jpegcrop source packages as given on page http://jpegclub.org/jpegtran/ (file jpegdib.cpp in the Windows version, file jpegimage.cpp in the Unix version). Note that this code is only a simplified version for approximate support, it does not give you the true results, and that is the reason why we must not include it in the reference libjpeg! I will give you a nice example in next message. You will notice that the approximated display shows quite oversaturated colors. This may be acceptable for fast image viewing and for tools like Jpegcrop where the display has only secondary function for operation, but it is not the true thing. I assume that for true conversion at least the 'K' channel has to undergo a special transfer function, similar to an 'A' channel in alpha modes, and this is best handled in a dedicated color management framework, or a display system which supports dedicated CMYK pixel maps (see later). Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Bill
Here is the example:
http://www.berlininart.com/timeless-beauty-at-co-berlin/
(Teen Vogue - preview above, full image below - this falls under art...)
http://www.berlininart.com/wp-content/uploads/2012/08/1330_Kim.jpg
You can download and open the full image with Jpegcrop and
see the approximate display.
Other viewers like XnView or FastStone give similar results
(on Windows, also using IJG library).
But with IrfanView and the Windows integrated Image Preview
component the colors appear more correct.
These tools apparently use a special CMYK bitmap mode in the
Windows display system which runs over kindof color management.
I have found that apparently the newer Windows graphics display
interfaces GDI-Plus or WPF have such mode, and I plan to
investigate that further and also include such option later
in Jpegcrop to get more clarity in this regard.
Interesting:
If I load the image with IrfanView under Windows 98 (good to
have such oldies available for such kind of tests), IrfanView
also does only the approximate (oversaturated) display, because
the system function is apparently not yet available on this system.
Also interesting:
If I convert the image to arithmetic coding (with new Jpegcrop
now possible), IrfanView can no longer display the image.
That means that IrfanView apparently lets Windows do the complete
decode in CMYK/YCCK case, which doesn't support arithmetic coding
yet (IrfanView otherwise does).
Here I would try to make it better than IrfanView by letting the
system only convert the bitmap received from own codec from CMYK
to RGB.
Note that all this consideration does not affect the core codec
(library): The core codec only receives or supplies the CMYK/YCCK
data and at most performs the YCCK-CMYK conversion, where the
'K' value is passed through unchanged, while everything else
(conversion to RGB) is left to the application.
The supported color spaces in libjpeg are now (jpeglib.h):
/* Known color spaces. */
typedef enum {
JCS_UNKNOWN,/* error/unspecified */
JCS_GRAYSCALE, /* monochrome */
JCS_RGB,/* red/green/blue, standard RGB (sRGB) */
JCS_YCbCr, /* Y/Cb/Cr (also known as YUV), standard YCC */
JCS_CMYK, /* C/M/Y/K */
JCS_YCCK, /* Y/Cb/Cr/K */
JCS_BG_RGB, /* big gamut red/green/blue, bg-sRGB */
JCS_BG_YCC /* big gamut Y/Cb/Cr, bg-sYCC */
} J_COLOR_SPACE;
Note that the BG_RGB mode is defined in IEC 61966-2-1 only for 10
or more bits sample precision. It can be easily extended for 9
bits precision (and we allow that), but not easily for 8 bits (so
we don't allow that), that's why it is actually not useful in the
8 bits implementation.
However, the BG_YCC mode CAN be used easily also with 8 bits
precision (although it is also formally defined in IEC 61966-2-1
only for 10 or more bits), while retaining the full luminance
precision and reducing only the color components, which can be
partially compensated by adapted quantization in the JPEG context!
That's why I have introduced the cjpeg -bgycc switch, for
demonstration that there is now an opportunity to exchange wide
gamut color images in standard JPEG file interchange format (will
be automatically clipped for normal RGB output, see jdcolor.c).
Note that you cannot actually generate wide gamut colors by this
option with cjpeg, because cjpeg actually supports only normal RGB
input - it just generates a wide gamut capable encoding format.
But an appropriate application can feed wide gamut colors directly
to the library in this way.
The IEC 61966-2-1 standard is not freely available, but you can
find an identical British Standard version (including the
important amendment) to read online (not possible to save
or print):
http://www.doc88.com/p-694270296039.html
Regards
Guido
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Bill Here you can see a correct rendering of the image (re-encoded in JFIF): http://www.zeit.de/lebensart/mode/2012-08/fs-zeitlos-schoen-2/seite-9 Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Guido Vollbeding gu...@jpegclub.org writes: The term JPEG FILE INTERCHANGE FORMAT (JFIF) primarily refers to the range of supported color space encodings, and it will be redefined by IJG in the upcoming IJG JPEG 9a release, see Just for the record, JFIF was not invented by IJG, and I don't believe that you get to redefine it. The original spec is perfectly clear that there is exactly one color space allowed in JFIF files. (Well, two if you count greyscale.) If you try to extend this you'll just end up creating incompatibilities with non-IJG implementations. In general, I'm quite disturbed that you seem to be willing to introduce file format incompatibilities with other implementations (and with older copies of the IJG code for that matter). This flies in the face of what IJG was founded to accomplish, namely promote universal compatibility of JPEG files. I took a quick look at the referenced Debian bug, and I'm in agreement with the this is not a bug position. Although the complainant is of the opinion that djpeg should be able to read any JPEG file, that's utter nonsense. It has never been intended to deal with CMYK data. The proposed patch involving somebody's hack-and-slash conversion to RGB just betrays complete ignorance of what CMYK is used for in the real world. (I will note that I rejected similar patches back when I was actively maintaining libjpeg.) In practice, if you want to deal with CMYK, you really need a file format like TIFF that is able to carry the necessary auxiliary info about which CMYK inks are meant. JFIF can't do this, and that's fine --- it was never meant to be all things to all people. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: libjpeg-progs: djpeg broken for some jpegs
Bill Allombert wrote: Dear Alan, I have forwarded your bug report to the upstream maintainer. Thanks for taking the time to work on this. However, I have a question: how do you generate such JPEG images ? Would there be benefit for libjpeg to be able to do that ? I gather from the archived libjpeg-turbo discussion that this weird kind of jpeg is generated by Photoshop when certain options are enabled. I don't know the motivation for creating them that way. I only wish I could take arbitrary jpegs from the wild and feed them to a shell script based on djpeg, without having the occasional failure because one of these YCCK images showed up. The second issue is that I'd also like to be able to run xli *.jpg in a directory full of images-not-made-by-me, and not see any failures. That means conversion needs to be done in xli or in the library. With the patched version of the library, I already have xli working (by adding 3 extra lines to request RGB output from the library). Without the patched library, it would be harder. I can appreciate that the YCCK/CMYK formats are non-standard hacks forced upon us by Adobe, and it's not pleasant to admit we need to support them. But the free software community in general has not rejected them. They can be converted by imagemagick, displayed by mozilla, and edited by gimp. The only places where YCCK/CMYK support is missing is in the small and fast alternatives to those programs. I want to fix that. If we're stuck with a djpeg that refuses to decode images with proprietary extensions, not because the extensions aren't understood but because the maintainer objects to the existence of the extensions, then djpeg has become more of a political object than a useful scripting tool. After testing this patch, I became aware of jpegtopnm in the netpbm package, which already handles YCCK. The easy way around this problem will be to just s/djpeg/jpegtopnm/g in all my scripts and apt-get remove libjpeg-progs. But that leaves the followup issue, lack of xli support, unsolved. I'd then have to port this patch (which inside libjpeg is *already working*) to xli. And then xloadimage. And how about xpaint? Making each one of them contain a duplicate of the conversion code would be ridiculous! -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Tom Lane wrote: I took a quick look at the referenced Debian bug, and I'm in agreement with the this is not a bug position. Although the complainant is of the opinion that djpeg should be able to read any JPEG file, that's utter nonsense. It has never been intended to deal with CMYK data. The proposed patch involving somebody's hack-and-slash conversion to RGB just betrays complete ignorance of what CMYK is used for in the real world. (I will note that I rejected similar patches back when Here's what happens in the real world: on rare occasions, I encounter jpeg files that I can't view because someone has put YCCK/CMYK in them. I present you with a simplified version of the problem: forget djpeg; ln -sf jpegtopnm /usr/bin/djpeg solved that. Now the only remaining problem is that xli *.jpg randomly fails on a small percentage of jpegs found in the wild. What's the correct solution to that? xli is not going to have any information about the image except what it gets from libjpeg. What should it display when libjpeg gives it CMYK output? If I take the conversion formula from this proposed patch and put it into xli instead, I'll have something satisfactory for the immediate purpose. But putting the code in the library gives other programs the opportunity to reuse it, and gives me identical results. How is that bad? If the formula itself is bad, where's the correct one? What formula would you use to display an image in a viewer that is dependent on libjpeg for all of its information about the image, in the case that libjpeg produces CMYK output? -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Tom Just for the record, JFIF was not invented by IJG, and I don't believe that you get to redefine it. The original spec is perfectly clear that there is exactly one color space allowed in JFIF files. (Well, two if you count greyscale.) Oh, maybe my words were capable of being misunderstood: With redefine I mean EXTEND JFIF, and that is perfectly OK. Previously we had JFIF version 1, and now we have JFIF version 2. Just an advancement. If you try to extend this you'll just end up creating incompatibilities with non-IJG implementations. In general, I'm quite disturbed that you seem to be willing to introduce file format incompatibilities with other implementations (and with older copies of the IJG code for that matter). This flies in the face of what IJG was founded to accomplish, namely promote universal compatibility of JPEG files. You are probably missing the fact that IJG is now responsible for further development of the whole still image technology, and that the prior standardization bodies for JPEG have been legally and lawfully foreclosed. Read the section FILE FORMAT WARS in the README file of current libjpeg version at http://www.infai.org/jpeg/ That means that IJG reference code is now normative, and we develop a single universal still image interchange file format called JPEG instead of a mess of incompatible botch which existed before. We are now at generation 9. Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
On Sat, 3 Aug 2013, Alan Curry wrote: If the formula itself is bad, where's the correct one? What formula would you use to display an image in a viewer that is dependent on libjpeg for all of its information about the image, in the case that libjpeg produces CMYK output? By definition, there is no one correct formula. The approach which works is to attach an ICC color profile to the JPEG which describes its colorspace. Then the viewer uses an ICC color profile describing its own colorspace to transform from the origin colorspace to the viewing colorspace. These transforms may be accomplished via the MIT/X11-licensed lcms library. If the colorspace enumeration is for a colorspace which has a precise definition (e.g. sRGB), then that can be used to select a locally-stored ICC profile (or hard-coded transform) so that the client can view it correctly. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Alan xli is not going to have any information about the image except what it gets from libjpeg. What should it display when libjpeg gives it CMYK output? If I take the conversion formula from this proposed patch and put it into xli instead, I'll have something satisfactory for the immediate purpose. But putting the code in the library gives other programs the opportunity to reuse it, and gives me identical results. How is that bad? If the formula itself is bad, where's the correct one? What formula would you use to display an image in a viewer that is dependent on libjpeg for all of its information about the image, in the case that libjpeg produces CMYK output? You simply have to accept the fact that CMYK is not JFIF, so you can't use it for common image interchange, because there is no standard comparable to IEC 61966-2-1 for it! I have elaborated why we can't use the given approximate formula in libjpeg reference code. The problem can only be handled in an appropriate color management framework, which is system/application dependent and is not aspect of a core image codec library like libjpeg. If somebody wants to make CMYK interchangeable, than he has to invest an effort to define something like IEC 61966-2-1, again see here: http://www.doc88.com/p-694270296039.html Obviously nobody has done this so far for CMYK, so there is no solution for handling CMYK in an image codec like libjpeg other than given. We are IJG, and we don't participate in botch and mess production, sorry. There is enough such stuff already. We aim for clarity. Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Bob Friesenhahn wrote: On Sat, 3 Aug 2013, Alan Curry wrote: If the formula itself is bad, where's the correct one? What formula would you use to display an image in a viewer that is dependent on libjpeg for all of its information about the image, in the case that libjpeg produces CMYK output? By definition, there is no one correct formula. The approach which works is to attach an ICC color profile to the JPEG which describes its colorspace. Then the viewer uses an ICC color profile describing its own colorspace to transform from the origin colorspace to the viewing colorspace. These transforms may be accomplished via the MIT/X11-licensed lcms library. You lose me already at attach an ICC color profile. How does the image viewer, relying on libjpeg to parse the file, find this attached information? The words attach, ICC, and profile do not appear in libjpeg.txt so I don't know how a client of the library is supposed to access this metadata. But I get the general outline: The function that maps input pixel values to RGB is defined by some metadata in the jpeg which I don't know how to find. Once I find it, I will pass it to liblcms for interpretation. -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
On Sat, 3 Aug 2013, Alan Curry wrote: You lose me already at attach an ICC color profile. How does the image viewer, relying on libjpeg to parse the file, find this attached information? The words attach, ICC, and profile do not appear in libjpeg.txt so I don't know how a client of the library is supposed to access this metadata. You need to learn about how to do this other than via this private discussion. It seems to be handled by storing a JPEG chunk with the computed ID JPEG_APP0+2. Suffice it to say that Photoshop and other software which cares (e.g. ImageMagick GraphicsMagick) has been doing this stuff for many years. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Bob Friesenhahn wrote: You need to learn about how to do this other than via this private discussion. It seems to be handled by storing a JPEG chunk with the computed ID JPEG_APP0+2. Yes, this falls under the category which I call color management system. This is an extensive topic and it will need some time to study before you get a sufficient understanding of the subject. In any case it exceeds by far the responsibilities of a core image codec. Suffice it to say that Photoshop and other software which cares (e.g. ImageMagick GraphicsMagick) has been doing this stuff for many years. Yes, but they didn't care to provide a SIMPLE mechanism for storing wide gamut colors for common image interchange. IJG now closes this gap, that is our distinguished responsibility. Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Guido Vollbeding wrote: [ Charset ISO-8859-1 unsupported, converting... ] Bob Friesenhahn wrote: You need to learn about how to do this other than via this private discussion. It seems to be handled by storing a JPEG chunk with the computed ID JPEG_APP0+2. Yes, this falls under the category which I call color management system. This is an extensive topic and it will need some time to study before you get a sufficient understanding of the subject. In any case it exceeds by far the responsibilities of a core image codec. I thought the responsibility of libjpeg was to encode and decode jpegs. And I thought decode meant give me pixels I can push to my screen, not make me parse the file myself to find metadata chunks. Here's my growing list of programs in Debian that choke on YCCK jpegs, and need to be individually modified if the library won't help out: aaphoto djpeg xjig xli xloadimage xpaint And ones that do the wrong conversion (multiply the first 3 components by the 4th component and divide by 255): jpegtopnm zgv All would benefit if they could get RGB output from the library, without needing to know about file format internals like APP0+2 markers. -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: [rlw...@sdf.org: Bug#718604: libjpeg-progs: djpeg broken for some jpegs]
Dear Alan I thought the responsibility of libjpeg was to encode and decode jpegs. And I thought decode meant give me pixels I can push to my screen, not make me parse the file myself to find metadata chunks. Here's my growing list of programs in Debian that choke on YCCK jpegs, Well, the point here is that YCCK is created NOT for display on screen, but for print! Look at your monitor and you will notice that it doesn't have CMYK components. Look at your printer and you will notice that it doesn't have RGB components. So these are distinct output areas. The screen people were kind enough to create something like IEC 61966-2-1 (sRGB) for common image interchange, and later came an amendment for sYCC and so on (this is used in digital cameras). The print people were not kind enough to create a corresponding amendement for YCCK and so on, because they don't care for common image interchange as much as the screen and camera people do. It is simply not part of their business model, you have to understand that. So if they don't care for common image interchange, why should anybody else do their work? So either you do it yourself, or you have to accept the situation. Regards Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718604: libjpeg-progs: djpeg broken for some jpegs
Package: libjpeg-progs
Version: 8d-1
Severity: normal
Tags: patch upstream
This report will mostly be a duplicate of #74087, closed almost 13 years
ago, without any explanation that I can find in the bug log, and without
actually fixing it as far as I can tell from the packages from that era
on archive.debian.org.
The problem now is as it was then: djpeg can't handle all jpegs. The
ones it doesn't handle are the ones encoded as YCCK or CMYK. The bug log
for #74087 doesn't mention YCCK or CMYK, so it's possible that the
problem just wasn't understood back then. But the sample included in the
original bug report is a YCCK jpeg.
This time, there's a patch. The patch has been seen before too, in a
slightly different form, targeted at libjpeg-turbo. It adds a couple of
conversion functions to the library, allowing clients like djpeg to get
RGB output regardless of the input.
http://sourceforge.net/p/libjpeg-turbo/patches/15/
It was rejected there, but I hope history won't repeat itself here.
It makes no sense that djpeg (the Decode JPEG program from the de facto
JPEG reference implementation!) can't decode all jpegs. The people in
the libjpeg-turbo discussion didn't even seem to realize they were
deciding to keep their version of djpeg crippled forever.
The conversion code could be moved into djpeg, leaving the library
untouched, but djpeg isn't the only place something like this is needed.
I'd also like to see xli not choke on these jpegs.
If the conversion is supported by the library, then adding YCCK-jpeg
support to djpeg and xli is a 3-line patch for each program.
If the conversion function is banned from the library like the
libjpeg-turbo people seem to want, xli and djpeg both need the same big
mess of pixel-shuffling code inserted into them, and so will the next
program. That's just a stupid way to do it.
Index: libjpeg8-8d/jdcolor.c
===
--- libjpeg8-8d.orig/jdcolor.c 2013-08-02 18:38:50.0 -0500
+++ libjpeg8-8d/jdcolor.c 2013-08-02 18:42:18.578891259 -0500
@@ -125,6 +125,105 @@
}
}
+/*
+ * Convert inverted CMYK to RGB
+ */
+METHODDEF(void)
+cmyk_rgb_convert (j_decompress_ptr cinfo,
+JSAMPIMAGE input_buf, JDIMENSION input_row,
+JSAMPARRAY output_buf, int num_rows)
+{
+ double c, m, y, k;
+ register JSAMPROW outptr;
+ register JSAMPROW inptr0, inptr1, inptr2, inptr3;
+ register JDIMENSION col;
+
+ JDIMENSION num_cols = cinfo-output_width;
+
+ while (--num_rows = 0) {
+inptr0 = input_buf[0][input_row];
+inptr1 = input_buf[1][input_row];
+inptr2 = input_buf[2][input_row];
+inptr3 = input_buf[3][input_row];
+input_row++;
+outptr = *output_buf++;
+for (col = 0; col num_cols; col++) {
+ c = (double) GETJSAMPLE(inptr0[col]);
+ m = (double) GETJSAMPLE(inptr1[col]);
+ y = (double) GETJSAMPLE(inptr2[col]);
+ k = (double) GETJSAMPLE(inptr3[col]);
+
+outptr[RGB_RED] = (JSAMPLE)(c*k/255);
+outptr[RGB_GREEN] = (JSAMPLE)(m*k/255);
+outptr[RGB_BLUE] = (JSAMPLE)(y*k/255);
+outptr += RGB_PIXELSIZE;
+}
+ }
+}
+
+/*
+ * Convert YCCK to RGB
+ */
+METHODDEF(void)
+ycck_rgb_convert (j_decompress_ptr cinfo,
+ JSAMPIMAGE input_buf, JDIMENSION input_row,
+ JSAMPARRAY output_buf, int num_rows)
+{
+ my_cconvert_ptr cconvert = (my_cconvert_ptr) cinfo-cconvert;
+ double cyan, magenta, yellow, black;
+ register int y, cb, cr;
+ register JSAMPROW outptr;
+ register JSAMPROW inptr0, inptr1, inptr2, inptr3;
+ register JDIMENSION col;
+ JDIMENSION num_cols = cinfo-output_width;
+
+ /* copy these pointers into registers if possible */
+ register JSAMPLE * range_limit = cinfo-sample_range_limit;
+ register int * Crrtab = cconvert-Cr_r_tab;
+ register int * Cbbtab = cconvert-Cb_b_tab;
+ register INT32 * Crgtab = cconvert-Cr_g_tab;
+ register INT32 * Cbgtab = cconvert-Cb_g_tab;
+ SHIFT_TEMPS
+
+ while (--num_rows = 0) {
+inptr0 = input_buf[0][input_row];
+inptr1 = input_buf[1][input_row];
+inptr2 = input_buf[2][input_row];
+inptr3 = input_buf[3][input_row];
+input_row++;
+outptr = *output_buf++;
+for (col = 0; col num_cols; col++) {
+
+
+ /* Read YCCK Pixel **/
+ y = GETJSAMPLE(inptr0[col]);
+ cb= GETJSAMPLE(inptr1[col]);
+ cr= GETJSAMPLE(inptr2[col]);
+ black = (double)GETJSAMPLE(inptr3[col]);
+
+ /* Convert YCCK to CMYK **/
+/* Range-limiting is essential due to noise introduced by DCT losses.
*/
+ outptr[0] = range_limit[MAXJSAMPLE - (y + Crrtab[cr])];
+ outptr[1] = range_limit[MAXJSAMPLE - (y +
+ ((int) RIGHT_SHIFT(Cbgtab[cb] + Crgtab[cr],
SCALEBITS)))];
+ outptr[2] = range_limit[MAXJSAMPLE - (y + Cbbtab[cb])];
+ /* K passes through unchanged */
+ outptr[3] = inptr3[col]; /* don't need GETJSAMPLE here */
+
+
