What's new
By:
Photoshop Gurus Forum

Welcome to Photoshop Gurus forum. Register a free account today to become a member! It's completely free. Once signed in, you'll enjoy an ad-free experience and be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

CS5 is corrupting some pixel values in jpg images


Just for yours and Tom's information. I loaded this file in PS CC. I looked at the coordinates and sampled the referenced colors. I did not go to the trouble of recording each of them, but some match your numbers, some don't. The first one for example, taking a point sample at 0y and 16x reads 6,0,0. where you say it supposed to be 5,0,3. but at 31,0 , I get 2,2,2. Something is amiss somewhere here and if any one can figure it out, it will be Tom. I will watch this thread as I am interested in what the answer is.
 
Tom Mann said:
To summarize my take on this, I stated two ways in which such a discrepancy could arise:

a) JPG compression errors (aka, "JPG artifacts"); and,

b) color space tagging / conversion problems.

We have not yet ruled out (a). If this is the only problem, the existence of a difference between the value reported by your PHP code and the value reported by one of the standard image editing programs would depend on whether the same JPG decoding library function was called by both PHP and the image editors. I doubt they are, so I still think this is a very viable possibility.

Nor have we ruled out (b), either. As I have now stated multiple times, the easiest and most direct way to rule (b) in or out experimentally is to first settle whether or not (a) is a possibility. You can easily do this if you either (1) generate an image consisting of big blocks of color where there will be no compression artifacts in the middle of these blocks, or (2) conduct a comparison using a file format like lossless TIFF (that has no compression artifacts) instead of using JPGs.

With respect to your question about how to force PS not to do any color space conversions, one can turn off color management in PS by using the "edit / assign profile / do not color manage" command. However if your input file truly is sRGB, and your working color space is also sRGB, then you should see no difference with it on or off. I tried this, and obtained the expected behavior. Since you assured me that this was indeed the case for your actual files, I'm starting to think that a color space conversion problem is less likely, but a simple test with the color blocks or the lossless TIFF files would immediately resolve this. To be honest, I don't understand why you are resistant to doing this since it would only take a couple of minutes of your time to do.

I am not going to do it for you because (i) I have done closely related tests in the past and know that JPG artifacts can easily cause RGB shifts of ten or twenty RGB units if significant compression is involved; and (ii) I don't have your actual file, or even a clue as to how much spatial structure it contains, and hence how severe the artifacts are likely to be.

T
Click to expand...

1) Yes, it's possible that PHP, PSP and Gimp are using the same decoding library. It's also possible that ps is not following the sRGB standard exactly.

2) So you think PS is identifying jpg artifacts and change those pixel values? How can PS decide if a pixel is a part of an artifact or not?

3) Already did that, when I did the compare test in php, using the original jpg (not from ps) and a png file from ps. The problem seems to affect only jpg.

4) That has no effect. Neither changing the color management policies in ps.
 
Last edited:
ALB68 said:
Just for yours and Tom's information. I loaded this file in PS CC. I looked at the coordinates and sampled the referenced colors. I did not go to the trouble of recording each of them, but some match your numbers, some don't. The first one for example, taking a point sample at 0y and 16x reads 6,0,0. where you say it supposed to be 5,0,3. but at 31,0 , I get 2,2,2. Something is amiss somewhere here and if any one can figure it out, it will be Tom. I will watch this thread as I am interested in what the answer is.
Click to expand...

So your PS CC reads 6 0 0 at that specific pixel, and my PS CS5 reads 4 0 3 (the 5 0 3 was read by PSP, PHP and Gimp).

Maybe we should compare settings. But I've changed my Color and Profile settings, but they don't seem to affect the reading value in ps at all.
 
So if it only seems to affect jpg, and the PS color space settings has no effect on the issue,
then I think it's a JPG decompression issue. Probably PS uses another decompression algorithm not according to the specification, maybe Adobe thinks their algoritm is better (when companies grows big they tend to create their own standards), or it's just a bug.
 
Don,
I am far from being the expert Tom is. But I was curious about this, and I did a couple more things. I opened this file in PSP and the values are identical to yours. I then opened it in PS CS6 and low and behold I get yet another set of values even from PS CC. I have an idea that Adobe would take the position that they are higher up on the food chain than Corel and others and if you create in their software, their would be no guarantee that the document when opened in Photoshop would match exactly down to the tiny difference your testing here. That's just my opinion from a business standpoint. Adobe thinks that way, they are considered by themselves and the world to be the standard. In other words, if your not using an Adobe product, then your doing it at your own peril. I'm sure Tom will have some more input and I may be totally off base but it's something to consider. (and actually this goes along with what you just mentioned in your last post)
Don33 said:
So if it only seems to affect jpg, and the PS color space settings has no effect on the issue,
then I think it's a JPG decompression issue. Probably PS uses another decompression algorithm not according to the specification, maybe Adobe thinks their algoritm is better (when companies grows big they tend to create their own standards), or it's just a bug.
Click to expand...
 
Last edited:
Do u intend to do the confirmatory test for this that I've been recommending since MSG #7?

...as I have now stated multiple times, the easiest and most direct way to rule (b) in or out experimentally is to first settle whether or not (a) is a possibility. You can easily do this if you either (1) generate an image consisting of big blocks of color where there will be no compression artifacts in the middle of these blocks, or (2) conduct a comparison using a file format like lossless TIFF (that has no compression artifacts) instead of using JPGs. ...
Click to expand...
 
ALB68 said:
Don, I am far from being the expert Tom is. But I was curious about this, and I did a couple more things. I opened this file in PSP and the values are identical to yours. I then opened it in PS CS6 and low and behold I get yet another set of values even from PS CC. I have an idea that Adobe would take the position that they are higher up on the food chain than Corel and others and if you create in their software, their would be no guarantee that the document when opened in Photoshop would match exactly down to the tiny difference your testing here. That's just my opinion from a business standpoint. Adobe thinks that way, they are considered by themselves and the world to be the standard. In other words, if your not using an Adobe product, then your doing it at your own peril. I'm sure Tom will have some more input and I may be totally off base but it's something to consider. (and actually this goes along with what you just mentioned in your last post)
Click to expand...

So obviously the pixel value differs between several PS versions as well. That's a bit funny :)

And that makes me think it's a bug, that is being slightly affected when code is changed in version upgrades.
 
Last edited:
Don33 said:
This has already been done, it does not affect png. It seems to be a jpg decompression issue or bug.
Click to expand...

Agreed, and I'm glad we got you a partial resolution of your question so quickly. However, doing the large-blocks-of-color test with a jpg will tell you (and everyone else) if the discrepancy only affects pixels near fairly hard edges, or is a much more serious problem and produces decoding discrepancies all throughout an image.

I have not followed the work of the Joint Photographic Experts Group but I clearly remember that there was a new revision to the JPEG standard as recently as last summer, so perhaps its a version problem. It certainly would be interesting to try to find out exactly what is going on here, and if there is indeed an unsavory "back story" here as you suggest where Adobe decided to intentionally deviate from the standards and go off in their own direction.

Personally, I don't make such allegations unless I'm damn sure of my facts, and by virtue of you asking your original question and not mentioning anything about color profiles or decompression algorithms in your early posts, it sounds like you are just getting your feet wet in this area.

Cheers,

Tom
 
You keep nagging about edges: Most JPG images contains lots of various edges in various sizes, edges containing thousands of pixel values. That is what jpg is suitable for. So it's likely that you'll find concentrations of these altered pixels near those edges. The sample.jpg contain 30% altered pixels and the coordinates the script logged indicates that it's not all over the image.

Maybe this slightly pixel bending does not matter due to the jpg specification. The small differences is not visible in image for the human eye. The contents of a jpg file changes all the time when saving it, so why not also when opening it (but much less). And most users doesn't compare pixel values, so it doesn't matter if the values changes slightly.
Or maybe it's a bug, or Adobe sets it owns standards.
I don't care, I'll just stick to another tool when I need to visually confirm pixel values from an analysis.

Note: that nonsense about "allegations": lighten up, this is not a court room. And the comment about "getting your feet wet" just makes you sound stuck-up.
 
Don33, please refrain from personal insults, you have come here for help and help as been supplied, thank you.
 
Back
Top