What's new
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


Don33

Member
Messages
17
Likes
1
Photoshop CS5 is reading/viewing incorrect pixel values in jpg images.
Approximately 30% of the pixels in a jpg image is getting wrong values when opening the image in photoshop.

For example, if the actual RGB value of a pixel in a file is:
24 86 109
After opening the file in photoshop the pixel has the value:
35 82 102
And PS sets these corrupted values permanently if the image is saved, for example as png.

Is this a bug? or some kind of feature in photoshop that can be turned off?
I've checked with several other software, and the problem seems to be photoshop.

Note:
if more info is needed I can attach an image and some pixel coordinates for checking this out.
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Check to see if the color space of the input file is different from the default color space you have set for Photoshop. If it is, there is a good chance that all that happened is that an automatic conversion from one space to the other occurred when you brought the file into PS.

When a color space conversion occurs, to represent the same color, the numbers MUST change.

HTH,

Tom M
 

Don33

Member
Messages
17
Likes
1
Thanx for answering.
No, it is the same color space in both, sRGB IEC61966-2.1. (If you open an image with another color space than PS working space then you get a message "empedded profile mismatch" and some alternatives to correct that).
-----------

Is it possible to attach a sample image to this post without the image is getting resized or altered?
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Ok, let's see what u have. Just zip the input file and your psd file together and upload the zip file. The forum software won't corrupt a zip file.

T
 

Don33

Member
Messages
17
Likes
1
Great, the attached zip file contains the file 'sample.jpg'. (The problem concerns images not created with PS, so psd is not involved).

Below are some pixel coordinates in 'sample.jpg' of pixels that PS is corrupting when viewing or saving the image.
The format in 16;0;5-0-3;4-0-3 is:
16;0 = x,y pixel position in PS
5-0-3 = correct RGB value
4-0-3 = corrupted RGB value when viewed with PS

16;0;5-0-3;4-0-3
18;0;3-0-0;1-0-0
31;0;2-2-2;2-2-4
46;0;0-0-0;0-1-0
48;0;1-3-2;0-3-2
:
:
224;447;155-190-186;161-187-188
225;447;154-186-183;158-184-185
228;447;161-203-199;159-204-199
:
:
and so on, 30% of the pixels in that image are getting corrupted.

Note:
I'm using CS5 64-bit, Win 7.
I have used PaintShop Pro and several other software to check this problem.
 

Attachments

  • sample.zip
    342.1 KB · Views: 0

Don33

Member
Messages
17
Likes
1
Great, the attached zip file contains the file 'sample.jpg'. (The problem concerns images not created with PS, so psd is not involved).

Below are some pixel coordinates in 'sample.jpg' of pixels that PS is corrupting when viewing or saving the image.
The format in 16;0;5-0-3;4-0-3 is:
16;0 = x,y pixel position in PS
5-0-3 = correct RGB value
4-0-3 = corrupted RGB value when viewed with PS

16;0;5-0-3;4-0-3
18;0;3-0-0;1-0-0
31;0;2-2-2;2-2-4
46;0;0-0-0;0-1-0
48;0;1-3-2;0-3-2
:
:
224;447;155-190-186;161-187-188
225;447;154-186-183;158-184-185
228;447;161-203-199;159-204-199
:
:
and so on, 30% of the pixels in that image are getting corrupted.

Note:
I'm using CS5 64-bit, Win 7.
I have used PaintShop Pro and several other software to check this problem.
 

Attachments

  • sample.zip
    342.1 KB · Views: 0

Tom Mann

Guru
Messages
7,223
Likes
4,343
PS - To ensure that we aren't seeing JPG compression artifacts or similar things, please make the test image that you hand off to PS spatially very simple, say, just a few big blocks of uniform color. That way, we also won't have to be bothered with exact pixel coordinates.

Also, let us know what software you used to read off RGB values (other than PS).


Thanks,

Tom
 

Don33

Member
Messages
17
Likes
1
You can zoom in the image to 3000% and turn on pixel grid (View->Show->Pixel grid), then there should be no difficulties to study the pixels.

Don't save the image, just open it in PS and read the pixel values. The RGB color value viewed in PS should be the same as the byte value in the file. When opening a file PS should view the file as it is, without modifying any values.

The problem occurs with photographs. This one I randomly picked from google just to upload a sample, instead of using my own pictures. I don't know if it is possible to reproduce this by creating an image with big blocks of uniform colors, I suspect the problem only occurs in more complex images like photographs.

The software I used are (latest versions):
PaintShop Pro
GIMP
PHP
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Sorry, Don, there was no attached image.

In addition, I feel that it is absolutely essential that we immediately separate out the possibility of JPG compression artifacts might be causing this problem from other possible sources of difficulty, and the only way to do this is with an appropriate test image (ie, big blocks of color). Please try to do this.

Also, can you please explain precisely how you get "the byte value in the file", especially if you are looking at JPGs, not BMPs or TIFs?

T
 
Last edited:

Tom Mann

Guru
Messages
7,223
Likes
4,343
BTW, the reason I am so emphatic about needing to rule out JPG compression artifacts as the problem you are seeing is because in any normal photographic image, the RGB value for a given location will always be different before and after compression, and the amount you mentioned is not at all unexpected.

We have to figure out if what you are seeing is above and beyond this known problem.

Tom
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Also, are you sure some of the values you are taking as "true values" are not screen values, ie, after your monitor profile has been applied? I can't yet determine this from the description of your methodology that you have thusfar provided.

Tom

PS - If you are having problems posting your files, just send me a private message and I'll give you my conventional email address and you can just send them to me directly, instead of through this forum. (...and then I'll post them here).
 

Don33

Member
Messages
17
Likes
1
?????????? I've posted the zip file and lots of text a couple of hours ago. It didn't show so I've posted it again. It didn't show then either, so I thought it was going to be checked by moderator before it was published. What happened?

The byte value is extracted from with PHP, actually it is the RGB value.

I'll try to post the file again, in next posting.
 

Don33

Member
Messages
17
Likes
1
Ok, let's see what u have. Just zip the input file and your psd file together and upload the zip file. The forum software won't corrupt a zip file.
T

Great, the attached zip file contains the file 'sample.jpg'. (The problem concerns images not created with PS, so psd is not involved).

Below are some pixel coordinates in 'sample.jpg' of pixels that PS is corrupting when viewing or saving the image.
The format in 16;0;5-0-3;4-0-3 is:
16;0 = x,y pixel position in PS
5-0-3 = correct RGB value
4-0-3 = corrupted RGB value when viewed with PS

16;0;5-0-3;4-0-3
18;0;3-0-0;1-0-0
31;0;2-2-2;2-2-4
46;0;0-0-0;0-1-0
48;0;1-3-2;0-3-2
:
:
224;447;155-190-186;161-187-188
225;447;154-186-183;158-184-185
228;447;161-203-199;159-204-199
:
:
and so on, 30% of the pixels in that image are getting corrupted.

Note:
I'm using CS5 64-bit, Win 7.
I have used PaintShop Pro and several other software to check this problem.

View attachment sample.zip
 

Don33

Member
Messages
17
Likes
1
Ok, let's see what u have. Just zip the input file and your psd file together and upload the zip file. The forum software won't corrupt a zip file.

T
File upload does not work. I post the text here again, and send you a pm.
---------------------

Great, the attached zip file contains the file 'sample.jpg'. (The problem concerns images not created with PS, so psd is not involved).

Below are some pixel coordinates in 'sample.jpg' of pixels that PS is corrupting when viewing or saving the image.
The format in 16;0;5-0-3;4-0-3 is:
16;0 = x,y pixel position in PS
5-0-3 = correct RGB value
4-0-3 = corrupted RGB value when viewed with PS

16;0;5-0-3;4-0-3
18;0;3-0-0;1-0-0
31;0;2-2-2;2-2-4
46;0;0-0-0;0-1-0
48;0;1-3-2;0-3-2
:
:
224;447;155-190-186;161-187-188
225;447;154-186-183;158-184-185
228;447;161-203-199;159-204-199
:
:
and so on, 30% of the pixels in that image are getting corrupted.

Note:
I'm using CS5 64-bit, Win 7.
I have used PaintShop Pro and several other software to check this problem.
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Hang on, Don. I'm not the moderator for this section. I just alerted the correct person.

T
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
Don, the problem I have with the value reported by code like this ...

<?php
$im = imagecreatefrompng('nexen.png');
$start_x = 40;
$start_y = 50;
$color_index = imagecolorat($im, $start_x, $start_y);
$color_tran = imagecolorsforindex($im, $color_index);
print_r($color_tran);

... Is that I don't know exactly what it factors in unless I spend considerable time looking up the details of the function calls.

For example, does the value that it returns include the effects of the color profile for the image. I suspect that it doesn't because I don't see any mention of including that as another parameter in any of the function calls or as a global, or as a call to another function. If it doesn't include this, all bets are off because all you are getting are the "uninterpreted" raw values. Of course, color-managed applications like PS will include this and translate the raw values into device-independent values for processing, for passing on to the display profile for conversion to display values, etc.

However, I can tell you this: Prompted by your question, I just did a little test, I took a sRGB JPG image with a very uniform blue sky and read the RGB values for the sky in three color managed photo viewers. The RGB values from all were absolutely identical, so I really don't think there is any problem with PS.

Instead of relying on just the PHP results, check it with other properly color-managed software.

Tom
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
PS - BTW. I realize that you said you also looked at the RGB values in PSP & the GIMP. Unfortunately, I am not familiar with those two programs and, for example, don't know if you have to manually turn on color management in those to get the correct, device-independent values to be calculated & then displayed, or if their default behavior is to have color management turned off.


T
 
Last edited:

Don33

Member
Messages
17
Likes
1
PS - BTW. I realize that you said you also looked at the RGB values in PSP & the GIMP. Unfortunately, I am not familiar with those two programs and, for example, don't know if you have to manually turn on color management in those to get the correct, device-independent values to be calculated & then displayed, or if their default behavior is to have color management turned off.
T

PSP has sRGB color working space setting activated by default, and gimp as well i believe.

..........because all you are getting are the "uninterpreted" raw values...........
Tom

It's those values I'm interested in. The question is then how to get PS to not convert the values?
 

Tom Mann

Guru
Messages
7,223
Likes
4,343
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
 

Top