sRGB previews thumbnails etc

[23]

CMYK thumbnails and previews have colour that does not look the same
as the original version. This is because the conversion is from
generic CMYK to generic RGB. Since CMYK is different depending on the
intended ink colours the only way to properly convert it is to use an
ICC colour profile conversion.

For my clients I use sRGB for any screen images (since it will look
fine on Windows monitors and convert properly on an Apple monitor). I
think this is the safest way to go. Basically anything that is a JPEG
becomes sRGB and the original TIFF can be any one of Japan Color 2001
CMYK, ECI V2 CMYK, AdobeRGB, ProPhotoRGB etc.

I changed some code, not really being sure if this is the way it
should be done. It will convert any smaller images to sRGB. If there
is no embedded profile it will embed sRGB and at least it will have a
profile from there on in. Your imagemagick needs to be compiled with
LCMS support built in and you need to get a copy of an sRGB ICC
profile here:
http://www.color.org/srgbprofiles.xalter

I'm using the same concept for making colour accurate contact sheets
and it really works well. I wonder if anyone else will find this
useful.

include/config.php
//After this line
# If using imagemagick, should colour profiles be preserved? (for
larger sizes only - above 'scr')
$imagemagick_preserve_profiles=true;
// Add these 4 lines (making sure your path to sRGB is correct)
# Accurate colour means smaller JPG previews and thumbnails will be
sRGB (so CMYK images show up properly)
$imagemagick_accurate_colour=true;
# ICC path must be set for accurate colour to take affect
$sRGB_path="/home/resourcespace/include/sRGBColorSpaceProfile.icc";


Here is the code change:
$ diff image_processing.php image_processing.php.orig
427c427
< global $imagemagick_path,$imagemagick_preserve_profiles,$sRGB_path,
$imagemagick_accurate_colour,$imagemagick_quality;
---
> global $imagemagick_path,$imagemagick_preserve_profiles,$imagemagick_quality;
507c507
< $profile="+profile \"*\" -colorspace RGB"; # By
default, strip the colour profiles ('+' is remove the profile,
confusingly)
---
> $profile="+profile \"*\" -colorspace RGB"; # By default, strip the colour profiles ('+' is remove the profile, confusingly)
509,510d508
< # Preserve colour profiles for everything - but make
small previews with sRGB colour for web preview
< if ($imagemagick_accurate_colour && ( $id="thm" ||
$id="col" || $id="pre" || $id="scr")) {$profile="-profile
$sRGB_path";}

[Tom Gleason]

Interesting...

I've long trying to find good documentation about whether it is even
possible to really work with color management and ImageMagick (other
than adding/removing the profiles from files).

Have you found any good documentation on this or any proof of how it works?

Tom

--
Tom Gleason
http://resourcespace.blogspot.com/

[Tom Gleason]

To be clear, I am not very familiar with color management, and would
love to understand what the variables are. I've been trying to
understand it for a couple years now but it hasn't really clicked.

[Dan Huby]

I'm not an expert on colour profiles so I'm not sure what the correct
thing to do here is.

I did add code some time back to deliberately strip colour profiles
from thumbnails and previews because they were adding to the file
sizes significantly and causing results to appear slowly. This
behaviour can be turned off using $imagemagick_preserve_profiles in
the config file.

Rather than adding a new colour profile (or leaving the existing one
intact) I think RS needs to migrate/translate the colour space used
within the file to sRGB so no embedded colour profile is needed as
with most JPEG files on the web.

I understand this is the bit that is missing from ImageMagick and it
can only attach/remove embedded profiles?

Dan

[23]

From my tests using shell scripts, ImageMagick is really accurate in
how it converts colour profiles. It doesn't only attach them, so I
think there is nothing missing anymore (if compiled with LCMS).

As far as I understand Imagemagick "+profile" is an operator, which
means you can convert with -profile /path/to/sRGB.icc then strip. This
would work for thumbnails, but the colour would be right on only if
the monitor is calibrated to sRGB. (Windows is roughly sRGB) To make a
proper conversion you need an input and output profile. If the image
has a profile already is it automatically used as the input.

(this code is just to show logic, it's a mix b/w shell and php)
sRGB="sRGB.icc"
inImage="myCMYKfile.tiff"
outImage="myStrippedSRGB.jpg"

convert $inImage -profile $sRGB +profile icc $outImage

This results in myStrippedSRGB.jpg that has no embedded profile but it
is the proper values for sRGB and will look ok on most Windows
computers.
I think this code would need more testing, for example the input image
has no profile it might not behave properly. You always need an input
and output profile. This might need to be addressed like this

if ( $noProfile ) {
if ( $testForColorSpace == CMYK ) { OriginalICCProfile=CMYK.icc }
if ( $testForColorSpace == RGB ) { OriginalICCProfile=RGB.icc }

convert $inImage -profile $OriginalICCProfile -profile $sRGB +profile
icc $outImage
}

This would apply (basically slap/attach a profile on) then convert to
sRGB and finally strip it. So you would need to test if it is CMYK or
RGB. Then you could apply a generic profile ie: Japan Color 2001 CMYK.
From this point the conversion is the same as before.

My clients complain about small colour and brightness shifts and most
of them have fiber optic internet (100 base-T) so file size isn't an
issue for me. And CMYK preview JPEGs take up a lot of space and are
not universally compatible. But for people with thousands of files on
slower networks, I can understand adding an sRGB profile to every
thumbnail would be an issue. sRGB.icc is 3144 bytes, much smaller than
a full CMYK profile which could be over 2 MB. It won't make much size
difference in a screen preview.

But any sRGB (gamma 2.2) image will not show up properly on an Apple
computer (gamma 1.8 display) without an ICC profile. It will be a bit
brighter on the Apple, but no biggie.

There is lots of good reading in the ICC website
This one is a primer: http://www.color.org/colormanagementtutorial.zip
More here: http://www.color.org/info_profiles2.xalter#intro


Additional arguments to convert would be rendering intent and black
point compensation. But for screen previews is might not make any
difference on 95% of the images.

convert $inImage -profile $sRGB -black-point-compensation -intent
Perceptual +profile icc $outImage

[Tom Gleason]

this is very helpful, thank you. Hopefully we can get some color
management into the next release.

[Blue-J]

I am a long-time color management expert and would love to contribute
here what i can.

"23" has most things right in my book, with a few slight stretches
thrown in. monitors in reality have a wide range of gammas
unfortunately, and the idea that PCs are 2.2 and Macs are 1.8 is a
polite and rarely useful fiction. nevertheless the gamma is assumed
in some architectures in this manner (until Snow Leopard Mac OS 10.6
changes it to 2.2 this year).

for all images with an embedded profile, we will want to convert to
sRGB as "23" indicates, with black point compensation on for sure.
"23" suggest a perceptual rendering intent, but i would advise using
that only in the case of images, not graphic files. if we can branch
on EPS and AI files, i would recommend a media-relative colorimetric
intent for those file types. if this is too difficult, "23" is wise
to suggest perceptual. (that means that sacred in-gamut colors in
illustrations may be shifted.)

i recommend we use the ICC's sRGB v2 with BPC profile for sRGB images:

sRGB_IEC61966-2-1_black_scaled.icc at the bottom of the page at:
http://color.org/srgbprofiles.xalter

It differs from the HP one distributed by Adobe, but I can't find that
one freely distributed and available for open use. it used to be
distributed as part of a UNIX download from adobe, but they axed it,
presumably because of HP. maybe sRGB.icc that "23" suggests will work
for us?

also, for untagged CMYK images (no profile embedded), it is
unfortunately a little thorny what profile you should suggest as
source. for north america, SWOP Coated v2 is still the standard
(though GRACoL is coming on fast). In Europe, Euroscale Coated v2 is
still standard (though FOGRA27 is on the move) and in Japan they
generally use Japan Standard v2.

Here are the CMYK profiles Adobe provides openly:

14 CMYK profiles

* Coated FOGRA27 (ISO 12647-2:2004)
* Web Coated FOGRA28 (ISO 12647-2:2004)
* Uncoated FOGRA29 (ISO 12647-2:2004)
* Coated FOGRA39 (ISO 12647-2:2004)
* Japan Color 2001 Coated
* Japan Color 2001 Uncoated
* Japan Color 2002 Newspaper
* Japan Color 2003 Web Coated
* Japan Web Coated (Ad)
* Web Coated (SWOP) v2
* Web Uncoated v2 Coated
* GRACol 2006 (ISO 12647-2:2004)
* Web Coated SWOP Grade 3 Paper
* Web Coated SWOP Grade 5 Paper

http://www.adobe.com/support/downloads/iccprofiles/icc_eula_mac_dist.html
http://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_dist.html

So at least we have SWOP v2 free! For Japan, using "Japan Color 2001
Coated" would probably be best, and could branch off language
parameter safely. For Europe, "Japan Color 2001 Coated" is a close
match, though a 350% ink limit is pretty high for many printers. SWOP
v2 for Europe would be passable, I presume. I don't know where to get
the Eurostyle profile for use. Can anyone help? (If people aren't
tagging their images, it's doubtful color accuracy at a fine-grained
level is important to them!)

(We should not use the generic CMYK profile; do not even suggest it!)

Marti also provides profiles with LCMS:

http://www.littlecms.com/profiles.zip

We could use the CIELAB profile here to tag Lab color images I
believe: LCMSLABI.ICM

currently if you upload an image in Lab color, it goes psychedelic.


as for embedding ICC profiles within images themselves... we're
working on getting Firefox 3.1 to respect them (3.0 does if you go
into the config) and Safari does, but surprise!! IE is out to lunch.

here's a helpful page:

http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html

the sRGB profile is small, about 4k, but having it for each and every
thumbnail might be a mistake and would drag down some browsers. how
about embedding only on big preview images? that seems wise to me.

"23," if you could point us to the profiles you are using and their
licenses, that would be great! thanks for bringing this matter up
again!

[Blue-J]

On Jun 2, 5:48 am, Dan Huby <danh...@gmail.com> wrote:
> Rather than adding a new colour profile (or leaving the existing one
> intact) I think RS needs to migrate/translate the colour space used
> within the file to sRGB so no embedded colour profile is needed as
> with most JPEG files on the web.

most implementations moving forward are assuming sRGB for untagged
images, so simply converting into sRGB might suffice. embedding for
large previews would add 4k but would be more future proof and optimal
as sRGB becomes more and more dated.

> I understand this is the bit that is missing from ImageMagick and it
> can only attach/remove embedded profiles?

no, you can convert between color spaces using icc profiles using
ImageMagick, as "23" illustrates.

[Blue-J]

I would advise against using the v4 sRGB profile, FYI.