RGB primaries in Photoshop?

[hugowolf]

This is a little off topic for this board, but…

I am trying to set up jpeg files in Photoshop with 6 rectangular blocks: the RGB primaries, white, mid gray, and black. I save these files at the lowest compression. The file type is limited because I need to use these in web pages.

When I reopen the files, the primaries are off. I get values like (RGB(254,0,0) and RGB(0,255,1). It happens in sRGB, AdobeRGB, and ProPhotoRGB.

Is there any way I can avoid this? Would GIF work instead of jpeg?

Brian A

[papa v2.0]

Hi
I wouldn't worry too much about the difference between 255 and 254 for web work.
Or 0 and 1.

Minimal colour difference.


.png would be better as it can hold index colours ifs it blocks as opposed to a picture.

Iain

[digitaldog]

Agreed, probably rounding errors and I'd even suspect they'd be slightly larger as the gamut of the color space is larger.

[hugowolf]

I am reopening these files in Photoshop, it seems like they should be the same as I saved them, but perhaps not. I save an image that is pure RGB(255,0,0), and when I reopen it shouldn't it be the same?

But another question: does HTML have a working space?

One of the main points of this exercise was to look at RGB values given by various browser addons. You hover over a color in a web page and the addon gives you the RGB values for that color. They work fine for HTML elements (they correspeond exactly with the hex values of the code), but I am having difficulty fathoming what the values mean for images. For images in different color spaces, the values are all over the place, except for neutrals, and don’t correspond with any color space triplets that I normally use.

Does HTML have a color space? If not, what can the HTML element RGB values mean without a reference point?

Brian A

[MarkM]

Does HTML have a color space? If not, what can the HTML element RGB values mean without a reference point?

HTML does not have a color space and the way browsers deal with this is inconsistent. Most browsers today will respect an image with an embedded profile. But html elements colored with css will behave as if there is no color management, which basically amounts to working in your monitor's color space. The result is that you can have a sRGB tagged jpeg that is pure green (i.e. [0, 255, 0]) with a css border that is pure green (i.e. #00FF00) and the border won't match the image. It can be a pain if you are trying to match graphic elements in the form of images with html elements on a page. The way most people handle this is by not tagging the graphic elements.

The last time I checked, Safari on Mavericks was assuming sRGB for untagged images and using sRGB for web elements. Both Chrome and Firefox on the Mac treat both untagged images and HTML elements as unmanaged. Firefox has a setting which is not the default (gfx.color_management.mode) that makes it behave like Safari. I'm not sure if Chrome has a similar setting.

An easy way to test is to make various tagged and untagged pure green jpegs and render them in the browser with something like this:
<img style="border: 10px solid #00ff00;"  src="green.jpg" />

[Schewe]

I am trying to set up jpeg files in Photoshop with 6 rectangular blocks:

Although JPEG tries to save color data while compressing the heck out of luminance, the very act of encoding to JPEG will cause subtle changes in color. That can't be helped. You might try 24-bit PNGs out of Save For Web...the files won't be very small but I think there will be no loss of color data. Note, the normal Save dlog for PNG doesn't offer the same options for PNG as SFW...

[D Fosse]

The last time I checked, Safari on Mavericks was assuming sRGB for untagged images and using sRGB for web elements. Both Chrome and Firefox on the Mac treat both untagged images and HTML elements as unmanaged. Firefox has a setting which is not the default (gfx.color_management.mode) that makes it behave like Safari. I'm not sure if Chrome has a similar setting.

Does that mean Safari now actively assigns sRGB to untagged material? (not "assume", which means doing nothing).

This is what Firefox does in the mode 1 setting, and that set it apart from all other browsers. What you get is active and full color management for all material, untagged or tagged, images or graphic page elements.

[MarkM]

Does that mean Safari now actively assigns sRGB to untagged material? (not "assume", which means doing nothing).

This is what Firefox does in the mode 1 setting, and that set it apart from all other browsers. What you get is active and full color management for all material, untagged or tagged, images or graphic page elements.

I'm not sure what the difference is between assigning and assuming in this context. If you hand the latest Safari  a tagged sRGB and an untagged sRGB image they match visually (this in Mavericks — I'm not sure if the OS is playing a role). They will also match with html elements of the same color numbers and with the photoshop document. I'm not sure if that's assuming or assigning, but one way or another Safari is treating the color numbers of untagged images and html elements as if they were sRGB.

Here's a quick and dirty example:
http://www.photo-mark.com/static/greentest/

If you look at it in Chrome or Firefox with the default setting you will see a distinct difference between the two squares and the top square and it's border. This is especially obvious on a wide gamut monitor, maybe not as clear on a monitor that is close to sRGB.

[Simon Garrett]

I'm not sure what the difference is between assigning and assuming in this context. If you hand the latest Safari  a tagged sRGB and an untagged sRGB image they match visually (this in Mavericks — I'm not sure if the OS is playing a role). They will also match with html elements of the same color numbers and with the photoshop document. I'm not sure if that's assuming or assigning, but one way or another Safari is treating the color numbers of untagged images and html elements as if they were sRGB.

Here's a quick and dirty example:
http://www.photo-mark.com/static/greentest/

If you look at it in Chrome or Firefox with the default setting you will see a distinct difference between the two squares and the top square and it's border. This is especially obvious on a wide gamut monitor, maybe not as clear on a monitor that is close to sRGB.

I've just tested on a PC (latest versions of browsers). 

Safari and Chrome both "fail" the green square test - in other words, they don't assign a profile to images without an embedded profile. 
Firefox, with gfx.colour_management.mode set to 1 "passes" the test - it assigns sRGB to images without a profile. 

IE11 also passes the test, but only by accident!  It ignores monitor profiles, making the implausibly unlikely assumption that all monitors have a colour space, TRC etc of exactly sRGB.  Thus its failure to colour-manage images with no embedded profile it cancelled out by it's failure to use the monitor profile. 

[D Fosse]

Is Safari configured differently between the Mac and Win versions? I've only tried the Win version, and when I did it behaved the way Simon describes. (I don't have it now).

"Assume" is a problematic word to use in this context because it doesn't really tell you anything. So we need to be more specific. And what's needed here specifically is to assign the sRGB profile. The reason is that in order to convert the document RGB values to the display profile, there has to be something to convert from. You can't convert from an assumption. There has to be an actual profile there.

[Ernst Dinkla]

The assignment should be done in an intelligent way like in Qimage that first observes no profile is assigned, then checks whether it can make an educated guess on possible EXIF data etc before it assigns sRGB (default choice) if it gets no clue at all. If it is a vintage image file or from applications today that have no color management and/or do not transfer assigned color spaces with saved files or the image provider has no clue about color management then sRGB usually fits best which is something else than assuming the image should have an sRGB color space assigned.

--
Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.

[Lundberg02]

Is Safari configured differently between the Mac and Win versions? I've only tried the Win version, and when I did it behaved the way Simon describes. (I don't have it now).

"Assume" is a problematic word to use in this context because it doesn't really tell you anything. So we need to be more specific. And what's needed here specifically is to assign the sRGB profile. The reason is that in order to convert the document RGB values to the display profile, there has to be something to convert from. You can't convert from an assumption. There has to be an actual profile there.

Safari 7 MacOS 10.9.3 shows no difference between border and image on my sRGB monitor.