Support CMYK, YCCK JPEGs

RESOLVED FIXED in mozilla1.9beta4

Status

()

Core
ImageLib
--
enhancement
RESOLVED FIXED
17 years ago
9 years ago

People

(Reporter: Mirek Hankus, Assigned: Alfred Kayser)

Tracking

Trunk
mozilla1.9beta4
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [imglib] [parity-opera], URL)

Attachments

(3 attachments, 6 obsolete attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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
(Reporter)

Comment 2

17 years ago
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

17 years ago
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Summary: JPEG saved in CMYK mode rendered incorectly → [RFE] support CMYK

Updated

17 years ago
Target Milestone: --- → Future

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: enhancement

Updated

17 years ago
Blocks: 61481

Updated

17 years ago
QA Contact: elig → tpreston

Comment 4

16 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
(Reporter)

Comment 5

16 years ago

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

Comment 6

16 years ago
This bug might have morphed into a new bug, it does crash on w2k build 
2001040304
Whiteboard: enhancement → enhancement [imglib]
(Reporter)

Comment 7

16 years ago
  I've sent information about this crash via talkback with id TB28646880W. 
Shoul'd i report this crash as a new bug ????? 

Updated

16 years ago
OS: Windows 98 → All
Priority: P3 → --
Hardware: PC → All
Whiteboard: enhancement [imglib] → [imglib]

Updated

16 years ago
Summary: [RFE] support CMYK → [RFE] Support CMYK JPEGs

Comment 8

16 years ago
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.
pavlov: we've got this patch here for the last 4 months... could you maybe
review it?

Updated

15 years ago
Keywords: patch, review
Whiteboard: [imglib] → [imglib] need review

Comment 10

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

r=pavlov
Attachment #61914 - Flags: review+

Comment 11

15 years ago
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.
Attachment #61914 - Attachment is obsolete: true

Comment 12

15 years ago
Created attachment 78389 [details] [diff] [review]
fold cut&paste image output code
Attachment #78385 - Attachment is obsolete: true

Updated

15 years ago
Attachment #78389 - Attachment is obsolete: true

Comment 13

15 years ago
Taking bug...
Assignee: pavlov → tor

Comment 14

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

Comment 15

15 years ago
Created attachment 79692 [details] [diff] [review]
update to tip + cleanups

Comment 16

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

Comment 17

15 years ago
As far as I know the patents are on RGB->CMYK seperation (the hard bit).
*** Bug 156310 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Summary: [RFE] Support CMYK JPEGs → [RFE] Support CMYK, YCCK JPEGs
tor: what's the status of this patch?

Comment 20

15 years ago
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

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

Comment 22

15 years ago
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

15 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

15 years ago
Summary: [RFE] Support CMYK, YCCK JPEGs → Support CMYK, YCCK JPEGs

Comment 24

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

Comment 25

15 years ago
BTW, Opera does have CMYK images support since version 6.
*** Bug 192089 has been marked as a duplicate of this bug. ***

Comment 27

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

Comment 28

14 years ago
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

14 years ago
Gimp 2.0 is supposed to have CMYK support.

Comment 30

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

Comment 31

14 years ago
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/.
>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.

Updated

14 years ago
Whiteboard: [imglib] need review → [imglib] parity-opera need review

Comment 33

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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

12 years ago
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

12 years ago
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

12 years ago
Created attachment 177891 [details] [diff] [review]
updated to tip
Attachment #79692 - Attachment is obsolete: true

Comment 41

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

Comment 42

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

Comment 43

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

Comment 44

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

Comment 45

11 years ago
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]
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

11 years ago
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

11 years ago
Created attachment 226016 [details]
renders in everything but Firefox

Comment 49

11 years ago
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

Updated

10 years ago
Duplicate of this bug: 373356

Updated

10 years ago
Duplicate of this bug: 376893

Comment 52

10 years ago
Bug 16769 will fix this as a side effect.

Depends on: 16769
(Assignee)

Comment 53

10 years ago
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...)

Updated

10 years ago
Depends on: 397214

Comment 54

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

Comment 55

10 years ago
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?
(Assignee)

Comment 56

10 years ago
Let me take this up. I will 'unbitrot' the existing patch.
Assignee: tor → alfredkayser
(Assignee)

Comment 57

10 years ago
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

10 years ago
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.
(Assignee)

Comment 59

10 years ago
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).
Attachment #177891 - Attachment is obsolete: true
Attachment #299249 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #299249 - Flags: review? → review?(pavlov)

Comment 60

10 years ago
The URL no longer seems to be valid.

Comment 61

10 years ago
(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

10 years ago
(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.

Updated

9 years ago
Attachment #299249 - Flags: review?(pavlov) → review+
Status: NEW → ASSIGNED
Keywords: helpwanted
QA Contact: tpreston → imagelib
Whiteboard: [imglib] parity-opera need review → [imglib] [parity-opera]
Target Milestone: Future → ---
Attachment #299249 - Flags: approval1.9?

Comment 63

9 years ago
Will we get this into the testsuite?  Does this impact perf at all?
Flags: in-testsuite?
(Assignee)

Comment 64

9 years ago
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

9 years ago
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
Attachment #299249 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Alfred, please attach an unbitrotten version of the patch for check-in.
(Assignee)

Comment 67

9 years ago
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.
Attachment #299249 - Attachment is obsolete: true
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?
Attachment #303027 - Flags: review?(pavlov)

Updated

9 years ago
Attachment #303027 - Flags: review?(pavlov) → review+
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?
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Depends on: 411626
(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).
Flags: in-testsuite? → in-testsuite+
(Assignee)

Comment 71

9 years ago
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

9 years ago
+      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.
(Assignee)

Comment 73

9 years ago
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...)
(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

9 years ago
The images from Geocities are available at:

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

Updated

9 years ago
Duplicate of this bug: 415861

Updated

9 years ago
Blocks: 440736
You need to log in before you can comment on or make changes to this bug.