JPEG and color management

I think two things here. One, I've still never seen a profiling target as jpeg - these links are to test images, not profile targets. Second - even if there may be the slightest color shift in some areas in some images, it's not an issue. In dealing with tens of thousands of images over the years, many of them jpegs, I've never come across a circumstance where there was a noticeable color shift. There is far more variability in any printing process than color shift in jpegs.

There has been a single instance where the compression of a CMYK jpeg caused a gradation problem in a very subtle Cyan to paper white gradation that we traced to the file being a jpeg, but that's a single image since 1995.

Peter,
I just happened to see the links and since you asked for it ...

And I think colour reference targets like this:
http://www.colourmanagement.ca/Images/Colour%20Reference%20Target%20RGB.jpg
should have accurate colours, too.

Anyway,
do you feel the conclusions ( Mark J Peterson, "JPEG and color management" #39, 9 Dec 2008 11:06 pm) I have drawn from your previous posting are correct?

"Peter Figen, I just happened to stumble across some. Look here:

http://www.colourmanagement.ca/resources.shtml "

Mark,

As far as I can see, the images there are all test images, not profile targets - a big difference, and their CMYK test image happens to omit an embedded profile, making it next to useless. Oh well.

> I will continue to watch this thread and see what everyone turns up.

great, thanks

> For my purposes, however, I am completely satisfied with JPG compression (for its intended purpose) and the fact that colors are reproduced accurately (except in artifact areas).

Hm, not accurately in the sense of 100% identical but maybe we could say barely visible to the human eye ?

>My testing shows that patches of color remain unchanged.

But I showed you above a clear test case (it was actually the very first picture that crossed my way, so it wasn't specially chosen), where I showed you a color shift of (0,+1,+2) ( post #32) No disrespect, but it is enough to provide a single counter-example to prove your statement wrong.

>I don't see why pasting a JPG version of the file over the uncompressed TIFF original in "difference" mode wouldn't show all the different pixels? When I do this and set magnification to 400% or higher, you can see the artifacts. The eye dropper, when set to "point sample", does not detect ANY differences except along the borders of two adjacent patches, where artifacts clearly exist. This can be done at maximum magnification and I don't see ANY shifting of pixel values.

I'm not sure if I understand right what you did. I just meant that pasting the jpg over the original file, setting its blending mode to difference, using the magic wand with abovementioned settings on it and filling the selection with white clearly shows you which pixels are 100% identical and which are not.

Thanks, Gernot....your technical and mathematical analysis confirms what I have seen with my eyes and my 'low tech' approach.

Mark,

I will continue to watch this thread and see what everyone turns up.

For my purposes, however, I am completely satisfied with JPG compression (for its intended purpose) and the fact that colors are reproduced accurately (except in artifact areas). My testing shows that patches of color remain unchanged. If this is the case with neutral grays, then it is a moot point (at least for me) as we stray farther from the neutral axis.

If I have to work THAT HARD to show any color shift due to rounding or compression, it seems irrelevant, at least for routine work.

I don't see why pasting a JPG version of the file over the uncompressed TIFF original in "difference" mode wouldn't show all the different pixels? When I do this and set magnification to 400% or higher, you can see the artifacts. The eye dropper, when set to "point sample", does not detect ANY differences except along the borders of two adjacent patches, where artifacts clearly exist. This can be done at maximum magnification and I don't see ANY shifting of pixel values.

Have fun!! I'll check in from time to time to see what everyone turns up.

Lou

> Just out of curiosity, what profile targets are being supplied as jpegs?

Peter Figen, I just happened to stumble across some. Look here:

http://www.colourmanagement.ca/resources.shtml

No propblem.
Here is the the lossless conversion to png, so you can see for yourself:

http://www.imageboo.com/files/dupil5jjanyti9wfzvik.png

grayscale patch in column 7: RGB=(150,150,149)
grayscale patch in column 8: RGB=(139,138,138)

all other grayscale patches have equal values for R,G,B

Lou and Mark,

sorry for the Forum confusion.

If the gray patches are not accurately reproduced
by R=G=B, then we might have had rounding errors
in the inverse set of this conversion:
Y =+0.299 R +0.587 G +0.114 B
Cb=-0.169 R -0.331 G +0.500 B
Cr=+0.500 R -0.419 G -0.081 B

But it's hard to believe, because the coefficients
should be accurate in this sense: R=G=B delivers
Cb=0 and Cr=0. The DCT for zeros delivers zeros,
and so on.

Lab is not involved.

Of course I've done immediately a test: Save for Web
in PhS CS2 with quality 50% delivers equal numbers
R=G=B in each gray patch.

Best regards --Gernot Hoffmann

Thanks for looking into this thread, too, Gernot Hoffmann. Of course the two threads are related, but "different results for decoding the same JPEG" (no saving to jpeg), that's the other thread. This here is about color distortion when saving to jpeg.

I don't know if you read my comment earlier on, but some graypatches are not gray:

>I have opened the .eps file you posted above in three different programs (as PS CS3 can't open it) and there are two patches in the grayscale row, that they don't show as pure gray. The grayscale patch in column 7 has the RGB values (150,150,149) and the grayscale patch in column 8 has the RGB values (139,138,138). All other grayscale patches have equal amounts for R,G,B. Are these rounding errors from the LAB to RGB conversion? If not, what else ?

Lou,

Gray remains gray in the JPEG workflow - even for
the worst quality.
The luminance channel Y is treated much better
than the (residual) color channels Cb,Cr.
Except for the best quality (this depends on the
program), the colors are handled by subsampling:
averaging 4 boxes 8*8 for one result 8*8.
This reduces the file size already by 50%.
The most important size reduction happens by
Quantization (see tutorial below). This is much
stronger for Cb,Cr than for Y.
http://www.fho-emden.de/~hoffmann/jpeg131200.pdf
According to older tests, the gray content of an
average photo consumes about 75% of the file size.

All this (including your test) isn't directly related
to Mark's observations: different results for decoding
the same JPEG by different programs.

The color target is here:
http://www.fho-emden.de/~hoffmann/targetrgb.txt
Replace the extension txt by eps, load in PhS and
assign sRGB. The numbers are accurately in sRGB.
Target patches with small squares were out-of-gamut
for sRGB, but these patches are consistent in the file.
The numbers are here on p.5:
http://www.fho-emden.de/~hoffmann/a3gencolorhigh.pdf
The target contains a step graywedge, R=G=B.

Best regards --Gernot Hoffmann