[argyllcms] Re: sRGB variants
- From: Elle Stone <l.elle.stone@xxxxxxxxx>
- To: Tom Lianza <tlianza@xxxxxxxxx>
- Date: Sun, 24 Jun 2012 16:51:17 -0400
Hi all,
Tom, I don't think we are talking about the same thing. But I'll try
to address your points, all of which are very interesting.
On 6/24/12, Tom Lianza <tlianza@xxxxxxxxx> wrote:
> Hello to all,
>
> Andy Kraushaar, from Fogra suggested that I should clarify the issue of
> sRGB
> variants of profiles found in the web-o-sphere.
>
> Fundamentally, the reason so many profiles exist is that sRGB is an
> encoding
> specification that has some viewing assumptions attached to it. If you
> measure the actual response of virtually any sRGB camera, it will not have
> the ³gamma² or TRC that is suggested by the sRGB specification. The actual
> working gamma is normally a factor of 1.2 to 1.4 times the pseudo gamma 2.2
> used in the sRGB specification. This is due to in camera rendering which
> makes the darkened room assumption that the sRGB specification cites and
> the
> desire to make the image on the screen appear more like a transparency. If
> you are working in an ICC workflow, and use the original sRGB profile, your
> images, when printed, will be recorded at a higher contrast and will often
> look too dark. The printer manufacturers actually tune the printer to a
> lower contrast assumption when dealing with ³Printer Color Management².
> This is why prints from sRGB sources often look better without ICC color
> management. It is a question of the assumptions that went into the
> rendering intent of the profile and the rendering used in the input device.
Nowhere in my article do I talk about sending an sRGB camera image to
a printer.
My article talks about how to deal with the fact that the different
***image editing softwares*** are offering to embed different versions
of sRGB, all matrix profiles, mostly V2 profiles, in the untagged
images from my point-and-shoot, when I open the images for editing.
Color.org V4 sRGB profiles aren't mentioned at all.
The topic of my article: when I open an untagged/profileless sRGB
image with various editing programs, for purposes of editing (not
printing) said image, the several different editing software packages
on my computer offer to embed a variety of different sRGB variants. I
was surprised and intrigued by the proliferation of V2 sRGB profiles.
I had always assumed sRGB (prior to V4) was completely monolithic,
"the sRGB color space profile". So I investigated carefully and wrote
up my findings. Which are:
1. Most of the time, for most of the variants, it doesn't matter which
one you use.
2. Sometimes it does matter: if the profile has the wrong tone
response curve. Or if the white points differ and you are doing, for
whatever odd reason, absolute colorimetric conversion to another
editing space. Or if the two profiles have different black points
and/or tone response curves and you don't use black point
compensation. Or if you run into one of the truly odd variants, such
as the non-Bradford-adapted mystery profile with the shadow-crushing
tone curve.
3. Regardless of how much or little it matters from a practical point
of view, one of the V2, matrix sRGB variants seemed better to me than
the rest. I gave my reasons why, with very repeatable examples.
If I am mistaken on any of the points I made in the article, I would
very much appreciate having my confusion sorted out.
I never, ever come anywhere near the topic of which version of V4 sRGB
you should embed before sending an image to a printer. I only talked
about opening an untagged image for editing.
> In this regard, I can understand Elle Stone¹s confusion in the use and
> application of the profiles. It is not immediately obvious that there is a
> huge difference between an input device profile and a color space profile.
> An input profile renders to the Profile Connection Space, a color space
> profile is a canonical description of the space although it can do
> rendering
> if the perceptual table is present.
Please go read my articles and tutorials on color management before
deciding that I am confused about the use and application of color
space profiles. Start with:
"Familiar Color Spaces Inside CieLab"
http://ninedegreesbelow.com/photography/pictures-of-color-spaces.html
"Color Space Profiles: All the Colors, Some of the Colors, the Colors
of Daylight"
http://ninedegreesbelow.com/photography/all-the-colors.html
"sRGB, the Universal Monitor Profile — Not So Good for LCD Monitors"
http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html
"digiKam/showFoto Settings for Color Management: Behavior Tab"
http://ninedegreesbelow.com/photography/digikam-settings-behavior-tab.html
"dcraw C Code, Outlined and Annotated (in particular the sections that
deal with the dcraw color management c code)"
http://ninedegreesbelow.com/photography/dcraw-c-code-annotated.html
I'm not claiming to be a color management guru. And I make mistakes,
just like everyone else. But I've been using, learning about, and
experimenting with color management and color managment issues ever
since I got my first digital camera, back in 2002. I use a fully
color-managed workflow and I profile my monitor and my camera (the
dRSL that shoots raw, not the point-and-shoot).
I do understand the difference between an input device profile
(camera, scanner) and a color space profile (ProPhoto, BetaRGB, sRGB
when it is used as a working space rather than a printer or monitor
profile), and an output profile (monitor, printer). I also understand
what a Profile Connection Space is. I know how to do the transforms
from one PCS to another. I know how to go from an RGB working space to
XYZ, etc. I've made spreadsheets and done the math and I've made gamut
maps. I understand the difference between a matrix profile and a
lookup table profile, and between perceptual intent and the
colorimetric intents.
If you could point to some specific confusion(s) in my article I would
be grateful. Learning from one's mistakes is always a bit painful, but
learning is always good.
>If you understand that difference,
> then
> you understand why there can be a large number of sRGB profiles.
>
> Within the ICC, there have been a number of studies to determine a profile
> that uses perceptual rendering to yield a better print. A rather large
> collaborative effort between Fuji Film and HP Labs, yielded some profiles
> which were better behaved for printing sRGB images that had the higher
> contrast rendering baked into the image. These profiles were aimed a
> better print reproduction and hundreds of prints were evaluated and scored.
> This is a never ending process because there are demographic preferences in
> preferred color reproductions.
>
I never said anything at all about using sRGB when sending an image to
a printer. I only talked about what to do when different softwares
offer to embed different (mostly V2) sRGB variants upon opening an
untagged image for editing.
> Some comments on Black Point Compensation. First and foremost, BPC has
> nothing to do with a profile, it is performed in the host CMM, if it is
> performed at all. At the last ICC meeting I forced the team working on the
> ISO spec to get it finished so that there could be a final ISO
> specification
> that details the BPC algorithm officially. It¹s important to note that the
> Black Point Tag has been deprecated because it was NEVER used by any of the
> founding members CMM¹s. Hopefully, all vendors will embrace the BPC spec
> when it comes out.
>
I do understand what black point compensation is. My article points
out problems that can occur when converting from one working space to
another, when using or not using black point compensation. I gave
illustrations. Everything I said is fully repeatable because I
described exactly what I did. I did indeed point out that one of the
differences between the various V2 profiles is that some do and some
don't have black points.
I commented that I like the idea of a profile black point, but that
opinions differ and that the ICC has said "not needed". I seem to have
stepped on some toes, but my intent was purely pedagogical. If people
learn that something as seemingly boring and technical as a "profile
black point" has been a topic of some disagreement, they might be
curious enough to go find out why. They might learn something. Many
people think color management is boring and too complicated to grasp.
I think it is fascinating and can be used creatively in the digital
darkroom. A major objective of my website is to share what I've
learned, to get people to not be afraid of color management.
In my article I was focussed on giving practical illustrations of
potential pitfalls with the various V2 sRGB profiles when assigned to
untagged images for purposes of editing. I failed to point out that
different applications do black point compensation differently. And I
failed to point out that different applications do absolute
conversions differently. It didn't really seem relevant and I try
(usually fail) to curb my tendency to go into too much detail.
Most likely, most of the time, most people don't make rendering intent
choices that will result in mangled images - they either use the
editing software default settings, or if they make do changes, they
probably know what they are doing. I was just pointing out that it is
possible, under certain circumstances, to create problems for yourself
when doing color space conversions. If you find yourself with a funny
looking image, the remedy is to not use those rendering intents.
> I pointed out in one of our earlier ICC meetings that the whole sRGB issue
> was not well presented on the web site. I was completely confused by the
> profile naming convention. If you go to the ICC website and click on the
> ³New v4 sRGB profile² link, you will see that we have expanded the
> documentation and scope of the sRGB profiles. If you are using sRGB as
> part
> of an ICC workflow, you need to READ THIS DOCUMENTATION carefully before
> whining about the reason for multiple profiles. Phil Green has done a
> great
I wasn't whining about the reasons for multiple V4 sRGB profiles on
the ICC website. I wasn't whining about anything. I have read big
chunks of the color.org website. Many of the pdfs, articles, and white
papers I've read more than once. And I'm sure I'll be reading more in
the future. But the documentation you are talking about doesn't have
anything at all to do with the topic of my article.
Nothing I said in my article has anything to do with using color.org's
V4 sRGB profiles in the context of sending an image to a printer
My article had nothing to do with using the color.org V4 sRGB profiles
in an sRGB workflow.
My article doesn't mention the color.org V4 sRGB profiles.
My article isn't about V4 profiles at all. There is a table summary of
my findings that notes which of the sRGB variants are V4 profiles (2)
and which are V2 profiles (all the rest). But neither of the two V4
sRGB variants is a color.org V4 sRGB profile, and the "V4-ness" of the
two V4 profiles is not the topic of the article.
My article points out the surprising fact (it surprised me, and
apparently it surprised some other people, too) that there are a lot
of different V2 sRGB profiles right on my own computer, being used by
the different editing softwares on my computer: different RBG XYZ
values, different white points, different black points, different tone
curves.
Practically speaking, I concluded that usually the differences are
benign. Sometimes they can cause, IN THE CONTEXT of assigning an sRGB
profile to an untagged image to use while EDITING an image, AND/OR in
the context of doing a color space conversion from sRGB (sRGB as a
working space, for image editing) to another working space. I'm sure
they could also cause problems in the context of sending an image out
for printing, but that was not the topic of the article.
> job there, although, in true ICC form, our naming conventions still suck.
> The sRGB v4 PREFERENCE profile is aimed at HARDCOPY printing using
> PERCEPTUAL rendering intent. The sRGB v4 Appearance profile is aimed at
> maintaining appearance across media. From the ICC web site: The Appearance
> profile is particularly recommended when the difference between source
> gamut
> and destination gamut is large and it is desired to 're-purpose' the image
> (i.e. make it optimal for the reproduction medium - see ICC White Papers 1
> and 2 for more on re-purposing and re-targeting of color).
>
Nothing I wrote had anything to do with printing or with color.org V4
sRGB profiles. Most of the software that I was talking about isn't
even V4-capable.
> In Conclusion, When dealing with an sRGB image from a camera consider the
> following:
>
> 1. The image has probably been rendered to appear similar to a transparency
> projected in a darkened environment
> 2. The overall contrast of the original reproduction is probably too high
> to
> print well, but it should display well in a darkened environment on a
> display.
> 3. If you want to print an sRGB image from a camera AND you are working in
> a version 4.0 environment, you should try the sRGB v4 Preference profile
> located on the ICC web site and try to follow the directions on that page.
>
At the risk of being incredibly repetitive, I never mentioned anything
at all about printing an sRGB image. I was talking about opening an
untagged sRGB for ***editing***, and the fact that different editing
softwares offer to embed different, mostly V2, all matrix, sRGB
variants. And I stressed that practically speaking, it doesn't make
much difference. UNLESS you run across one of the oddball variants or
do something unusual during a color space conversion to another
working space. Again, editing. Working space. *Not* sending an image
out for printing. No V4 profiles were harmed in the writing of my
article.
> If you are sourcing data from a large gamut workspace to sRGB the ICC
> recommends that you try the ICC sRGB appearance profile that is obtained by
> the contact listed on the web site.
I think the whole concept of using a virtual print to create an V4
sRGB variant with a perceptual intent lookup table is pretty neat. But
again, my article doesn't even once mention converting from a large
gamut working space to a small gamut working space. Not once. Never.
The article isn't about V4 profiles and doesn't mention color.org's V4
sRGB profiles.
> I hope this gives some insight into the reason for the large number of
> ³opinions² about sRGB content in an ICC workflow. If you don¹t really know
> what you are doing, DO NOTHING.
I have neither formed nor shared any opinion about using the ICC V4
sRGB profiles in an ICC workflow. I'm still cogitating on the matter.
As most of the software I use is not V4-capable, at present my
cogitations are purely theoretical. If and when I start using V4
profiles, I might eventually form an opinion that I think is worth
sharing.
But I do know what I'm doing regarding the multiple V2 sRGB profile
variants on my computer: I'm opening an untagged sRGB profile from my
point-and-shoot camera with an editing program. Then I'm choosing
which of the multiple mostly V2 (and all matrix rather than lookup
table) sRGB profiles I'm going to allow my mostly not-yet-V4-capable
editing softwares to assign before I begin editing my image in my
digital darkroom.
If you disagree with my conclusions regarding the best V2 sRGB profile
on my computer, for use when editing the untagged images from my point
and shoot camera, I would love to hear your reasons.
>The printer vendors have been optimizing
> the sRGB workflow for years and they do a great job, in general. The
> in-camera rendering has normally been designed to look good on a display
> that has sRGB characteristics. So in a pure sRGB workflow, doing nothing
> is
> going to work to display and to print.
>
Sending an image to a printer was not the topic of the article. If
anything I said has misled people into believing that they should run
out and do the wrong thing when sending an sRGB image to a printer, I
apologize. But I don't see how anyone who read the article could
possibly form such a conclusion. Here's the link in case anyone wants
to read it again:
"Will the Real sRGB Profile Please Stand Up?"
http://ninedegreesbelow/photography/srgb-profile-comparison.html
If anything I said has led people to think that I think that they
shouldn't use the color.org V4 sRGB profiles, they need to go back and
read the article. It isn't about color.org V4 sRGB profiles.
After reading everything you've said several times over, I think I
will change the name of the article to make it absolutely crystal
clear that I'm talking about the old V2 matrix profiles. Although I
don't think "Will the Real old V2 sRGB Profile Please Stand Up?"
sounds quite as catchy.
Having been a teacher, I know how easy it is to say "A" and have a
classroom full of students hear "B". From now on I'm going to sign all
my messages with "What you probably think you heard me say is probably
not what I thought I was intending to say."
Kindest regards,
Elle Stone (somewhat puzzled by all the fuss)
--
http://ninedegreesbelow.com
"What you probably think you heard me say is probably not what I
thought I was intending to say."
Other related posts:
