I put all my photos in the sRGB color space before I upload them. Typically, this is considered the best move to be most compatible with all browsers. The full-size images look good on all of the following:
-color-dumb browsers (meaning everything except Safari and FireFox w/ color management on)
-average monitors (meaning monitors that mostly live in the sRGB gamut)
-good monitors (meaning monitors calibrated to color spaces larger than sRGB)

I've noticed, however, that when images are resized or processed in some way via ZP, that the color profile is dropped. This is mostly a problem on good monitors since no longer can calibrate the image properly.

Is there any way to maintain the color space on an image when it is processed in ZP? If not, is there another work-around?

Thanks in advance.

So, how did you "put all [your] photos in the sRBG color space"?. Most WEB software is not profile aware. The zenphoto graphics tools do not process profile information. For this to work you have to `convert` your images to sRGB.

I'm not sure what you're asking.

When I create the JPGs, they are in the sRGB color space. I understand that is the web standard. (And in LightRoom, for example, I don't think it is possible to export images without any color space.)

In any case, the color space seems to be maintained when viewing the full-size images, but not when the images are processed. So for the re-sized images, the colors are bad on a good monitor. For example, the thumbnail of an image differs (color-wise) from the full-size version.

--

I suppose another line of questioning would simply be:
In terms of color space, what SHOULD I do with the images before I upload them?

There are two aspects of color space. The first is the RGB values of the pixels. Then there is a color profile which may be associated with an image. So you can have pixels which are sRGB or adobeRGB or some other "color space". If the pixels are not sRGB then typically the WEB programs will not display the color correctly. If they are, then things should be fine.

Zenphoto makes no manipulation of the pixel values. What you have in is what you get out. I do not know why you would have a problem with the resized images. I am not seeing this on my system. Of course, for thumbnails, there are much fewer pixels and that may impact the appearance. Subtle colors may take many pixels to represent. If the resize removes some of those pixels then the colors may look different.

Hmm... okay, I made a test page for you:

`http://www.stanats.com/testingsite/colorspace.htm`

If you look at that in Safari on the Mac, on a good monitor, then there is a significant color difference. In non-color-space-aware browsers, there is no difference. There is also no difference in Firefox, either with color management on or off, which is somewhat confusing to me since that SHOULD be the same as Safari if FF's color management is turned on.

Perhaps I am not understanding something fully. Thoughts/advice?

And for my edification, I'll repeat my previous question: when you prepare your photos for upload, do you use the sRGB color space or do you use no color space at all?

Sorry, I am not a MAC person. Maybe acrylian will have a thought. When I prepare for upload I convert my images from adobeRBG (which is what my camera and I normally work in) to sRBG. I do this at the same time as I resize them for WEB efficiency. (I have a 10MP camera.)

You can see this on the PC through Safari as well, if that helps.

I actually post from both Macs and PCs. In the past, Safari was the only color-space-aware browser, so it made sense for people to use it on the PC solely for that reason. Now, however, FF3 has caught up.

I'll wait to see if Acrylian has any ideas.

There is no different on other browser, because the default is sRGB profile. There is different on Safari, because the default is system profile.

On the other hand, the photo in cache folder is missing the header information, I think it is better to kept them.

Generally I have no other idea than to use sRGB, too. But to my knowledge the problem is that color profiles are not used generally as you said yourself. So it of course also a sRGB profile is ignored.

A good check is to use the "export for web" in Photoshop (or how it is named in english, have the German version). If the preview image in that function is missing saturation and colors then something probably must have went wrong as to my knowledge this function drops any profles from the file at all, too.

I understand that this can be painful if you take really lots of photos but it seems the most secure for me (well, I don't take photos myself).

I am actualy not used to the image processor functions in detail but I found a forum thread about gdlib and color changes. That mentions that the `imagecopyresize()` function often results in wrong colors and recommends to use `imagecopyresampled()` as that is more accurate. We probably need to check which one we use (the latter one is GD2 but I guess that should really be widely in usel, shouldn't it).

WARNING: There is a flaw in Photoshop `export for web`. This `featrue` strips off all EXIF/IPTC data from the image!

You have at least with CS3 an option to keep XMP data which is a variant of exif if I recall correctly. If that also keeps pure exif I don't know since I rarely use it.
Also you can check if you want to convert to sRGB and/or include ICC-color profiles. But basically stripping out all these data that is not needed for "pure dissplay" is what makes image filesize significantly smaller with this feature.

No plan for keeping header of the cache version of image?

Without the color profile, it is unable to know what is the color profile using on Safari...

I am not a GDlib expert but to my knowledge the GDlib just does not support profiles.

hmm... i agree with fatman on this; it would be better to pass along the information to all subsequent edits of an image if it is included in the original file. fatman's right; without this, safari will interpret the image incorrectly. and eventually, one might hope that other browsers will start interpreting color spaces (Firefox already does, with certain settings).

That said, if GD just ignores it, then I'm not sure if there is anything to do about it.

Is there any progress on Acrylian's comment above about using `imagecopyresampled()` instead of `imagecopyresize()`? I'm assuming this has to be handled by the programmers instead of individual users.

Actually, Zenphoto does use `imagecopyresampled()` not `imagecopyresize()`. The tinyMCE editor seems to use `imagecopyresize()` but that is not in code that we created so I think it would be up to the authors to make that change.

I have not really a problem with image display. So I guess maybe there is something wrong in the the "chain" of creating? As far as I know tinyMCE does not really resize images if you include them instead they are just scaled. If tinyZenpage was meant that uses the normal Zenphoto image processing and should therefore not generate anything different.

well... i'm not really following all that clearly. sounds like you guys are using the best code, so that's not the problem.

but i do know for a fact that the problem does exist, and i don't think i can do anything to change it, so i guess i'm probably stuck with it until somebody starts writing code that actually deals with color spaces instead of just ignoring them.

i don't know anything about GD or tinyMCE, so i have no idea how to do anything else about the "chain." let me know if i'm missing something or if there's some research i could do that would help.

thanks.

Well, really everything for the WEB should be in sRGB colors with their color space profile indication sRGB also. Then it will not matter if the WEB applications honor the profile or not.

Sorry to restart this thread almost a year later, but I've stumbled across this problem as well in the last couple of days.

The problem is actually [b]not related to resizing or resampling[/b]. It only occurs on [b]watermarked[/b] images!

I believe this is actually a serious problem, at least for those of us planning to showcase their work to a potentially paying audience. The images simply do not look good enough. Anybody on a Mac (or with a color-space-aware browser) may reproduce the issue and see the difference within two minutes:

1. Download a watermarked image to the desktop
2. Open it in Preview and open the inspector (cmd-I)
3. You will see that the color model is RGB (of course), but the Color-Sync-Profile is empty ("-")
4. Go to "Tools-Assign Profile" and select an sRGB-Profile from the drop-down-list...
5. ...the colors pop-up

NB: Assigning a profile does not change the "pixels", it only writes the profile to the jpeg-header.

The bottom line is that the watermarking-routine drops the color-space information that was initially in the jpeg-header of the uploaded image. If watermarking is turned off, everything is fine.

Here's an example image in case you want to see it yourself:

http://www.andreasbrandl.ch/Namibia/NAM-20091005-06-42-12.jpg

BTW: Although this issues is a bit annoying , ZP is awesome...

Cheers, Andreas

Sorry, I see the color change in your image but the GDlib used for resizing does not preserve color profiles at all as it simple does not have any support for it. At least in my test the color profile is removed either with or without watermark if the image is resized.

It is recommend to work with images in sRGB mode always if they are supposed to be on the web and do not use the "export to web" function of Adobe programs as that removes the profile, too (but that is surely no news to you).

The only workaround for you would be currently. To use the full image instead of the sized image on the image.php page. Of course you will then have to resize the images manually before uploading and loose a benefit of using zp...

Sorry, but this is nothing we can change as the GDlib is not done by us and installed on your server anyway. We hope to get Imagick graphic libary support in the future (a user is thankfully working on that) which is said to support color profiles.

btw, you might also want to upgrade to the current Zenphoto version (I do not recall if anything has been changed on the image processing)