Finding the right image for a splash is always a tedious process… We had a couple of ideas rendered with the sheep, Victor, and the tornado, but in the end we settled on the cute Franck-caterpillar.
Read the Release notes or download the 2.75 Release Candidate.
(edited post, june 13)
The colors from the splash were too saturated. What happened? This is what I found so far.
The newly exported splash now has a color profile too (why?). And it even looks different than the original caterpillar.
And worse, on Mac OS X (GIMP 2.8.14) it assigns it a different profile than on Linux.
Images are here. http://download.blender.org/gooseberry/CM-woes/
Anyone has info about what I am doing wrong here? Note that I use GIMP’s default install; no CM was changed.
-Ton-
This is the splash now. Solved by setting GIMP’s default sRGB profile first, then copy/paste. To compare, the bad one is the second, below.
Well done!
Juicy!
Can’t wait!
The problem seems to be that the caterpillar image is in that “Generic RGB colorspace” that Preview for Mac assigned.
That image should have been converted to sRGB upon importing it, in order to make it match the colorspace of the template file (I’m guessing it was sRGB, am I correct?)
If that’s the case the proper workflow would be to choose sRGB as working space and convert anything you bring from outside to sRGB.
That would apply a colorimetrically correct conversion from the Generic RGB to the sRGB space, keeping the color appearance.
Once the final splash file is exported back to PNG, it will be an sRGB PNG.
As for its spec (iirc), the sRGB PNG won’t have a profile embedded if it’s sRGB. It will only have an embedded profile if it’s in a different colorspace.
In any case, using the display profile for images seems a very bad idea.
Specially in this case, where the Generic RGB profile has a smaller gamut than sRGB.
Hi again,
I just confirmed my suspicions: I downloaded the xcf of the template which is sRGB.
If you used GIMP without setting up color management (choosing your working profile, rendering intent, etc.) it’s possible that when you imported the caterpillar image into the template it wasn’t converted and no warnings about the color mismatch were shown.
The caterpillar data was used as raw RGB data, because no color management was applied.
When the composited file was saved as PNG, the exporter didn’t embed profiles (CM is off and sRGB PNGs don’t get the profile embedded).
So it was in part human error, part software error.
Preview for Mac shouldn’t have added that profile, and GIMP should have the color management properly set. It was deactivated.
This can be solved easily by turning on GIMP screen color management and set both the working colorspace (sRGB would be the right choice here) and the screen profile.
In that case, when an image with a different colorspace is imported, GIMP will offer two options: keep the space from file or convert to the working space. “Convert” is the right choice. It will re-map the colors from your source colorspace to the closest colors in the target space (sRGB).
Anyway, I would investigate further how the generic RGB profile ended up in the original image. That seems to be a nasty bug in Preview for Mac.
Was the image captured from the screen or copy/pasted with Preview? That’s the only instance I can imagine it could happen.
the default gimp 2.8 behaviour is to
automatically convert opened files to sRGB.
Check these settings, if you haven’t:
edit->preferences->color management
– Mode of operation: “Color managed display” (default)
if set to “no color management” color appearance definitely
shouldn’t change!
– File open behaviour: “Convert to RGB workspace” (default)
Maybe set to “keep…” or “ask…”
Hope this makes sense!
Stephan
It could be also the fact, that the template Gimp-file has the
“sRGB IEC 61966-2.1” profile attached, which is not installed
in Gimp by default because of intellectual property rights.
Gimps default RGB-profile is “RGB workspace (sRGB build-in)”
A sRGB profile can be installted under
edit->preferences->color management–>RGB profile
This profile here might be worth a try: http://www.color.org/srgbprofiles.xalter#v2
The xcf file went through many hands, I don’t know how it ended up with this Mac profile… but by changing the profile to GIMP’s default , then copy paste caterpillar, the image saved correct. See update in the post up there!
Stephan, that’s not correct.
An automatic conversion to sRGB would have saved Ton these troubles.
The issue was probably that “no color management” was set, and two images with different colorspaces were blended together as raw RGB, disregarding their color profiles.
The default file open behaviour isn’t convert to RGB, it is “ask”. So if no warnings about the color mismatch appeared, either CM was off or the color profile warning was dismissed.
Is this how it has to look?
http://www.ohweb.com.ar/share/index.php/s/biQkJQDoUddK1fU
I stand myself corrected.
if OSX silently color-corrects the copied buffers, then copying from one document to other in GIMP resulted in passing “generic RGB” data as raw RGB to a document that was sRGB.
Since “generic RGB” is smaller gamut than sRGB, that resulted in boosted saturation.
If I’m right and this was caused by OSX’s corrected copy buffer, then the only way to avoid this is to avoid using copy and paste, and import the scaled image as layer instead. If it asks about how to treat the embedded profile, make sure to choose “convert” so it’s converted to sRGB.
Hi Gez,
Thanks for all the feedback, busy days here, which is why I didn’t reply earlier.
The tests so-far doesn’t give me a clue whether Mac pollutes copy/pastes, I think it doesn’t though.
I think the issue is the sRGB IEC 61966-2.1 profile in the splash template.
When I changed that in GIMP to convert to GIMP’s own sRGB, and then do the copy/paste from the caterpillar, the export went all OK. I added the new exported png to the post.
Hi, Ton.
Assigning sRGB tells OSX that the copied buffer is sRGB, avoiding the automatic tagging.
What caused the problem in the first place is the questionable treatment that OSX gives to untagged RGB.
The render that came from Blender was sRGB, but without an embedded profile OSX decided that it was untagged and chose to stuff the “generic RGB profile” to it when you copied it (please explain where did that profile came from if OSX didn’t do it).
I don’t think the issue is the sRGB profile is the template. it’s pasting the non sRGB buffer on the sRGB document. The only way you can end with an oversaturated image is by pasting raw RGB from a smaller colorspace into wider-gamut RGB.
If you compare the 3D gamut volume of sRGB and Apple’s Generic RGB you can see exactly what I’m saying, and where sRGB gamut exceeds Apple’s Generic is exactly in the colors you see more saturated in the wrong splash.
This document from Apple adds some background:
http://www.zipaphoto.com/ICC_Color/RGB%20profiles%20explained.pdf
Are you working on a pre-mavericks mac with no display profile?