Photoshop has problem with .JPEG decoding ??

[Mark_J_...@adobeforums.com]

There seems to be an issue with either JPEG decoding in Photoshop or the blend modes don't work as they should. Or maybe someone finds the true reason ... ?

Let's go step-by-step:

This is the original image file (JPEG):

[IMG]http://img528.imageshack.us/img528/8885/fotoqb2.jpg[/IMG]

This is the same image converted to .png:

<http://img155.imageshack.us/my.php?image=convertedxx1.png>

I examined the differences. Open one image and add the second image as a new layer over it with blend mode = difference. Use magic wand tool, with tolerance=zero. Expected results: entirely black image, entire image selected. Actual esults (white filled selection):

[IMG]http://img372.imageshack.us/img372/694/differencepg1.png[/IMG]

Merge both layers, invert the colors and you see the differences between the images. I applied a curves adjustment to exaggerate the differences:

[IMG]http://img241.imageshack.us/img241/1995/difference2zw5.png[/IMG]

Again, this time you should see an entirely white image, if both images were identical.

The JPEG-to-PNG conversion was done with a third party image viewer that I trust. Obviously, the possibility exists, that this conversion is not exact/losless. But I can refute this, as I converted both the source JPEG image and the converted PNG image to BMP images, and the two files that were obtained this way were bit-for-bit identical:

<http://img396.imageshack.us/my.php?image=fotolq4.png>

So it's impossible that any loss occured, given that in the a losless reconstruction was possible.

Thus the error must be somewhere within Photoshop.
Any ideas?

[dave_...@adobeforums.com]

Thus the error must be somewhere within Photoshop.

or the jpg spec.

Any ideas?

jpg is lossy. png is not.

[Mark_J_...@adobeforums.com]

There seems to be an issue with either JPEG decoding in Photoshop or the blend modes don't work as they should. Or maybe someone finds the true reason ... ?

Let's go step-by-step:

This is the original image file (JPEG):

This is the same image converted to .png:

<http://img155.imageshack.us/my.php?image=convertedxx1.png>

I examined the differences. Open one image and add the second image as a new layer over it with blend mode = difference. Use magic wand tool, with tolerance=zero. Expected results: entirely black image, entire image selected. Actual esults (white filled selection):

Merge both layers, invert the colors and you see the differences between the images. I applied a curves adjustment to exaggerate the differences:

Again, this time you should see an entirely white image, if both images were identical.

[Mark_J_...@adobeforums.com]

sorry, I hadn't finished editing my post. So here is the entire post:

[Mark_J_...@adobeforums.com]

Dave, you didn't really think about the issue before posting. Not a single step I mentioned is lossy !!

[J_Ma...@adobeforums.com]

The two PNG files (fotolq4 and convertedxxx1) you posted are the same. Both are different from the JPG (fotoqb2). You state that you created the PNG files from the JPG file, but since you created them with another converter, I'm going to ask why you wouldn't suspect the third party converter. A quick conversion in PS reveals the files stay the same. I'd trust PS.

[J_Ma...@adobeforums.com]

The way I read your post, you start with PS JPG (a). You convert from this point forward without PS in all instances. Convert JPG to PNG with software x and get (a) to (b). Convert JPG to PNG to BMP in software x and get (a) to (b) to (a). Convert in software PS and what happens? (a) to (a) to (a) to (a), except where you re-compress using lossy compression? Not that this rules out PS at fault, but it does speak to a workaround. Or maybe it's a bug in CS4. What version are you using?

[Myle...@adobeforums.com]

Mark, I really don't get what you are trying to say. The way I figure it, you are concerned about different tools producing different JPEG compression patterns in the file, which is perfectly normal. JPEG is based on a series of waveform transformations and some other hocuspocus and depending on what the developer considers his topmost priority, there's even room in the specs on the code end in terms of trading quality/ precision for speed/ performance. At least that's what my feeble mind understands. I could quite well imagine that this also somehow affects the reconstruction on file open, depending on how it's implemented.

Mylenium

[Mark_J_...@adobeforums.com]

@Mylenium: The first part of your message isn't related to this issue. None of the steps described involves saving to a .jpeg file.

The second part of your message is interesting. Are you suggesting, that according to the .jpeg specifications a .jpeg file can be interpreted in more than one way and thus be displayed differently depending on the program ?!??

[Mark_J_...@adobeforums.com]

Hi J Maloney. Thanks for looking at this. Sorry, I forgot to mention, I use CS3.

I have to correct the information in my OP. The last thumbnail links to a .png file (fotolq4.png), but I had uploaded a .bmp file which was converted by the storage site.

Please ignore fotolq4.png. Here is the .bmp I uploaded:

<http://www.mediafire.com/?sharekey=65004fb46f8cafa091b20cc0d07ba4d2bcd6cf19f5eed331>

[Mark_J_...@adobeforums.com]

@Mylenium: I always thought a .jpeg file UNIQUELY defines exactly one image.

[Mark_J_...@adobeforums.com]

PS: it's also not an issue pertaining to color management. I made sure that the images are interpreted consistently.

[Mark_J_...@adobeforums.com]

OK, sorry everyone for the confusion. I just realized that I did all the conversions outside PS.

I further tested with the files and found out that the story is much easier. So forget the old story, here is the new one:

#1 I open the original .jpeg file in PS and save it as a 24bit .bmp image.

#2 I open the original .jpeg file in the 3rd party app I mentioned in my OP and save it as 24bit .bmp image.

#3 I compare the two .bmp images with the blending methods described in my OP and get the same results/differences.

So the way I see it, there must be differences in .jpeg-decoding. At this point, most of you here will probably say "I just trust Photoshop". But how can I prove which application is flawed ? Following the principle "trust is good, control is better", I'd like to unambiguously identify the error, but how ?

[J_Ma...@adobeforums.com]

What about an uncompressed file? What about third, fourth, fifth iterations?

[Mark_J_...@adobeforums.com]

don't understand you. "what about an uncompressed file" ... ??
And where are iterations in this example ?

[J_Ma...@adobeforums.com]

What about PNG to BMP (as oppposed to JPG to BMP)? Iterations would be BMP to PNG and back I suppose.

[Gernot_...@adobeforums.com]

Mark,

the decoding of a JPEG is algorithmically unique.
Small differences between the results can happen
for floating point versus fixed point integer arithmetic.
Never tested, but the differences shouldn' be
larger than 1 unit of 255 in R,G,B.

About color management:
It's assumed that the third party decoder works
without color management. The working space in
PhS should be sRGB. For the comparison one has
to consider several cases:
a) The JPEG doesn't have an embedded profile.
Leave as is (don't color manage).
b) The JPEG has an embedded profile sRGB:
Discard the embedded profile.
c) The JPEG has a different embedded profile:
Discard the embedded profile (the appearance will
be wrong, but the decoding by numbers will be
identical to the other decoder).

Please show then the difference in mode Subtract
with scalefactor 1 and offset 128. This is a medium
gray image with almost invisible variations.

Best regards --Gernot Hoffmann

[Toby_...@adobeforums.com]

Mark,

You've merely shown that different JPEG implementations will give slightly different results. This is entirely expected; move on.

[Mark_J_...@adobeforums.com]

@J Maloney: I didn't choose jpeg deliberately. I just happened to discover these discrepancies and the original source file happened to be a .jpeg file. I don't expect to encouter the same issues with .png and .bmp

@Toby Thain: No, this is not expected at all. Read Gernot Hoffmann's posting.

@Gernot Hoffmann: Interesting. So you suggest, that there can be differences that are large enough to exceed 1 unit in 8bpc RGB ? I'm not a maths genius admittedly, but I can't imagine that fixed point vs. floating point would lead to such relatively dramatic differences that can already be seen as pixel differences in standard 8bpc RGB images.

The file doesn't have an embedded ICC profile. I used "don't color manage" in both PS and the image viewer and - as a second step - I applied an sRGB profile in both applications. Same results.

I will post the results for subtract as well, because I'm curious. But for two images that are exactly the same, difference blending alone would already be conclusive enough, isn't it?

[Mark_J_...@adobeforums.com]

@Gernot Hoffmann: Can you post a concrete example with specific values illustrating how a pixel in a .jpeg file can be decoded in two separate ways (floating point, fixed point) and have two considerably different values (for example (230,228,117) and (231,228,118)). The example can of course be entirely imaginary.

[Gernot_...@adobeforums.com]

Mark,

it's long ago that we had programmed this stuff:
<http://www.fho-emden.de/~hoffmann/jpeg131200.pdf>

Two parts in the decoding can be programmed either
by float single precision (using the floating point
unit, as I did) or by fixed point: the conversion
from DCT coefficients to Y,Cb,Cr (one after the
other) and from there to 'Device RGB'.
I'm at present not able to evaluate a comparison.
But what's more important: JPEG encoding+decoding
creates anyway wrong colors. Therefore it's hardly
very interesting whether two different implementations
are creating the SAME wrong colors.
The underlying principle is this, for C=Y,Cb,Cr one
after the other:
C:=Round(17*Round(C/17))
Right the original value C, left the recovered(recon-
structed) value C. And 17 is an example for a quantization
coefficient (transmitted in the file in a quantization
table).

I'm sure, if you show the difference by Subtract, we
won't see much difference. If the files were identical,
then Difference would be black, but that's not to be
expected.
Subtract with offset 128 (for instance) shows signed
deviations.

By the way: the wrong colors don't affect the appearance
of photos, because the variations are like noise around
the true values, but they are a bigger problem for uniform
areas.

Best regards --Gernot Hoffmann

[Mark_J_...@adobeforums.com]

Hi Mark, thanks for the detailed information and thanks for sharing the paper you wrote, it seems very interesting. I have the impression, it's beyond my mathematical faculties, but I'll study your proposals in detail later on.

Here is the image with subtract@offset128 like you asked:

You can easily reproduce it by using these two source files:
<http://img528.imageshack.us/img528/8885/fotoqb2.jpg>
<http://img155.imageshack.us/my.php?image=convertedxx1.png>
(... the first two images of my OP as corrected in my second post)

[Mark_J_...@adobeforums.com]

OK, the more I study this thing, the more it seems to me that Photoshop indeed has issues with JPEG-decoding.

I regret that this whole thread started out so messy and confusing, I'd actually like to start a whole new thread for this, but I don't think that would be appreciated, so I make a line here :

==============================================================================================================================

and below this line starts the new thread :)

[Mark_J_...@adobeforums.com]

I restart from scratch ...

One fine day I was testing PNG-optimization methods (hence the confusion with .png files in my OP) and accidentally discovered something completely different:

problems with JPEG-DECODING in Photoshop

The starting point of my investigations is a simple JPEG file. I opened it with Photoshop and a third party image viewer and saved it as BMP respectively. Then I compared the two BMP files and found them to be different, whereas they should be identical.

Continuing the investigation, I used several different programs to do the JPEG to BMP conversion and ALL resulting BMP images were 100% identical ... except the one Photoshop produced. I find these findings quite disconcerting.

Here is a .zip file with the ORIGINAL SOURCE FILE in JPEG format, plus the converted BMP files (choose one link, the zip file is the same):

<http://www.mediafire.com/file/mzn3cyyrvy2/JPEG-decoding.zip>
<http://www.badongo.com/file/12340680>
<http://rapidshare.de/files/41059588/JPEG-decoding.zip.html>

I used the following programs for the conversion:

- Photoshop CS3
- ImageMagick 6.4.6-7-Q16
- Irfan View 4.20
- Microsoft Paint 5.1
- online conversion on the website www.media-convert.com

The BMP images are not necessarily bit-for-bit identical on the file level, but all pixels are identical. I used two techniques to verify if the images are identical:
1) Photoshop's difference blending mode
2) ImageMagick's "compare.exe" in the following metric mode : "absolute number of differnet pixels" (BTW, there are a couple of interesting comparison modes available, if anybody is interested:

AE absolute number of differnet pixels
MAE mean absolute error (normalized), average channel error distance
MEPP mean error per pixel (normalized mean error, normalized peak error)
MSE mean error squared, average of the channel error squared
PAE peak absolute (normalize peak absolute)
PSNR peak signal to noise ratio
RMSE root mean squared (normalized root mean squared)

[Mark_J_...@adobeforums.com]

I also made sure that color-management wasn't falsifying the results. The original source file does not have an embedded ICC profile. For the purposes of this test, I set my RGB working color space to sRGB IEC61966-2.1. Then I opened the .jepg file and upon opening, I chose "leave as is (don't color manage)", saved it as .bmp, closed the file, re-opened the .jpeg and this time I chose "assign working RGB: sRGB IEC61966-2.1" before saving it as another .bmp file. The two .bmp files were (as expected) bit-for-bit identical. This was the .bmp file I used for all subsequent comparisons with the other application's .bmp files.

[Mark_J_...@adobeforums.com]

ImageMagick reports 109817 different pixels out of a total of 250800, that's more than 43% !

ImageMagick also produces a visual representation of the differences. The red pixels are those that are different. You can see, that they correspond exactly to the black-and-white images in my second posting. If you save both images and switch back and forth between them, you'll see that the white pixels in the black-and-white image correspond exactly to the red pixels here:

Judging from the picture, you can see that it's not a color management issue, because the differences would affect either the entire image (everything red) or at least in a more uniform manner. But here you can see the vertical and horizontal patterns that stem from the jepg-artefacts, a further indication that indeed the JPEG-DECODING is at the heart of the whole issue.

[Mark_J_...@adobeforums.com]

PS: the red pixels above show the location of the pixels that are different between Photoshop's interpretation of the original JPEG file and the interpretation of the JEPG file by ALL OTHER PROGRAMS. The lighter colors in the image are actually a very "faded" version of the source image, just for orientation purposes ...

[Buko]

the red pixels above show the location of the pixels that are different
between Photoshop's interpretation of the original JPEG file and the interpretation
of the JEPG file by ALL OTHER PROGRAMS.

Photoshop is color managed the other programs are not. Until you get a grasp on color management talking to you is just like running in circles.

[Mark_J_...@adobeforums.com]

I configured Photoshop's color management to act like the other applications do, as you can read above. Besides, from the diff-images, you can see that it's not a color management issue. I don't find your message very friendly either.

[Mark_J_...@adobeforums.com]

Buko, you either didn't read post #24 or otherwise I find it amusing that your condescending remarks are paired with ostensible lack of knowledge. Just to demonstrate what I was saying above: I opened the source file in PS and converted it to AdobeRGB1998 and ProPhotoRGB and used perceptual and relative colorimetric rendering intents, which combined gave me 4 variants, that I saved as .bmp files. I compared those to ALL .bmp files I previously produced as described above, including the .bmp Photoshop produced when assuming an sRGB profile and with color management turned off (which obviously resulted in the same file as I said above). As I had written above, I expected these results to be quite different:

Judging from the picture, you can see that it's not a color management

issue, because the differences would affect either the entire image (everything
red) or at least in a more uniform manner. But here you can see the vertical
and horizontal patterns that stem from the jepg-artefacts, a further indication
that indeed the JPEG-DECODING is at the heart of the whole issue.

And indeed, when different color spaces come into play, the differences are considerably bigger. For example, here is the comparison between the source file converted in PS into AdobeRGB1998 (perceptual) and the (identical) BMP files created by the 4 other applications:

Again, the reddish pixels denote pixel changes, in other words almost the whole image is different. And I even picked the example with the "least" differences, because in ProPhotoRGB virtually all pixels are different aside from the black stripe at the bottom of the image.

Instead of your "I-know-everything-you-know-nothing" mentality nobody here is keen on, you could do something meaningful and contribute in a technical manner to this issue.

[John Joslin]

Well I'm not saying, "I-know-everything-you-know-nothing".

What I am saying is that this is not unexpected and reinforces the advice that is given to everyone:

"Avoid using JPEGs except where the final output requires it and then only as the last step."

[Mark_J_...@adobeforums.com]

Obviously you are right (in my opinion) with your recommendation. But that's not the point. Photoshop apparently decodes .jpeg files incorrectly and the point here is to find out why and what happens exactly.

[Gernot_...@adobeforums.com]

Mark,

the gray 'difference image' shows via Histogram:
Standard deviations in pixels:
Red 1.16
Green 0.60
Blue 1.76 (not a simple Gaussian bell)
Lum. 0.24

IMHO: these tiny deviations aren't worth a further
discussion (except for Blue perhaps).

Method: Screenshot, Crop, Trim, Windows > Histogram.

Best regards --Gernot Hoffmann

[Mark_J_...@adobeforums.com]

So far nobodody has found a logical explanation (at least not backed by argumentation rather than sole guesswork) that would account for the differences.

@Gernot Hoffmann:
Thanks for looking into that! Yes, I can see these values, too. So you find the standard deviation for blue a bit curious too?

My point is not how big or tiny those differences are, but why there are differences at all ! And again, aside from your fixed-point vs. floating point idea, I don't think we have been able to come up with an explanation so far.

[Don_Mc...@adobeforums.com]

So far nobody has found a logical explanation

Or more likely, nobody else cares.

[Mark_J_...@adobeforums.com]

Don, if you don't care, then please go and post somewhere else.
Please don't interfere with unconstructive off-topic posts.

[Mark_J_...@adobeforums.com]

Another user could confirm my findings here:

<http://en.irfanview-forum.de/vb/showpost.php?p=16585&postcount=6>

[John Joslin]

Can you explain why you are digging into this?

Is it preventing you getting work done or affecting the quality of your end product?

Or are you just a curious person?

[Mark_J_...@adobeforums.com]

No, none of the above. If you do color-critical work, you have to be able to fully trust your program. If the program produces different colors than it should, you can't fully trust your program until you find the explanation and understand the way it works.

[Chri...@adobeforums.com]

I'm sorry, but so far all that you have shown is that you do not understand JPEG encoding/decoding.

If all other apps produce the same bits, that would mean that they are all using the same JPEG decoding code. There is no "one true" JPEG implementation - there will be small differences, and that's ok because JPEG is a lossy file format.

And if you do color critical work, then JPEG is not the right format to use.

[Basil_...@adobeforums.com]

I think a key issue here is what is meant by lossless, in this context. Strictly speaking, the term applies to a file format to which image data (basically a set of pixel values) can be saved and subsequently recovered without the data having changed. I think there is a distinction to be made between this and the reversibility of a process to which the image data may be subjected. A reversible process being one which can be reversed so that, when the inverse process is applied to the processed data, the original data are precisely recovered. For example, for a file format to be lossless, any compression algorithm has to be reversible.

However, the conversion of image data from one format to another is not necessarily reversible, even if the formats are considered to be lossless (which only means that the data can be recovered, in some form, without having been altered). This is because the data consist of integer values and, if arithmetic is applied in the conversion, rounding errors can occur. The most obvious example is when the pixel values are converted from one colour space to another. Where rounding errors occur, there is always loss of information; the process is then not precisely reversible. For example, suppose I have a pixel whose value is 13 and I multiply this by 1/9. This gives 13/9 which rounds to 1. Applying the inverse process by multiplying by 9 gives 9 with a resulting error of -4.

Mark did not say if there was a colour profile embedded in the original jpeg file. If so, and particularly if it was not sRGB, this has the potential to introduce rounding errors, depending on how the software handles embedded profiles.

I am not saying that rounding errors are the cause of this particular problem, just pointing out that such errors can occur and mean that what might be considered to be lossless conversions are not necessarily so in the sense of being reversible.

This means that subjecting an image to a series of what might be considered to be "non-destructive" processes and reversing them does not necessarily get you back to where you started. Rounding errors are likely to be most noticeable in the data at low pixel values, and, possibly, according to how the arithmetic is done, at high pixel values as well. However, one would expect that processing algorithms will be designed so that image degradation due to rounding is minimised.

[Mark_J_...@adobeforums.com]

Chris, while I do honour your dedication as you show up (voluntarily I imagine) in a user forum, I also want to make some points clear.
I am a user.
I am not a mathematician, nor a software engineer, nor a genius. I am not ashamed of my skills either, but even if I were the dumbest Photoshop user on the planet, where is the point in saying "you don't understand this, you don't understand that", etc. And you haven't been the only one in this thread.

The forums here should be a place for constructive issue-orientated comments and ideas. Instead, it has become, so often, a place for condescending remarks and fingerpointing.

Until you get a grasp on color management talking to you is just like
running in circles.

I don't claim to have any knowledge whatsoever, but I did find some interesting things most users - and I'm sure not even in this thread ironically - were aware of or have tried out and seen the concrete results in this detail. I found it interesting and wanted to know the reasons for it, hardly a crime. It's a simple question on my behalf.

And so far nobody was really able to explain the issue. Most here were either confusing the issue with color management or with the lossy part of jpeg-ENCODING. Why does nobody here tell them, that they don't understand it ??

At least, I correctly identified the source of the problem as jpeg-decoding issues and was intelligent enough to understand, that it is completely unrelated to color management, ICC profiles, etc. (and while you are at it, Chris, I'd kindly ask you to confirm this, so that at least this issue is settled).

Again, I would be curious to know the reason for the discrepancies. JPEG is a well defined standard. And I think you would agree, Chris, that the jpeg-data cannot be interpreted arbitrarily. There is a single well-defined (186 pages for the main document) method.
The modest knowledge that I have tells me, that JPEG-encoding is a lossy process, but that the process of JPEG-decoding (and that's the topic here) is theoretically lossless if we had an infinite amount of calculation precision. So the loss which occurs during the decoding only depends on the decoder's precision, right ? Again, I don't claim anything, these are questions.

If all the other applications decode the .jpeg file to exactly the same image and only Photoshop produces a different image, I think it's a legitimate question to ask.

Does Photoshop use a higher precision for decoding and is this the reason for the differences ? Or if not, what else ?

Thank you.

[Mark_J_...@adobeforums.com]

Mark did not say if there was a colour profile embedded

Basil Crowley, if you make such claims, please have at least the politeness to read the thread. I did say it.

[Gernot_...@adobeforums.com]

Mark,

nothing wrong with your investigation, but it should
be based on a reliable test image with known color
values.
You may use a target with sRGB numbers, p.5 here:
<http://www.fho-emden.de/~hoffmann/a3gencolorhigh.pdf>
Some target colors are out-of gamut for sRGB. These
are indicated by a small dot and one channel is 0
(or 255) which indicates clipping.
This doesn't matter for the test - colors and numbers
are consistent.
Tests should be done by comparing the values in the
middle of each patch in the lower image (without numbers).
The upper image is the reference by numbers.

Best regards --Gernot Hoffmann

[Mark_J_...@adobeforums.com]

Very good idea, thanks Gernot.

[Basil_...@adobeforums.com]

Basil Crowley, if you make such claims, please have at least the politeness
to read the thread. I did say it.

Now who is being unfriendly? If you read my post, you will see that I made no claims at all. All I am pointing out is that, although the file formats may be lossless, the conversions are not necessarily so.

Given some of your own comments above, your remark is inexcusable.

Quite a lot of the postings above appeared while I was writing my little treatise. I was only trying to make a useful contribution. I am now really sorry I bothered to write anything at all!

Due to the lack of civility on this thread, I am leaving.

Bye

[Free...@adobeforums.com]

As so many others have pointed out, this discussion basically has no meaning.

When you work with jpegs, you accept that what leaves your computer is not the same as what came in. It's just how the jpeg format works.

IOW Mark, this parrot is dead. It is no more. This is an ex-parrot (ah, nevermind, you're probably too young... ;-) )

But I have to say I like the image. Very happy and relaxed atmosphere, and the blue color is just right.

[dave_...@adobeforums.com]

you accept that what you save is not necessarily the same as what you
opened. It's just how the jpeg format works.

yes, but i see mark's point. the problem he's describing has nothing to do with SAVING jpgs, which is where any loss would occur (according to spec). he's saving BMPs. it seems he's losing data in PS when OPENING jpgs. that is NOT expected behavior.

UNLESS there's something going on with color mgmt that i'm not seeing. it's been said (by chris, i believe) that there's no way to really turn CM "off" in photoshop, so is this behavior caused by the CM? if so, there should be a way to get the expected results.

[dave_...@adobeforums.com]

and ditto FA's comments on the picture itself. nice pose and lighting mark.

[Mark_J_...@adobeforums.com]

Basil Crowley, first of all I'm thankful for that you intend to make a useful contribution.

If you read my post, you will see that I made no claims at all.

I did read your post and in my previous message I quoted exactly the passage where you made the claim. Once again, here it is:

Mark did not say if there was a colour profile embedded

My reply to this was:

Basil Crowley, if you make such claims, please have at least the politeness
to read the thread. I did say it.

Now what's unfriendly or inexcusable about this?? I didn't find it polite that you make claims about me, obviously without reading the thread and therefore I asked you to read it. Where is the problem ?

[Mark_J_...@adobeforums.com]

Freeagent, in this whole thread saving to jpeg never occurs!

>> you accept that what you save is not necessarily the same as what you
opened. It's just how the jpeg format works.

yes, but i see mark's point. the problem he's describing has nothing to
do with SAVING jpgs, which is where any loss would occur (according to
spec). he's saving BMPs. it seems he's losing data in PS when OPENING
jpgs. that is NOT expected behavior.

Dave Milbut, thanks for pointing this out again. I had been saying this all along in the thread, and I'm completely unable to relate to why they still answer "jpeg is lossy, get over it" ... Because saying so is oversimplifying the issue here and ignoring some aspects.

[Mark_J_...@adobeforums.com]

And I want to say once and for all: I don't use JPEGs for my work. So I hope, I won't see comments again suggesting "just don't use JPEGs and you are fine". The point is - as I mentioned above - that you have to trust your image editing software to be accurate, whether it is color management or JPEG decoding. So far we have only seen pixels with unexpected colors. I strongly assume that it has to do with jpeg-decoding, but untill this can be determined definitely, we don't know the extent of the problem that produces inaccurate colors (either in PS or all the other apps).

[Mark_J_...@adobeforums.com]

it's been said (by chris, i believe) that there's no way to really turn
CM "off" in photoshop, so is this behavior caused by the CM? if so, there
should be a way to get the expected results.

If it is so, I hope Chris will comment on that. But I think the difference images above clearly show, that it's not a color management issue. As I mentioned above, I opened the source image and assumed each time another profile and compared the results both one to each other and to the BMP images produced by the other programs. When different color spaces were involved, virtually all pixels were different. But when working in the same color space, you could see that the differences occur along the lines of the JPEG-artefacts and form a checker board pattern caused by the JPEG-compression. The fact that the differences occur along edges and the typcial JPEG square zones simply suggest that the differences are related to JPEG-decoding.

[Mark_J_...@adobeforums.com]

Among the professional photographers, designers, etc. here, sometimes I get the impression that it's a sin to have the word jpeg cross one's lips :)

[Mark_J_...@adobeforums.com]

And to make the opposition [color management vs. JPEG-decoding] more apparent to the eye:

Here is an enlargement of a portion of the image. The differences between [Photoshop] and [all the other tested programs] are shown in white this time. In other words, all the non-white pixels are identical. Do you still think this is possible, if different color spaces were used? The pattern, the white pixels form are too similar to JPEG-patterns, that this could be considered a coincidence:

[Mark_J_...@adobeforums.com]

(didn't forget about your idea, Gernot, that's next)

[Free...@adobeforums.com]

Ok, ok, saving, opening, same thing (in practical terms).

But maybe it's me beating a dead horse. I'll shut up and listen :-)

[dave_...@adobeforums.com]

saving, opening, same thing (in practical terms).

no. opening shouldn't change anything (unless a color profile is being assigned or read by photoshop). saving is where changes (if any) to the file should occur.

[dave_...@adobeforums.com]

saving is where changes (if any) to the file should occur.

and saving to a non lossy format should yield the same results as another program saving to that same non lossy format. at least logically.

[Free...@adobeforums.com]

I realize that, Dave, and it's not that I don't see the distinction. It just seemed to me that even if this is correct, it's a very minor concern compared to the overall degradation that happens to jpegs, and probably already has happened several times before the jpeg finally arrives at your computer.

...oh, sorry. I promised to shut up.

[Mark_J_...@adobeforums.com]

Dave Milbut, thanks for confirming. (I admit I was beginning to lose any hope ... :) )
And Freeagent, no need to shut up. Everyone here (and I count me in) has the right to make errors or ignore one aspect or another. We should just try to be constructive and help each other.

[dave_...@adobeforums.com]

it's a very minor concern compared to the overall degradation that happens
to jpegs

sure it is. but there's nothing wrong with being curious. it's not like we're on the clock here. ;)

Dave Milbut, thanks for confirming.

just dave, please. :)

[David_E_...@adobeforums.com]

Interesting to read.

[Chri...@adobeforums.com]

"JPEG is a well defined standard"

"jpeg-data cannot be interpreted arbitrarily"

I'm sorry, but you're wrong on both points. The file format encoding is pretty standard (there are still some open issues and a few things that people just guess at for interoperability), but how the bits are transformed is far from standard. The math is not well defined: round or truncate, aim for middle or lower limit when dequantizing, nearest neighbor or interpolated when combining channels, how much precision is kept in intermediates, etc.
That's why I'm surprised you got identical results from several different software packages.

The errors in your large version look like small differences in the DCT reconstruction. I suspect that may be a quality choice in the Adobe JPEG engine that prefers higher quality reconstructions when dequantizing the DCT coefficients.

[Mark_J_...@adobeforums.com]

Thanks Dave+David!

[David_E_...@adobeforums.com]

So in other words once something is divided to reduced size any extra bits are tossed out. The reconstruction, however, tries its best to multiple out with the same number it was divied by (or something pretty close) but the answer will never be the same because of the tossed out bits. Or am I too simple here :)

So the two types of software used are using the same algorithm? I always hated math........ But it is cold outside and I think I will read up on this.

[Mark_J_...@adobeforums.com]

But it is cold outside and I think I will read up on this.

hehe, I think from now on I'll always look what the weatherman tells us before posting ... :)

[Mark_J_...@adobeforums.com]

Chris Cox,

The math is not well defined: round or truncate, aim for ...

OK for all the other examples, but since when is truncate more precise than round ??

The errors in your large version look like small differences in the DCT
reconstruction.

You might be aware of it, but the "large version" is just an enlargement of a small portion in the original image. So whatever you say about it, automatically also applies to the differences shown here:
<http://img117.imageshack.us/img117/1872/differencetb4.png>
and here:
<http://img372.imageshack.us/img372/694/differencepg1.png>
and here:
<http://img241.imageshack.us/img241/1995/difference2zw5.png>

[Mark_J_...@adobeforums.com]

And before I post some additional findings:

As I am not a specialist in this domain, I would like someone to confirm that my color management settings described in post#24 ( Mark J Peterson, "Photoshop has problem with .JPEG decoding ??" #24, 3 Dec 2008 7:04 pm </webx?14@@.59b726f1/23> ) are appropriate for this test here, in which applications without color management are involved.

And if there are any Photoshop settings (color-management related or other), that could interfere with the test results, than please tell me.

[Mark_J_...@adobeforums.com]

Chris Cox, could you please state whether or not there are differences in JPEG-decoding between:

Photoshop CS3 (10.0),
Photoshop 7.0 and
Photoshop Elements 1.0.128.0

Thank you.

[Gernot_...@adobeforums.com]

Another test:
<http://www.fho-emden.de/~hoffmann/phs+nc.jpg>

The original JPEG was made for Quality 50%.
The image of the image pair was compressed for
quality 100%, which doesn't add more artifacts.

Opened by Photoshop (left) and by Netscape(right):
1) Equal in the grays (last row).
2) Different in the colors (last color row).
Compare the artifacts in the patches and at the
edges !

For a real world JPEG image with Quality 100% the
difference is very small.
Measured standard deviation between 0.1 and 0.2
pixels for R,G or B.

Best regards --Gernot Hoffmann

[Timothy_...@adobeforums.com]

Thanks Gernot Hoffmann. I'll look into that. And if you are still around Chris Cox, could you maybe just quickly comment on the abovementioned versions ? Thanks.

[Mark_J_...@adobeforums.com]

[David_E_...@adobeforums.com]

The edges are interesting. However, red and green in the 4th and 5th row, at least on my monitor, are not so small in difference with reguard to the population. Anyways it is a interesting post!!

[Mark_J_...@adobeforums.com]

David, I had to laugh so hard about your comment about the MS-Adobe relationship (David E Crawford, "Photoshop thumbnails and CS4" #60, 6 Dec 2008 3:31 pm </webx?14@@.59b6ba1a/59>), hilarious!

[Mark_J_...@adobeforums.com]

Gernot Hoffmann, thanks for doing some tests. Very interesting. If it's possible for you, maybe you can store the final result in a lossless format (png for example), because if we compare jpeg-decoding and store it once again in jpeg, it adds one further uncertainty.

[Mark_J_...@adobeforums.com]

Gernot Hoffmann, I compared the two images in your split-screen image. My comparison is inevitably arbitrary, because I have to decode the jpeg image you posted in some application and we have seen, that there are differences in decoding.

I decoded the jpeg in PS CS3 and compared the left to the right part of the image. I can confirm your findings only partly.

I can confirm this:

* Equal in the grays (last row). [by Gernot Hoffmann]
* Compare the artifacts in the patches and at the edges ! [by Gernot Hoffmann]

But I cannot confirm this:

* Different in the colors (last color row). [by Gernot Hoffmann]
* However, red and green in the 4th and 5th row, at least on my monitor, are not so small in difference with reguard to the population. [by David E Crawford]

The difference image looks as follows:

From this image, you see that the color patches are identical. The only difference result from jpeg artefacts (which differ quite heavily between the two images).

[David_E_...@adobeforums.com]

Maybe I just should have said that I noticed visual differences in colors in the 4th and 5th row, red and green. :)

[Mark_J_...@adobeforums.com]

OK, I see.

[Mark_J_...@adobeforums.com]

As I don't know whether Chris Cox (or anyone else from Adobe) will show up here anytime soon, I post my results regardless. I know how the dialogue with him would have been like anyway:

Mark Peterson: Chris Cox, could you please state whether or not there
are differences in JPEG-decoding between Photoshop CS3, Photoshop 7.0
and Photoshop Elements 1.0.128.0

Chris Cox: We use different decoding implementations in all three of them.

Mark Peterson: How come? The jpeg standard hasn't advanced since Photoshop
7.0. If you had a good working and accurate jpeg decoding implementation,
why the need to change it between releases ?

Chris Cox (knowing that he has to account for the tested differences somehow
and that the following can't easily be refuted): You are wrong on both
points. We have improved our algorithms and made them more precise.

I posted this thread at the same time in another forum and people there took the issue seriously right from the beginning (maybe because in non-Adobe-forums, they don't see Photoshop as a Holy Cow, on which taking a closer look would represent a sacrilege). They were so helpful to convert the original source image to BMP (with applications I don’t have access to) and send me the results.

That's why I'm surprised you got identical results from several different

software packages. (Chris Cox, "Photoshop has problem with .JPEG decoding
??" #63, 5 Dec 2008 5:00 pm </webx?14@@.59b726f1/62>)

Chris, in order to further add to your surprise, let me post these new results. The archive contains the BMPs made by different applications resulting from the conversion from the original jpeg file:

<http://www.fileducky.com/zYBtknUS/>
or
<http://www.mediafire.com/file/e5mtjd3wrnz/JPEG> decoding differences.7z

The results are as follows:

identical images:

- ImageMagick 6.4.6-7-Q16.bmp - Irfan View 4.20.bmp - Microsoft Paint
5.1.bmp - online conversion on the website www.media-convert.com (3 Dec
2008).bmp - PictureGear 5.1.bmp - ACDSee 3.1.BMP - FastStone MaxView 2.2.bmp
- XnView 1.94.bmp

different images:

- Photoshop CS3 (10.0).bmp - Photoshop 7.0.bmp - Photoshop Elements 1.0.128.0.bmp

Note, that the images in the "different images" section are not only different compared to the non-Adobe-products, they are also different compared to each other. Hence my question for Chris Cox.

I find it a bit strange that Adobe claims to have a more precise JPEG decoding algorithm then its competitors, but produce different images for different Adobe products, whereas the competitors produce exactly the same image!

The differences between the three Photoshop BMPs respectively and all the other applications are as follows:

Photoshop CS3 vs. all other programs: 109856 of 250800 pixels different (43,8%)

Photoshop 7.0 vs. all other programs: 109272 of 250800 pixels different (43,6%)

Photoshop Elements 1.0.128.0 vs. all other programs: 109817 of 250800 pixels different (43,8%)

[Mark_J_...@adobeforums.com]

[previous posting updated]

[Buko]

If are going to bold type you need to end the bold.

So it does not keep bolding everyone elses posts.

I can believe you are still talking about this.

[Mark_J_...@adobeforums.com]

I did end the bold, I don't know what went wrong. Did you edit my posting?

Glad that you can believe. :)

[Mark_J_...@adobeforums.com]

It's not only me by the way, there are experts as Gernot Hoffmann and Chris Cox. Several people declared that they find the topic interesting. And Chris, a photoshop engineer found the findings - quote - "surprising". Maybe you want to think twice.

[Mark_J_...@adobeforums.com]

I find it a bit strange that Adobe claims to have a more precise JPEG
decoding algorithm then its competitors, but produce different images
for different Adobe products, whereas the competitors produce exactly
the same image!

Gernot Hoffmann, I hope I don't misunderstand your proceedings leading to the different images you posted, but what strikes me is that - although Adobe claims that the differences occur, because their JPEG decoding algorithm is more precise than the one all the other tested programs here have in common - in the picture on the left side (decoded by Photoshop CS2) the jpeg artefacts are considerably stronger (even visually) than in the picture on the right side (decoded by Netscape 7.1). Particularly in the bottom-most color patch in the pink column and in all the patches of the red and green column. I think that is what David E Crawford meant and I agree with him:

The edges are interesting. However, red and green in the 4th and 5th row,

at least on my monitor, are not so small in difference with reguard to

[Mark_J_...@adobeforums.com]

nothing wrong with your investigation, but it should be based on a reliable
test image with known color
values. You may use a target with sRGB numbers, p.5 here:
<http://www.fho-emden.de/~hoffmann/a3gencolorhigh.pdf>

Gernot Hoffmann, I was trying to use one of your color charts as test image, but I encounter a problem at the outset. The probem seems to stem from color management (as opposed to the jpeg decoding artefacts we are talking about here), so I posted the problem in the color management section: <http://www.adobeforums.com/webx/.59b7381c/13> Maybe you can have a look ? Thanks a lot.

[Gernot_...@adobeforums.com]

Mark,

a new clean start might help:
Photoshop Color Settings RGB=sRGB
Download the target
<http://www.fho-emden.de/~hoffmann/targetrgb.txt>
and rename as targetrgb.eps.
It's pure PostScript, numbers for sRGB but without
embedded profile.
Open targetrgb.eps in PhS and assign sRGB.
Save as targetrgb.tif with embedded profile (for
clarity).
Make JPEG. The numbers of the source are used as
they are. The profile sRGB can be embedded.
Open JPEG in PhS (still using sRGB as working space).
The numbers of plain color areas are of course
slightly modified, besides the artifacts.
Save as BMP or PNG (1).
Open JPEG in other application, either with color
management (use embedded profile) or without and
save as BMP or PNG (2).
Compare (1) and (2) in PhS.

Sorry, in the moment I won't take part in the other
discussion.

Best regards --Gernot Hoffmann

[Mark_J_...@adobeforums.com]

thanks for your participation. I'll try that out in a second.

The numbers of plain color areas are of course slightly modified, besides
the artifacts.

That sentence was crucial for me, because I thought if color management works correctly, aside from the artefacts, the color patches should have the same values, even in a JPEG file.
So you suggest that jpeg compression not only introduces JPEG artefacts but changes the color of entire color patches ?

[Mark_J_...@adobeforums.com]

Hm, what I don't understand is why you suggest my investigation

"should be based on a reliable test image with known color values"

if

"the numbers of plain color areas are of course slightly modified, besides
the artifacts."

If the numbers change, then the whole idea of having exact numbers is compromised.

[Mark_J_...@adobeforums.com]

The file format encoding is pretty standard (there are still some open
issues and a few things that people just guess at for interoperability),
but how the bits are transformed is far from standard. The math is not
well defined: round or truncate, aim for middle or lower limit when dequantizing,
nearest neighbor or interpolated when combining channels, how much precision
is kept in intermediates, etc. (Chris Cox, "Photoshop has problem with

.JPEG decoding ??" #63, 5 Dec 2008 5:00 pm </webx?14@@.59b726f1/62>)

VS.

the decoding of a JPEG is algorithmically unique. Small differences between
the results can happen
for floating point versus fixed point integer arithmetic.
Never tested, but the differences shouldn' be
larger than 1 unit of 255 in R,G,B. (Gernot Hoffmann, "Photoshop has problem
with .JPEG decoding ??" #16, 1 Dec 2008 11:06 pm </webx?14@@.59b726f1/15>)

[John Joslin]

I think someone should warn the next G8 summit. This is earth-shattering stuff!

[Mark_J_...@adobeforums.com]

Thanks to Ramón G Castañeda who contributed to this test by converting the original JPEG source file to BMP with Photoshop CS4, I can include CS4 in the list now. The BMP file Ramon produced is bit-for-bit identical to the BMP file I produced with Photoshop CS3. He made sure, that sRGB was assigned when opening the jpg file, as was the case for all other comparisons here in the thread.

The new list is as follows:

identical BMP images made by:

* ImageMagick 6.4.6-7-Q16
* Irfan View 4.20
* Microsoft Paint 5.1
* online conversion on the website www.media-convert.com (3 Dec 2008)
* PictureGear 5.1
* ACDSee 3.1
* FastStone MaxView 2.2
* XnView 1.94

different images made by:

* Photoshop CS4
* Photoshop CS3
* Photoshop 7.0
* Photoshop Elements 1.0.128.0

Feel free to convert the original JPEG source file to BMP with a program that is not yet listed here and post the resulting BMP file here, if you want to contribute.

[Gernot_...@adobeforums.com]

Mark,

using a target with well-known RGB values is probably
a better starting point than using a photo, also for
the discussion.

Again, why JPEG can change the colors, the example:

C = round (17*round(C/17))

The right C is an original Cb or Cr value after
applying the Discrete Cosine Transform, let say,
for simplicity, a color number.
Division by 17, followed by rounding (or truncation ?)
is called Quantization. 17 is here an example.
These numbers are in quantization tables, as parts of
the image file.
Multiplication by 17 and rounding belongs to the recon-
struction (decoding). The left C is the decoded value.
This happens sometimes without error, sometimes with:
72 = round (8*Round (72/8))
68 = round (17*Round (72/17)) <> 72

<http://www.fho-emden.de/~hoffmann/jpeg131200.pdf>

IMO, it had been shown that different programs create
different results, though with very little deviations.
Not the least relevant for high-quality compression.
It could not be proved that Photoshop delivers less
artifacts.

Best regards --Gernot Hoffmann

[Ramón_G_Castañeda@adobeforums.com]

Just for the record:

I've just read this thread for the first time. The reason my name comes up here now is a thread Mark started over in the Color Management forum.

Mark J Peterson, "JPEG and color management" #1, 8 Dec 2008 8:45 pm </webx?14@@.59b7381c/0>

This excerpt from my next-to-last post there sums up my conclusions on this subject:

…if you run your cursor in the BLACK rectangle as per step #7 above, over
the areas where we know now that the pixels aren't quite black, you'll
see values with minimal deviations from pure black, as I noted above in
post #12 (values like 0,0,1 or 1,0.1 or 1,0,0).

I am surprised that the variations in color rendition are that insignificantly
small.

In any event, I'm glad I don't need JPEGs myself.

A little earlier, I had stated:

Mind you, I am a notorious JPEG hater and avoid them like the proverbial
plague. I only use them to upload screen shots or other images to Pixentral
to illustrate a point.

and

I must admit that I still don't quite grasp your methodology, nor do I
understand how all that translates into a color management issue rather
than a JPEG compression weakness.

It seems to me that Mark is on the wrong track. The comments here by Chris Cox, Gernot Hoffmann and others appear to support this view of mine.

(Verflixt nochmal, es tut mir geradezu weh, den akademischen Titel weg zu lassen, Gernot!)

[Mark_J_...@adobeforums.com]

It could not be proved that Photoshop delivers less artifacts.

No, the goal was never to find out if Photoshop delivers more or less artefacts than other programs, but to find out if there are any differences at all and why they occur.

Having said that, look at your own picture, don't you think that :

in the picture on the left side (decoded by Photoshop CS2) the jpeg artefacts
are considerably stronger (even visually) than in the picture on the right
side (decoded by Netscape 7.1). Particularly in the bottom-most color
patch in the pink column and in all the patches of the red and green column.

I think that is what David E Crawford meant and I agree with him: (Mark
J Peterson, "Photoshop has problem with .JPEG decoding ??" #84, 8 Dec
2008 11:14 pm </webx?14@@.59b726f1/83>)

The edges are interesting. However, red and green in the 4th and 5th row,
at least on my monitor, are not so small in difference with reguard to

the population. Anyways it is a interesting post!! (David E Crawford,
"Photoshop has problem with .JPEG decoding ??" #73, 8 Dec 2008 9:33 am
</webx?14@@.59b726f1/72>)

[Mark_J_...@adobeforums.com]

.

[Mark_J_...@adobeforums.com]

the decoding of a JPEG is algorithmically unique. Small differences between
the results can happen for floating point versus fixed point integer arithmetic.
Never tested, but the differences shouldn' be larger than 1 unit of 255

in R,G,B. (Gernot Hoffmann, "Photoshop has problem with .JPEG decoding

??" #16, 1 Dec 2008 11:06 pm </webx?14@@.59b726f1/15>)

Look for yourself, the differences are much bigger than 1 unit of 255, sometimes reaching 30!

The math is not well defined (Chris Cox, "Photoshop has problem with .JPEG

decoding ??" #63, 5 Dec 2008 5:00 pm </webx?14@@.59b726f1/62>)

And come on Chris, do you really suggest that differences this big occur just because "math is not well defined" ?

[Mark_J_...@adobeforums.com]

It could not be proved that Photoshop delivers less artifacts.

No, but it was proven, that a significant amount of widespread programs decode the jpeg to the same image and the Adobe products don't. This WAS proven.

[Mark_J_...@adobeforums.com]

(Verflixt nochmal, es tut mir geradezu weh, den akademischen Titel weg
zu lassen, Gernot!)

I couldn't find any academic title in your papers Gernot Hoffmann, I can use it here in the forum if you want, it wasn't meant to be any disrespect :)

[Mark_J_...@adobeforums.com]

why JPEG can change the colors, the example:

C = round (17*round(C/17))

The right C is an original Cb or Cr value after applying the Discrete
Cosine Transform, let say,
for simplicity, a color number.
Division by 17, followed by rounding (or truncation ?)
is called Quantization. 17 is here an example.
These numbers are in quantization tables, as parts of
the image file.
Multiplication by 17 and rounding belongs to the recon-
struction (decoding). The left C is the decoded value.
This happens sometimes without error, sometimes with:

72 = round (8*Round (72/)

68 = round (17*Round (72/17)) <> 72

Thanks for the thorough explanation. Given all your scientific papers about that and that maths is not my strongest suit, I won't argue about that, but what I don't understand is this:
round (17*Round (72/17)) equals indeed 68, but this would mean that all decimal places are discarded in the course of the calculation. Normally one would expect that at least some decimal places are kept till the end and only discarded at the very end of the decoding process.

Anyway, can these dequantization errors possibly account for the dramatic differences that are shown in the table above ?