44781 - Support CMYK, YCCK JPEGs

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, enhancement)

Description

[Mirek Hankus]

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]

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]

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]]

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]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 5

[Mirek Hankus]

I know that this is marked as helpwanted, but after landing of
new imagelib mozilla crashes on test url. 

Comment 6

[Terri Preston]

This bug might have morphed into a new bug, it does crash on w2k build 
2001040304

Comment 7

[Mirek Hankus]

  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]

Attachment: 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)]

pavlov: we've got this patch here for the last 4 months... could you maybe
review it?

Comment 10

[Stuart Parmenter]

Comment on attachment 61914 [details] [diff] [review]
CMYK JPEG support

r=pavlov

Comment 11

[tor]

Attachment: 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]

Attachment: fold cut&paste image output code

Comment 13

[tor]

Taking bug...

Comment 14

[tor]

*** Bug 78860 has been marked as a duplicate of this bug. ***

Comment 15

[tor]

Attachment: update to tip + cleanups

Comment 16

[Damian Yerrick]

Don't Adobe and Pantone have patents on any form of CMYK support?

Comment 17

[tor]

As far as I know the patents are on RGB->CMYK seperation (the hard bit).

Comment 18

[Matthias Versen [:Matti]]

*** Bug 156310 has been marked as a duplicate of this bug. ***

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

tor: what's the status of this patch?

Comment 20

[tor]

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

[Eugene Kanter]

Does the image http://extraserv.softpress.kiev.ua/~eismont/Bublik_10_2002.jpg
fall into the same category?

Comment 22

[ghosh]

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]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 24

[tor]

*** Bug 177361 has been marked as a duplicate of this bug. ***

Comment 25

[Manko]

BTW, Opera does have CMYK images support since version 6.

Comment 26

[Boris Zbarsky [:bzbarsky]]

*** Bug 192089 has been marked as a duplicate of this bug. ***

Comment 27

[Stefan Borggraefe]

*** Bug 203643 has been marked as a duplicate of this bug. ***

Comment 28

[Damian Yerrick]

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]

Gimp 2.0 is supposed to have CMYK support.

Comment 30

[Chris Bolt]

http://www.littlecms.com/faq.htm might also be useful

Comment 31

[Craig Ringer]

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)]

>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]

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]

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]

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]

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]

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]

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]

Attachment: 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]

Attachment: updated to tip

Comment 41

[u88484]

*** Bug 262776 has been marked as a duplicate of this bug. ***

Comment 42

[[e-mail]]

*** Bug 326427 has been marked as a duplicate of this bug. ***

Comment 43

[Mike Cowperthwaite]

*** Bug 338462 has been marked as a duplicate of this bug. ***

Comment 44

[Mike Cowperthwaite]

*** Bug 228960 has been marked as a duplicate of this bug. ***

Comment 45

[Mike Cowperthwaite]

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)]

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]

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]

Attachment: renders in everything but Firefox

Comment 49

[Hermann Schwab]

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 52

[tor]

Bug 16769 will fix this as a side effect.

Comment 53

[Alfred Kayser]

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]

Ping! Any progress on this one? Can the patch be applied?

Comment 55

[Marius Hudea]

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]

Let me take this up. I will 'unbitrot' the existing patch.

Comment 57

[Alfred Kayser]

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]

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]

Attachment: 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]

The URL no longer seems to be valid.

Comment 61

[Mike Cowperthwaite]

(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]

(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]

Will we get this into the testsuite?  Does this impact perf at all?

Comment 64

[Alfred Kayser]

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]

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]]

Alfred, please attach an unbitrotten version of the patch for check-in.

Comment 67

[Alfred Kayser]

Attachment: 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]]

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]]

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]]

(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]

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)]

+      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]

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]]

(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]

The images from Geocities are available at:

http://www.definethis.org/temp/bugzilla/cmyk_jpg/

Comment 77

[Christian Völker]

Attachment: VI-TschuessKohle_Klimagerechtigkeit-1040x633.jpg

I think, this bug has reoccured in a recent version of Firefox. 
It should be reopened.

Using Firefox 58.0.2 (currently current) on macOS High Sierra 10.13.3 (currently current).

Here is my example:
<https://umweltfairaendern.de/wp-content/uploads/2018/03/VI-TschuessKohle_Klimagerechtigkeit-1040x633.jpg>

The file displays as expected in Chrome and Safari. 
It also displays fine when saved locally and opened in Preview.
However, colours are extremly distorted when seen in Firefox.

I know the author of this blog. He uses Corel Draw to edit pictures. And he saves them as CMYK with embedded profile (at least a sensible profile for print production, but that doesnt help when it comes to online content). No, I cant educate him to use his computer more efficiently. I appreciate his blog for the written content. And I guess, Firefox should do just as good as other browsers can do.

Comment 78

[Christian Völker]

Comment on attachment 8955928 [details]
VI-TschuessKohle_Klimagerechtigkeit-1040x633.jpg

I think, this bug has reoccured in a recent version of Firefox. 
It should be reopened.

Using Firefox 58.0.2 (currently current) on macOS High Sierra 10.13.3 (currently current).

Here is my example:
<https://umweltfairaendern.de/wp-content/uploads/2018/03/VI-TschuessKohle_Klimagerechtigkeit-1040x633.jpg>

The file displays as expected in Chrome and Safari. 
It also displays fine when saved locally and opened in Preview.
However, colours are extremly distorted when seen in Firefox.

I know the author of this blog. He uses Corel Draw to edit pictures. And he saves them as CMYK with embedded profile (at least a sensible profile for print production, but that doesnt help when it comes to online content). No, I cant educate him to use his computer more efficiently. I appreciate his blog for the written content. And I guess, Firefox should do just as good as other browsers can do.

Comment 79

[alexander92ck]

I think that this bug is most definitely back:

https://imgur.com/a/xFy1S

Those 2 pictures are screenshots taken of the same foto, one taken while the photo was in thunderbird, the other while opened on the desktop, as you can see the colors are very much different.

I am running: Thunderbird 52.6.0 (64 bit)
OS: macOS HS 10.13.3