Colour Profile Question
420 views
Skip to first unread message
David Shaw
Jun 16, 2010, 11:46:06 AM6/16/10
to ResourceSpace
Is there a way of converting from Adobe RBG to sRBG colour profile on
the image files ResourceSpace generates? It appears to embed the
original profile in the derivatives. I have tried the
$imagemagic_preserve_profiles=false in config too, which just appears
to strip out the profile info but not change it.
It's going to be a fundamental requirement for us to have the original
left as is but have all derivatives ResourceSpace generates to be
converted to sRGB and have that profile embedded. All our hi-res
originals are in Adobe RBG colour profile, users downloading
derivatives from ResourceSpace are going to wonder why their images
look all washed out - the effect of showing an Adobe RBG image in a
non-colour managed application. I can't really expect them to convert
to sRBG any image they download from ResourceSpace...
thanks,
David
the image files ResourceSpace generates? It appears to embed the
original profile in the derivatives. I have tried the
$imagemagic_preserve_profiles=false in config too, which just appears
to strip out the profile info but not change it.
It's going to be a fundamental requirement for us to have the original
left as is but have all derivatives ResourceSpace generates to be
converted to sRGB and have that profile embedded. All our hi-res
originals are in Adobe RBG colour profile, users downloading
derivatives from ResourceSpace are going to wonder why their images
look all washed out - the effect of showing an Adobe RBG image in a
non-colour managed application. I can't really expect them to convert
to sRBG any image they download from ResourceSpace...
thanks,
David
Dan Huby
Jun 16, 2010, 12:22:35 PM6/16/10
to ResourceSpace
It might be possible to configure ImageMagick to do this using
+profile and -profile options. Bear in mind that converting to sRGB
could be 'lossy' if the image contains colours outside the sRGB range
(which is a subset of Adobe RGB).
Could you email me a small Adobe RGB image, and the same image
converted to sRGB correctly (i.e. in Photoshop), so I can run some
tests? If possible choose an image that looks particularly 'washed
out' in ResourceSpace currently, so I can tell when it's working
correctly.
Thanks,
Dan
David Shaw
Jun 16, 2010, 12:39:11 PM6/16/10
to ResourceSpace
Many thanks Dan, I'm at home now but will find a suitable image at
work tomorrow for you and email as requested. David
work tomorrow for you and email as requested. David
Jeff Harmon
Jun 16, 2010, 6:00:39 PM6/16/10
to ResourceSpace
i don't believe there are embedded ICC profiles in derivatives. if
you are solely going by what's in the config, know that "profile" in
ImageMagick amounts not only to ICC, but other metadata segments.
it's not just referring to the ICC profile.
firefox and safari support embedded profiles in images in the browser,
but the profiles add file weight - sRGB is 4k.
you need LCMS to do profile conversions with IM - it's a variant i
believe and doesn't come in the standard install. i believe the same
is true for GM, which also uses LCMS. note also that LCMS just
released a major new rev (2.0) that is really still in beta. i would
build with 1.19a.
ideally, original images with ICC profiles embedded should be
converted to sRGB with a media-relative colorimetric intent and black
point compensation on, and then strip the ICC profile out of the
destination files, so you don't add the file weight. ICC profile-
aware browsers assume sRGB for untagged images anyway, so it's the
best of all worlds.
for original images without ICC profiles, their should be config
options defining the default profiles to use for each colorspace.
then use that, then strip the profile out of the created images.
- Jeff Harmon
Colorhythm LLC
you are solely going by what's in the config, know that "profile" in
ImageMagick amounts not only to ICC, but other metadata segments.
it's not just referring to the ICC profile.
firefox and safari support embedded profiles in images in the browser,
but the profiles add file weight - sRGB is 4k.
you need LCMS to do profile conversions with IM - it's a variant i
believe and doesn't come in the standard install. i believe the same
is true for GM, which also uses LCMS. note also that LCMS just
released a major new rev (2.0) that is really still in beta. i would
build with 1.19a.
ideally, original images with ICC profiles embedded should be
converted to sRGB with a media-relative colorimetric intent and black
point compensation on, and then strip the ICC profile out of the
destination files, so you don't add the file weight. ICC profile-
aware browsers assume sRGB for untagged images anyway, so it's the
best of all worlds.
for original images without ICC profiles, their should be config
options defining the default profiles to use for each colorspace.
then use that, then strip the profile out of the created images.
- Jeff Harmon
Colorhythm LLC
Jeff Harmon
Jun 16, 2010, 6:11:11 PM6/16/10
to ResourceSpace
prior discussion, with links to profiles to use:
http://groups.google.com/group/resourcespace/browse_thread/thread/8e6a679783ea6db4/aae85dff7ed28c32?lnk=gst&q=icc+profile#aae85dff7ed28c32
let me know if the links are broken, and i'll try to help.
http://groups.google.com/group/resourcespace/browse_thread/thread/8e6a679783ea6db4/aae85dff7ed28c32?lnk=gst&q=icc+profile#aae85dff7ed28c32
let me know if the links are broken, and i'll try to help.
Dan Huby
Jun 17, 2010, 7:16:35 AM6/17/10
to ResourceSpace
I can confirm locally that simply dropping the Adobe RGB ICC profile
results in a washed out image, as no colour space translation is
performed.
Jeff is right, RS simply strips the profile rather than moving to sRGB
or attempting translation.
To attempt the translation you need to do something like:
convert example1_AdobeRGB.jpeg +profile '*icc*' -profile "/Library/
Printers/hp/Profiles/sRGB_A.icc" output.jpg
Personally I get the error:
convert: delegate library support not built-in
`example1_AdobeRGB.jpeg' (LCMS) @ profile.c/ProfileImage/898.
As Jeff has pointed out above I need to complile ImageMagick with LCMS
(LittleCMS) support in order to enable colour space translation. If
you do this, the above command should work (you need to add a path to
your own sRGB ICC file). Then it's just a matter of updating the
appropriate 'convert' commands within ResourceSpace.
I hope this gives you some direction.
As an aside I wonder if there is some simpler solution, such as using
"-color-matrix" to set up the correct colour translation, then there's
no need for LCMS/profiles. But working out the transformation could
involve some interesting maths.
Dan
results in a washed out image, as no colour space translation is
performed.
Jeff is right, RS simply strips the profile rather than moving to sRGB
or attempting translation.
To attempt the translation you need to do something like:
convert example1_AdobeRGB.jpeg +profile '*icc*' -profile "/Library/
Printers/hp/Profiles/sRGB_A.icc" output.jpg
Personally I get the error:
convert: delegate library support not built-in
`example1_AdobeRGB.jpeg' (LCMS) @ profile.c/ProfileImage/898.
As Jeff has pointed out above I need to complile ImageMagick with LCMS
(LittleCMS) support in order to enable colour space translation. If
you do this, the above command should work (you need to add a path to
your own sRGB ICC file). Then it's just a matter of updating the
appropriate 'convert' commands within ResourceSpace.
I hope this gives you some direction.
As an aside I wonder if there is some simpler solution, such as using
"-color-matrix" to set up the correct colour translation, then there's
no need for LCMS/profiles. But working out the transformation could
involve some interesting maths.
Dan
Dan Huby
Jun 17, 2010, 7:22:49 AM6/17/10
to ResourceSpace
To fixed the 'washed out' look, you can do the following:
convert AdobeRGB.jpeg +profile '*icc*' -modulate 100,115,99 output.jpg
It's not exactly the same as the original image but is a lot closer
than it is right now. Not a complete fix of course, but it's an
improvement.
Dan
David Shaw
Jun 17, 2010, 8:23:05 AM6/17/10
to ResourceSpace
Dear Dan and Jeff thanks for your comments and looking into this, much
appreciated.
If we plan to allow users within the museum to download derivatives
it's very desirable that the colour profile is included, especially if
it's not sRGB.
The images downloaded from RS will likely get used for reports,
powerpoints, academic study, so the colour reproduction needs to be as
spot on as we can manage - our photographers spend a lot of time
getting their image as close a match as possible to the original
object. We're also probably unusual in that our original hi-res TIF
won't be available to anyone to download, they'll have to request it
via our Image Library Manager.
While it's encouraging that we could hack RS to create sRGB
derivatives from Adobe RGB originals (we may also use ProPhoto RGB
which looks even worse), we'd rather not alter the base build of RS to
do this, as we've no real guarantee that it won't break or become
unworkable with later updates of RS.
So I think for now we may look at creating a lower-res JPG derivative
set all in sRGB that we create which in effect then become masters for
RS. We lose the ability for users to see what the original size of
the TIF we have is, but could pop this in the metadata somewhere.
Ideally it would be good to have an option in the RS config that lets
you control derivative creation and how the original is ingested too
(although we plan to staticsync for images). ie.,
$derivative_convert_to_sRGB ="true";
$original_image_convert_to_sRGB="false";
Maybe someday something like this could be incorporated into the
standard build?
best, David
appreciated.
If we plan to allow users within the museum to download derivatives
it's very desirable that the colour profile is included, especially if
it's not sRGB.
The images downloaded from RS will likely get used for reports,
powerpoints, academic study, so the colour reproduction needs to be as
spot on as we can manage - our photographers spend a lot of time
getting their image as close a match as possible to the original
object. We're also probably unusual in that our original hi-res TIF
won't be available to anyone to download, they'll have to request it
via our Image Library Manager.
While it's encouraging that we could hack RS to create sRGB
derivatives from Adobe RGB originals (we may also use ProPhoto RGB
which looks even worse), we'd rather not alter the base build of RS to
do this, as we've no real guarantee that it won't break or become
unworkable with later updates of RS.
So I think for now we may look at creating a lower-res JPG derivative
set all in sRGB that we create which in effect then become masters for
RS. We lose the ability for users to see what the original size of
the TIF we have is, but could pop this in the metadata somewhere.
Ideally it would be good to have an option in the RS config that lets
you control derivative creation and how the original is ingested too
(although we plan to staticsync for images). ie.,
$derivative_convert_to_sRGB ="true";
$original_image_convert_to_sRGB="false";
Maybe someday something like this could be incorporated into the
standard build?
best, David
Dan Huby
Jun 17, 2010, 10:00:10 AM6/17/10
to ResourceSpace
Does anyone know which browsers are not colour profile aware?
It seems the best solution might be as follows: instead of trimming
everything down to sRGB, we keep the profile embedded. That way if we
ever moved beyond sRGB for computer displays then all our images will
look better and closer to that captured by the original device, as the
CCD in most digital cameras can capture colours well outside of sRGB.
It's a shame ICC profiles are so big, because the problem with this
solution is that 4kb is added to every thumbnail, and thumbnails be
only be 4kb themselves, thus adding significantly to loading times for
search results. That's why, by default, the profiles are stripped from
the images intended for previewing only, and is probably why sRGB is
'the recommended colour profile for the web'.
Dan
David Shaw
Jun 17, 2010, 11:08:18 AM6/17/10
to ResourceSpace
The big one I'm aware of is all versions of Internet Explorer on
Windows, which make up at least 65% of our web visitors looking at the
stats. I believe Firefox from version 3.5 onwards colour corrects by
default. So all web images end up as sRGB as a 'standard' as it
ensure all browsers on all operating systems will render the colours
correctly.
A little out of date but good info here:
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html#
Other destination applications I don't think are colour profile aware
are Powerpoint and Word, again sRGB is needed. Also when people come
to print images they need to use an application that honours the
embedded profile.
So in theory it's a great idea to keep the original images in as wide
a colour gamut as possible, but in practice for the average user it's
far more convenient and 'safer' to have it in sRGB. So we end up have
to create derivatives.
I should say we do keep our camera RAW files, these are usually
12-14bit files, the TIFs we currently create from those are 8-bit and
in Adobe RGB. I can see a time soon when we're archiving 16-bit TIFs
in ProPhoto RGB. There's quite a bit of effort in tidying up from a
RAW before its saved as a TIF for us. So the TIF ends up being the
base archival image and the RAW only used very occasionally.
best, David
Windows, which make up at least 65% of our web visitors looking at the
stats. I believe Firefox from version 3.5 onwards colour corrects by
default. So all web images end up as sRGB as a 'standard' as it
ensure all browsers on all operating systems will render the colours
correctly.
A little out of date but good info here:
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html#
Other destination applications I don't think are colour profile aware
are Powerpoint and Word, again sRGB is needed. Also when people come
to print images they need to use an application that honours the
embedded profile.
So in theory it's a great idea to keep the original images in as wide
a colour gamut as possible, but in practice for the average user it's
far more convenient and 'safer' to have it in sRGB. So we end up have
to create derivatives.
I should say we do keep our camera RAW files, these are usually
12-14bit files, the TIFs we currently create from those are 8-bit and
in Adobe RGB. I can see a time soon when we're archiving 16-bit TIFs
in ProPhoto RGB. There's quite a bit of effort in tidying up from a
RAW before its saved as a TIF for us. So the TIF ends up being the
base archival image and the RAW only used very occasionally.
best, David
Tom Gleason
Jun 17, 2010, 11:44:55 AM6/17/10
to resour...@googlegroups.com
http://linux.die.net/man/1/jpegicc
Could using lcms directly could be an option for conversion?
> --
> You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> To post to this group, send email to resour...@googlegroups.com.
> To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
>
>
--
Tom Gleason, PHP Developer
DBA Impressive Design
Exploring ResourceSpace at:
http://resourcespace.blogspot.com
Tom Gleason
Jun 17, 2010, 12:07:11 PM6/17/10
to resour...@googlegroups.com
Documentation on imagemagick color management is totally unclear as to
whether it's even possible.
whether it's even possible.
In several years, I have not discovered a clear answer on whether
imagemagick of graphicsmagick have lcms integrated. Any knowledge or
research on this is appreciated.
There is a lot of confusion over the -profile option, which seems to
just allow embedding or removing a profile, but not conversion.
Ghostscript seems to have some color management coming, but the
details are also unclear:
http://old.nabble.com/GS-and-LCMS-td28852144.html
David Shaw
Jun 17, 2010, 1:03:35 PM6/17/10
to ResourceSpace
We may try letting RS generate the derivatives as normal (preserving
embedded profiles) but scripting a process to then convert all those
RS JPGs to sRGB, and only for modified files after the last run. As
we're staticsyncing this could be done overnight after a staticsync so
there's no chance a user will happen upon an unconverted derivative.
There will be a delay of one day for new files to appear but I think
we can live with that.
What we use to convert the colour space is the next question. I'll
have a play with imagemagick to see if it can do it, at worst I expect
we can batch a photoshop action to do this.
Will RS mind in any way if we modify the JPGs it creates?
best, David
embedded profiles) but scripting a process to then convert all those
RS JPGs to sRGB, and only for modified files after the last run. As
we're staticsyncing this could be done overnight after a staticsync so
there's no chance a user will happen upon an unconverted derivative.
There will be a delay of one day for new files to appear but I think
we can live with that.
What we use to convert the colour space is the next question. I'll
have a play with imagemagick to see if it can do it, at worst I expect
we can batch a photoshop action to do this.
Will RS mind in any way if we modify the JPGs it creates?
best, David
Tom Gleason
Jun 17, 2010, 1:12:21 PM6/17/10
to resour...@googlegroups.com
If you can try jpegicc for conversion, that would be good to hear about.
David Shaw
Jun 17, 2010, 2:14:47 PM6/17/10
to ResourceSpace
While our dev environment for RS is Ubuntu running in VirtualBox it
will ultimately be run on Windows Server 2008, so jpegicc won't be
that useful, but I may try it out if there's time. We also need to
find something that overwrites the original file, so if it only works
by creating a new file that won't be much use.
best, David
On Jun 17, 6:12 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> If you can try jpegicc for conversion, that would be good to hear about.
>
>
>
> On Thu, Jun 17, 2010 at 1:03 PM, David Shaw <dws2...@googlemail.com> wrote:
> > We may try letting RS generate the derivatives as normal (preserving
> > embedded profiles) but scripting a process to then convert all those
> > RS JPGs to sRGB, and only for modified files after the last run. As
> > we're staticsyncing this could be done overnight after a staticsync so
> > there's no chance a user will happen upon an unconverted derivative.
> > There will be a delay of one day for new files to appear but I think
> > we can live with that.
>
> > What we use to convert the colour space is the next question. I'll
> > have a play with imagemagick to see if it can do it, at worst I expect
> > we can batch a photoshop action to do this.
>
> > Will RS mind in any way if we modify the JPGs it creates?
>
> > best, David
>
> > --
> > You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> > To post to this group, send email to resour...@googlegroups.com.
> > To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/resourcespace?hl=en.
will ultimately be run on Windows Server 2008, so jpegicc won't be
that useful, but I may try it out if there's time. We also need to
find something that overwrites the original file, so if it only works
by creating a new file that won't be much use.
best, David
On Jun 17, 6:12 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> If you can try jpegicc for conversion, that would be good to hear about.
>
>
>
> On Thu, Jun 17, 2010 at 1:03 PM, David Shaw <dws2...@googlemail.com> wrote:
> > We may try letting RS generate the derivatives as normal (preserving
> > embedded profiles) but scripting a process to then convert all those
> > RS JPGs to sRGB, and only for modified files after the last run. As
> > we're staticsyncing this could be done overnight after a staticsync so
> > there's no chance a user will happen upon an unconverted derivative.
> > There will be a delay of one day for new files to appear but I think
> > we can live with that.
>
> > What we use to convert the colour space is the next question. I'll
> > have a play with imagemagick to see if it can do it, at worst I expect
> > we can batch a photoshop action to do this.
>
> > Will RS mind in any way if we modify the JPGs it creates?
>
> > best, David
>
> > --
> > You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> > To post to this group, send email to resour...@googlegroups.com.
> > To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
Jeff Harmon
Jun 17, 2010, 5:08:23 PM6/17/10
to ResourceSpace
firefox and safari.
web-ready images should be sRGB - color managed browsers ASSUME sRGB
for images without an embedded profile, so adding an sRGB profile
makes no sense in-browser, though it might make sense for downloads.
color management only works with a valid monitor profile anyway,
remember that. most people don't have one. monitors come with a
default description of their capacities, but these descriptions are
not very accurate.
so, for images destined for preview, thumbs, etc. sRGB is the path of
joy.
now if you want downloads to have the original profile, you run into
another problem - CMYK JPEGs. they aren't formally supported by the
JPEG spec. some readers fail with them. Photoshop honors them, but
alas, yowsa, we are also talking about much larger profiles. if you
think 4k was bad, some CMYK profiles are in the MBs. so, perhaps for
RGB images, retain the profile without transformation, and for CMYK,
convert to sRGB would be advised? i really don't think it's a good
idea to support CMYK JPEGs as proxies.
we are almost gesturing at another function - exporting. of course
gradually we want to provide the ability to custom export different
sizes, color spaces, and even profile-based conversions, with presets,
etc.
more later, gots to go,
jeff
web-ready images should be sRGB - color managed browsers ASSUME sRGB
for images without an embedded profile, so adding an sRGB profile
makes no sense in-browser, though it might make sense for downloads.
color management only works with a valid monitor profile anyway,
remember that. most people don't have one. monitors come with a
default description of their capacities, but these descriptions are
not very accurate.
so, for images destined for preview, thumbs, etc. sRGB is the path of
joy.
now if you want downloads to have the original profile, you run into
another problem - CMYK JPEGs. they aren't formally supported by the
JPEG spec. some readers fail with them. Photoshop honors them, but
alas, yowsa, we are also talking about much larger profiles. if you
think 4k was bad, some CMYK profiles are in the MBs. so, perhaps for
RGB images, retain the profile without transformation, and for CMYK,
convert to sRGB would be advised? i really don't think it's a good
idea to support CMYK JPEGs as proxies.
we are almost gesturing at another function - exporting. of course
gradually we want to provide the ability to custom export different
sizes, color spaces, and even profile-based conversions, with presets,
etc.
more later, gots to go,
jeff
Jeff Harmon
Jun 17, 2010, 5:11:41 PM6/17/10
to ResourceSpace
i've converted from profile to profile using IM many times, with
decent results. pretty sure it's using LCMS for me here. i'll go
chat with the IM folks and confirm. i can guarantee you can use LCMS
with GM, as Bob Friesanhahn it the GM lead and is a MAJOR contributor
to LCMS, and has been for years.
- Jeff
decent results. pretty sure it's using LCMS for me here. i'll go
chat with the IM folks and confirm. i can guarantee you can use LCMS
with GM, as Bob Friesanhahn it the GM lead and is a MAJOR contributor
to LCMS, and has been for years.
- Jeff
Tom Gleason
Jun 17, 2010, 5:16:32 PM6/17/10
to resour...@googlegroups.com
I think someone needs to clarify the issue a bit (with real examples/images)
Ben Vanderberg
Jun 17, 2010, 5:23:37 PM6/17/10
to resour...@googlegroups.com
If I remember color management class correctly, web browsers that
support color management will assume the color profile of the computer
or device. It will not run any processing to process as sRGB. While it
would be amazing if the entire world were all calibrated the same,
life would be so much simpler. For example, the default settings of
the gamma from leopard and older to snow leopard switched from 1.8 to
2.2, making things looks relatively darker to the normal user.
support color management will assume the color profile of the computer
or device. It will not run any processing to process as sRGB. While it
would be amazing if the entire world were all calibrated the same,
life would be so much simpler. For example, the default settings of
the gamma from leopard and older to snow leopard switched from 1.8 to
2.2, making things looks relatively darker to the normal user.
You said there was a wash out issue when converting from sRGB to Adobe
1998? What are your conversion settings?
Also, I do not believe color managment is turned on by default in
firefox.
Jeff Harmon
Jun 17, 2010, 5:39:25 PM6/17/10
to ResourceSpace
no, you're confusing source with destination profile. the source
profile is the profile associated with the image, and the monitor
profile is its own description. the transform that happens in browser
or in photoshop is between the source and destination. to confuse
matters, yes, you can calibrate your monitor to "sRGB" but that
doesn't mean it's the source, even if the source is sRGB as well.
firefox 3.5> has color management on by default now.
http://blog.patyuen.com/2009/07/04/firefox-35-and-color-management/
- Jeff
On Jun 17, 2:23 pm, Ben Vanderberg <macthinkdiffer...@gmail.com>
wrote:
profile is the profile associated with the image, and the monitor
profile is its own description. the transform that happens in browser
or in photoshop is between the source and destination. to confuse
matters, yes, you can calibrate your monitor to "sRGB" but that
doesn't mean it's the source, even if the source is sRGB as well.
firefox 3.5> has color management on by default now.
http://blog.patyuen.com/2009/07/04/firefox-35-and-color-management/
- Jeff
On Jun 17, 2:23 pm, Ben Vanderberg <macthinkdiffer...@gmail.com>
wrote:
> If I remember color management class correctly, web browsers that
> support color management will assume the color profile of the computer
> or device. It will not run any processing to process as sRGB. While it
> would be amazing if the entire world were all calibrated the same,
> life would be so much simpler. For example, the default settings of
> the gamma from leopard and older to snow leopard switched from 1.8 to
> 2.2, making things looks relatively darker to the normal user.
>
> You said there was a wash out issue when converting from sRGB to Adobe
> 1998? What are your conversion settings?
>
> Also, I do not believe color managment is turned on by default in
> firefox.
>
> support color management will assume the color profile of the computer
> or device. It will not run any processing to process as sRGB. While it
> would be amazing if the entire world were all calibrated the same,
> life would be so much simpler. For example, the default settings of
> the gamma from leopard and older to snow leopard switched from 1.8 to
> 2.2, making things looks relatively darker to the normal user.
>
> You said there was a wash out issue when converting from sRGB to Adobe
> 1998? What are your conversion settings?
>
> Also, I do not believe color managment is turned on by default in
> firefox.
>
Jeff Harmon
Jun 17, 2010, 5:40:16 PM6/17/10
to ResourceSpace
if you have a question, i can answer it for you.
check this link for real examples:
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
- J
On Jun 17, 2:16 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> I think someone needs to clarify the issue a bit (with real examples/images)
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:11 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > i've converted from profile to profile using IM many times, with
> > decent results. pretty sure it's using LCMS for me here. i'll go
> > chat with the IM folks and confirm. i can guarantee you can use LCMS
> > with GM, as Bob Friesanhahn it the GM lead and is a MAJOR contributor
> > to LCMS, and has been for years.
>
> > - Jeff
>
> > On Jun 17, 9:07 am, Tom Gleason <theorysav...@gmail.com> wrote:
> >> Documentation on imagemagick color management is totally unclear as to
> >> whether it's even possible.
>
> > --
> > You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> > To post to this group, send email to resour...@googlegroups.com.
> > To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/resourcespace?hl=en.
check this link for real examples:
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
- J
On Jun 17, 2:16 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> I think someone needs to clarify the issue a bit (with real examples/images)
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:11 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > i've converted from profile to profile using IM many times, with
> > decent results. pretty sure it's using LCMS for me here. i'll go
> > chat with the IM folks and confirm. i can guarantee you can use LCMS
> > with GM, as Bob Friesanhahn it the GM lead and is a MAJOR contributor
> > to LCMS, and has been for years.
>
> > - Jeff
>
> > On Jun 17, 9:07 am, Tom Gleason <theorysav...@gmail.com> wrote:
> >> Documentation on imagemagick color management is totally unclear as to
> >> whether it's even possible.
>
> > --
> > You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
> > To post to this group, send email to resour...@googlegroups.com.
> > To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
Tom Gleason
Jun 17, 2010, 5:42:56 PM6/17/10
to resour...@googlegroups.com
why would David's images end up washed out?
> For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Jeff Harmon
Jun 17, 2010, 5:55:30 PM6/17/10
to ResourceSpace
adobe RGB images, if they don't have an ICC profile saying that's what
they are, are assumed by color managing browsers like firefox and
safari to be sRGB, so the transform that is applied is poorly
executed. if you assume an image is sRGB when it's really adobe RGB,
you are assuming it doesn't have meaningful color designations in
certain areas, a lot of them blues and purples, some greens, etc. (i
can post a gamut hull comparison for you in a moment). in non-color
managed browsers, you get wildly different results, depending on the
monitor's behavior (in color managed ones, the behavior depends on the
accuracy of the monitor's profile as well - defined in the OS). check
the link provided, on the left, comparing tagged vs. untagged Adobe
RGB images.
does that help?
- Jeff
On Jun 17, 2:42 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> why would David's images end up washed out?
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:40 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > if you have a question, i can answer it for you.
>
> > check this link for real examples:
>
> >http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles...
they are, are assumed by color managing browsers like firefox and
safari to be sRGB, so the transform that is applied is poorly
executed. if you assume an image is sRGB when it's really adobe RGB,
you are assuming it doesn't have meaningful color designations in
certain areas, a lot of them blues and purples, some greens, etc. (i
can post a gamut hull comparison for you in a moment). in non-color
managed browsers, you get wildly different results, depending on the
monitor's behavior (in color managed ones, the behavior depends on the
accuracy of the monitor's profile as well - defined in the OS). check
the link provided, on the left, comparing tagged vs. untagged Adobe
RGB images.
does that help?
- Jeff
On Jun 17, 2:42 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> why would David's images end up washed out?
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:40 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > if you have a question, i can answer it for you.
>
> > check this link for real examples:
>
Tom Gleason
Jun 17, 2010, 6:02:38 PM6/17/10
to resour...@googlegroups.com
so if the source image has an embedded AdobeRGB profile, convert it to
sRGB actually, so that the end program can assume it?
sRGB actually, so that the end program can assume it?
when imagemagick converts to rgb, is it the srgb space? would
changing RGB to sRGB in the command make any difference?
convert -list colorspace
CMY
CMYK
Gray
HSB
HSL
HWB
Lab
Log
OHTA
Rec601Luma
Rec601YCbCr
Rec709Luma
Rec709YCbCr
RGB
sRGB
Transparent
XYZ
YCbCr
YCC
YIQ
YPbPr
YUV
> For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Jeff Harmon
Jun 17, 2010, 6:02:40 PM6/17/10
to ResourceSpace
sorry, david's really complaining more about the color management of
derivatives here, not in browser representation - separate but related
issues.
i'll have to look at the code again, but i believe we are translating
into -colorspace RGB and removing any ICC profile from derivatives.
so again, the browser has no way of knowing whether it's adobe RGB.
color values are constrained by bit depth - bit depth tells you the
range of acceptable values. ICC profiles try to describe the visual
result, so color values in sRGB for example, may be different but not
actually result in different colors visually. color values that are
outside of the range of the colors (gamut) in the profile are all
pushed into range by different algorithms called rendering intents.
so, in adobe RGB, many color values amount to visual differences that
aren't visible in sRGB. they are out of sRGB's "gamut." so, colors
outside of sRGB's gamut that are inside Adobe RGB's gamut are not
handled properly in viewers that aren't color managed or don't have
the proper information about the source image.
- Jeff
On Jun 17, 2:42 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> why would David's images end up washed out?
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:40 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > if you have a question, i can answer it for you.
>
> > check this link for real examples:
>
> >http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles...
derivatives here, not in browser representation - separate but related
issues.
i'll have to look at the code again, but i believe we are translating
into -colorspace RGB and removing any ICC profile from derivatives.
so again, the browser has no way of knowing whether it's adobe RGB.
color values are constrained by bit depth - bit depth tells you the
range of acceptable values. ICC profiles try to describe the visual
result, so color values in sRGB for example, may be different but not
actually result in different colors visually. color values that are
outside of the range of the colors (gamut) in the profile are all
pushed into range by different algorithms called rendering intents.
so, in adobe RGB, many color values amount to visual differences that
aren't visible in sRGB. they are out of sRGB's "gamut." so, colors
outside of sRGB's gamut that are inside Adobe RGB's gamut are not
handled properly in viewers that aren't color managed or don't have
the proper information about the source image.
- Jeff
On Jun 17, 2:42 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> why would David's images end up washed out?
>
>
>
>
>
> On Thu, Jun 17, 2010 at 5:40 PM, Jeff Harmon <jeffreyhhar...@gmail.com> wrote:
> > if you have a question, i can answer it for you.
>
> > check this link for real examples:
>
Tom Gleason
Jun 17, 2010, 6:04:34 PM6/17/10
to resour...@googlegroups.com
the option to strip profiles, by the way, is only applied to the
col,pre,thm,and scr images; I don't believe it applies to high/low res
downloadables.
col,pre,thm,and scr images; I don't believe it applies to high/low res
downloadables.
> For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Tom Gleason
Jun 17, 2010, 6:25:27 PM6/17/10
to resour...@googlegroups.com
can someone send me an AdobeRGB image?
Tom Gleason
Jun 17, 2010, 6:34:42 PM6/17/10
to resour...@googlegroups.com
Tom Gleason
Jun 17, 2010, 7:44:02 PM6/17/10
to resour...@googlegroups.com
After some tests, I do see color management working, based on what Dan suggested. However, note the order of operations in stripping and converting makes a difference.
Here are the results:
starting with TaggedAdobeRGB.jpg, I did four test conversions:
1) STRIP ONLY, with the washed out results:
convert TaggedAdobeRGB.jpg +profile '*' stripped_convert.jpg
======== stripped_convert.jpg
File Size : 41 kB
2) CONVERSION to sRGB, which seems to produce the intended result
convert TaggedAdobeRGB.jpg -profile sRGB_v4_ICC_preference_displayclass.icc to_sRGB.jpg
======== to_sRGB.jpg
Profile Description : sRGB v4 ICC preference perceptual intent beta display class
File Size : 128 kB
3) STRIP THEN CONVERT. I believe this skipped the conversion as there was no reference profile, and the output is again washed out.
convert TaggedAdobeRGB.jpg +profile '*' -profile sRGB_v4_ICC_preference_displayclass.icc strip_to_sRGB.jpg
======== strip_to_sRGB.jpg
Profile Description : sRGB v4 ICC preference perceptual intent beta display class
File Size : 100 kB
4) CONVERT THEN STRIP, visually has same results as to_sRGB but no profile attached.
convert TaggedAdobeRGB.jpg -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' to_sRGB_strip.jpg
======== to_sRGB_strip.jpg
File Size : 42 kB
Here are the results:
starting with TaggedAdobeRGB.jpg, I did four test conversions:
1) STRIP ONLY, with the washed out results:
convert TaggedAdobeRGB.jpg +profile '*' stripped_convert.jpg
======== stripped_convert.jpg
File Size : 41 kB
2) CONVERSION to sRGB, which seems to produce the intended result
convert TaggedAdobeRGB.jpg -profile sRGB_v4_ICC_preference_displayclass.icc to_sRGB.jpg
======== to_sRGB.jpg
Profile Description : sRGB v4 ICC preference perceptual intent beta display class
File Size : 128 kB
3) STRIP THEN CONVERT. I believe this skipped the conversion as there was no reference profile, and the output is again washed out.
convert TaggedAdobeRGB.jpg +profile '*' -profile sRGB_v4_ICC_preference_displayclass.icc strip_to_sRGB.jpg
======== strip_to_sRGB.jpg
Profile Description : sRGB v4 ICC preference perceptual intent beta display class
File Size : 100 kB
4) CONVERT THEN STRIP, visually has same results as to_sRGB but no profile attached.
convert TaggedAdobeRGB.jpg -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' to_sRGB_strip.jpg
======== to_sRGB_strip.jpg
File Size : 42 kB
Tom Gleason
Jun 17, 2010, 7:49:06 PM6/17/10
to resour...@googlegroups.com
And the exiftool output for that source image:
Profile Description : Adobe RGB (1998)
File Size : 68 kB
Profile Description : Adobe RGB (1998)
File Size : 68 kB
Tom Gleason
Jun 17, 2010, 8:10:25 PM6/17/10
to resour...@googlegroups.com
There are slight differences between the source AdobeRGB image and the 'to_sRGB.jpg' and 'to_sRGB_strip.jpg' output, particularly a bit of vibrancy is lost and the blue and green color bars seem to be altered more significantly than the rest, but is a slight difference like that expected?
It is certainly better than the full strip, which completely washes it out.
It is certainly better than the full strip, which completely washes it out.
Jeff Harmon
Jun 17, 2010, 8:17:43 PM6/17/10
to ResourceSpace
that's a good idea if it's honoring the source profile embedded in the
image, which i believe it would not using the colorspace switch.
- J
image, which i believe it would not using the colorspace switch.
- J
Jeff Harmon
Jun 17, 2010, 8:21:20 PM6/17/10
to ResourceSpace
no, RGB colorspace is not the same kind of things as sRGB. sRGB is an
abstracted profile, meaning it describes the visual meaning of color
values, not the space in which the color values reside. so,
converting to RGB colorspace simply means converting the values
without taking into account the visual meaning of the values. ICC
profiles like sRGB are an additional layer ON TOP of colorspacelike
RGB. in other words, if you wanted a color to be converted from Adobe
RGB to sRGB, you'd figure out what numbers you'd need in the new
profile space to get the same visual result. ICC profiles are about
visual impression, not values in and of themselves!
- Jeff
abstracted profile, meaning it describes the visual meaning of color
values, not the space in which the color values reside. so,
converting to RGB colorspace simply means converting the values
without taking into account the visual meaning of the values. ICC
profiles like sRGB are an additional layer ON TOP of colorspacelike
RGB. in other words, if you wanted a color to be converted from Adobe
RGB to sRGB, you'd figure out what numbers you'd need in the new
profile space to get the same visual result. ICC profiles are about
visual impression, not values in and of themselves!
- Jeff
Jeff Harmon
Jun 17, 2010, 8:23:17 PM6/17/10
to ResourceSpace
IM is playing a little loose here, listing sRGB as a colorspace
proper. it's kludgy. notice how it's the only ICC profile "space" to
be listed.
- Jeff
proper. it's kludgy. notice how it's the only ICC profile "space" to
be listed.
- Jeff
Tom Gleason
Jun 17, 2010, 8:24:27 PM6/17/10
to resour...@googlegroups.com
I got strange results when switching RGB to sRGB..
if I used -colorspace sRGB, I ended up with oversaturated images in most cases
if I used -colorspace sRGB, I ended up with oversaturated images in most cases
Tom Gleason
Jun 17, 2010, 8:25:57 PM6/17/10
to resour...@googlegroups.com
And those observations are based on viewing the images in Firefox which is color managed.
To attempt to back up these finding futher, I'm looking at the same images in Eye of Gnome, which appears not to have color management.
both images that were converted to sRGB, 'to_sRGB_strip.jpg' and 'to_sRGB.jpg' look colorful,
while the three other images:
-embedded AdobeRGB
-embedded sRGB but not converted
-stripped profile, not converted
all look washed out.
From my understanding of the issue at this point, this makes complete sense.
To attempt to back up these finding futher, I'm looking at the same images in Eye of Gnome, which appears not to have color management.
both images that were converted to sRGB, 'to_sRGB_strip.jpg' and 'to_sRGB.jpg' look colorful,
while the three other images:
-embedded AdobeRGB
-embedded sRGB but not converted
-stripped profile, not converted
all look washed out.
From my understanding of the issue at this point, this makes complete sense.
Jeff Harmon
Jun 17, 2010, 8:27:42 PM6/17/10
to ResourceSpace
I'll test this as well as ask the IM community and get back to
everyone post haste.
- jeff
everyone post haste.
- jeff
Tom Gleason
Jun 17, 2010, 8:29:19 PM6/17/10
to resour...@googlegroups.com
note that you have to actually View these images as who knows what happened to the thumbnails that gmail produced.
Jeff Harmon
Jun 17, 2010, 9:04:07 PM6/17/10
to ResourceSpace
On Jun 17, 5:10 pm, Tom Gleason <theorysav...@gmail.com> wrote:
> There are slight differences between the source AdobeRGB image and the
> 'to_sRGB.jpg' and 'to_sRGB_strip.jpg' output, particularly a bit of vibrancy
> is lost and the blue and green color bars seem to be altered more
> significantly than the rest, but is a slight difference like that expected?
that's EXACTLY as expected! the blue green regions are where the
> There are slight differences between the source AdobeRGB image and the
> 'to_sRGB.jpg' and 'to_sRGB_strip.jpg' output, particularly a bit of vibrancy
> is lost and the blue and green color bars seem to be altered more
> significantly than the rest, but is a slight difference like that expected?
difference between Adobe RGB and sRGB lie the most!
Tom Gleason
Jun 17, 2010, 9:17:01 PM6/17/10
to resour...@googlegroups.com
also note the file called stripped_convert.jpg should probably just be named stripped.jpg... I was differentiating it between a straight imagemagick convert and an imagemagick convert stripping profiles... convert in this case doesn't mean a color profile conversion.
--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To post to this group, send email to resour...@googlegroups.com.
To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Tom Gleason
Jun 17, 2010, 9:19:34 PM6/17/10
to resour...@googlegroups.com
Here are visualizations that confirm the mostly blue-green difference between sRGB and AdobeRGB as well.
http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm
http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm
--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To post to this group, send email to resour...@googlegroups.com.
To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Jeff Harmon
Jun 17, 2010, 10:27:40 PM6/17/10
to ResourceSpace
FYI, the license on even saying "Adobe RGB" is fairly strict.
"The name 'Adobe RGB (1998)' also is used as a software product
trademark for Adobe's implementation of the Adobe RGB (1998) ICC
profile. Adobe does not permit the use of the Adobe RGB trademark for
software, hardware, or other related products from companies other
than Adobe, unless the company has obtained a prior written license
from Adobe to do so."
http://www.adobe.com/support/downloads/iccprofiles/icc_eula_mac_dist.html
so, well, we can't show it in the UI without permission.
-Jeff
"The name 'Adobe RGB (1998)' also is used as a software product
trademark for Adobe's implementation of the Adobe RGB (1998) ICC
profile. Adobe does not permit the use of the Adobe RGB trademark for
software, hardware, or other related products from companies other
than Adobe, unless the company has obtained a prior written license
from Adobe to do so."
http://www.adobe.com/support/downloads/iccprofiles/icc_eula_mac_dist.html
so, well, we can't show it in the UI without permission.
-Jeff
Jeff Harmon
Jun 17, 2010, 10:32:10 PM6/17/10
to ResourceSpace
are you using the LCMS variant? i assume so.
you should also try these switches between input and output:
-intent relative -black-point-compensation
and see if you like the result better.
- Jeff
you should also try these switches between input and output:
-intent relative -black-point-compensation
and see if you like the result better.
- Jeff
Tom Gleason
Jun 17, 2010, 10:51:06 PM6/17/10
to resour...@googlegroups.com
You're right! relative intent and blackpoint compensation produces almost indistinguishable translation.
Here are four more variants:
RELATIVE/BLACKPOINT (clearly BEST! as the blacks aren't squashed)
convert TaggedAdobeRGB.jpg -intent Relative -black-point-compensation -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' relative_blackpoint_sRGB.jpg
RELATIVE (dark gray swatches get squashed to black)
convert TaggedAdobeRGB.jpg -intent Relative -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' relative_sRGB.jpg
PERCEPTUAL/BLACKPOINT (more color shifting than relative)
convert TaggedAdobeRGB.jpg -intent Perceptual -black-point-compensation -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' perceptual_blackpoint_sRGB.jpg
PERCEPTUAL (more color shifting than relative)
convert TaggedAdobeRGB.jpg -intent Perceptual -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' perceptual_sRGB.jpg
Here are four more variants:
RELATIVE/BLACKPOINT (clearly BEST! as the blacks aren't squashed)
convert TaggedAdobeRGB.jpg -intent Relative -black-point-compensation -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' relative_blackpoint_sRGB.jpg
RELATIVE (dark gray swatches get squashed to black)
convert TaggedAdobeRGB.jpg -intent Relative -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' relative_sRGB.jpg
PERCEPTUAL/BLACKPOINT (more color shifting than relative)
convert TaggedAdobeRGB.jpg -intent Perceptual -black-point-compensation -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' perceptual_blackpoint_sRGB.jpg
PERCEPTUAL (more color shifting than relative)
convert TaggedAdobeRGB.jpg -intent Perceptual -profile sRGB_v4_ICC_preference_displayclass.icc +profile '*' perceptual_sRGB.jpg
--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To post to this group, send email to resour...@googlegroups.com.
To unsubscribe from this group, send email to resourcespac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.
Tom Gleason
Jun 17, 2010, 10:55:26 PM6/17/10
to resour...@googlegroups.com
actually it's totally indistinguishable to me. Awesome.
David Dwiggins
Jun 17, 2010, 11:09:29 PM6/17/10
to resour...@googlegroups.com
I've been following this conversation with interest, since I've been
looking at some of our color workflow for unrelated reasons over the
last few weeks. We're using Adobe 1998 for most new imagery, but are
using the ResourceSpace previews for our website. So getting the color
to flow more accurately between these would be great.
looking at some of our color workflow for unrelated reasons over the
last few weeks. We're using Adobe 1998 for most new imagery, but are
using the ResourceSpace previews for our website. So getting the color
to flow more accurately between these would be great.
Regarding the naming issue below, according to another adobe page, "If
vendors choose to create their own profile according to this
specification, and they want to indicate to their customers that this
profile was written in accordance with Adobe's specification, then an
alternate phrasing is required, such as "compatible with Adobe RGB
(1998)."
http://www.adobe.com/digitalimag/adobergb.html
-David
Jeff Harmon
Jun 18, 2010, 12:40:38 AM6/18/10
to ResourceSpace
i can take a moment to explain rendering intents and black point
compensation, since everyone seems engaged!
renderings intents tells you how to deal with gamut differences:
relative colorimetric says "leave all the color values that are within
gamut alone, and for colors outide of gamut, push them in (generally
by reducing saturation) until they are within gamut. don't adjust the
color of white... for example, if you were printing on a slightly
yellowish paper and changed to a really bright white paper, don't
change the color of white so it's yellowish... let it remain relative
to the target gamut "
absolute colorimetric says "do the same thing as above, but don't
sanctify white. feel free to change the values for white. so, for
example if you are going from a space where white is yellowish, to a
space where the white is rather blue, add yellow so the whites
visually match - don't sanctify white, make it absolutely accurate"
saturation intent says "just pick the most saturated color in the
target gamut - saturation is more important than accuracy to
me" (think bar graphs or pie charts or something where all you care is
that they remain as vivid as they were
perceptual/photographic says "just keep all the relationships among
the colors as close as possible to what we had before, i don't care
whether they're in gamut or not" it turns out people notice
relationships more than absolute value matches much of the time,
especially with photos with a lot of range in them. however, that
sacralized brand color could be shifted.
so, relative is used most and is the default in photoshop. perceptual
is used second most, then absolute (used most in printing and trying
to get a perfect match across different papers), then saturation.
black point compensation is a way of trying to maintain shadow
details. with bpc, the full dynamic range of the source is mapped
into the full range of the target. it is also on by default. it's
pretty much useless in combindation with photographic/perceptual, as
the ratio algorithm already keeps the blacks distributed
proportionately to how they were in the source image. it's used very
often with relative colorimetric, and pretty much never with absolute
- i assume because it would overlap with what the white point
operation is trying to do.
when relative doesn't seem to make a difference, it's because most/all
off the colors are in gamut between the spaces. since relative intent
honors in-gamut values and only shifts out of gamut ones, when you're
mostly in gamut, it doesn't do anything. and since the dynamic ranges
are nearly identical in that case, bpc also does almost nothing.
HOWEVER, relative with bpc on is where we want to live as our
default. for reasons that may be clearer i hope!
- Jeff Harmon
Colorhythm LLC
compensation, since everyone seems engaged!
renderings intents tells you how to deal with gamut differences:
relative colorimetric says "leave all the color values that are within
gamut alone, and for colors outide of gamut, push them in (generally
by reducing saturation) until they are within gamut. don't adjust the
color of white... for example, if you were printing on a slightly
yellowish paper and changed to a really bright white paper, don't
change the color of white so it's yellowish... let it remain relative
to the target gamut "
absolute colorimetric says "do the same thing as above, but don't
sanctify white. feel free to change the values for white. so, for
example if you are going from a space where white is yellowish, to a
space where the white is rather blue, add yellow so the whites
visually match - don't sanctify white, make it absolutely accurate"
saturation intent says "just pick the most saturated color in the
target gamut - saturation is more important than accuracy to
me" (think bar graphs or pie charts or something where all you care is
that they remain as vivid as they were
perceptual/photographic says "just keep all the relationships among
the colors as close as possible to what we had before, i don't care
whether they're in gamut or not" it turns out people notice
relationships more than absolute value matches much of the time,
especially with photos with a lot of range in them. however, that
sacralized brand color could be shifted.
so, relative is used most and is the default in photoshop. perceptual
is used second most, then absolute (used most in printing and trying
to get a perfect match across different papers), then saturation.
black point compensation is a way of trying to maintain shadow
details. with bpc, the full dynamic range of the source is mapped
into the full range of the target. it is also on by default. it's
pretty much useless in combindation with photographic/perceptual, as
the ratio algorithm already keeps the blacks distributed
proportionately to how they were in the source image. it's used very
often with relative colorimetric, and pretty much never with absolute
- i assume because it would overlap with what the white point
operation is trying to do.
when relative doesn't seem to make a difference, it's because most/all
off the colors are in gamut between the spaces. since relative intent
honors in-gamut values and only shifts out of gamut ones, when you're
mostly in gamut, it doesn't do anything. and since the dynamic ranges
are nearly identical in that case, bpc also does almost nothing.
HOWEVER, relative with bpc on is where we want to live as our
default. for reasons that may be clearer i hope!
- Jeff Harmon
Colorhythm LLC
Jeff Harmon
Jun 18, 2010, 12:44:59 AM6/18/10
to ResourceSpace
watch out tom, you're using an ICC v4 sRGB profile... i have no idea
why it's been working for you at all!!
v4 profiles aren't honored in firefox!
https://bugzilla.mozilla.org/show_bug.cgi?id=488800
http://www.color.org/version4html.xalter
when mozilla dropped LCMS and rolled their own for speed, they lost
some things in quality...
the ICC provides v2 versions:
http://color.org/srgbprofiles.xalter
i recommend the no_black_scaling version, and defaulting to BPC on.
why it's been working for you at all!!
v4 profiles aren't honored in firefox!
https://bugzilla.mozilla.org/show_bug.cgi?id=488800
http://www.color.org/version4html.xalter
when mozilla dropped LCMS and rolled their own for speed, they lost
some things in quality...
the ICC provides v2 versions:
http://color.org/srgbprofiles.xalter
i recommend the no_black_scaling version, and defaulting to BPC on.
Tom Gleason
Jun 18, 2010, 12:53:46 AM6/18/10
to resour...@googlegroups.com
Thanks much! First time CM (esp within IM) is making some sense to me.
--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To ...
Tom Gleason
Jun 18, 2010, 1:00:17 AM6/18/10
to resour...@googlegroups.com
Thanks, I suppose the profile doesn't matter much here because its srgb .. and because the colors would work with or without it? A v4 source image, I imagine, would have left me scratching my head
On Jun 18, 2010 12:45 AM, "Jeff Harmon" <jeffrey...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To ...
Jeff Harmon
Jun 18, 2010, 3:55:29 AM6/18/10
to ResourceSpace
i'd like to try to tidy up the overview:
imagine going into a TV shop and looking at all the TVs on the same
station. they're all receiving the same signals, the same color
values. but wait, perhaps they look a little different. well, that's
what ICC profiles were invented to deal with, that kind of situation.
so, it's not the color values, it's the visual result that they deal
with. if you can describe the curve ball that each display is
applying to the signal, you could theoretically compensate for it, and
change the values on the fly to become the same visual
result. ...that's what monitor profiling enables.
calibration means making something act a particular way - it means
you're actually changing the way it behaves. profiling is just
describing how it's behaving, not changing it. much of the time,
people calibrate. then profile. they try to make a device hit a known
target, then they build a description of how it behaves.
the way ICC profiles are built is by sending known color values, light
ones, dark ones, red ones, green ones, blue ones, etc., of all kinds,
and then measuring the visual result of what comes out, either by
attaching something to a monitor and measuring a bunch of values (with
a colorimeter, sometimes a spectrophotometer) or measuring a print out
of a bunch of values (with a spectrophotometer). then you build a
description in a matrix or table or curve that describes how the
device changed the values on the way out. you want to know how a
printer or display handles pure white and pure black, too, because
they're special.
with things that shine directly out like monitors, you'll also want to
know about the amount of light it puts out (luminance) and how that
changes as you go from pure black to pure white (gamma), which is
generally not a straight line because of the way voltages are not
linear. with printers, you need to know how much ink expands when it
hits paper (dot gain), when to use black ink or even amounts of C, M
and Y (UCR/GCR), the max limits of how much ink you can put in one
spot (total ink limit), etc. you can then use that description in many
ways. it travels with files that were authored on that device to
inform people about the conditions under which it was captured/
approved/corrected, so that can be used to transform it into another
space. like an image with an Adobe RGB profile embedded in it going
to a printer. you would convert from Adobe RGB to the printer's CMYK
profile, and what that means is that it would do its best job to get
the same visual result under the new conditions (guided by rendering
intent, BPC, etc., as discussed).
profiles like adobe RGB and sRGB are weird because they are abstracted
"workspaces" - they are almost like mythical "device" descriptions,
invented for various purposes. (sRGB was invented by HP and MIcrosoft
to be a description of kind of average monitor.) they are specially
created so if you convert into them, they are easy to work with. good
shared standards for everyone. cameras that give you adobe RGB images
are not actually adobe RGB devices - they are secretly converting from
the camera's RGB space to Adobe RGB without telling you about it!
imagine going into a TV shop and looking at all the TVs on the same
station. they're all receiving the same signals, the same color
values. but wait, perhaps they look a little different. well, that's
what ICC profiles were invented to deal with, that kind of situation.
so, it's not the color values, it's the visual result that they deal
with. if you can describe the curve ball that each display is
applying to the signal, you could theoretically compensate for it, and
change the values on the fly to become the same visual
result. ...that's what monitor profiling enables.
calibration means making something act a particular way - it means
you're actually changing the way it behaves. profiling is just
describing how it's behaving, not changing it. much of the time,
people calibrate. then profile. they try to make a device hit a known
target, then they build a description of how it behaves.
the way ICC profiles are built is by sending known color values, light
ones, dark ones, red ones, green ones, blue ones, etc., of all kinds,
and then measuring the visual result of what comes out, either by
attaching something to a monitor and measuring a bunch of values (with
a colorimeter, sometimes a spectrophotometer) or measuring a print out
of a bunch of values (with a spectrophotometer). then you build a
description in a matrix or table or curve that describes how the
device changed the values on the way out. you want to know how a
printer or display handles pure white and pure black, too, because
they're special.
with things that shine directly out like monitors, you'll also want to
know about the amount of light it puts out (luminance) and how that
changes as you go from pure black to pure white (gamma), which is
generally not a straight line because of the way voltages are not
linear. with printers, you need to know how much ink expands when it
hits paper (dot gain), when to use black ink or even amounts of C, M
and Y (UCR/GCR), the max limits of how much ink you can put in one
spot (total ink limit), etc. you can then use that description in many
ways. it travels with files that were authored on that device to
inform people about the conditions under which it was captured/
approved/corrected, so that can be used to transform it into another
space. like an image with an Adobe RGB profile embedded in it going
to a printer. you would convert from Adobe RGB to the printer's CMYK
profile, and what that means is that it would do its best job to get
the same visual result under the new conditions (guided by rendering
intent, BPC, etc., as discussed).
profiles like adobe RGB and sRGB are weird because they are abstracted
"workspaces" - they are almost like mythical "device" descriptions,
invented for various purposes. (sRGB was invented by HP and MIcrosoft
to be a description of kind of average monitor.) they are specially
created so if you convert into them, they are easy to work with. good
shared standards for everyone. cameras that give you adobe RGB images
are not actually adobe RGB devices - they are secretly converting from
the camera's RGB space to Adobe RGB without telling you about it!
Jeff Harmon
Jun 21, 2010, 12:07:11 AM6/21/10
to ResourceSpace
FYI, Bob just announced that the next rev of GrapicsMagick will
support LCMS 2. LCMS 2 is a MAJOR upgrade. and if Bob feels it's
release ready, I trust him. He's worked closely with Marti and the
LCMS community for.. almost a decade? wow, time flies!
- Jeff Harmon
support LCMS 2. LCMS 2 is a MAJOR upgrade. and if Bob feels it's
release ready, I trust him. He's worked closely with Marti and the
LCMS community for.. almost a decade? wow, time flies!
- Jeff Harmon
Jeff Harmon
Jun 21, 2010, 12:28:54 AM6/21/10
to ResourceSpace
well, you were using the v4 profile in the conversion, so the color
values were converted properly by IM/LCMS, which DOES honor v4
profiles. it's just when you embedded a v4 profile into the image to
proof it within firefox when you weren't actually getting a correctly
proofed image. that said, there is the other part of the equation -
your monitor profile. do you have one? does firefox know where it is?
go to about:config and check for gfx.color_management.display_profile
and see if it has any string listed?
it should have the full path to an ICC profile; the default is an
empty string in which case the OS global profile is used. if no global
profile is found, it assumes sRGB for the monitor profile, which is
good to know!
http://kb.mozillazine.org/Gfx.color_management.display_profile
the default value for gfx.color_management.enabled is 2, which means
"enable color management for tagged graphics only" so no transform is
attempted for non-tagged images. i suppose that's ok, though i
thought it assumed untagged images were sRGB and transformed them
anyway. i'll check on this!
also, note that for gfx.color_management.rendering_intent firefox is
defaulting to perceptual (photographic) rendering intent. i suppose
that's ok. i would love to be able to specify that on a per-image
basis. alas, until CSS supports color management (last I knew they
dumped it from the CSS3 list) we won't have that type of control.
here's the working draft:
http://www.w3.org/TR/css3-iccprof
- Jeff Harmon
values were converted properly by IM/LCMS, which DOES honor v4
profiles. it's just when you embedded a v4 profile into the image to
proof it within firefox when you weren't actually getting a correctly
proofed image. that said, there is the other part of the equation -
your monitor profile. do you have one? does firefox know where it is?
go to about:config and check for gfx.color_management.display_profile
and see if it has any string listed?
it should have the full path to an ICC profile; the default is an
empty string in which case the OS global profile is used. if no global
profile is found, it assumes sRGB for the monitor profile, which is
good to know!
http://kb.mozillazine.org/Gfx.color_management.display_profile
the default value for gfx.color_management.enabled is 2, which means
"enable color management for tagged graphics only" so no transform is
attempted for non-tagged images. i suppose that's ok, though i
thought it assumed untagged images were sRGB and transformed them
anyway. i'll check on this!
also, note that for gfx.color_management.rendering_intent firefox is
defaulting to perceptual (photographic) rendering intent. i suppose
that's ok. i would love to be able to specify that on a per-image
basis. alas, until CSS supports color management (last I knew they
dumped it from the CSS3 list) we won't have that type of control.
here's the working draft:
http://www.w3.org/TR/css3-iccprof
- Jeff Harmon
Reply all
Reply to author
Forward
0 new messages