Last Comment Bug 44781 - Support CMYK, YCCK JPEGs
: Support CMYK, YCCK JPEGs
Status: RESOLVED FIXED
[imglib] [parity-opera]
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: All All
: -- enhancement with 10 votes (vote)
: mozilla1.9beta4
Assigned To: Alfred Kayser
:
Mentors:
http://www.definethis.org/temp/bugzil...
: 78860 156310 177361 192089 203643 228960 262776 326427 338462 373356 376893 415861 (view as bug list)
Depends on: colorsync 397214 411626
Blocks: 61481 440736
  Show dependency treegraph
 
Reported: 2000-07-07 08:41 PDT by Mirek Hankus
Modified: 2008-06-20 07:08 PDT (History)
52 users (show)
dolske: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
CMYK JPEG support (4.14 KB, patch)
2001-12-16 19:44 PST, James Simonsen
pavlov: review+
Details | Diff | Splinter Review
tweak of previous patch (6.14 KB, patch)
2002-04-09 12:48 PDT, tor
no flags Details | Diff | Splinter Review
fold cut&paste image output code (7.11 KB, patch)
2002-04-09 13:12 PDT, tor
no flags Details | Diff | Splinter Review
update to tip + cleanups (9.05 KB, patch)
2002-04-17 14:49 PDT, tor
no flags Details | Diff | Splinter Review
cmyk test image (5.05 KB, image/jpeg)
2005-03-18 09:56 PST, Axel Hecht
no flags Details
updated to tip (4.49 KB, patch)
2005-03-18 10:00 PST, tor
no flags Details | Diff | Splinter Review
renders in everything but Firefox (101.12 KB, image/jpeg)
2006-06-17 14:39 PDT, skierpage
no flags Details
Updated to tip and much simpler/better conversion algorithm (7.50 KB, patch)
2008-01-25 11:33 PST, Alfred Kayser
pavlov: review+
mtschrep: approval1.9+
Details | Diff | Splinter Review
Unbitrotted and corrected bug in jdcolor.c introduced by bug 411379 (8.08 KB, patch)
2008-02-13 06:21 PST, Alfred Kayser
pavlov: review+
Details | Diff | Splinter Review

Description Mirek Hankus 2000-07-07 08:41:38 PDT
Hello !!
  There is a problem with JPEG images saved in CMYK mode. Check the above URL to
see the same image saved in RGB mode and CMYK mode. They should look
identically, but results are very ugly (try to save foto in CMYK). Images where
created using Photoshop.
Comment 1 pnunn 2000-07-07 11:13:52 PDT
This is a duplicate bug. We have not supported CMYK in the past,
but hope to in the future.

MHankus, want to volunteer to add CMYK support for jpeg?
-p
Comment 2 Mirek Hankus 2000-07-10 01:18:26 PDT
I also hoped that Mozilla will support it (i needed such feature some time ago), 
but I know that there are other things to do. Don't count on me. I'm also very 
busy, but I'm very happy to help you with testing.
Comment 3 Asa Dotzler [:asa] 2000-07-14 19:09:01 PDT
could not find the original for this bug after searching for too long.  Adding 
helpwanted keyword, updating and [RFE] to summary. (was JPEG saved in CMYK mode 
rendered incorectly)
Comment 4 pnunn 2001-03-19 14:18:12 PST
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Comment 5 Mirek Hankus 2001-04-03 12:10:04 PDT

I know that this is marked as helpwanted, but after landing of
new imagelib mozilla crashes on test url. 
Comment 6 Terri Preston 2001-04-03 13:38:27 PDT
This bug might have morphed into a new bug, it does crash on w2k build 
2001040304
Comment 7 Mirek Hankus 2001-04-04 00:15:20 PDT
  I've sent information about this crash via talkback with id TB28646880W. 
Shoul'd i report this crash as a new bug ????? 
Comment 8 James Simonsen 2001-12-16 19:44:57 PST
Created attachment 61914 [details] [diff] [review]
CMYK JPEG support

Adds support for CMYK JPEGs. The K conversion is slow, but accurate.

Tested on Linux-i386.
Comment 9 Christian :Biesinger (don't email me, ping me on IRC) 2002-04-09 06:25:57 PDT
pavlov: we've got this patch here for the last 4 months... could you maybe
review it?
Comment 10 Stuart Parmenter 2002-04-09 11:00:23 PDT
Comment on attachment 61914 [details] [diff] [review]
CMYK JPEG support

r=pavlov
Comment 11 tor 2002-04-09 12:48:59 PDT
Created attachment 78385 [details] [diff] [review]
tweak of previous patch

Updated version makes the formatting match the existing code, removes
some redundant logic, and tells libjpeg to take care of grayscale->rgb
and YCbCr->RGB conversions.

One thing I'm unsure about my change to make libjpeg convert YCCK to 
CMYK and dumping the result through James' YCCK code.  Works fine on 
the test url, but it seems somewhat sketchy.
Comment 12 tor 2002-04-09 13:12:47 PDT
Created attachment 78389 [details] [diff] [review]
fold cut&paste image output code
Comment 13 tor 2002-04-14 11:06:17 PDT
Taking bug...
Comment 14 tor 2002-04-16 05:46:54 PDT
*** Bug 78860 has been marked as a duplicate of this bug. ***
Comment 15 tor 2002-04-17 14:49:57 PDT
Created attachment 79692 [details] [diff] [review]
update to tip + cleanups
Comment 16 Damian Yerrick 2002-06-06 02:23:07 PDT
Don't Adobe and Pantone have patents on any form of CMYK support?
Comment 17 tor 2002-06-06 11:16:36 PDT
As far as I know the patents are on RGB->CMYK seperation (the hard bit).
Comment 18 Matthias Versen [:Matti] 2002-07-09 16:58:25 PDT
*** Bug 156310 has been marked as a duplicate of this bug. ***
Comment 19 Christian :Biesinger (don't email me, ping me on IRC) 2002-09-26 06:00:06 PDT
tor: what's the status of this patch?
Comment 20 tor 2002-09-26 11:08:57 PDT
biesi: bit-rotted, plus waiting for the original author to look at the question
in comment 11 (or me to find my copy of Foley, van Dam, et. al.).
Comment 21 ekanter 2002-09-26 12:54:27 PDT
Does the image http://extraserv.softpress.kiev.ua/~eismont/Bublik_10_2002.jpg
fall into the same category?
Comment 22 ghosh 2002-09-26 23:59:17 PDT
It'd be *very* cool if CMYK jpeg's would not be converted again
back from RGB on printing but use the original CMYK data.
I'm only dreaming... ;-)
Comment 23 Brant Gurganus 2002-10-13 11:28:23 PDT
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Comment 24 tor 2002-11-07 11:00:53 PST
*** Bug 177361 has been marked as a duplicate of this bug. ***
Comment 25 Manko 2002-11-21 05:59:56 PST
BTW, Opera does have CMYK images support since version 6.
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2003-02-05 22:38:36 PST
*** Bug 192089 has been marked as a duplicate of this bug. ***
Comment 27 Stefan Borggraefe 2003-04-28 05:43:57 PDT
*** Bug 203643 has been marked as a duplicate of this bug. ***
Comment 28 Damian Yerrick 2003-06-16 15:45:28 PDT
Would it even be lawful?  Aren't the usable color-space conversion
algorithms patented in many jurisdictions including the United States
and unavailable for licensing in open-source software?
Comment 29 Aaron Kaluszka 2003-06-16 16:34:00 PDT
Gimp 2.0 is supposed to have CMYK support.
Comment 30 Chris Bolt 2003-06-16 16:58:38 PDT
http://www.littlecms.com/faq.htm might also be useful
Comment 31 Craig Ringer 2003-08-24 23:55:05 PDT
As a quicker+easier alternative to giving Mozilla built-in CMYK JPEG support,
perhaps it might be an idea to simply recognise CMYK JPEGs and hand them off to
a proper graphics program (Photoshop, GIMP, etc). Currently, Mozilla reports
that the image is damaged, and the user must save it then open it in another
program to view the image.

Working in pre-press, I get this /a lot/.
Comment 32 Christian :Biesinger (don't email me, ping me on IRC) 2003-08-25 04:47:42 PDT
>perhaps it might be an idea to simply recognise CMYK JPEGs and hand them off to
>a proper graphics program (Photoshop, GIMP, etc).

that seems rather difficult to do.
Comment 33 Craig Cockburn 2004-09-16 03:06:50 PDT
Any prospect of headway on this? We receive images in CMYK format and it is a
major people for people not to use Mozilla/Firefox if they are unable to view them.
Comment 34 Craig Cockburn 2004-09-16 03:10:50 PDT
Any prospect of headway on this? We receive images in CMYK format and it is a
major reason for people not to use Mozilla/Firefox if they are unable to view them.
Comment 35 jdavidb-mozilla 2004-11-29 18:37:36 PST
There was a patch for this four years ago which never got integrated.  I'm
certain it doesn't work now, but maybe someone can do the fix again and get it
included this time?  Is there any chance this feature could be tied to a future
release rather than just "future"?
Comment 36 jdavidb-mozilla 2004-11-29 18:42:25 PST
When trying to view an HTML page containing one of these images, the user simply
sees the broken image icon.  When trying to view such an image directly,
however, the user receives this message: 'The image
“http://www.ce3.pl/~mhankus/moz/cmyk.jpg” cannot be displayed, because it
contains errors.'

This message is not accurate.  Such images do not contain errors; they make use
of a feature which Mozilla does not yet support.  In the interim before the bug
is fixed, perhaps the message could be updated for accuracy to say, 'The image
“http://www.ce3.pl/~mhankus/moz/cmyk.jpg” cannot be displayed, because it is in
CMYK format, which is not yet supported by Mozilla.'  In fact, maybe the error
message could include a link to this bug with the statement, "If you feel that
displaying images of this format is important, please express this by voting for
bug #44781."
Comment 37 Aaron Kaluszka 2004-11-29 20:53:40 PST
The way the image error messages are currently displayed is through a hack (see
bug 177747).  Bug 216538 would have to be fixed first in order to do what you
propose.
Comment 38 Axel Hecht 2005-03-18 09:33:20 PST
Awards artwork is coming in in CMYK, which is ok. But it's sad that Firefox
can't look at it. Confusing to me, at least.
Konquerer is not erroring, but is getting the colors plain wrong.
Comment 39 Axel Hecht 2005-03-18 09:56:22 PST
Created attachment 177889 [details]
cmyk test image

Here is a little test image I created with gimp and converted with imagemagick.

Broken in mozilla, imagemagick display works, wrong colors in kde.
Comment 40 tor 2005-03-18 10:00:26 PST
Created attachment 177891 [details] [diff] [review]
updated to tip
Comment 41 u88484 2005-04-19 08:34:20 PDT
*** Bug 262776 has been marked as a duplicate of this bug. ***
Comment 42 cignangulo 2006-02-08 12:13:16 PST
*** Bug 326427 has been marked as a duplicate of this bug. ***
Comment 43 Mike Cowperthwaite 2006-06-10 10:53:35 PDT
*** Bug 338462 has been marked as a duplicate of this bug. ***
Comment 44 Mike Cowperthwaite 2006-06-10 10:57:03 PDT
*** Bug 228960 has been marked as a duplicate of this bug. ***
Comment 45 Mike Cowperthwaite 2006-06-10 11:02:43 PDT
Looking at the test images from the duplicates, IE6 does not display any of 
them correctly.  Opera 8.5 displays this one OK, but not the others:
  http://www.coop99.at/darwins-nightmare/darwin/press/darwin_03.jpg [4MB]
Comment 46 Olivier Vit (just a reporter) 2006-06-10 23:04:22 PDT
Having a better message than "the image cannot be displayed because it contains errors", 
like "This software cannot display JPEG images using the CMYK color encoding" would be much more helpful to end users, and would already help a lot !
Comment 47 skierpage 2006-06-17 14:37:48 PDT
I ran into what I think is this bug, I will attach the problem JPG I received.  It fails to render in latest Minefield and in an early Deerpark with "The image “file:///C:/blahblah/Firefox_problem.jpg” cannot be displayed, because it contains errors."

This JPEG renders fine in Windows XP SP2 Paint, Windows Picture & Fax Viewer, Media Player Classic, and ImageMagick Display.  The only program besides Firefox/Thunderbird that fails to render it is Jpegcrop, which displays the alert "We do not support non-RGB color spaces".  The image file contains the string "File written by Adobe Photoshop¨ 5.0".
Comment 48 skierpage 2006-06-17 14:39:08 PDT
Created attachment 226016 [details]
renders in everything but Firefox
Comment 49 Hermann Schwab 2007-01-31 20:06:54 PST
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.2pre) Gecko/20070131 SeaMonkey/1.1

http://www.wma.com/christie_brinkley/imgs/christie_brinkley_1.jpg
Seamonkey is showing an Alternate Text:
The image “http://www.wma.com/christie_brinkley/imgs/christie_brinkley_1.jpg” cannot be displayed, because it contains errors.

IrfanView renders a local copy, Image Information shows Compression:JPEG, CMYK
Comment 50 Marco Perez 2007-03-09 10:46:23 PST
*** Bug 373356 has been marked as a duplicate of this bug. ***
Comment 51 Jeremy Baron 2007-04-09 12:44:31 PDT
*** Bug 376893 has been marked as a duplicate of this bug. ***
Comment 52 tor 2007-04-09 12:47:45 PDT
Bug 16769 will fix this as a side effect.

Comment 53 Alfred Kayser 2007-08-13 13:05:36 PDT
Note, bug 16769 did not fix all the CMYK, but only when CMS transformation is enabled, so it seems that this patch is valid (except for some minor bitrot...)
Comment 54 Tom Parker 2007-12-07 02:13:40 PST
Ping! Any progress on this one? Can the patch be applied?
Comment 55 Marius Hudea 2008-01-25 02:05:41 PST
http://www.definethis.org/temp/bugzilla/132_cmyk.jpg 

Picture above won't open in Firefox.

This is a pretty old feature request...I mean... it's 8 years old... is it that hard to be implemented?
Comment 56 Alfred Kayser 2008-01-25 02:46:36 PST
Let me take this up. I will 'unbitrot' the existing patch.
Comment 57 Alfred Kayser 2008-01-25 05:39:11 PST
And the conversion as given in the patch doesn't seem to be correct.

The conversion should be from CMYK to CMY and then from CMY to RGB:
// See: http://www.easyrgb.com/math.php?MATH=M12#text12
// Or:  http://www.ilkeratalay.com/colorspacesfaq.php#rgb
//Where CMYK and CMY values = 0 ÷ 1

C = ( C * ( 1 - K ) + K )
M = ( M * ( 1 - K ) + K )
Y = ( Y * ( 1 - K ) + K )

//CMY values = 0 ÷ 1
//RGB values = 0 ÷ 255

R = ( 1 - C ) * 255
G = ( 1 - M ) * 255
B = ( 1 - Y ) * 255
Comment 58 Craig Ringer 2008-01-25 05:46:58 PST
There is no such thing is a "correct" CMYK -> RGB conversion without real colour management. Even then there's not really any one correct conversion, but we make the the colour engine's problem.

Simple transforms like the above are absolutely awful, much worse than blindly assuming a SWOP or Euroscale source and sRGB destination and using a colour management library. Worse again than using the embedded profile in the source JPEG and the destination monitor profile.

Firefox 3.x has just added colour management support. Depending on how intrusive the changes are, it might be worth yanking out of the firefox tree and introducing into Tbird as well. That'd provide a dramatically better solution to handling CMYK JPEGs and improve display overall.
Comment 59 Alfred Kayser 2008-01-25 11:33:59 PST
Created attachment 299249 [details] [diff] [review]
Updated to tip and much simpler/better conversion algorithm

This patch seems to display correctly all kinds of CMYK based jpeg images that I could find. 

The conversion is based on the following principles:
CMYK conversion to CMY by 'adding' the Key=black to CMY, and then from CMY to RGB. However CMYK in jpeg's is really inverted CMYK (normally 0 is no ink, 1 is maximum ink, but in the jpeg it is the other way round). So the conversion needs to convert from Inverted CMYK to CMYK, from CMYK to CMY and then from CMY to RGB. See the formulas in the comments. Basing all calculations on value range from 0..255, we can then do all maths using integers.

For real color conversion one needs to enable CMS, but this conversion is without CMS, and good enough for simple display purposes.

At least, Firefox (and other Gecko based apps) can now display CMYK jpeg's even with CMS disabled (which is the default).
Comment 60 AndrewM 2008-01-25 12:37:32 PST
The URL no longer seems to be valid.
Comment 61 Mike Cowperthwaite 2008-01-27 16:28:07 PST
(In reply to comment #60)
> The URL no longer seems to be valid.

You mean the one in the URL field in bug headers, right?  You're not commenting on the patch?

The URL from comment 55 is valid, so I'll update with that.  It doesn't display correctly in IE6 or Opera 9, either, but Opera at least tries to decode it into a canvas.  Does IE7 handle it?
Comment 62 AndrewM 2008-01-27 16:47:46 PST
(In reply to comment #61)
> (In reply to comment #60)
> > The URL no longer seems to be valid.
> 
> You mean the one in the URL field in bug headers, right?  You're not commenting
> on the patch?

Sorry, I should have been clearer; yes I meant the one in the URL field.

> The URL from comment 55 is valid, so I'll update with that.  It doesn't display
> correctly in IE6 or Opera 9, either, but Opera at least tries to decode it into
> a canvas.  Does IE7 handle it?

I just get the broken image icon in IE7.
Comment 63 Mike Schroepfer 2008-02-12 12:47:02 PST
Will we get this into the testsuite?  Does this impact perf at all?
Comment 64 Alfred Kayser 2008-02-12 13:37:43 PST
It won't impact any images that are not CMYK (except for the 'if (mInfo.out_color_space == JCS_CMYK) {' statement).
Only CMYK require an extra conversion from CMYK to RGB, after which the normal path of optionally applying CMS transformation follows.

As for test-suite, I have a small collection of CMYK images that could be used for that, mail me for that.

And Safari does display some image for the URL above, but the colors are wrong (inverted!)
Comment 65 Mike Schroepfer 2008-02-12 14:19:44 PST
Comment on attachment 299249 [details] [diff] [review]
Updated to tip and much simpler/better conversion algorithm

a+ if you can work with Dolske to get the images in the testsuite
Comment 66 Reed Loden [:reed] (use needinfo?) 2008-02-13 02:35:58 PST
Alfred, please attach an unbitrotten version of the patch for check-in.
Comment 67 Alfred Kayser 2008-02-13 06:21:39 PST
Created attachment 303027 [details] [diff] [review]
Unbitrotted and corrected bug in jdcolor.c introduced by bug 411379

Bug 411379 introduced a nasty bug in ycck_cmyk_convert:
   range_limit[MAXJSAMPLE - (y + Crrtab[cr])];
was replaced by:
   range_limit_y + Crrtab[cr];
This gives at least compile warnings, but more seriously the minus before the ( of (y+Crrtab... was not applied anymore.

So, I reversed this little bit optimization, as it is not valid.
Comment 68 Reed Loden [:reed] (use needinfo?) 2008-02-14 03:07:05 PST
Comment on attachment 303027 [details] [diff] [review]
Unbitrotted and corrected bug in jdcolor.c introduced by bug 411379

stuart, r= the jdcolor.c changes, please?
Comment 69 Reed Loden [:reed] (use needinfo?) 2008-02-14 12:39:32 PST
Checking in modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp;
/cvsroot/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp,v  <--  nsJPEGDecoder.cpp
new revision: 1.92; previous revision: 1.91
done
Checking in jpeg/jdcolor.c;
/cvsroot/mozilla/jpeg/jdcolor.c,v  <--  jdcolor.c
new revision: 3.5; previous revision: 3.4
done

Alfred, can you put your collection of images up somewhere so dolske can add them to the test suite?
Comment 70 Justin Dolske [:Dolske] 2008-02-14 21:34:48 PST
(In reply to comment #64)
> And Safari does display some image for the URL above, but the colors are wrong
> (inverted!)

Just for future reference (ie, when people file bugs saying we're broken!), I checked the CMYK image in attachment 177889 [details] in some different places.

On OS X 10.5, Safari, the Finder, and Preview all display the image with a black background. Interestingly, the text is shown in RGB ("cyan" is red, "magenta" is green, and "yellow" is blue), so that sure looks like a problem with OS X.

In Photoshop for Windows, the image has a white background and the text colors are correct. Gimp, Eye of Gnome, and Nautilus on my Solaris box also display it that way. IE 7 can't display the image, but the default "Windows Picture and Fax Viewer" will (with a white background and correct text colors).
Comment 71 Alfred Kayser 2008-02-18 03:48:10 PST
These are the images that I tested the CMYK/YCCK color decoding with:
CMYK coded jpeg's at: http://www.geocities.com/alfredkayser/jpeg/cmyk/
YCCK coded jpeg's at: http://www.geocities.com/alfredkayser/jpeg/ycck/
Comment 72 jag (Peter Annema) 2008-02-18 07:14:09 PST
+      outptr[0] = range_limit[MAXJSAMPLE - (y + Cr_r_tab[cr])];   /* red */
+      outptr[1] = range_limit[MAXJSAMPLE - (y +                   /* green */
+				  ((int) RIGHT_SHIFT(Cb_g_tab[cb] + Cr_g_tab[cr],
+                         SCALEBITS)))];
+      outptr[2] = range_limit[MAXJSAMPLE - (y + Cb_b_tab[cb])];   /* blue */

Wouldn't it be faster to do |range_limit + MAXJSAMPLE - y| once and subtract the variable parts from that? I believe that's what the original code meant to do but it added instead of subtracting.
Comment 73 Alfred Kayser 2008-02-18 07:56:37 PST
Yes, but I tried to keep it simple and revert to the original code for this piece, as the previous attempt to optimize this part failed.

And, CMYK/YCCK images are very, very rare (and IE7 can't do them...)
Comment 74 Justin Dolske [:Dolske] 2008-02-18 19:39:24 PST
(In reply to comment #71)
> These are the images that I tested the CMYK/YCCK color decoding with:
> CMYK coded jpeg's at: http://www.geocities.com/alfredkayser/jpeg/cmyk/
> YCCK coded jpeg's at: http://www.geocities.com/alfredkayser/jpeg/ycck/

GAH! Geocities. :( Both locations are dead with "The GeoCities web site you were trying to view has temporarily exceeded its data transfer limit" errors. Attach here (or Google Pages)? Or, better yet, convert a representative sample to reftests and and checkin under http://mxr.mozilla.org/seamonkey/source/modules/libpr0n/test/reftest/jpeg/ :-)

Comment 75 Marius Hudea 2008-02-19 02:39:59 PST
The images from Geocities are available at:

http://www.definethis.org/temp/bugzilla/cmyk_jpg/
Comment 76 Shailen 2008-02-20 00:04:17 PST
*** Bug 415861 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.