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 … ?
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.
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:
Learn how to rescue details, remove flyaways, add volume, and enhance the definition of hair in any photo. We break down every tool and technique in Photoshop to get picture-perfect hair, every time.
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 … ?
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.
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:
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.
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?
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: 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 ?!??
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:
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 ?
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.
@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?
@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.
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.
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.
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 :
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):
– 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)
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.
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.
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 …
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.
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.
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.
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.
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.
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.
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.
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.
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 ?
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.
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.
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.
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 ?
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.
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).
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.
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:
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.
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.
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.
"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.
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.
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/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.
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.
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.
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.
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, 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/59>), hilarious!
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.
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).
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 dont 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/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:
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%)
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.
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 the population. Anyways it is a interesting post!!
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.
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.
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 ?
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/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/15>)
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
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.
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
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.
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/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!)
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/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/72>)
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/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/62>)
And come on Chris, do you really suggest that differences this big occur just because "math is not well defined" ?
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.
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 ?
(Mark, you completely misconstrued my remark addressed to GH in German. I was commenting on how difficult it is for me to follow his wishes and address him simply as Gernot. The exact opposite of what you thought.)
Ramon, I didn’t misconstrue your remark. Where do you see any interpretation of it? I quoted it that’s all. Afterwards I said something on my own. I think I can do that, no disrespect 🙂
No, no disrespect, but your comment was diametrically opposed to GH’s wishes. If you didn’t misconstrue it, then shame on you for deliberately twisting it around.
I didn’t ever mention my title in posts here – it shouldn’t be used.
There was something misssing (replaced by a smiley): 72 = round ( 8*Round (72/ 8)) 68 = round (17*Round (72/17)) <> 72
The calculation inputs and outputs are integer. The lightness is packed into an unsigned byte 0..255 and the Cb,Cr values into signed bytes -128..+127. The output of the DCT is also coded by bytes, but intermediate floating point arithmetic cannot be excluded.
I think a comparison of single pixels isn’t correct because of the different artifacts. You had alread this almost uniform gray difference (subtract) image. The standard deviation was up to 2 units. This says, almost all values differ by not more than +-4 units, but mostly less.
There is another aspect which might explain the edge enhancement: JPEG is based on 16 x 16 pixel blocks. If width and height are not integer multiples of 16, then PhS seems to add hidden columns and rows. Are these at the right and at the bottom ? Or are they evenly distributed to all edges ? A misinter- pretation would make a difference.
Given that half the people here have problems understanding where you’re headed, perhaps you could take a little time to explain why this is so important to you and why you need to know this? Other than purely academic curiosity I mean. Maybe we are missing something.
Re-reading the entire thread shows that the general consensus here can be summed up as "yes, and so what?"
Now, if you had been talking about psd, tiff or other non-lossy formats changing as much as one pixel, you bet we’d be all ears. But jpegs?
No, no disrespect, but your comment was diametrically opposed to GH’s wishes. If you didn’t misconstrue it, then shame on you for deliberately twisting it around.
Ramon, please. Can we stop the off-topic posts. Why shame on me ?? I just quoted your text, that’s all. I didn’t interpret or construe your words in any way. I didn’t make any claims/statements about YOU or what YOU SAID. okay? Do you know the french word "à propos" or the english equivalent "speaking of"/"on the subject of" … that means on picks up a subject and says something about it. It doesn’t mean at all that one agrees NOR DISAGREES with what was said previously. It just means, that the subject is somehow connected, okay? And in particular if Gernot Hoffmann is in reality Dr. Gernot Hoffmann and because you are good friends he doesn’t mind if you call him Gernot, that doesn’t mean that he couldn’t think that me – a completely different person than you Ramón – should rather show respect for his title. I said it for sake of completeness. Can we please move on now and Ramón please stop these off-topic posts. Thank you for your understanding.
That would be Professor Dr. Gernot Hoffmann to you and me, and he has categorically stated his title shouldn’t be used.
Let me give you one piece of advice, whoever you are, Mark J Peterson, don’t you ever presume to lecture me again or to tell me what to do or not to do. I will deal with you in whatever fashion I deem fit, and if you don’t like it, you can just stuff it.
I’m not afraid of being banned from a forum, I’ve been run out of much better and finer places. So I won’t bite my tongue, and I do not suffer fools lightly.
From some of your comments in other threads, for instance where you suggested you wanted to edit your monitor profile, it’s clear that you’re no color geek heavyweight. I’m an old geezer with absolutely nothing to lose, and I’ll be damned if I’m going to put up with you. The s.o.b. who can tell me what to do or when and how to speak or write hasn’t been born.
Try to just leave me alone and I’ll leave you alone in return.
The calculation inputs and outputs are integer. The lightness is packed into an unsigned byte 0..255 and the Cb,Cr values into signed bytes -128..+127. The output of the DCT is also coded by bytes, but intermediate floating point arithmetic cannot be excluded.
72/17 = 4,23529411… 17*4 = 68
If I understand you correctly, you wanted to demonstrate that rounding in intermediate steps can lead to different final outcome. But my point was, that rounding in intermediate steps should be avoided and only done at the very end of the decoding process (i.e. when calculating the final R,G,B values).
I think a comparison of single pixels isn’t correct because of the different artifacts.
I think, we must not see it that way. The artefacts were mainly introduced by previous JPEG-encoding, but they are not part of the test now. For the sake of this test, artefacts are only differences/deviations etc. introduced during decoding, not during the previous encoding.
You had alread this almost uniform gray difference (subtract) image. The standard deviation was up to 2 units. This says, almost all values differ by not more than +-4 units, but mostly less.
Sure, but from the table you can see that some values are +-30! I simply cannot conceive how it is possible, that based on the same jpeg filePhotoshop displays one pixel as (55,122,227) and 8 other tested programs all display the very same pixel with completely different values: (71,120,197)
There is another aspect which might explain the edge enhancement: JPEG is based on 16 x 16 pixel blocks. If width and height are not integer multiples of 16, then PhS seems to add hidden columns and rows.
Things get stranger and stranger I think. Photoshop adds hidden columns and rows? Never heard of that, but if Photoshop adds things, then that might account for the differences between Photoshop and all other tested programs.
Are these at the right and at the bottom ? Or are they evenly distributed to all edges ? A misinterpretation would make a difference.
I don’t know where they are. How can I know if they are "hidden". I don’t really know what to do with your very last statements about hidden columns and rows. I posted a ton of "difference-pictures" here in this thread. I invite you to see for yourself where any "hidden rows and columns" are. I don’t have any more information than can be seen in the pictures I posted here.
Ramón, in post #98 I didn’t say anything about you and in post #107 I repeated that I didn’t interpret anything you said in any way and very friendly begged you to stop off-topic posts. Therefore I don’t understand why you feel attacked.
There is another aspect which might explain the edge enhancement: JPEG is based on 16 x 16 pixel blocks. If width and height are not integer multiples of 16, then PhS seems to add hidden columns and rows. Are these at the right and at the bottom ? Or are they evenly distributed to all edges ? A misinter- pretation would make a difference.
A misinterpretation of what? Of the "hidden columns and rows" Photoshop adds? Actually, the during decoding the JPEG file should be interpreted, not some hidden columns and rows Photoshop adds, in my opinion.
OK, as requested by Freeagent (and this is a good idea), I think I should quickly sum up what we have discovered so far throughout this thread. Letting aside the details and put simply, the bottom line is this:
We have a JPEG file. This is our starting point. We converted this JPEG file to BMP with 8 different widely used programs (see list above) and the resulting BMP images were 100% identical. On the other hand, the different Photoshop versions we tested, create different BMP files (both different from the 8 other identical BMPs and different from each other!). For me, these results were unexpected, as I assumed that opening a JPEG file would be a lossless process (as opposed to the lossy process of saving a JPEG file). The discovered differences are quite dramatical: when opening the original JPEG source file in Photoshop there is for example one pixel with RGB values (55,122,227) but when opening the very same JPEG file in 8 other widely used applications, the very same pixel has a value of (71,120,197) (see the table above for other examples). Since a JPEG file cannot be interpreted in a completely arbitrary fashion and given that there are clear rules to follow, such considerable differences suggest that either Photoshop or all the other 8 applications (!?) have a flawed JPEG-decoding algorithm.
I think it’s important to know, if Photoshop has problems reading JPEG files. And as long as we don’t know what really happens, we can’t even know for certain that only JPEG images are affected by the problem we discovered.
OK, Gernot Hoffmann, I try to do some comparisons based on the EPS file you posted. I can open and convert it with some other applications I have, but when opening in Photoshop CS3 I’m first presented with a windows titled "Rasterize Generic EPS Format" in which I would select the default values (width: 843 pixels, height: 596 pixels, resolution: 72 pixels/inch, mode: RGB color, anti-aliased: off, constrain proportions: on), but afterwards I get the error: "Could not complete the request because the parser module cannot parse the file". Even selecting LAB color, or any other option doesn’t help, I tried everything. I just thought I let you know, since it is your file. But don’t worry about it otherwise, I can open the file with other programs.
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.
OK, I followed your instructions. I just took the color chart from your pdf file as I had already used it in the other thread ( Mark J Peterson, "JPEG and color management" #1, 8 Dec 2008 8:45 pm </webx?14/0> ) :
The differences between Photoshop and the 8 other applications are as follows (different pixels are shown in red):
There are clearly differences between the JPEG-decoding algorithms. By the way, any idea why patch D9 is the only one that has a different color ?
But what is far more interesting, is the following: The JPEG file used as source file for the comparison above was produced with color subsampling DISABLED. But the following comparison is based on a JPEG file with color subsampling ENABLED and the considerable differences this time suggest, that Photoshop has particular problems with decoding JPEG files with color subsampling (as was probably also the case for the "cinema image"):
thanks for the greetings. As well all the best to you.
Mark,
for me, this thread is far more interesting than the discussions about CS4 misbehaviour.
Let me sum up: Photoshop’s JPEG decoding is different to the decoding of other programs. Calculating the difference by Subtract, followed by the calculations in Histogram shows, that the standard deviation is very small. This is so for High Quality JPEGs.
Less Quality JPEGs are showing for all decodings visible artifacts with different patterns. Artifacts are belonging to JPEG per se, and therefore it’s IMO no more useful to interprete the differences numerically – the JPEGs are anyway wrong, therefore it doesn’t matter how much they differ (in limits …).
I admit that’s it’s difficult to follow all steps in this investigation. But there is IMO one outcome ‘by the way’: PhS doesn’t create especially few or small artifacts, and perhaps the Adobe engineers should have a look at this phenomenon.
The introduction of an assumed source of errors ‘hidden rows and columns’ needs some further explanations: If PhS adds rows and columns at all edges – in order to create width and height as multiples of 16 – , but the decoding program assumes these at the right and bottom edge, then the interpretation would be indeed different. The blown up file has to be transmitted, the original size has to be shown.
Please let us slow down (maybe further investigations in the background). Photoshop doesn’t have ‘problems’ with JPEG decoding.
Gernot Hoffmann, as a side note: 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 ?
And Gernot Hoffmann, I don’t want to be disrespectful at all, and I really hope you won’t take it that way, but at first you said :
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/15>)
And correct me if I’m wrong, but this time you were clearly not talking about the standard deviation, but you meant that the difference for EACH pixel shouldn’t be larger than 1 unit of 255 in R,G,B.
But later on, we discovered differences 30 times as large ! And this was just an image I discovered accidentally, other images could yield even considerably bigger differences ! So maybe we talk about 40-50 times or more the difference that you initially expected. And saying now that the standard deviation is – in your view – "very small" doesn’t take anything away from that fact, isn’t it ?
for me, this thread is far more interesting than the discussions about CS4 misbehaviour.
I was trying to avoid any premature conclusions, but this thread has now >122 postings and I have verified a whole lot of values, difference-images, etc. and for me everything points to this conclusion. But eventhough I don’t use JPEGs I would be happier if Photoshop could read JPEGs correctly, so I’m all ears for diverging conclusions.
Let me sum up: Photoshop’s JPEG decoding is different to the decoding of other programs.
Yes. Different to the decoding of ALL other tested programs which ALL decode the JPEG image identically !
Calculating the difference by Subtract, followed by the calculations in Histogram shows, that the standard deviation is very small.
The standard deviation is :
Red 1.16 Green 0.60 Blue 1.76 (not a simple Gaussian bell) Lum. 0.24
And you said the standard deviation for blue *might* be worth further discussions.
This is so for High Quality JPEGs. Less Quality JPEGs are showing for all decodings visible artifacts with different patterns.
No, the "cinema image" was the only JPEG we examined (before getting to your color chart), and the "cinema image" is certainly not a High Quality JPEG.
Artifacts are belonging to JPEG per se, and therefore it’s IMO no more useful to interpret the differences numerically – the JPEGs are anyway wrong, therefore it doesn’t matter how much they differ (in limits …).
I don’t think it’s scientifically correct to say "JPEGs are anyway wrong". Let me explain: When you save a .jpeg file you introduce artefacts, or let’s just say differences. I think nobody would argue about that. Now we have proven that different programs (Photoshop on one hand and all the other programs on the other hand) decode the JPEG file differently. As a consequence there is no other possibility than either Photoshop or all the other programs (or both) introducing further differences. We therefore have proven that during JPEG decoding additional differences are introduced, independent from the differences introduced during JPEG encoding. As there are these two distinct categories, it does make sense to analyze how much this second category differs (in limits …) between the programs. This was the purpose of the table I posted.
I admit that’s it’s difficult to follow all steps in this investigation.
As far as the methodology is concerned ? What is unclear ? I posted all the source files and intermediate results as image files and/or numeric values here in the thread.
The introduction of an assumed source of errors ‘hidden rows and columns’ needs some further explanations: If PhS adds rows and columns at all edges – in order to create width and height as multiples of 16 – , but the decoding program assumes these at the right and bottom edge, then the interpretation would be indeed different. "The blown up file has to be transmitted, the original size has to be shown."
Don’t know what the very last sentence means, but the remainder of your explanation now somehow rings a bell. Remember the difference images I posted in #3 #25 #54 and #79 ? It might be a coincidence (given the inherent jpeg zoning) but the patterns visible in these images indeed show squares with a side-length of 16 pixels. Look to these postings for the real-size image. I display a enlarged version (200%, nearest neighbour) here, to make the patterns more obvious:
Photoshop doesn’t have ‘problems’ with JPEG decoding.
Depends on how we define "problems". Photoshop can open JPEGs. If that’s the definition … But you seem to agree, that:
But there is IMO one outcome ‘by the way’: PhS doesn’t create especially few or small artifacts, and perhaps the Adobe engineers should have a look at this phenomenon.
I also see it that way. Especially if I look at the image you posted here:
Please let us slow down (maybe further investigations in the background).
Don’t worry, I think I’ve put everything I have on the table. From my side I have examined everything I needed and have drawn my conclusions from that. Now if you want to make further investigations in the background, of course I would be very very interested to see further developments. And I’d be also interested to hear Adobe’s official stance in light of all the new findings.
please use pixentral to post thumbnails guys! the large images make the thread impossible to read without jumping left and right all over the browser window!
Normally I don’t post images that big. But do you have less than 1200 pixel horizontal monitor resolution ? (PS: pixentral deletes images after 30 days)
Chris, apparently all you are able to say is "you don’t understand" … that’s a long thread in which not few aspects were examined, questions raised and striking differences exposed. In between you admitted, that yourself was quote "suprised".
And now, all of a sudden you pretend that "nothing happened". You are funny, you now that?
You don’t explain anything in your response, instead you resort to condescending finger-pointing "I know, you don’t know", like before in this thread, but without dealing with the subject at all, which suggests you just don’t know any answer.
And its equally ridiculous and populist to repeat thought-terminating clichés ( http://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A9) like jpeg is lossy, because that never was the point in this discussion and people who, unlike you apparently, really read the thread do understand that.
And its also ridiculous to even remotely suggest that scientists like Dr. Gernot Hoffmann would find this thread quote very interesting and would ambitiously participate in the discussion, if the point was jpeg is lossy.
And dont think just because you are an acclaimed programmer people dont realize that.
Photoshop is certainly an incredibly amazing program and like millions of other users Im very glad to use it. As a software engineer you have every reason to be proud of your baby. But sometimes, people here get the impression, that you regard it as a Holy Cow and are blind to any potential shortcomings. Just look at the other thread Ho, "Photoshop thumbnails and CS4" #56, 6 Dec 2008 1:32 pm </webx?13/55> about PSD files and thumbnails, where the Microsoft team member offered you his help, brought up possible solutions, gave you his e-mail, offered to introduce you to a revelant colleague, etc.. Quite a few people expressed their surprise and said they found you to be quite resistant:
Reading this current exchange, It seems that we have a Microsoft team member who is willing to help (almost bend over backwards) and the Adobe team member who seems to be very resistant. I would hope that isn’t the pervasive philosophy within the Adobe team.
You just prove it here once again.
Especially when you say I should file a bug report. If you were taking potential issues that your users find seriously, you would have forwarded the matter to the relevant department yourself. And even if its only to make sure that there are indeed no problems with Photoshop. Dont take it from me. As far as I can see from his papers, Dr. Gernot Hoffmann is an expert concerning JPEG algorithms. Take it from him:
But there is IMO one outcome ‘by the way’: PhS doesn’t create especially few or small artifacts, and perhaps the Adobe engineers should have a look at this phenomenon. (Gernot Hoffmann, "Photoshop has problem with .JPEG decoding ??" #122, 9 Dec 2008 8:29 am </webx?14/121>)
But you know what Chris, I never work with jpegs, so personally I couldnt care less if Photoshops JPEG decoding implementation is flawed or not. Its Adobes paying customers. Not mine.
And I tell you something else Chris. Im a doctor. If you discover problems and come to my practice and seek advice/explanations, would you feel especially overhappy and nicely treated if, instead of helping you or explaining anything, I only say you just prove that you dont understand medicine ? See, Im an expert in a different field, and as much as I dont expect you to have the same knowledge in my domain, I am not expected to have yours in yours. And finger-pointing in this regard is only childish, Chris.
Still waiting for a single factual/to the point argument on your behalf.
Mark – so far, you’re just babbling nonsense. You have no idea what you are talking about, and don’t appear to be interested in learning more. I don’t know what your problem is, but you have not provided any evidence of a JPEG problem other than "different JPEG decoders produce different bits" – which is just stating the obvious.
Of course I am very interested in learning more. But all you ever say is "you don’t know anything, you are just babbling nonsense". What should I learn from that ??
We have provided enough evidence. And don’t think nobody realizes that you first call it, quote, "surprising" and now "obvious". That’s just embarrassing.
All you are arguing here is that you don’t understand the JPEG "standard", or that JPEG is lossy. I suggest you learn more about JPEG image compression. (Chris Cox, "Photoshop has problem with .JPEG decoding ??" #127, 9 Dec 2008 11:58 am </webx?14/126>)
All you are arguing here is that "JPEG is lossy" – after 131 postings – which demonstrates that you didn’t understand this thread. I suggest you learn more about this thread by reading it when you are concentrated.
This is how Adobe programmers treat you here, if you ask specific, technical questions … they get personal:
"so far all that you have shown is that you do not understand…" (Chris Cox, "Photoshop has problem with .JPEG decoding ??" #39, 4 Dec 2008 5:09 pm </webx?14/38>)
" All you are arguing here is that you don’t understand…" (Chris Cox, "Photoshop has problem with .JPEG decoding ??" #127, 9 Dec 2008 11:58 am </webx?14/126>)
"so far, you’re just babbling nonsense. You have no idea what you are talking about,… I don’t know what your problem is," (Chris Cox, "Photoshop has problem with .JPEG decoding ??" #129, 9 Dec 2008 8:20 pm </webx?14/128>)
And this is how helpful hobby freeware programmers are when seeing the very same thread in another forum. I let you make your own judgements about friendliness/karma. But the difference in willingness to contribute on a technical/factual level (as opposed to a populist one) is striking. I just got the following post today:
The differences are related to dct method and fancy upsampling.
The Discrete Cosine Transform (DCT) method works with blocks of 8×8 pixels and all those calculations by approximation affects visual representation.
Here is part of a header file
typedef enum { JDCT_ISLOW, /* slow but accurate integer algorithm */ JDCT_IFAST, /* faster, less accurate integer method */ JDCT_FLOAT /* floating-point: accurate, fast on fast HW */ } J_DCT_METHOD;
As you can see there are different methods and programs may use one of them.
The JPEG default colorspace is YCbCr. The components are downsampled during compression by the chroma factors and later upsampled during decompression. This upsampling is handled differently by different programs.
Fancy upsampling is a option of IJG library to better approximate the original component values. I don’t know what Photoshop is using but I heard it simply uses a fast method. The original IJG library uses also some kind of resampling methods for approximation like nearest neighbor (box, pixel replication), or bilinear interpolation (triangle). They can introduce pixelation or blurring.
The IJG code is very technical and it takes someone with strong mathematical and programming knowledge to understand it.
So Chris, instead of just repeating "you don’t know" you could have said for example if Photoshop uses JDCT_ISLOW, JDCT_IFAST or JDCT_FLOAT. That would have been a starting point.
I don’t know what Photoshop is using but I heard it simply uses a fast method.
No guys, you prove the contrary. And Gernot Hoffmann is still here. At least he looks at it from a technical point of view. Unfortunately that’s rare here. And from the post above you can see that other forums have other mentalities.
Anyway, feel free to contribute. Otherwise I would very kindly and friendly ask you to set aside off-topic posts if possible.
Mark, What we’re dealing with here is two different implementations of the JPEG standard. IrfanView (and, I suspect, the other programs you mentioned) uses the ubiquitous IJG implementation. If you look at the compressor side of the codec, you have a quality slider with a range of 1-100. Adobe has their own implementation with a quality slider with a range of 1-12. If I save an image at best quality with the IJG codec and then save the same image with the Adobe codec, no matter how I try to change the settings, I can’t match the file size, much less the actual pixels. They are two independently developed codecs. They can decompress each others saved files but using their own internal algorithms. It becomes completely subjective from there. If you like the Adobe results, use the Adobe codec. If you like the IJG results, use a program that uses that codec. Both will give you an an aproximation of what the photographer saw as he tripped the shutter. Nothing will reproduce what he actually saw.
I saved it as a TIFF file with Photoshop. Let’s say this TIFF file is our starting point.
Converting the TIFF file to JPG in Photoshop CS3 with highest quality settings (12) results in : 6.408.804 bytes
Converting the TIFF file to JPG with the IJG implementation and quality 100 results in: 7.147.035 bytes
Converting the TIFF file to JPG with the IJG implementation and quality 100 + color subsampling disabled results in: 10.025.083 bytes
I used baseline format for all to have a fair comparison. OK, so far for the encoding. Interesting.
But as this thread focuses on JPEG decoding, for me it seems as if with your take on it there were three different opinions (if I interpret all correctly):
1) Gernot Hoffmann, who seemed to suggest that the decoding of JPEG is algorithmically unique and that the math is well-defined enough so that differences shouldn’t be larger than 1 unit of 255 in R,G,B:
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/15>)
2) Chris Cox, who also states that the jpeg standard per se is well-defined but who suggests that the math is far from well-defined and that this would account for the differences we encountered:
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/62>)
3) Torkel Tweite, who suggest that the decoding is not algorithmically unique and that there are in fact two different implementations of the JPEG standard and two independently developed codecs:
What we’re dealing with here is two different implementations of the JPEG standard. IrfanView (and, I suspect, the other programs you mentioned) uses the ubiquitous IJG implementation. If you look at the compressor side of the codec, you have a quality slider with a range of 1-100. Adobe has their own implementation with a quality slider with a range of 1-12. If I save an image at best quality with the IJG codec and then save the same image with the Adobe codec, no matter how I try to change the settings, I can’t match the file size, much less the actual pixels. They are two independently developed codecs. They can decompress each others saved files but using their own internal algorithms. It becomes completely subjective from there.
Torkel Tweite, I think from this account, it is not all surprising that all the tested applications decode the original JPEG source file to the same image, given that they probably all use the "ubiquitous IJG implementation". If this is true, then it’s hard to understand why Chris Cox says:
That’s why I’m surprised you got identical results from several different software packages.
I beg to differ. When seven consecutive messages come from one person, then yes, you are on your own. You have spiked some interest from Gernot, because color and file formats are his specialty, but the rest of us could care less.
You demonstrate impressively that you have not read the thread, or you would know that I said I don’t use jpegs at all.
I just can’t imagine a seasoned pro even giving any of this a first thought.
Yes? You don’t say! That’s because there’s a lot of things you just can’t imagine. For example that this is not about color management:
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. (Buko, "Photoshop has problem with .JPEG decoding ??" #27, 3 Dec 2008 8:15 pm </webx?14/26>)
…. and everyone here agrees that this has absolutely nothing to do with this topic.
Zebra uses floating point arithmetic for numerical calculations like RGB to YCbCr, DCT, IDCT, YCbCr to RGB and color subsampling: 4 boxes 8×8 to 1 box 8×8 for CbC by averaging (encoding) and 1 box 8×8 to 4 boxes 8×8 (decoding).
Freeagent, I see you have carefully read this thread.
No one questions that you are probably right… You’re just kicking in doors that are already WIDE open.
I can’t remember anyone saying I am right, but didn’t make any claims anyway, I was only asking questions in the first place. And for a long time nobody seemed capable of offering answers beyond "jpeg is lossy" (which wasn’t the point). Afterwards Gernot Hoffmann showed up and he is obviously examining the issue and I hope I don’t forget anybody else, but I think the first real part of an answer came with post #135 here (which was a copy/paste from post #3 in another forum, which speaks volumes) and then with post #140 here.
Coincidentally, both suggest that Photoshop’s JPEG implementation is faster and of lesser quality:
If I save an image at best quality with the IJG codec and then save the same image with the Adobe codec, no matter how I try to change the settings, I can’t match the file size, much less the actual pixels. (Torkel Tweite, "Photoshop has problem with .JPEG decoding ??" #140, 10 Dec 2008 4:00 am </webx?14/139>)
JDCT_ISLOW, /* slow but accurate integer algorithm */ JDCT_IFAST, /* faster, less accurate integer method */ JDCT_FLOAT /* floating-point: accurate, fast on fast HW */ I don’t know what Photoshop is using but I heard it simply uses a fast method. ( post #135, 10 Dec 2008 1:54 am </webx?14/134>)
If everyone agrees that Photoshop’s JPEG decoding algorithm is worse than IJG, than we have found a reason for the differences we discovered and can certainly put this matter to rest soon. (Although I’ll stick around if Gernot Hoffmann discovers interesting things).
Mark J, you are correct. Adobe obviously is not. Cox, I don’t understand his problem but if 10% of your buddies got the boot you may be a little disgruntled, too.
The *FAST* etc. things you asked about make no real difference, not to the wide variances in pixel levels you’ve shown. (Nevermind that none of the different Adobe products even produce the same out!)
You must be new here. The same clowns do the same to all topics that show bugs in the Adobe products. Don’t go by what Cox does here; he’s not someone in a position to do anything about it. Go through the motions by filing a bug ("wish") report using the regular channels. Call if you have the time and make a big deal about it that way. It does no good here. Bugs are not dealt with here.
As to buko, Joslin, Levine, dots, and the few others – really, only a few but they just can’t shut up – you must ignore them. They only do what they do because they have nothing else to do. Have pity on them, not contempt.
"Mr/Ms Here" is obviously someone who knows this place well but doesn’t have the courage to speak his/her mind without registering under a different user name.
The deltas around the macro block edges is too weird to ignore. The room for interpolation of YUV 411/422 to RGB 888 would not account for that. If you want to comment on that, go right ahead. If you want to waste bytes about bad karma, why not keep that to yourself.
"Mr/Ms Here" is obviously someone who knows this place well but doesn’t have the courage to speak his/her mind without registering under a different user name. That’s just lame.
I have been "Phos" since 1972. More people KNOW me as Phos, than as my birth certificate name.
You’re trotting out a flaccid argument that holds no water, Mark. I don’t change my name here, or anywhere else, just to ruffle feathers. I have the balls to say what I meanand I mean what I sayto any person here, under the name I’ve been using in meatspace and online for 36+ years.
I AM Phos, have been Phos for bloody decades, and will continue to BE Phos until I FKN die. I guarantee you it’ll be at the top of my obituary listing.
Apart from slagging off people who genuinely try to help here, I haven’t seen the "ex-spurt" handing out much constructive advice round in this forum.
The regulars like to poke fun at the MJPs of this world, because they pursue an insignificant, academic topic at great lengths as if it were of earth-shattering significance.
He was told "Yes yes, there’s a discrepancy but it isn’t hurting anyone". He was told his conversation largely with himself was becoming a bore.
I hold no grudge against the guy; he is entitled to tilt at windmills if he wants to. I just think he should be aware that people tune in to this thread now, not to learn something new about JPEG coding, but to have a laugh.
Buko, you have a senior moment. You don’t remember what you asked less than 24 hours ago (not to mention the answer):
If you are doing color critical work why are you using Jpegs? (Buko, "Photoshop has problem with .JPEG decoding ??" #148, 10 Dec 2008 7:49 am </webx?14/147>)
You demonstrate impressively that you have not read the thread, otherwise you would know that I said I don’t use jpegs at all. (Mark J Peterson, "Photoshop has problem with .JPEG decoding ??" #149, 10 Dec 2008 8:29 am </webx?14/148>)
Well then if you are not using them for color critical work, and you know Jpeg is a lossy format and you only use Jpeg to SFW one time as a last step in the process, This entire conversation you’ve been having with yourself, although quite entertaining, has been pretty much a waste of time.
