Dan Margulis Applied Color Theory
ProPhoto RGB or sRGB?
ProphotoRGB or sRGB
Posted by: "Wai-hong Chung"
Date: Fri Jun 30, 2006 8:58 am (PDT)
Hi All,
I normally shoot my photos in RAW and get them
printed in photo processing shop whose laser printer assumes sRGB
colorspace in the input files.
As you know, there are 4 choices of RGBs,
namely, Adobe RGB, ProPhoto RGB, Colomatch RGB and sRGB in the Camera Raw
space setting. I would like to use ProPhoto RGB and 16 bits because it has
the widest color gamut and are less prone to posterization after many curve
moves.
Please tell me whether it is advisable to
correct my photos in ProPhoto RGB and then change it to sRGB just before
taking it to photo processing shop for printing or should I use sRGB right
from the start from the Camera Raw space setting ?
Many thanks in advance !
Wai-hong Chung from Hong Kong
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Maris V. Lidaka Sr.
Date: Fri Jun 30, 2006 1:06 pm (PDT)
Yes, it is advisable IMHO - and I would first save it
in ProPhoto RGB for possible future use before converting to sRGB for the
processing shop.
Maris V. Lidaka Sr.
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Fri Jun 30, 2006 1:09 pm (PDT)
That will work just fine, however, you may wish to
select an encoding color space based on scene gamut. In ACR, the Histogram
provides this useful feedback as you toggle to differing spaces. IF you see
a colored spike on either end of the Histogram in say Adobe RGB (1998),
this indicates there are colors out of gamut that you captured that can1t
be contained in this working space based on the current rendering you have
set. Toggle now to a larger space (ProPhoto RGB) and I'll bet the spikes go
away. However, say you don1t see the spikes in Adobe RGB (1998) or even a
smaller color space. Then use that working space since placing the bits
into a wider gamut space doesn1t buy you anything. In other words, if time
permits, encode into the smallest color space that fully contains the scene
gamut based on the clipping you see in ACR.
When you1re ready to go off to this lab, then or course
convert the master image into sRGB.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Paul D. DeRocco"
Date: Mon Jul 3, 2006 4:55 am (PDT)
In my opinion, sRGB is a perfectly good color space,
unless your images have really saturated colors, especially yellows and
greens. Remember that your monitor probably doesn't cover very much of the
ProPhoto RGB color space (especially if it's an LCD), so editing in that
space means you're guessing about how saturated the greens really are. And
if you know that you're targeting an sRGB printer, I see no point in
editing in a wider space. As long as you keep the raw file, that is.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Duffy Pratt"
Date: Mon Jul 3, 2006 5:02 am (PDT)
If your final space is sRGB, then I don't see what the
advantage is of working in a wider space for editing.
Whenever you move from PhotoPro to sRGB, you will lose
information that lies outside of sRGB's gamut. A narrower color space
is less likely to posterize than a wider one, as a matter of theory.
If you are editing either in 8 bits, there is a smaller distance
between the 256 levels in each channel, and thus less chance for strange
jumps between levels. Move to 16 bits, and the numbers change, but
the idea stays the same. In practice, I don't think it makes any
difference whether you edit in 8 or 16 bits.
I guess the question is whether there is any difference
in doing 2 conversions (RAW to PhotoPro to sRGB) or only 1 (RAW to sRGB).
I don't know the answer to this for sure, but my guess is that there
is probably no visible difference. It should be easy enough to test.
Duffy Pratt
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Wai-hong Chung"
Date: Mon Jul 3, 2006 8:57 am (PDT)
Hello Duffy and Paul,
Thanks to your replies !
The argument is that doing
RAW>ProPhotoRGB>sRGB is that I can always have a wide gamut file for
future use and going from ProPhotoRGB to sRGB may conjure up better color
which I'm only guessing. The important point is, is there any harm from
doing ProPhotoRGB>sRGB ?
Wai-hong Chung from Hong Kong
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Mon Jul 3, 2006 9:09 am (PDT)
On 6/30/06 12:02 PM, "Duffy Pratt"
wrote:
If your final space is sRGB, then I don't see what the
advantage is of working
in a wider space for editing.
sRGB is never a final color space, always an
intermittent space (unless your only output is a display that behaves as
sRGB).
Whenever you move from PhotoPro to sRGB, you will lose
information that lies
outside of sRGB's gamut. A narrower color space
is less likely to posterize
than a wider one, as a matter of theory.
Not in 16-bit... If you have output devices that exceed
sRGB, you1ll lose a lot more data not working in a wider space.
IF your only output EVER is a display (and we would
have to excuse the new wide gamut displays that far exceed sRGB), then yes,
you never need anything other than sRGB.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "George Machen"
Date: Mon Jul 3, 2006 2:26 pm (PDT)
I'm not in front of Photoshop this weekend, but I
wonder if this use of the regular Photoshop histogram can be made when one
already is in an RGB or CMYK space, by converting to HSL (Hue Saturation
Lightness) and looking for spikes at the edges of the Saturation histogram
to indicate gamut clipping?
(I will second-guess Dan M. to say that one doesn't
need no stinkin' histogram when all that is necessary is to look at the
image for loss of detail in the saturated colors, but I'm just wondering if
what I'm saying in principle is correct.)
George Machen
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Mon Jul 3, 2006 8:53 pm (PDT)
On 7/3/06 10:28 AM, "George Machen"
wrote:
I'm not in front of Photoshop this weekend, but I
wonder if this
use of the regular Photoshop histogram can be made when
one
already is in an RGB or CMYK space, by converting to
HSL
(Hue Saturation Lightness) and looking for spikes at
the edges
of the Saturation histogram to indicate gamut clipping?
Photoshop1s histogram already provide a saturation
clipping in the histogram options set correctly. But, it1s too late
(you1ve encoded the data). ACR shows you this prior to rendering and
encoding.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Rick Gordon"
Date: Mon Jul 3, 2006 9:00 pm (PDT)
I'm not personally convinced the the HSL filter is
capable of clarifying those judgements. The conversions look pretty rough
to me. I'm not sure I'd trust it in practice, even if the idea makes sense
in theory. However, I'd be interested in other's opinions regarding this.
Rick Gordon
___________________________________________________
RICK GORDON
EMERALD VALLEY GRAPHICS AND CONSULTING
___________________________________________________
WWW: http://www.shelterpub.com
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Paul D. DeRocco"
Date: Mon Jul 3, 2006 9:00 pm (PDT)
I don't think you get any better color going
raw->ProPhotoRGB->sRGB, as opposed to raw->sRGB. You'll probably
get slightly different results, because profile conversions sometimes
involve some tweaking of the color. I don't think there's any harm in it,
though.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Marco Ugolini
Date: Mon Jul 3, 2006 9:31 pm (PDT)
Hi Paul.
In a message dated 6/30/06 8:05 PM, Paul D. DeRocco
wrote:
In my opinion, sRGB is a perfectly good color space,
unless your images have
really saturated colors, especially yellows and greens.
Plus reds, purples and cyans, which in sRGB all fall
short even of AdobeRGB.
Remember that your monitor probably doesn't cover very
much of the
ProPhoto RGB color space (especially if it's an LCD),
so editing in
that space means you're guessing about how saturated
the greens really are.
Although I have not explored this feature quite yet,
some monitor profiling packages apparently offer ways to compress
out-of-gamut colors, so that the user is able to perceive tonal
differentiations in area that are outside the gamut of one's display. I
have not tried these solutions yet, as I said, so I cannot say whether they
work well, but I intend to give them a try.
Also, the gamut of most "normal" displays
(ones that are not meant to cover AdobeRGB, for example) falls short even
of sRGB (mostly in the blue-purples, and occasionally in the cyan-greens),
so that even the use of sRGB is not fully free of problems and of
guesswork.
And if you know that you're targeting an sRGB printer,
I see no point
in editing in a wider space.
Two problems with that:
1) "sRGB printer" is an imprecise definition.
For example, the gamut shape of my Epson 2200 (using Premium Luster at
1440dpi) is short of sRGB almost all the way around, *except* in a very
meaningful range between green yellows and orange, where it pokes a
remarkable hole outside sRGB.
2) So the question there is: how do you preserve those
colors, specially if you start out by chopping them at the outset by
choosing sRGB? Even AdobeRGB does not fully contain that peak in my
printer's gamut, whereas ProPhoto RGB does. Of course, one has to decide
for himself how important it is to preserve those colors for one's own
specific type of work. If it isn't, then in that case sRGB may be alright.
As long as you keep the raw file, that is.
Isn't it impractical to go back to the RAW converter
every time one needs to repurpose an image?
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Olivier"
Date: Tue Jul 4, 2006 3:43 am (PDT)
I'd agree with all, the issue would then be as far as I
am concerned not so much the working space choice (since either option
offers pros and cons) but rather the way to proceed depending on this
choice.
There's clearly clipping in any sRBG and
"small" gamut spaces, but somehow peripherals will often
encompass those spaces and larger, at the detriment of a full information
range.
Oppositely, in a prophoto space, at some stage the
display is to be needed to correct the image (it's hard to work only by the
numbers). The use of an output soft-proofing with out-of-gamut warning
helps a bit, but the file somehow becomes output dependent. Besides, even
though the display could be profiled with a perceptual rendering (which I
have experienced either), it's my belief the conversion will
"corrupt" the viewing in the sense the display and the video card
have their physical limitations.
I'm much tempted to benefit from the full power of ACR
and Prophoto, but I'm sure I miss a point to properly use it. Can expert
users share their knowledge here.
Olivier Desmaison
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Paul D. DeRocco"
Date: Tue Jul 4, 2006 3:51 am (PDT)
From: Marco Ugolini
Plus reds, purples and cyans, which in sRGB all fall
short even
of AdobeRGB.
Cyans, yes, but I've never seen saturated cyans in real
life. As to reds and purples, sRGB and ARGB have the same red and blue
primaries, in the xy space. Only the green is much more saturated.
Although I have not explored this feature quite yet,
some monitor profiling
packages apparently offer ways to compress out-of-gamut
colors, so that the
user is able to perceive tonal differentiations in area
that are outside the
gamut of one's display. I have not tried these
solutions yet, as I said, so
I cannot say whether they work well, but I intend to
give them a try.
Standard gamma-based profiles assume relative
colorimetric rendering intent, so they just chop the out-of-gamut colors. A
full lookup table based profile (like a printer profile) lets you support
perceptual rendering intent. I don't know what software lets you do that
for monitors, though. Maybe ProfileMaker?
Also, the gamut of most "normal" displays
(ones that are not meant to cover
AdobeRGB, for example) falls short even of sRGB (mostly
in the blue-purples,
and occasionally in the cyan-greens), so that even the
use of sRGB is not
fully free of problems and of guesswork.
Yup.
1) "sRGB printer" is an imprecise definition.
For example, the gamut shape
of my Epson 2200 (using Premium Luster at 1440dpi) is
short of sRGB almost
all the way around, *except* in a very meaningful range
between green
yellows and orange, where it pokes a remarkable hole
outside sRGB.
Agreed. I have the 2200 too.
The original poster, if I remember correctly, was
talking about shipping his images out to some print shop that specified
that they wanted sRGB images. There are some printers out there that are
calibrated to behave like sRGB printers, although I expect that they, too,
don't really meet sRGB at all densities.
Isn't it impractical to go back to the RAW converter
every time
one needs to repurpose an image?
Depends. If you convert with CaptureOne, then it may
seem a chore to reconvert every time. If you use Adobe Camera Raw, then
you're just opening an image into Photoshop--no big deal.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Tue Jul 4, 2006 5:48 pm (PDT)
On 7/3/06 11:42 PM, "Paul D. DeRocco"
wrote:
The original poster, if I remember correctly, was
talking about shipping his
images out to some print shop that specified that they
wanted sRGB images.
There are some printers out there that are calibrated
to behave like sRGB
printers, although I expect that they, too, don't
really meet sRGB at all
densities.
Not really (they can1t). They assume sRGB for a source
color space for conversions to an output color space. A Fuji Frontier is an
example. I1ve profiled them and they don1t have a gamut that1s
significantly larger in many areas than sRGB but in no way behave or appear
like sRGB. The reference media is totally different too. The synthetic sRGB
color space was mathematically constructed to define a CRT display in a
very precise way (down to the ambient light this theoretical display
resides). I1ve never seen an emissive device that behaved like a reflective
print.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Jim Goshorn"
Date: Tue Jul 4, 2006 5:48 pm (PDT)
On Jul 3, 2006, at 5:33 PM, Andrew Rodney wrote:
Photoshop’s histogram already provide a
saturation clipping in the histogram
options set correctly. But, it’s too late
(you’ve encoded the data). ACR
shows you this prior to rendering and encoding.
How do the options have to be set to show this?
Jim
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Ric Cohn"
Date: Tue Jul 4, 2006 5:49 pm (PDT)
On Jul 4, 2006, at 1:42 AM, Paul D. DeRocco wrote:
Depends. If you convert with CaptureOne, then it may
seem a chore to
reconvert every time. If you use Adobe Camera Raw, then
you're just opening
an image into Photoshop--no big deal.
If your usual practice is to get the image exactly like
you want it in Camera Raw and then output, yes. However, most of this list
is about getting more out of an image. Unless there's a really really good
reason, I only want to do Channel blends, spotting, color adjustment, set
basic end points, go to Lab or CMYK, etc., etc. once. I'll then use this
file to repurpose.
Whether it's worth taking an image this far in
ProPhotoRGB (in which case you better stick with 16 bit as well) is a
matter of opinion, expectations, workflow, etc. Personally, I believe for
excellent image quality the kinds of adjustments listed above are far more
important than what color space one starts in. NOT that it doesn't ever
matter- just that it's worried about way too soon in the learning process
and given much more importance than I believe is warranted. It reminds me
of a beginning violin student who thinks if he could only use a
Stradivarius he would be able to play well.
My 2¢.
Ric Cohn
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "Walter Young"
Date: Tue Jul 4, 2006 5:53 pm (PDT)
Using the Place command to place the Raw file as a
layer allows you to double-click the layer to continually edit within ACR,
and even allows working in other color spaces by converting on the fly
after making the Raw edits.
The file must however be saved as a PSD to preserve the
Raw placed layer.
—Walter Young
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Tue Jul 4, 2006 6:09 pm (PDT)
On 7/4/06 1:57 AM, "Olivier" wrote:
Oppositely, in a prophoto space, at some stage the
display is to be
needed to correct the image (it's hard to work only by
the numbers).
Let1s see, the maximum red in both sRGB and ProPhoto
RGB are R255/G0/B0. So much for numbers.
Yes, the gamut limitation of displays is real. Even
with more wide gamut systems coming on line, those that now exceed Adobe
RGB (1998), you1re still in a situation where many colors cannot be viewed.
But cant these colors be output? Yes. The Epson K3 inks exceed in many
colors, Adobe RGB (1998). I just profiled the new Canon i5000 and it does
the same (although in different areas). Nice to have a 12 ink printer!
So you may be unable to see the colors on one device,
but you can reproduce them on another leading to the question, do you
squash down the file so you can see it all but lose a great deal of
potential colors you can output? Each user has to decide that for
themselves. Personally I1d like to stick with one rendered file from my
RAWs and be done with the RAW conversions. Since I have some images that
fall outside Adobe RGB (1998) and I can tell which based on the ACR
Histogram AND I want to be able to reproduce those colors on current
technology, the answer is ProPhoto RGB in 16-bit. Note that I often encoded
in smaller color spaces but only after viewing the capture/scene gamut
using the Histogram. I can assure you that a file captured on a Canon 5D
shooting of a gray card will fit in sRGB.
I'm much tempted to benefit from the full power of ACR
and Prophoto,
but I'm sure I miss a point to properly use it. Can
expert users
share their knowledge here.
There are no perfect RGB working space or we1d all use
just one. Scene gamut and the gamut of the captured image need to be
considered if you wish to contain and ultimately use those colors on
output. In the last few months, a 12 ink, very wide gamut and affordable
ink jet printer was released. I have no idea what kind of output technology
we1ll see in a year, let alone 5 years and yes, I occasionally capture
images I1d love to print in the future. So for me, it1s pretty simple;
capture and hold all the colors possible. I know I can1t see them on one
device (the display) or reproduce them on others (press) but I1d rather
have them for output to devices where the colors can be used.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: "George Machen"
Date: Wed Jul 5, 2006 12:01 pm (PDT)
Andrew Rodney wrote:
Photoshop1s histogram already provide a saturation
clipping in the histogram
options set correctly.
I don't see a Saturation choice among the Histogram
palette's Colors popup menu. There is a Luminosity and a Colors, the latter
of which is the only one I can find that you might be meaning. Unless I'm
missing something. But isn't the Colors an amalgam of Hue & Saturation?
It purely wouldn't show gamut clipping, would it? That's why I was thinking
of making these inspections in HSL.
But, it1s too late (you1ve encoded the data). ACR
shows you this prior to rendering and encoding.
Oh yeah, I know. But I'm not coming out of ACR; I'm
talking about looking at what happens going into a lower-gamut space from a
wider-gamut one in an existing image, and how steps I have taken to
mitigate gamut clipping (e.g., channel blending) have worked out. And I do
have an undo.
George Machen
___________________________________________________________________________
Re: ProphotoRGB or sRGB
Posted by: Andrew Rodney
Date: Wed Jul 5, 2006 3:37 pm (PDT)
Setup the info palette to show all colors so you get
individual red, green and blue histograms. Within each, if you see a spike
on either end that represents zero or 255, the indicates saturation
clipping. Only when all three produce zero or 255 are you showing the
clipping of tone (shadow or highlight). So, if Red and Green are 255 but
blue is say 253, you1re seeing that red and green are clipped.
Another way to see this is to use the clipping overlay
in Levels. Hold down the Alt/Option key and slide the black or white input
sliders. So if you do this on the white input slider, when you see a white
pixel, that indicates all three channels are clipping. However, a single
color shows you which color is clipping (red green or blue indicates a clip
of that color. Cyan would indicate green and blue channel clipping, Yellow
Red+Green, Magenta, Red+Blue).
However, its vastly more useful to do this in the RAW
converter and see the effect of larger and smaller gamut encoding spaces
based on the current rendering. Once the file is rendered, you really have
no idea what was past the individual color channels with respect to
saturation clipping. True for tone as well although the only way to recover
clipping of all three channels is to start plying with the actual rendering
controls.
Andrew Rodney
___________________________________________________________________________
Re: ProphotoRGB or sRGB: Is plotting helpful?
Posted by: "Sonny"
Date: Wed Jul 5, 2006 3:46 pm (PDT)
I am somewhat of a novice, and wonder if this procedure
is helpful. I don't process many images, and time is not an issue. And, I
hope to learn some fundamentals.
In ACR I check the Histogram to see if ProPhotoRGB
decreases clipping, and if so, use that rather than aRGB.
Since my monitor (Eizo CE240W) does not show more than
sRGB, I can't even vizualize the additional gamut that ProphotoRGB would
offer.
So, I am playing with ColorThink. I plot 1) the image
colors (drag the image onto the plot), 2) the working space(s), and 3) the
printer (R2400) profile. Then I look at the plot to see if my printer can
print those additional colors offered by ProphotoRGB.
It takes only a few minutes, but I am wondering if this
really gives accurate info, or, is it just theoretical?
Thanks very much,
Sonny Taylor
___________________________________________________________________________
ProphotoRGB or sRGB: Is plotting helpful?
Posted by: Andrew Rodney
Date: Wed Jul 5, 2006 11:07 pm (PDT)
On 7/5/06 1:02 PM, "Sonny" wrote:
So, I am playing with ColorThink. I plot 1) the image
colors (drag the
image onto the plot), 2) the working space(s), and 3)
the printer (R2400)
profile. Then I look at the plot to see if my printer
can print those
additional colors offered by ProphotoRGB.
It takes only a few minutes, but I am wondering if this
really gives
accurate info, or, is it just theoretical?
This is an excellent tool to view all this. What1s
great is you could render the same RAW file in one or more working spaces
and load that image in ColorThink along with your printer profile. The
image appears as 3dots2 of actual color and you can spin that in 3D to see
how it maps in relationship to the output device gamut. Having the ability
to spin this in 3D really aids in seeing what will or will not clip from
the image.
I1d be less worried about messing with the display
profile. As I said, with today1s display technology, the gamut is a
limitation however, the gamut of the scene and capture device (which really
has no gamut) and the output device at least allows you to get an idea of
what you can capture and actually output to the printer. Both devices far,
far exceed the gamut of the display.
Try shooting some very saturated scenes in RAW using
the above tools in ColorThink, then try a very muted scene as well. A very
educational tool and process!
Andrew Rodney
___________________________________________________________________________
ProPhoto (Wide gamut) spaces for RAW processing
Posted by: Andrew Rodney
Date: Fri Jul 7, 2006 3:30 pm (PDT)
VERY interesting Podcast discussing how Adobe Lightroom
(and Adobe Camera RAW) are designed via a wide gamut, linear encoded
ProPhoto RGB space with Bruce Fraser, Thomas Knoll (the father of Photoshop
and ACR) and Mark Hamburg can be found here:
http:
//photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted/
Very worthwhile color theory discussions.
Andrew Rodney
___________________________________________________________________________
Re: ProPhoto (Wide gamut) spaces for RAW processing
Posted by: "Ric Cohn"
Date: Sat Jul 8, 2006 4:45 pm (PDT)
On Jul 7, 2006, at 3:29 PM, Andrew Rodney wrote:
VERY interesting Podcast discussing how Adobe Lightroom
(and Adobe Camera
RAW) are designed via a wide gamut, linear encoded
ProPhoto RGB space with
Bruce Fraser, Thomas Knoll (the father of Photoshop and
ACR) and Mark
Hamburg can be found here:
Yes, very interesting. The blending of ProPhoto gamut
with sRGB encoding was way over my head. Sounds interesting, although I
couldn't grasp if this creates a better behaved wide gamut space or what
other advantages there might be. Andrew, care to share any more info on
this?
It does seem that virtually all the heavy hitters on
the Photoshop team are advocating ProPhotoRGB as a standard working space.
If nothing else it seems to guarantee, for better or worse, that many more
people will be using ProPhotoRGB in the future. I guess that we will see if
there are any problems that arise more, or less, frequently because of
this. If nothing else it would finally "prove" the advantages of
16 bit editing, as I believe editing ProPhoto in 8 bits is virtually a
guarantee of inferior results.
Ric Cohn
___________________________________________________________________________
Re: ProPhoto (Wide gamut) spaces for RAW processing
Posted by: Andrew Rodney thedigitaldog
Date: Sat Jul 8, 2006 8:12 pm (PDT)
On 7/8/06 4:46 PM, "Ric Cohn" wrote:
Yes, very interesting. The blending of ProPhoto gamut
with sRGB
encoding was way over my head.
In a nutshell, the native space is ProPhoto RGB (at
least it's primaries) but instead of the usual gamut tone curve (better to
say tone response curve) its linear. RAW data is linear, makes sense.
However, if you viewed such a Histogram, it look pretty odd, all pushed to
one side. So the Histogram is represented as a gamma corrected color space.
The display preview is funneled into sRGB.
Sounds interesting, although I
couldn't grasp if this creates a better behaved wide
gamut space or
what other advantages there might be.
It is what it is, linear but represented with a gamma
correction (otherwise, folks would look at the Histogram and say 3oh my
god2).
It does seem that virtually all the heavy hitters on
the Photoshop
team are advocating ProPhotoRGB as a standard working
space.
For RAW processing yes. But you can encode that into
four color spaces, all gamma corrected: sRGB, ColorMatch RGB, Adobe RGB
(1998) or ProPhoto RGB.
If nothing else it seems to guarantee, for better or
worse, that many
more people will be using ProPhotoRGB in the future.
As the internal RAW to RGB color space yes but that1s
not presented to the user. They can ask for a gamma corrected ProPhoto
space or any of the other three spaces (based if done correctly on the
Histogram that shows clipping, should scene gamut exceed those three
encoding color spaces).
RAW is Grayscale data. It1s linear encoded. These
sensors on these digital cameras are simply photon counters and record the
light striking them in a linear fashion. Each level recorded produces the
same, corresponding level of data in the RAW file. If one photon strikes
the sensor representing the first dark tone that can be recorded, the
result is level 1 in a digital file. If 4096 photons strike the sensor,
representing the brightest value it can record, then the result is level
4096 in a digital file. When you encode into a gamma correct working space
(usually 2.2 or 1.8), the tones and histogram are remapped and look as most
users expect. That's the point Thomas (or Mark) made about having to use a
gamma correct histogram even though the processing is all linear.
Andrew Rodney
Encode appropriately and convert as needed just before
print time. You have the most flexibility with the data.
As far as I know, this is not a concern of the original
poster, the
lab with sRGB input to their printer is the only
concern.
If it's not a concern now, it might be in the future.
If he starts with the most data and funnels it down for the lab, the lab
will do fine and he'll have data he might be able to use later. The
alternative offers none of this flexibility or safety.
Andrew Rodney
___________________________________________________________________________
...and around a month later:
Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Tue Aug 1, 2006 12:41 pm (PDT)
Hi All,
Recalling my earlier enquiry on whether using
ProPhoto RGB or sRGB as working space, after consolidating the replies, I
come up with the following color management workflow. I would like you to
provide your comments.
First of all, I'm a amateur. I use a Minolta A200 to
shoot RAW files. I use a CRT monitor which has a color gamut similar to
sRGB and I take the files to a commercial lab to print the photos who use a
Fujifilm Frontier minilab which assume its input files as sRGB.
As advised by Andrew Rodney, I used ACR histogram to
check whether there is any color spike to see whether there is any out of
gamut color. If there isn't any, then I used sRGB all the way to print.
However, if there are color spikes, I use ProPhoto RGB to remove them.
Then, I use ProPhoto RGB as working space for editing. I know I'm guessing
the out of gamut color on my CRT display, but I want to keep a wide gamut
file to cater for future advance in technology. In the midlle of the
editing, I might also convert the file to LAB for color correction but that
dosn't matter. After editing, I save a copy of the ProPhoto RGB file and
then convert the file to sRGB choosing perceptual rendering intent for
heavily saturated color photos. However, I would always toggle between
perceptual intent and relative colorimetric intent to suit my taste in the
convert to profile dialog box. After converting to sRGB, I make minor color
adjustments. I also used 16 bits for both the ProPhoto RGB
& sRGB to cater for the many curve editing to
avoid posterization. Then I take the sRGB files to the lab for
printing.
I would be most grateful if you would tell me your
color management workflow for RAW files editing as well.
TIA!
Wai Hong Chung from Hong Kong
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Ric Cohn"
Date: Tue Aug 1, 2006 4:07 pm (PDT)
As long as you're using more than one color space I'd
suggest using AdobeRGB when the colors fit there but not sRGB. Also, you
don't say if you're working in 8 bit or 16 bit. IMHO when using ProPhotoRGB
you should use 16 bit-- the info is spread so thin that unlike the more
traditional spaces, I believe, large corrections in ProRGB have been
shown to cause "see-able" damage when performed on 8 bit data.
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Stephen Marsh
Date: Tue Aug 1, 2006 5:41 pm (PDT)
Wai-hong Chung wrote:
As advised by Andrew Rodney, I used ACR histogram to
check whether
there is any color spike to see whether there is any
out of gamut
color. If there isn't any, then I used sRGB all the way
to print.
However, if there are color spikes, I use ProPhoto RGB
to remove them.
Dear Wai-hong, please refer to my post here in regards
to converting between a larger matrix based working space and a smaller one:
http://groups.yahoo.com/group/colortheory/message/14486
"Many get so caught up on the first point, that
they toss it all out when performing the second. Perhaps this is becuase
all one hears about is the theory, rather than putting it to good
use."
After editing, I save a copy of the ProPhoto RGB file
and then
convert the file to sRGB choosing perceptual rendering
intent for
heavily saturated color photos. However, I would always
toggle between
perceptual intent and relative colorimetric intent to
suit my taste in
the convert to profile dialog box.
This does not work going to sRGB, no perceptual, you
only have RelCol and clipping, thus you are loosing all the extra work you
have done in ProPhoto.
Regards,
Stephen Marsh.
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini
Date: Wed Aug 2, 2006 3:53 am (PDT)
Unfortunately, when you have matrix-based profiles as
both your source and target, as is the case here, changing the rendering
intent does not change the results. That's just the way it works.
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Dan Margulis"j
Date: Wed Aug 2, 2006 8:25 am (PDT)
Ric writes,
Also, you don't say
if you're working in 8 bit or 16 bit. IMHO when using
ProPhotoRGB you
should use 16 bit-- the info is spread so thin that
unlike the more
traditional spaces, I believe, large corrections in
ProRGB have been
shown to cause "see-able" damage when
performed on 8 bit data.
This is not correct. It has been shown that making
major corrections in an ultra-wide gamut RGB can produce results that are
visibly *different* when 16-bit is used rather than 8-bit. This is as
opposed to more rational RGBs, where any series of real-world moves produce
results that are indistinguishable for quality.
Making big moves in an ultra-wide RGB would yield
similar results to doing it in a grayscale file. Most of the time there's
no visible difference; occasionally an area (or a whole image) will look
better if done in 16-bit--and around three times as often, it will look
better if done in 8-bit.
The differences show up in areas where the 8-bit file
is already suspect and the extra eight bits contain nothing but random
numbers. Skies, strongly colored areas, and deep colors are examples. In
these cases, using 16-bit amounts to applying a sophisticated form of
blurring. In skies and shadows that may help, everywhere else, it hurts.
The bottom line is, that if anyone choosing to make
major edits in an ultra-wide RGB--a practice that has no advantages at all,
AFAIK, and a lot of disadvantages--needs to be aware not just of the times
that 16-bit is better, but of those when 8-bit is better, as opposed to the
rest of us, who can use either one whenever we like.
Watching this thread develop while on vacation a few
weeks back was a depressing experience. Once again, we saw people who don't
understand what histograms show advising others to take action based on
what histograms do not show.
Paul DeRocco made one of the only sensible posts,
pointing out that even sRGB is suitable for most applications, because the
colors in which it is theoretically weak don't exist in nature. I can't
locate a single real image in which sRGB is inadequate for CMYK output. I
*surmise* the existence of real images for which sRGB is inadequate for
better conditions. I *don't* surmise that any real color photographs or any
output conditions would be unsuitable for something moderate-gamut like
ColorMatch RGB, let alone something as huge as Adobe RGB.
Before we talk about anything bigger than Adobe RGB,
let's first see an example of a real-world photograph that somebody thinks
is printable under any current output conditions, yet unsuitable for
ColorMatch RGB--or even sRGB.
Dan Margulis
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: "Terry Wyse"
Date: Wed Aug 2, 2006 10:56 am (PDT)
Forgetting about wide vs. "rational" RGB
working spaces for the moment, are you saying that working in 16-bit can
actually HARM images? Do you have any examples where this has occurred? I
can accept the argument that 16-bit may be of questionable value for a
majority of images but to imply that 16-bit is harmful - well, I just can't
buy that assuming there are no bugs in the way Photoshop handles
16-bit/channel editing.
In regards to "real world" images, are you
discounting the fact that someone may PREFER a more highly-saturated
rendering of a "real-world" photographic scene as opposed to one
that is "accurate" or faithful to the original scene? I would
contend that virtually no one would prefer an "accurate"
rendering of a scene and would prefer instead a bit of added
"punch" as being more pleasing. Acknowledging that this may be
the case for a majority of photographs, it then only becomes a matter of
degree to which this preference may be contained in a smaller space such as
sRGB or that it may "punch-out" or sRGB and require a larger
container/color space.
To further bludgeon this near-dead horse, one can also
demonstrate that, in fact, current inkjet technology (and I assume
photographic imaging technology) can not only exceed sRGB but can indeed
exceed parts of the "huge" AdobeRGB space. In my mind, if a
current printing technology can be demonstrated to exceed several of these
so-called rational color spaces, these now become REAL colors that I can
print requiring a color space that will contain them and are not simply
some theoretical colors that I MAY be able to print and should allow for in
the hopes some future imaging technology comes along that will permit this.
No, these are colors that I CAN print today and might well WANT to print
depending on how I chose to render a real-world image.
Regards,
Terry Wyse
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Wed Aug 2, 2006 10:57 am (PDT)
Dear Marco Ugolini and Stephen Marsh,
Thanks to your reply. Do you mean that changing from
ProPhoto RGB to sRGB using perceptual rendering intent is just like
relative colorimetric intent which is the out-of-gamut colors will got
clipped! In fact, I've tested by toggling the 2 rendering intent and I
found there is no difference between them for out-of-gamut color. Under
what situation will there be a visible difference when toggling between the
perceptual and relative colorimetric intent ? TIA.
Wai Hong Chung from Hong Kong
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Matthew Rigdon"
Date: Wed Aug 2, 2006 1:22 pm (PDT)
There's been some other discussions about bit-depths
and what-not and I believe it was mentioned that internally most of the
D-SLRs of 35mm and APS-C sensor size are 12-bit processors. Throw the
number conversion of a color-profile into the mix, and you're going to come
up with some variation in color numbers depending on what algorithm you
use, how you handle rounding errors, etc. Depending on the image, the
program doing the work, the gamma curve of the profile, etc, you're bound
to find some cases where a 16-bit conversion could damage an image. I guess
it comes down to a question (and an image processing programmer would
better answer this) of whether you run into more problems padding values in
an image or dropping values in an image.
And never underestimate the abilities for bugs to crop
in a software tool, especially one as complicated as Photoshop. I've heard
a number of complaints in online forums about the way in which Camera Raw
handles conversions compared to other RAW conversion tools. This is
obviously going to compounded by the fact that most of the Camera
manufacturers keep their RAW formats undocumented to outsiders, so a lot of
the work the Photoshop team does is trial-and-error, especially when a
camera first comes out.
I only talk about cameras as this is probably the most
popular way of grabbing digital images right now and what I have experience
with. If you're working with a scanner pulling images off film, you may
never see a problem.
Just my two cents,
Matthew Rigdon
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: "Ric Cohn"
Date: Wed Aug 2, 2006 4:36 pm (PDT)
On Aug 2, 2006, at 10:08 AM, Dan Margulis wrote:
This is not correct. It has been shown that making
major corrections in an
ultra-wide gamut RGB can produce results that are
visibly *different* when
16-bit is used rather than 8-bit. This is as opposed to
more rational RGBs, where any series of real-world moves produce results
that are indistinguishable for quality.
I did mark this as my opinion, and I'm not ready to
change it. However, I do want to make clear that I was not advocating using
ProPhotoRGB, just pointing out what I think needs to be done to protect
your images if you believe ProPhotoRGB makes a difference. I don't use it
because I don't see any benefits for my images and I would rather take
pictures than do endless tests looking for the one image that might
theoretically be improved slightly if I took on a more difficult and error
prone workflow. However, I'm not knowledgeable enough to tell experts (who
may be wrong about this area, but still know more than I do in their areas
of expertise) that they are wrong. I'll leave that to other experts
<g>.
I will also wait for the advocates to show me the
images that prove their points. Maybe if they show me images where it makes
a difference I will be able to see their point (and even learn something
which is more than I can say now).
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Stephen Marsh
Date: Wed Aug 2, 2006 4:37 pm (PDT)
Thanks to your reply. Do you mean that changing from
ProPhoto RGB to
sRGB using perceptual rendering intent is just like
relative colorimetric intent
which is the out-of-gamut colors will got clipped!
Yes.
In fact, I've tested by toggling the 2
rendering intent and I found there is no difference
between them for
out-of-gamut color.
Then why does the software interface allow one to
select an option that has no effect, with no warning that the user selected
option that is invalid or going to be ignored and another option used
instead? Why is the option not greyed out? Why do users need to learn so
much "useless" information about profiles just to drive a
colour conversion correctly?
Don't bother answering, these are rhetorical questions.
Perhaps we will have a future version of Photoshop that
is smarter in how it presents the 'loose' nature of ICC profiles, or
perhaps smarter ICC profiles if this is beyond the ability of Photoshop.
Under what situation will there be a visible
difference when
toggling between the perceptual and relative
colorimetric intent ? <<
When converting to a table based profile, instead of a
matrix based one. An easy way to look at the file size of the profile.
As a general rule*, table based profiles are
usually/commonly found in output profiles, such as RGB or CMYK printer
profiles. In the Adobe v2 CMYK profiles, which are built with special Adobe
ICC generation software - the perceptual transform is rather tame, more
like RelCol in that the transform is closer to the original on the monitor
after conversion. Profiles built by publicly available third party software
have more variation in their perceptual transform (what some call special
sauce or secret sauce, the proprietary method used for compression specific
to the software), after conversion the image is often very different to the
RGB or a RelCol transform - but on press or inkjet this may be more
appealing, depending on personal taste and other factors. It appears that
the ICC does not specify how gamut compression is achieved, only that it
can be offered as one of the four intents when converting (a profile may
not have all four intents, even though CMM software allows one to select
them).
It does seem a major flaw that working space profiles
do not offer this proprietary method.
*An exception to the general rule:
http://www.josephholmes.com/profiles.html
Joseph Holmes has a family of table based profiles for
sale (there is a matrix based free profile for download and a PDF with more
info on the table based family profiles that are same/similar in gamut to
the free matrix profile), I have not used them and can't vouch for their
usefulness - but at least there is one person offering RGB film type gamut
working space profiles that offer gamut compression.
But I would ask again - does the image contain these
wide gamut colours in useful areas and is the output actually better off
even if it can make use of the wider gamut.
Regards,
Stephen Marsh.
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Fri Aug 4, 2006 3:10 am (PDT)
Hi All,
Thank you all for giving me so many valuable
advices regarding the captioned subject, in particular to Mr. Andrew Rodney
who advised me of the PhotoGamut RGB. I have test this profile and at last
I've found a RGB space which has response to perceptual rendering intent
(i.e. when I toggle between RelCol and perceptual, there is a visible
difference). When I print a real world photo using the PhotoGamut RGB
space, I found it give brighter color than sRGB.
May I take this opportunity to request those of
you who know the Adobe Photoshop programmers to tell them to include
perceptual rendering intent when converting to sRGB in the next update of
Photoshop.
The more I learn, the more I found I don't know
!
Wai Hong Chung from Hong Kong
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Fri Aug 4, 2006 7:33 am (PDT)
convert the file to sRGB ... (cut)
Dear Wai Hong Chung,
Editing in ACR using ProPhoto as your color space when
your final output is sRGB can result in inferior images as I have found
many times. For instance, if you edit bright saturated reds in "ACR-
ProPhoto" you will most probably end up with reds
that are way outside the sRGB gamut so when you eventually convert to sRGB
those reds will be clipped. Since color = detail then clipped colors =
clipped details.
My experience with real-life photos have shown that if
the final output is sRGB then you should definitely do your ACR corrections
using the sRGB color space.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: Dan Margulis
Date: Fri Aug 4, 2006 7:33 am (PDT)
Terry writes,
Forgetting about wide vs. "rational" RGB
working spaces for the
moment, are you saying that working in 16-bit can
actually HARM
images?
I don't understand this word "harm". I am
interested only in which method produces a better image. They are two
different calculations. With a rational RGB it won't matter which one you
use. Under conditions of severe stress, such as making major corrections in
an ultra-wide RGB, it *can* make a difference. When it does, the viewer may
prefer one way or the other. It is more common to prefer the 8-bit under
these circumstances.
Do you have any examples where this has occurred?
If you are asking whether there are any real-world,
rational RGB images where correcting in 8-bit got a better result than
doing the same thing in 16-bit, no, no more than a 16-bit correction ever
does better than 8-bit in the real world. When you get into the exotic RGB
and other non-real world image category, yes, you've seen them.
Notably, in one of the examples shown on another list and discussed
here, the 16-bit advocate's idea of a real-world image was to acquire a
normally lit capture in Camera Raw with the Exposure setting as far to the
left as possible, making it grossly dark. This procedure was correctly
described by another list member as a "never in a million years"
kind of thing.
He then applied the drastic corrections needed to
reverse his own sabotage, on both an 8- and 16-bit file, and called
attention to the deepest shadows, where the 16-bit version was indeed
softer. However, looking at the image as a whole, everyone who examined it
concluded that the 8-bit version was superior. This effect is similar to my
own findings in B/W. Anyone making major corrections in an ultra-wide RGB
needs to be aware of it--there are more cases where 8-bit is superior than
the other way round. (Again, in a rational RGB it doesn't matter which you
use).
In regards to "real world" images, are you
discounting the fact that
someone may PREFER a more highly-saturated rendering of
a "real-
world" photographic scene as opposed to one that
is "accurate" or
faithful to the original scene?
No.
I would contend that virtually no one
would prefer an "accurate" rendering of a
scene and would prefer
instead a bit of added "punch" as being more
pleasing. Acknowledging
that this may be the case for a majority of
photographs, it then only
becomes a matter of degree to which this preference may
be contained
in a smaller space such as sRGB or that it may
"punch-out" or sRGB
and require a larger container/color space.
Do you have an example image to show us?
In my mind, if a current printing
technology can be demonstrated to exceed several of
these so-called
rational color spaces, these now become REAL colors
that I can print
requiring a color space that will contain them and are
not simply
some theoretical colors that I MAY be able to print and
should allow
for in the hopes some future imaging technology comes
along that will
permit this.
This does not speak to the point made both by me and
Paul DeRocco. Even accepting the vendors' claims that they can hit such
colors, which I do not accept, or that human beings can perceive minor
differences in them, which I do not accept either, the question becomes
whether you have any files that would actually take advantage of these
purported capabilities.
No output device approaches any of these RGBs except in
dark, saturated yellows, magentas, and cyans. The better the output
conditions, the bigger the range of these potentially problematic colors,
but no device creates a problem for these RGBs in red, green, and blue.
Variations in extremely saturated yellows are inconsequential as nobody can
see them. The problems with magentas and cyan are potentially real--as long
as you can find an image that wants to use these colors. I suggest that you
probably can't.
No, these are colors that I CAN print today and might
well WANT to print
depending on how I chose to render a real-world
image.
Then it shouldn't be too much trouble for you to show
us the kind of image you have in mind--a real-world color photograph with
discernable detail that only LAB or an ultra-wide RGB can retain, and yet
is printable on any existing device.
Dan Margulis
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andrew Rodney thedigitaldog
Date: Fri Aug 4, 2006 9:06 am (PDT)
On 8/4/06 7:51 AM, "colorman042000"
wrote:
Editing in ACR using ProPhoto as your color space when
your final
output is sRGB can result in inferior images as I have
found many
times.
Can you post some RAWs and rendered examples?
For instance, if you edit bright saturated reds in
"ACR-
ProPhoto" you will most probably end up with reds
that are way outside
the sRGB gamut so when you eventually convert to sRGB
those reds will
be clipped. Since color = detail then clipped
colors = clipped details.
Of course itxs clipped, you went from a much larger
color space (one you hopefully selected to contain colors captured
otherwise why select it?) to a smaller one (because that sRGB color space
is appropriate for some use). Now if you have the ProPhoto image and need
to output to say a $600 Epson 2400, you can use those colors since itxs far
more capable of producing the extended gamut that sRGB canxt.
Andrew Rodney
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andre Dumas
Date: Fri Aug 4, 2006 10:03 am (PDT)
Terry Wyse wrote:
one can also demonstrate that, in fact, current inkjet
technology (and I assume photographic imaging
technology) can not
only exceed sRGB but can indeed exceed parts of the
"huge" AdobeRGB
space. ..
Isn't it a fact that inkjets are dependent to a large
extent on the profiles that one has built for his own particular printer?
If one's profiles are somewhat deficient in the reds for instance, isn't it
possible then that the inkjet might not reproduce those reds correctly even
if they are well within its gamut?
If so then, when we talk about the large gamut of the
Epson 2200 and other printers should we not talk about, and take into
consideration, the gamut of the profiles that we are using, and should we
not recognize that few people have access to really good profiles for their
very own printer and for all their papers and printing conditions?
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "MARK SEGAL"
Date: Fri Aug 4, 2006 11:05 am (PDT)
Andre,
The Epson 2400 and X800 series using the Epson
K3 inkset do have wider gamut in some respects than that of its immediate
pre-decessors, the Epson 2200 and the 4000/7600/9600 series. This shows on
gamut plots and printer test charts that I have seen presented. The gamut
plots also show that these printers' gamuts exceed that of ARGB98 in in
some respects.
Based on extensive experience using both the
Epson 4000 and the Epson 4800, and having various custom profiles made for
both machines, and comparing my results with those obtained on other
similar machines using a well-known and respected RIP, I find that the
profiles which Epson supplies for its own papers are indeed VERY good on
their professional machines (4000/4800 upward). Owners of these machines
would have to go to some lengths to improve upon them.
The remaining issue, which Dan has raised I
believe, is whether "real world images" would actually contain
those colours at the edge of the printer's gamut such that one would want
to print them (and therefore wish to have the larger working space from
which to draw upon them). The answer to that question in my case is YES,
especially for reds. People who have done alot of photography in Thailand
and China will know what I mean.
Mark Segal
___________________________________________________________________________
Color Management Workflow for RAW files Editing
Posted by: "Richard Chang"
Date: Fri Aug 4, 2006 11:09 am (PDT)
Terry writes,
I would contend that virtually no one
would prefer an "accurate" rendering of a
scene and would prefer
instead a bit of added "punch" as being more
pleasing. ...
I would contend that virtually no one in the off-figure
catalog business would prefer anything less than accurate. Because
customers commonly lay a garment across the catalog page to see if that
rendered image goes with an outfit they already have, the image must be
accurate. Returns of product, based on non-accurate rendering of
color specific goods, can impair a clothing retailer's bottom line in a
hurry.
Richard Chang
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Terry Wyse"
Date: Fri Aug 4, 2006 3:32 pm (PDT)
Assuming a good (professional) profiling application
has built the profile, if the profile happens to be deficient in red, by
definition so is the printer. The printer defines the gamut of the profile,
not the other way around.
I'm, naturally, assuming the use of custom profiles not
mystery-meat profiles downloaded from questionable sources.
Regards,
Terry Wyse
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andrew Rodney thedigitaldog
Date: Fri Aug 4, 2006 3:32 pm (PDT)
The profile defines and describes the color space
(gamut) of the device.Therexs no adding or artificial gamut although there
are differing ways ofmapping out of gamut colors to the gamut of the
device.
The gamut of many ink jet printers requires a color
gamut significantlylarger than sRGB (and in some cases Adobe RGB (1998)) if
you wish toreproduce all captured colors also outside that gamut.
Andrew Rodney
http://www.digitaldog.net/
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: Andre Dumas
Date: Fri Aug 4, 2006 3:32 pm (PDT)
I have posted "petunias" in the Photos
section. This was opened directly from the RAW, it was adjusted in
RAW but unmodified after opening except that it was cropped and saved to a
JPEG.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Matthew Rigdon"
Date: Fri Aug 4, 2006 7:12 pm (PDT)
I opened your file and assigned an sRGB file (i assume
you used sRGB, you didn't specify how you did the conversion to JPEG, but
most converters use sRGB since JPEG is assumed to be for web work).
I put up a picture of some ducklings that I took in an
album called "Ducklings at a Red Trough". The little feed trough
is a rather intense red color, maybe not exactly the same red as your
petunias, but something with a good amount of saturation. It seems sRGB can
handle intense red shades (your image looks very flat and desaturated).
If the issue is that you just let the machine convert
to sRGB and it came up with that, that doesn't necessarily represent a
failing on the part of sRGB. It may have just needed a different adjustment
before the conversion. Of course, you'd need to know you were going to sRGB
to begin with. I don't think any of the profiles or conversion methods can
always be expected to be done without operator assistance.
Matthew Rigdon
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: Ric Cohn
Date: Fri Aug 4, 2006 7:13 pm (PDT)
Andre,
Not sure what you uploaded. I've noticed before that
Yahoo strips any profile and resamples the jpeg when it uploads. Was this
edited and output as ProPhotoRGB? If I assign ProPhotoRGB to it the red
becomes super bright and, at least on my Laptop, large areas of the reds
are outside the monitors gamut and appear flat red even though the channels
aren't clipped.
Please elaborate on your point- it appears to be an
interesting one.
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini marcougolini2
Date: Fri Aug 4, 2006 10:53 pm (PDT)
In a message dated 8/4/06 9:33 AM, colorman042000 wrote:
Isn't it a fact that inkjets are dependent to a large
extent on the
profiles that one has built for his own particular
printer? If one's
profiles are somewhat deficient in the reds for
instance, isn't it
possible then that the inkjet might not reproduce those
reds
correctly even if they are well within its gamut?
If so then, when we talk about the large gamut of the
Epson 2200 and
other printers should we not talk about, and take into
consideration,
the gamut of the profiles that we are using, and should
we not
recognize that few people have access to really good
profiles for
their very own printer and for all their papers and
printing
conditions?
That statement belies a sharp misunderstanding of the
profiling process. AsTerry says elsewhere (I paraphrase), if you create
your own custom outputprofile consciensciously and accurately, observing
all the usualprecautions, the reds (or greens, or blues, etc) that your
printer canproduce are reflected in it. In other words, your custom profile
will mirrorthe color range that your printer can produce, and do so with
good toexcellent fidelity, depending on the situation and the variables at
play.
If the profile one uses with a given printer is shown
to be clipping thegamut of the printer (e.g., is unable to express the
color intensity ofwhich the device is capable), it's extremely likely that
this is occurringbecause one is either using the wrong profile for the
device or the customprofile has been made without the due care.
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini
Date: Sat Aug 5, 2006 9:08 am (PDT)
In a message dated 8/4/06 10:49 AM, MARK SEGAL wrote:
I find that the profiles which Epson supplies for its
own papers are indeed
VERY good on their professional machines (4000/4800
upward). Owners of these
machines would have to go to some lengths to improve
upon them.
Yes, I have seen them in action, and they do seem to
provide a good andsurprisingly reliable statistical average for the user
who does not haveaccess to profile-making hardware and software of one's
own. But I have tosay, without false modesty, that I have created custom
profiles that haveshown a clearly perceptible improvement (though not
earth-shattering) overEpson's canned profiles on more than one occasion,
providing betterneutrality and color vibrancy. And that makes sense,
because, no matter howgood the statistical average (and I admit it is good,
from what I haveseen), individual devices stray enough from the norm to
need their ownprofile in order to perform at their best.
Epson is seemingly aware of the need to address this
inevitable statisticaldeviation, since it released its ColorBase software
last year precisely toattempt to bring individual inkjet printers in line
with the conditions ofthe printer from whose output Epson's profiles were
created (a.k.a. Epson'sfactory reference standard).
The paradox here is that ColorBase is supposed to
promote Epson's factoryprofiles, but requires a spectrophotometer to do its
bit. I'm sure that thisstops more than a few people in their tracks when
evaluating whether to useColorBase. After all, it's likely that many of
these are people who, thoughthey may want to use Epson's profiles, probably
want nothing to do withspectrophotometers, and are even less likely to
contemplate buying one.
The remaining issue, which Dan has raised I believe, is
whether "real world
images" would actually contain those colours at
the edge of the printer's
gamut such that one would want to print them (and
therefore wish to have the
larger working space from which to draw upon them). The
answer to that
question in my case is YES, especially for reds. People
who have done alot of
photography in Thailand and China will know what I
mean.
Dan's claims seem to suit his needs fine, apparently,
but to see thatassessment as valid for everyone else is problematic at the
very least.
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Sat Aug 5, 2006 9:08 am (PDT)
Andrew Rodney wrote:
Now if you have the ProPhoto image and need to output
to say a $600
Epson 2400,you can use those colors since it1s far more
capable of
producing the extended gamut that sRGB can1t.
I see the logic in your suggestion and I always keep my
RAW files for that purpose but regarding Wai Hong Chung's workflow it is my
opinion (and experience)that he will achieve better sRGB outputs if he edit
his RAWs in the sRGB color space.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Sat Aug 5, 2006 9:08 am (PDT)
Ric and Matthew,
What I uploaded was first edited and outputed as a
ProPhoto/TIFF 360ppi, then it was downsampled to 100ppi, converted to a
ProPhoto/JPEG and uploaded to Yahoo's Photos.
I downloaded the image from Yahoo this morning and
noticed that the profile had been stripped away, I reassigned ProPhoto and
the results match my original almost perfectly.
On my monitor all colors, of the Prophoto image, that
are outside of its gamut have been clipped to its nearest displayable
colors and readings of the brightest reds are in the vicinity of 198,84,57.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Larry Wangelin"
Date: Sat Aug 5, 2006 9:09 am (PDT)
Cars have four tires usually with a prescribed amount
of air in them but you can drive with the air pressure lower than it is
suppose to be, to a point.
I guess that you could drive with them a little flat on
the bottom too.
Larry Wangelin
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "David Riecks"
Date: Sat Aug 5, 2006 12:43 pm (PDT)
Andre:
Any chance you were using Photoshop "Save for
Web"? If so that will drop all metadata and strip the color profile.
There is a check box in the newer versions to retain the color profile, but
not the metadata.
FYI if you are using this feature to save images that
are going to others and you don't want to create "orphan
works."
See http://orphanworks.blogspot.com/ for details on
that issue.
David
--
David Riecks (that's "i" before
"e", but the "e" is silent)
See the new Universal Photo Digi-Image Guidelines at
http://www.updig.org/
Chairman, SAA Imaging Technology Standards Committee
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Ric Cohn"
Date: Sat Aug 5, 2006 12:44 pm (PDT)
I just want to add one more thing I just did, as I
found it interesting. On my laptop and on my computer with the Artisan I
set the Proof Space to my Monitor's Profile and then did a Gamut Warning.
On my laptop almost all the reds in the flowers turn gray (plus all the
dark greens). On the Artisan only some of the reds turn gray (plus most of,
but less of, the dark greens).
I believe this is a valid way to see what colors in an
image are outside your monitor's gamut?
I also converted the image from ProPhotoRGB to sRGB.
When I did the same settings for this image the reds show virtually the
identical gray Gamut Warning, but the dark greens almost all come back into
gamut (somewhat less on the laptop than on the Artisan are now in gamut).
Not sure why this should be so. Perhaps someone else can comment on this?
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Dan Margulis j
Date: Sat Aug 5, 2006 12:44 pm (PDT)
Mark Segal writes,
The remaining issue, which Dan has raised I believe, is
whether "real world
images" would actually contain those colours at
the edge of the printer's
gamut such that one would want to print them (and
therefore wish to have the
larger working space from which to draw upon them). The
answer to that question in my case is YES, especially for reds. People who
have done alot of photography in Thailand and China will know what I mean.
I agree that photography in that region of the world
needs to get good reds, but in return, I would ask that you agree that your
printer uses a subtractive, and not an additive, color model. If so,
then it is *most* likely to exceed the gamut of a given RGB in cyans,
magentas, and yellows. It is *least* likely to match up in reds, greens and
blues. I am familiar with the machines you name, and they are
impressive--but they haven't found a way to evade the above-mentioned law.
If you've got some brilliant purples, then we have something to discuss.
But if all you're worried about is reds, sRGB should be more than
sufficient for your needs.
Dan Margulis
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: "Ric Cohn"
Date: Sat Aug 5, 2006 12:44 pm (PDT)
On Aug 5, 2006, at 11:27 AM, colorman042000 wrote:
On my monitor all colors, of the Prophoto image, that
are outside of
its gamut have been clipped to its nearest displayable
colors and
readings of the brightest reds are in the vicinity of
198,84,57.
OK, now we're both assigning ProPhotoRGB. As I said, on
my Laptop large areas of red become blobs. I took it over to my Artisan
monitor and it looks good with only small areas of over saturation.
Certainly an excellent example of the limitations imposed on editing by
one's monitor! BTW, this got me to re-calibrate my Laptop (Using a
Spyder2). I used Gamma 2.2, Native White Balance. The new profile does show
a little more detail than whatever it had drifted to, but still was blown
out in the bright reds compared to my better monitors.
I used Gamut Warning to see what Photoshop considers
out of gamut. For US Webcoated SWOP (V2) there are huge areas out of gamut.
However, for a custom CMYK profile supplied by the last printer I've used,
only small areas are out of gamut-- comparable to the size of the out of
gamut areas if I look at the custom glossy paper profile for my Canon
i9900. Interestingly (to me) while all the output previews lose saturation,
they all show more detail for Perceptual intent and, as expected, blown out
areas of saturation for Relative.
From this I conclude that the file would output
with more detail than I see on my Laptop, but less color saturation, if
output to my i9900 printer.
I don't believe any of this is unexpected, except
perhaps how bad it looks on a Laptop vs a good CRT. Still curious, I
brought it open to my G5 iMac. I was pleased to see that the image looked
pretty much the same there as on my Artisan. This is an excellent lesson
for me, because if I converted your image straight to sRGB and uploaded it
to my website it would look perfectly acceptable to those with
"good" monitors and unacceptable to those with
"limited" monitors. I'll have to be more careful when prepping
very colorful images for the Web.
Now, what was your point?
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Mark Segal"
Date: Sat Aug 5, 2006 12:44 pm (PDT)
Marco,
Thanks for responding on this one. I'm
interested........I've ordered profiles, and I've had them custom made
under my nose by a friend who owns a G-M Eye-One, and quite frankly none of
it performed any better overall than did the Epson profiles. SO, my
question: What are you using for making your profiles, and if you can
mention in very general terms, are you doing any special kind of profile
editing? I'm not afraid of the word "spectrophotometer". In fact
I've been serioulsy considering buying an X-Rite Pulse system, because much
as I find the Epson profiles satisfactory, there are occasional issues with
deep shadow rendition (all profiles have trouble with this on matte media
because of the media), I'm hoping that if I can do my own profile editing I
can target such issues, and I've only heard and read very good things about
Pulse. Also as I intend to branch out into using different media types,
this could be the right time to fork-out that kind of money - costs about
1K. Any suggestions?
Mark Segal
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andre Dumas
Date: Sat Aug 5, 2006 12:45 pm (PDT)
Hello Ric,
My point was about Terry's statement: "one
can also demonstrate that, in fact, current inkjet technology (and I assume
photographic imaging technology) can not only exceed sRGB but can indeed
exceed parts of the "huge" AdobeRGB space"
I think (perhaps erroneously and in that case I would
like to be corrected) that whether or not a very wide gamut printer can
display all reds correctly depends to a great extent on the quality of the
profile and to say that the Epson 2400, or other printers, can display all
those reds is only partially true. It probably could if the printer
profile which does the interpretation could describe all the reds in my
"Petunias", the question is: can it really?
That is why I asked: "when we talk about the large
gamut of the Epson 2200 and other printers should we not talk about, and
take into consideration, the gamut of the profiles that we are
using?"
Terry says that the printer defines the gamut of the
profile and not the other way around. I say perhaps it would be so if the
profiler could describe the printer and build a profile that really
represents all of the printer's capabilities to reproduce colors, but it
does not (I think). It seems to me that it is more "real
world" to say that the profile defines the gamut of the printer, in
the end it is the profile that modifies the numbers in your image and the
printer prints only what the profile gives it.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Dan Margulis
Date: Sat Aug 5, 2006 12:45 pm (PDT)
Marco writes,
Dan's claims seem to suit his needs fine, apparently,
but to see that
assessment as valid for everyone else is problematic at
the very least.
I am more than happy to change my assessment if someone
can show me real photographs with colors outside the Adobe RGB gamut that
print better on any output device because the user used LAB and/or an
ultra-wide RGB.
Would you happen to have any such?
Dan Margulis
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andrew Rodney thedigitaldog
Date: Sat Aug 5, 2006 12:46 pm (PDT)
I always archive my RAWs too (as .DNGs) but I don1t
want to re-render andencode them just to have a larger working space when I
can see the veryfirst time the most appropriate working space to encode the
data into (basedon ACRs Histogram). So, if I see the gamut of the captured
scene needsProPhoto RGB, I'll use that. I can always convert that rendered
data into asmaller color space with no need to go back to the RAW. If the
gamut of thescene fits into sRGB, I'll use that the first time as well
(again, unless Ifind an update to the RAW processor yields better
rendering, something thatis common, I don1t have to go back to the RAW
files and start from scratch).
Andrew Rodney
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Ric Cohn"
Date: Sat Aug 5, 2006 2:27 pm (PDT)
Andre,
For inkjet profiles, I think Terry and others are
correct- with one caveat. When building a profile for a printer, I
print a target that sends pure numbers (such as 255, 0, 0) to the printer.
This patch is then read and that's what tells the profiling program what is
the brightest red the printer is capable of for that paper and printer
setting. The caveat is that you must first find what printer setting will
give you the most ink laydown without creating other problems such as
bleeding or mottling.
Ric Cohn
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Iliah Borg"
Date: Sat Aug 5, 2006 2:28 pm (PDT)
Dear Wai-hong,
I kind of disagree with your subject line.
First, what is "RAW files Editing"?
All the moves at the stage of raw file conversion are
not editing rawdata, they are to edit how the raw data will be rendered
into someother form, usually RGB. That means that making moves at raw
fileconversion stage, like in ACR, you actually can change the outputgamut.
You can fit it into a smaller colour space, or expand it to gopast the
widest one.
Second, what is "Color Management Workflow"
is raw converters?
RAW file itself is not even an RGB file, and when you
convert it toRGB, or Lab, or other colour model you should do something
about thatif you want colour managed workflow *after* raw conversion
stage.Usually it is assigning some pre-determined colour space,
andoptionally converting to some oither. IMHO that is the only
"colourmanagement" to speak of here.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Mark Segal"
Date: Sat Aug 5, 2006 2:29 pm (PDT)
Dan,
Yes, I agree the printer uses a subtractive colour
model, given that its inks are CMYK and not RGB. My understanding is that
the printer is called an RGB device because it wants to be sent RGB data,
but this data is then converted into CMYK values for printing. That said,
I'm not sure I understand the necessity of how that relates to the
rest of what you say. Grateful if you could elaborate - I may have a mental
blockage on some elementary colour theory here!
Mark Segal
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andrew Rodney thedigitaldog
Date: Sat Aug 5, 2006 2:30 pm (PDT)
On 8/5/06 10:18 AM, "colorman042000"
wrote:
I think (perhaps erroneously and in that case I would
like to be
corrected) that whether or not a very wide gamut
printer can display
all reds correctly depends to a great extent on the
quality of the
profile and to say that the Epson 2400, or other
printers, can
display all those reds is only partially true.
I think you have a basic misunderstanding of ICC
profiles. They onlydescribe device behavior. The Epson produces a certain
maximum red that canbe defined by knowing its color space (where does red
fall within humangamut or CIE XYZ if you want numbers). That1s all a
profile is doing here.You can mess around with the driver settings or
introduce a RIP which canaffect ink delivery and hence gamut. But a profile
reflecting that state isabsolute and isn1t affecting gamut.
You can set an Epson in the Epson driver to produce
more linear output atthe expense of gamut of some saturated colors. Its not
a huge amount butit1s an amount that each profile made of that condition
describes.
In the case of the Epson 2400 and other K3 devices, no
matter how you setthe driver, you1re going to produce a much wider gamut in
some colors thansRGB can describe.
Terry says that the printer defines the gamut of the
profile and not
the other way around.
The profile describes the gamut of the printer.
Andrew Rodney
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Dan Margulis" j
Date: Sat Aug 5, 2006 5:33 pm (PDT)
Mark Segal writes,
Yes, I agree the printer uses a subtractive colour
model, given that its
inks are CMYK and not RGB. My understanding is that the
printer is called an RGB device because it wants to be sent RGB data, but
this data is then converted into CMYK values for printing.
Right, plus sometimes some other inks as well, but CMYK
for sure.
That said, I'm not sure I understand the
necessity of how that relates to
the rest of what you say. Grateful if you could
elaborate - I may have a
mental blockage on some elementary colour theory here!
It's not elementary but it is understandable. This will
be a quick explanation because I'm headed out for Costa Rica in the morning
and need to do some language work tonight. I'll be offline until late next
week.
If you want to make the most saturated possible magenta
in RGB, you turn the red and blue light sources on full blast, no green at
all. If you want to do it in CMYK, you lay down a solid coating of an ink
formulated to prevent the reflection of green light, while allowing red and
blue to reflect freely--in fact, more red and blue reflects off this solid
coverage of magenta ink than it would off blank paper.
Similarly, if you want to make the most saturated
possible yellow in RGB, you turn the red and green light sources on full
blast, no blue at all. If you want to do it in CMYK, you lay down a solid
coating of an ink formulated to prevent the reflection of blue light, while
allowing red and green to reflect freely--in fact, more red and green
reflects off this solid coverage of yellow ink than it would off blank
paper.
In these two cases--solid coverages of either yellow or
magenta colorant--typically the CMY, even under indifferent conditions, is
outside of the gamut of most RGBs. Same goes for solid cyan.
If you want to make a lighter, but still very pure
magenta, you do this in RGB by adding some green light, since you're
already generating as much red and blue as you possibly can. In CMYK, you
subtract some magenta ink, relying on the blank paper to make the overall
color lighter. Unfortunately, paper is not completely reflective. It
blocks some red and some blue. The more paper is exposed, the worse the
effect, so that if you're printing on commercial stock, even 90% magenta
coverage is likely within RGB gamut, and anything less will be *well*
within it. With the much whiter papers that you presumably use, you can
probably go a little lighter and still be around the edge of the RGB gamut,
but if you start adding other colorants or reducing magenta coverage
further you may as well stick to sRGB.
If you want to make the most saturated possible *red*
in RGB, you turn the red light source on full blast, no green and blue at
all. In CMYK, you lay down solid magenta to kill the green, plus solid
yellow to kill the blue. In a perfect world, this works because the two
colorants are totally transparent. In the real world, they are not,
especially the magenta. 100M100Y allows more green to reflect than 100M,
and more blue to reflect than 100Y. As green and blue are red-killers, you
can't get particularly close to the limit of the RGB gamut here.
Consequently, you don't have to worry about gamut in
reds. You have to worry about it in dark, pure CMY primaries. For
commercial printing, if you're using sRGB, you have to worry about
something at least 85-90% of the dominant ink and less than 5% of the other
two. For your kind of printing, (again assuming that you use sRGB) maybe it
goes down to 70-75% plus less than 10%.
*Reds* that are that dark and that pure happen all the
time, as you know from your Asian images. *Magentas* and *cyans* dark and
pure enough to pose a problem in commercial printing don't happen. For your
kind of printing, cyans don't happen either. Many flowers and some products
fall in the problematic range for you yet are too light to cause a
commercial printer any difficulties.
Therefore, I would say that those people who shoot a
lot of flowers and also have very good inkjet printers with high-quality
paper should avoid sRGB. I don't think, however, that something as big as
Adobe RGB is needed, (although I see little harm in it.)
Dan Margulis
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Terry Wyse"
Date: Sat Aug 5, 2006 5:36 pm (PDT)
We're ALL correct! The printer (print conditions
really) DEFINES the gamut that the profile DESCRIBES.
I was mostly trying to dispell the notion (or what was
implied by an earlier post) that an output/printer profile is some sort of
stretchy Play-Doh type of thing that can be made to have any sort of
"gamut" behavior you'd like it to have irrespective of the
device/printer it is supposed to describe. That's simply not the case.
Regards,
Terry Wyse
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini
Date: Sat Aug 5, 2006 5:38 pm (PDT)
In a message dated 8/5/06 10:53 AM, Dan Margulis wrote:
Marco writes,
Dan's claims seem to suit his needs fine, apparently,
but to see that
assessment as valid for everyone else is problematic at
the very least.
I am more than happy to change my assessment if someone
can show me real
photographs with colors outside the Adobe RGB gamut
that print better on any
output device because the user used LAB and/or an
ultra-wide RGB.
Would you happen to have any such?
None that would satisfy you, I'm afraid.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini marcougolini2
Date: Sat Aug 5, 2006 5:39 pm (PDT)
In a message dated 8/5/06 9:18 AM, colorman042000 wrote:
I think (perhaps erroneously and in that case I would
like to be
corrected) that whether or not a very wide gamut
printer can display
all reds correctly depends to a great extent on the
quality of the
profile and to say that the Epson 2400, or other
printers, can
display all those reds is only partially true.
"The Epson 2400 or other printers": that's a
wide brush. Does that includeRolands too? How do you reach such a
conclusion (that the claims are only"partially true")? And does
an opinion stated in such a vague and genericmanner mean much at all in
actual practice?
It probably could if the printer profile which does the
interpretation could
describe all the reds in my "Petunias", the
question is: can it really?
Potentially, profiles can describe ALL the colors in
the L*a*b* space uponwhich ICC Color Management is based. Atsa spicy
meatball of colors! (Withapologies to the Alka Seltzer commercial.) That
includes your petunias andthen some. Some profiles actually go even further
-- for technical reasonshaving to do with matrix-related math or some such
-- into that realm of"imaginary colors" which Dan is fond of
ridiculing now and again.
Then there is the bottleneck of the actual printer that
one uses, which mayor may not be capable of producing those colors. And
that's where the funstarts: if the colors exist in the printer/paper
combination, the profilewill handle them.
So, your question is puzzling. Have you tried? Have you
tried and failed? Iwould think that, if the answer is not within one's
reach, one starts out byasking others, or else goes about trying on one's
own, if possible, anddraws conclusions later, after some concrete and
sufficient evidence is in.
That is why I asked: "when we talk about the large
gamut of the Epson
2200 and other printers should we not talk about, and
take into
consideration, the gamut of the profiles that we are
using?"
Certainly: was the profile poorly made? And in that
case, how do we make abetter profile? There is always room for improvement
(a better measuringinstrument, better software, more appropriate settings,
etc).
Terry says that the printer defines the gamut of the
profile and not
the other way around. I say perhaps it would be so if
the profiler
could describe the printer and build a profile that
really represents
all of the printer's capabilities to reproduce colors,
but it does
not (I think).
Again, you think... But based on what, if you pardon my
impatience? Do youbase this on personal experience, hearsay, the opinions
of this forum'shosts, or what else?
It seems to me that it is more "real world"
to say
that the profile defines the gamut of the printer, in
the end it is
the profile that modifies the numbers in your image and
the printer
prints only what the profile gives it.
People used to say that the Sun and all the stars (the
printer in this case)revolved around the Earth (the profile), and I'm sure
some still think thatway. Heck, it's so loopy out there that there's even a
Flat Earth Societystill alive and kicking! (I'm not kidding: Google it!)
But my pal Galileo Galilei -- another stubborn Italian
skeptic just like me-- could not be convinced: he said "Eppur si
muove!", and things were neverthe same again. :o)
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Mark Segal"
Date: Sat Aug 5, 2006 7:30 pm (PDT)
Dan,
Many thanks for that extensive explanation, especially
so close to leaving on a trip.
Safe return,
Mark
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini marcougolini2
Date: Sun Aug 6, 2006 9:24 am (PDT)
Hi Ric.
I personally do not completely trust the Gamut Warning
function in Photoshop. People who have more inside info than I do have told
me that the math in that function is far from foolproof, actually faulty
enough not to recommend depending on it for critical evaluations of color.
(I may turn out to be wrong in thinking this, but there's only so much that
I can verify on my own at a scientific level. If people whose judgment I
regard as trustworthy warn me, I tend to consider myself warned, though I
remain curious and open to contrary evidence.)
I prefer to use ColorThink to see how the colors of a
tagged image stack up to a given ICC profile that I may contemplate
converting that image to. It does not have the same direct visual impact as
Gamut Warning (with its flat swatches of warning color superimposed over
the image), but there are ways to pinpoint certain colors with ColorThink,
and how they are remapped to the target profile, that, with practice,
become quite precisely predictive and useful.
The procedure is described in the chapter called
"The Grapher" of the ColorThink 2.2 PDF manual (starting at page
24).
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Sun Aug 6, 2006 9:25 am (PDT)
Andrew
I think I understand your point, I usually edit RAWs in
ProPhoto because my work usually does not end up in sRGB (but sometimes it
does).
Your statement, "unless I find an update to the
RAW processor yields better rendering, something that is common," is
what I meant to say and I would like to add that not only is it common that
one has to go back to the RAW when the image is to be re-rendered into sRGB
"it has been my experience" that it often yields a better sRGB
image specially if your image has flamboyant reds. My findings are not
based on a scientific analysis of the results,I can explain what they were
but right now I will spare you the details.
My suggestion to Wai Hong Chung was that if he knows
right from the start that the final image will be in sRGB then he should
adjust his RAW for that output rather than converting later on.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: "colorman042000"
Date: Sun Aug 6, 2006 9:25 am (PDT)
I think you have a basic misunderstanding of ICC
profiles. They only
describe device behavior. The Epson produces a certain
maximum red
that can be defined by knowing its color space (where
does red fall
within human gamut or CIE XYZ if you want numbers).
That1s all a
profile is doing here.You can mess around with the
driver settings or
introduce a RIP which can affect ink delivery and hence
gamut. But a
profile reflecting that state is absolute and isn1t
affecting gamut.
Andrew, "They only describe device
behavior." is what I'm trying to understand, I have not found an
explanation to this riddle in your book or in Chris Murphy's. Could
be due to some mental blockage ...???
If you know where it is (the explanation) would you be
kind enough to point me in the right direction or to some other book on the
subject.
I'm not ashamed of "my basic misunderstanding of
ICC profiles", I'm learning.
Now raise your hand all those in this group who have a
*clear, accurate and complete* understanding of ICC profiles ...! ;-)
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Sun Aug 6, 2006 9:26 am (PDT)
Mark.
Thanks for your suggestion Mark. I have an Epson
R800 (with the extra red and blue inks) and yes I find that this printer
can really turn out excellent reds on Epson papers.
I also have Epson's profiles that came with the printer
but my own profiles were better than theirs. That was almost two
years ago and your message reminded me that I recently heard that Epson has
come out with new, more accurate profiles. I will see if I can
get something for the R800.
Thanks,
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Marco Ugolini marcougolini2
Date: Sun Aug 6, 2006 9:28 am (PDT)
One advantage of the Pulse is that it can be used
untethered, operating on a battery that allows the unit to store
"approx. 10 profiles", according to the XRite brochure. Of
course, 10 profiles based on a large number of patches consume more storage
space than profiles based on a smaller number, but it's nice not to have to
fuss with a cord, as one must inevitably do with the EyeOne Pro.
On the other hand, the Pulse samples at 20 nanometer
(nm) intervals. It has a "16 point engine" (20nm between the
spectrum ends of 400nm and 700nm) with "31 point reporting" (at
10nm intervals), which means that it interpolates the intermediate values,
instead of measuring them directly, which diminishes accuracy. On the other
hand, the EyeOne Pro samples at 10nm, true, not interpolated. It reads 36
points at 10nm intervals between 380 and 730nm. (The Spectrum Locus for the
1931 Standard Observer, which attempts to model human vision, lists
frequencies between 380 and 700nm, just to give you an idea). The added
range at the low end is useful for detecting fluorescence, which is then
compensated for via software in ProfileMaker.
As for editing profiles, I have tried to stay away from
that so far. There is a risk of messing up a good thing very easily, simply
by not knowing where and when to stop. I've reluctantly edited a profile
for a client recently, because he wanted to improve the neutrality of the
highlights (make them less blue), but that was an exception that I don't
intend to repeat too soon.
Instead of messing with the profile by editing it, I
prefer to find ways to make profiles that are more accurate from the
get-go. I test different settings and output choices (I find that proper
ink limiting is very important on inkjets, for example).
I personally think that relying on profile *editing*
before attempting to figure out the best way to deal with the profile
*creation* part of the procedure is a misguided approach, one that can lead
to frustration compounded by the unintended results that editing may have
on portions of the output that were not meant to change. Also, fixing a
poorly-made profile seems like a pointless thing to do, just from a purely
logical point of view, something that would make sense only if it were the
only option available.
I am sticking with ProfileMaker for now, and my clients
are happy with the results. I have not used Monaco Profiler so far, but I
have heard good things about it. What I like about ProfileMaker that Monaco
Profiler apparently doesn't offer is the ability to read targets
spectrally, not just only colorimetrically, and also to compensate for
fluorescence.
I am happy with my EyeOne Pro Rev B and ProfileMaker.
Having to deal with the cord is a minor annoyance that I have learned to
live with. It hasn't disappointed me yet.
Best of luck, and regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Re: Color Management Workflow for RAW files
Editing
Posted by: Andrew Rodney thedigitaldog
Date: Mon Aug 7, 2006 1:18 am (PDT)
On 8/6/06 10:01 AM, "colorman042000"
wrote:
Andrew, "They only describe device
behavior." is what I'm trying to
understand, I have not found an explanation to this
riddle in your
book or in Chris Murphy's. Could be due to some
mental
blockage ...???
Just look at the word used to describe these small
files; profiles. The profile (define) device behavior. That1s their only
real role.
WordNet (r) 2.0
1 definition(s) found
profile
n 1: an analysis (often in
graphical form) representing the
extent to which
something exhibits various
characteristics;
"a biochemical profile of blood"; "a
psychological
profile of serial killers"
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Mon Aug 7, 2006 1:20 am (PDT)
Dear Iliah Borg,
Please excuse me because my English is not very
good. Forget about the title. I just want some body to comment on my
workflow starting from RAW in the ACR then output it in one of the 4 RGB
options provided by ACR. In case if I need to use ProPhoto RGB due to the
large gamut captured from the camera or as a result of editing in ACR, I
want somebody to comment on my way of handling this wide gamut RGB because
I know there is limitation on the display and the printer.
Please note that I take the files to the lab to
print the photos and they only accept sRGB files. I must say that for most
of the time, I stick with sRGB from RAW to print. However, I just want some
body to advise me what should I do in case there are some highly saturated
colors in my photos where it will be clipped if I choose sRGB from the ACR.
Please accept my apology for the confusion
caused.
Kind regards,
Wai Hong Chung from Hong Kong
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Mark Segal"
Date: Mon Aug 7, 2006 1:20 am (PDT)
Marco,
Thanks for the advice on both aspects. Makes sense.
Mark Segal
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Stephen Marsh
Date: Mon Aug 7, 2006 5:08 am (PDT)
Wai-hong Chung wrote:
I just want some body to comment on my workflow
starting from RAW
in the ACR then output it in one of the 4 RGB options
provided by ACR.
In case if I need to use ProPhoto RGB due to the large
gamut captured
from the camera or as a result of editing in ACR, I
want somebody to
comment on my way of handling this wide gamut RGB
because I know there
is limitation on the display and the printer.
Wai-hong, as is often the case on this list, the thread
has a life of it's own, beyond the intent of the original post. Posts that
directly answer your concerns will retain this topic title, but the
"side issue" replies will be re-titled to cut down on the
confusion in this thread.
If I recall correctly, your old/new workflow is as
follows:
Your 'output target' is sRGB.
Your originals are ACR files.
Most of the time you process direct to sRGB in ACR. On
rare occasions, you find that viewing the histogram in ACR shows clipping
when going to sRGB, so in these cases you use ProPhoto RGB so as not to
clip the gamut.
You then find that you suffer clipping *anyway* when
going from ProPhoto to sRGB as there is no perceptual gamut compression
taking place in these profiles.
You have found that an alternative is to go from
ProPhoto RGB to Photo Gamut RGB which does offer a perceptual table.
Once the gamut compression from ProPhoto to PhotoGamut has been performed,
you then convert to sRGB for final image delivery (which only offers RelCol
rendering, not perceptual).
Is this correct?
Please note that I take the files to the lab to
print the photos
and they only accept sRGB files.
It would be nice if they offered you their device
profile, that also offered Perceptual rendering. But this is not the case,
so you are stuck with sRGB and clipping. Perhaps you can ask if they have a
"pro" output workflow option using an output device profile
instead of the "consumer" orientated one based around sRGB.
I must say that for most of the time, I stick with sRGB
from RAW to
print. However, I just want some body to advise me what
should I do in
case there are some highly saturated colors in my
photos where it will
be clipped if I choose sRGB from the ACR.
This is a personal thing for you to decide. You are
best set to test and answer this for yourself. That being said, if I were
you - I would do the following:
* I would find examples in your work of RAW images that
show clipping in sRGB under your normal workflow. Render these out as sRGB
doing your best work as if you had no other option to fall back on. Get the
lab to print these using your standard workflow. This is the baseline to
compare against.
* I would then perform test renders to Adobe RGB, as
well as ProPhoto RGB - using the same images as in the sRGB test. Edit the
wider gamut files using your standard workflow. Compare these two wider
gamut lab output prints to the "baseline" sRGB lab output
examples. Which of the three do you prefer? Is the preference always the
same, or does one colour space handle one certain type of image better than
another (high key, low key, dull colours, saturated colours etc).
* Next I would compare perceptual renders from the RGB
space you prefer from the above tests, to PhotoGamut RGB which is converted
to sRGB for final output. Get the lab to do more standard prints as per the
previous workflow. Compare again.
You may wish to include colour bars and or the original
sRGB test images on the wider gamut prints as a quality control measure to
ensure that the differences are not due to process control issues at the
lab.
Of course, this would have to be repeated half a dozen
times at different time periods to ensure that the lab was consistent and
that you were making evaluations on a non-moving target.
There comes a time when you have to put the theory to
the test, it would appear that you are approaching that point. The proof is
in the pudding, so to speak.
I am sure the list would love to hear of your findings
based from consistent output tests at the lab.
Somebody like Dan, could make the sRGB image fantastic,
better than a lesser user of Photoshop that relied on the profiles to do
the gamut mapping and or compression. The lesser user may get better
results with the wider gamut files, and only taking advantage of the
profiles conversions (whichever profiles and workflow are found to work
best). As one advances, they can make use of both Dan's methods and the
features offered by the profiles.
This is not so different from the old days of scanning
a transparency for SWOP type output, the same sort of decisions come into
play from a wider gamut original to a smaller gamut output. You just have
to decide when is the appropriate time for dealing with the out of gamut
colours, and what is the appropriate method for the image at hand. It would
seem that you have less to worry about than the average CMYK user.
Please accept my apology for the confusion
caused.
I don't think you need to apologise, you are doing
fine!
Sincerely,
Stephen Marsh.
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "colorman042000"
Date: Mon Aug 7, 2006 7:11 am (PDT)
Dear Wai-hong Chung,
I think that Stephen Marsh's expert advice should
answer your question. Your concern about highly saturated colors in
your photos being clipped if you choose "sRGB from the RAW" is a
concern that I also have. My solution so far has been to modify these
colors while in RAW so that they will not be clipped and this is easily
achieved if you choose the sRGB space in RAW.
The added advantage to this workflow is that, once they
are in sRGB, these colors will all fit nicely within your display profile
and you will see them exactly as they are.
Andre Dumas
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Mon Aug 7, 2006 2:33 pm (PDT)
Stephen Marsh carefully wrote :-
Is this correct?<<
Yes !
I'll talk to person in the lab to do the tests
you've subsequently mentioned and will tell you the results but it will
take some time.
Kind regards,
Wai Hong Chung
___________________________________________________________________________
Thread Fragmentation "Color Management Workflow
for RAW files Editin
Posted by: Stephen Marsh
Date: Mon Aug 7, 2006 1:45 am (PDT)
Dear list,
As the "Color Management Workflow for RAW files
Editing" thread is fragmenting into various side topics that no longer
fit the topic title or address the original post, it is probably time to
start to draw a close to this thread under the current topic title.
If you have a reply to the old topic, please alter the
topic title with a reference to the old thread, such as "WAS: CM for
RAW Workflow" or similar and clearly mark the new topic in the title.
Posted message topic titles may be renamed by the
moderation team from this point forward to provide easier naviation within
this topic, if not done by the author.
While I am at it, I would also like to ask all list
members to remember to trim their replies of excessive quotes and to
remember to sign their full name at the end of the message.
Thank you for your help in making this group run
smoother.
Sincerely,
Stephen Marsh
List Moderator
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Stephen Marsh
Date: Tue Aug 8, 2006 4:22 am (PDT)
I hope the lab is interested in this and takes a
partnership approach on this project so that you do not have to pay for the
test prints. But I would not hold my breath. With luck this will not be too
costly.
If they had an output device profile that offered
perceptual rendering, this would likely be a better option than using sRGB.
If the issue concerns you this much, nothing beats live
results.
I personally would base my workflow decisions around
real output, over histogram clipping in ACR. If the output tests show that
important detail and or saturation is being lost with you best efforts in
sRGB, but retained with Adobe RGB or ProPhoto perceptually converted to
PhotoGamut then relcol converted to sRGB - then your wide gamut workflow
choice will be justified and you will have confidence in your choice that a
histogram will never give you. The histogram may be indicative of a real
problem, or not. Others may feel confident in basing their workflow
decisions around only a histogram but I personally would decide on output
tests (that were consistent, so test all colour space workflows at the lab
at the same time).
Best,
Stephen Marsh.
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung
Date: Tue Aug 8, 2006 5:49 am (PDT)
You don't have to worry about the price. Due to
intense competition in Hong Kong, the cost of high quanlity laser printing
4R (4"x6") photo only amounts to US$0.13 per print and we can get
50 photos printed in an hour's time. That's why there is little incentive
for amateur photographers to buy printers because the inks are quite
expensive.
By the way, when you say about printing ProPhoto
RGB photos in the lab, since they assume sRGB, it will result in a false
profile situation. Is this what you intent to find out ?
I still haven't have time to talk to the lab person
because my wife is complaining I spent too much time in photography and I'm
ignoring her! This should become a side issue because I bet I'm not the
only one who received this sort of complain!
Cheers,
Wai Hong Chung
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Andrew Rodney thedigitaldog
Date: Tue Aug 8, 2006 6:09 am (PDT)
On 8/8/06 5:06 AM, "Stephen Marsh"
wrote:
I personally would base my workflow decisions around
real output, over
histogram clipping in ACR.
ACR1s Histogram doesn1t show output clipping per say.
It simply shows you what colors you can and cannot render based on an
encoding color space (of which you have four).
At this stage of the game, the final output (and there
may be many) isn1t really an issue. Do you encode the colors of the scene
or clip them into a smaller encoding color space to even view the image
pixel based (not proxy based as in ACR)?
If the output tests show that important
detail and or saturation is being lost with you best
efforts in sRGB,
but retained with Adobe RGB or ProPhoto perceptually
converted to
PhotoGamut then relcol converted to sRGB - then your
wide gamut
workflow choice will be justified and you will have
confidence
in your choice that a histogram will never give you.
You don1t really have to output the file. Yes, it1s
possible you1ll be quite happy with the output in a smaller (sRGB) working
space compared to a larger space. But you1ve tossed away the colors at this
point and unless you know you1ll never use another output device (something
like the 12 ink Canon being discussed), you1ll have to do a lot of output
testing to be 100% sure you don1t gain anything by encoding in a smaller
working space.
Andrew Rodney
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: Stephen Marsh
Date: Tue Aug 8, 2006 6:13 am (PDT)
Wai-hong Chung wrote:
You don't have to worry about the price. Due to intense
competition
in Hong Kong, the cost of high quanlity laser printing
4R (4"x6")
photo only amounts to US$0.13 per print and we can get
50 photos
printed in an hour's time. That's why there is little
incentive for
amateur photographers to buy printers because the inks
are quite
expensive.
Great, I was not sure of your output method or the
market conditions.
By the way, when you say about printing ProPhoto RGB
photos in the
lab, since they assume sRGB, it will result in a false
profile situation.
No.
Is this what you intent to find out ?
I did not suggest this, nor is this my intent.
Language can be a problem, as I was condensing the
steps into a paragraph. I wrote:
"If the output tests show that important detail
and or saturation is being lost with you best efforts in sRGB, but retained
with Adobe RGB or ProPhoto perceptually converted to PhotoGamut then relcol
converted to sRGB"
The key and valid steps are:
1. sRGB ACR conversion that shows clipping of concern
in an image that may have important detail or gamut in this
colour/tonal area. The lab prints your sRGB image.
2. The same ACR settings, except rendering out to Adobe
RGB and or ProPhoto RGB (also using 16 bpc for ProPhoto).
3. Once in Photoshop proper (not ACR), convert to
profile from A98RGB and PPRGB to PhotoGamut RGB using perceptual intent.
4. Convert to profile, from PhotoGamut RGB to sRGB,
using RelCol intent. The lab prints your sRGB image that was previously
gamut compressed directly after coming out of ACR.
Then compare the output from step 4 to that of step 1.
You may wish to combine the images from step 1, with
the final sRGB images from steps 3 & 4 as a quality control measure
(clealy marked as the clipped sRGB originals). These images should look the
same as the prints from step 1. If they do, then you know that the
differences in the step 3 & 4 images are true and not due to process
control issues at the lab (for 13c a print I would not expect much quality
control).
I hope that my original intent in the testing is now
clear.
Sincerely,
Stephen Marsh.
___________________________________________________________________________
Do it yourself printing vs photo lab printing (was CM
for RAW
Posted by: "MARK SEGAL"
Date: Tue Aug 8, 2006 6:18 am (PDT)
Hi Wai-hong,
At the risk of meandering off-topic again, I
couldn't resist responding to this one. First a serious point and then a
comment on your "side issue".
The serious point is that regardless of how
cheap a commercial lab may be, there is something very satisfying about
having total process control right at one's desk from the start to the end
of the photographic process. Having one's own printer just opens all kinds
of convenient options for experimentation with print sizes, media and
photographic effects that one would find much more of a nuissance
implementing with an outside lab. Despite the flourishing state of the web,
I think most of us would still most value the final result of artistic
photography as being on a piece of paper. Once you own a good photographic
printer, you would be far less bothered by the kind of constraints that you
have struggling with, as seen in this discussion thread. I don't want to
sound as if I'm trying to sell you a printer, but am I making sense?
So, that much said, turning to the "side
issue", there is no bet to be made, because of course you are not the
only one who is the object of spousal complaints. This stuff is EXTREMELY
ADDICTIVE, such that only those who live closest around us see what is
really happening to us and complain about it. Need I say more?
Mark Segal
___________________________________________________________________________
ACR Histogram, Rendering & Encoding (was CM for RAW
Workflow)
Posted by: Stephen Marsh
Date: Tue Aug 8, 2006 6:52 am (PDT)
Andrew Rodney wrote:
ACR1s Histogram doesn1t show output clipping per say.
It simply
shows you what colors you can and cannot render based
on an encoding color
space (of which you have four).
Thanks Andrew, please forgive me if I used a term that
was not totally accurate Andrew, I believe that I was using terms that are
familiar to Wai-hong (English is a crazy language, not to mention tech
jargon, not easy on a second language/casual language user).
Be that as it may, it might be a good time for you to
lay out some real world hands on advice for working with ACR from a larger
gamut original to sRGB - as Wai-hong has been running in circles from your
earlier mentioning of using the histogram in ACR to avoid the issue you
raise above.
At this stage of the game, the final output (and there
may be many)
There is only one of any concern at this point, it is
fed sRGB.
isn1t really an issue.
It is in this case.
This is not "theory".
This is a real person, with real images, a real lab
that only accepts sRGB and real hard copy prints at 13 cents a photo.
Wai-hong would like advice on his specific needs, this member and thus this
thread has suffered enough from the lack of focus and brief explanations.
Do you encode the colors of the scene or clip them into
a
smaller encoding color space to even view the image
pixel based (not
proxy
based as in ACR)?
Damn, that clipping word is hard to shake!
I think that I know what you mean here.
You don1t really have to output the file.
Come on Andrew, are you serious? Please review the
thread.
That is the purpose of the exercise.
Again this is not theory, we are here to try to help a
real person with a specific concern/issue. I know that you are often
speaking to the lurking masses, rather than the original poster, but it
helps to remember that even though you may wish to impart a general
message, it often obscures or cofuses the more specific message that is the
exception for the user at hand.
Yes, it1s possible you1ll be quite
happy with the output in a smaller (sRGB) working space
compared to
a larger space. But you1ve tossed away the colors at
this point and unless
you know you1ll never use another output device
(something like the 12 ink Canon
being discussed), you1ll have to do a lot of output
testing to be 100% sure
you don1t gain anything by encoding in a smaller
working space.
As far as I know, this is not a concern of the original
poster, the lab with sRGB input to their printer is the only concern. I am
sure that this can be factored into the workflow evaluation if it is a
concern for Wai-hong.
Sincerely,
Stephen Marsh.
___________________________________________________________________________
ACR Histogram, Rendering & Encoding (was CM
for RAW Workflow)
Posted by: Andrew Rodney thedigitaldog
Date: Tue Aug 8, 2006 8:05 pm (PDT)
On 8/8/06 7:36 AM, "Stephen Marsh"
wrote:
Be that as it may, it might be a good time for you to
lay out some
real world hands on advice for working with ACR from a
larger gamut
original to sRGB - as Wai-hong has been running in
circles from your
earlier mentioning of using the histogram in ACR to
avoid the issue
you raise above.
I've mentioned before I use ACR to produce the
rendering I wish, then simply view the Histogram while toggling the four
encoding color space options and pick the one that fits best. I don't want
to re-render the RAW just for this one task (if a RAW converter greatly
improves rendering quality and I feel it's worth the time to do so on a
particular important image, OK but that's rare).
If the image fits in ColorMatch RGB, I'll use that. If
the gamut is such that I need ProPhoto RGB, I use that. I always encode in
16-bit.
This is a real person, with real images, a real lab
that only accepts
sRGB and real hard copy prints at 13 cents a photo.
That doesn't change anything really. He needs sRGB for
this lab but might need a much wider gamut file for other output. He can go
from ProPhoto RGB or even ColorMatch RGB to sRGB for the lab while
containing the original color gamut for other uses. The alternative is to
always set ACR for sRGB for this lab. That's fine IF (big if) he never has
any other output needs nor wants to contain color information that was
captured.
Damn, that clipping word is hard to shake!
There's always going to be clipping! We are constantly
trying to fit round pegs in square holes. This discussion of using masks
and such is not making any sense to me. We have very sophisticated means of
mapping out of gamut colors into gamut (which is going to cause clipping).
The question becomes WHEN do you clip? I would submit,
you do it as one of the last step before sending the file to an output
device. That's why I encode in the largest working space from RAW in the
beginning.
Come on Andrew, are you serious? Please review the
thread.
Absolutely. Let's pretend I have ACR and I'm sending
files to sRGB labs. I've done tests and yes, sRGB works lovely for these
test images. I now have 1000 images I've printed and are in sRGB but go out
and buy a new Canon or Epson ink jet and want to reprint the files. They
are all clipped to sRGB. My "tests" going to the output device
months earlier indicated that converting from RAW to sRGB is fine and
dandy. Now when I output the tests again, I'm not too happy with the
saturated colors on my 12 ink Canon.
If I encode in the largest color space the image can
fit from RAW, I can always use that data later. I have absolutely no idea
the gamut of any device that may come out in the future I may use.
This isn't much different from how we handle
resolution. You have the "scan once, use once" mentally and you
have the "scan once, use many" mentally. You can scan to a
specific size but should you need a larger file later, it might have made
more sense to scan at a higher (some would suggest highest) resolution from
the get-go.
You can pay me now or you can pay me later. I'd rather
not have to worry about resolution or color gamut later.
Again this is not theory, we are here to try to
help a real person
with a specific concern/issue.
Encode appropriately and convert as needed just before
print time. You have the most flexibility with the data.
As far as I know, this is not a concern of the original
poster, the
lab with sRGB input to their printer is the only
concern.
If it's not a concern now, it might be in the future.
If he starts with the most data and funnels it down for the lab, the lab
will do fine and he'll have data he might be able to use later. The
alternative offers none of this flexibility or safety.
Andrew Rodney
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "MARK SEGAL"
Date: Tue Aug 8, 2006 8:06 pm (PDT)
Stephen,
Thanks for trying to bring this discussion back
on track in a manner that mere mortals can understand.
Sometimes it is worthwhile reasoning from the
end-game back to the beginning. In this case Wai-hong's end-game is hard
prints using a RelCol sRGB colour space. For this end-game, I see no reason
why he shouldn't convert his RAW files in ACR at sRGB 8-bit mode and
process them in Photoshop soft-proofed - if he can obtain their profile -
to his lab's printer. Suggesting this means one is trusting ACR to do the
best gamut compression mathematically achieveable for any colours in his
original image file that may be out of sRGB gamut. Is this trust
well-placed? If so, seems to me - end of story and very simple - why should
he agonize about anything else? If the trust is not well-placed, it means
that by all these manipulations between colour spaces, somehow or other
Wai-hong will himself be able to improve upon the results of ACR's
mathematics by the time he gets back into sRGB for sending to the lab. What
is the realistic probability of that being the case?
Next one may argue - why assume Wai-hong's lab
is the only end-game forever after? Well, we don't really need to assume
that. But we do need to assume he keeps his raw files stored as raw files.
Remembering - that unless by deliberate acts of destruction - raw files
remain raw files with all their original data either intact or easily
"resettable" to such, if the time comes that he buys a printer
and wants to make 30*40 inch prints from 16 bit ProPhoto versions, all he
needs to do is reconvert the same raw files accordingly.
Bottom line - I think we can help Wai-hong keep
his life very simple with all this, at no cost to the quality of his images
relative to their final destinations now or in the future. Am I making
sense, or are there some deep-dark technicalities that have by-passed me?
Mark Segal
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "colorman042000"
Date: Tue Aug 8, 2006 8:08 pm (PDT)
Hello Stephen,
I have been doing some tests on a workflow that Andrew
mentioned before, working with ACR-ProPhoto, opening the image in Photoshop
then converting to PhotoGamutRGB with perceptual rendering (as an
intermediate step) before finally converting to sRGB. The results on
real-world photos seem to be better than when converting directly from
ProPhoto to sRGB. The display shows a very different picture and the
numbers are also very different. Do you have an opinion on that, and has
anyone tried that?
Andre Dumas
___________________________________________________________________________
ACR Histogram, Rendering & Encoding (was CM for RAW
Workflow)
Posted by: Andrew Rodney thedigitaldog
Date: Wed Aug 9, 2006 5:57 am (PDT)
On 8/8/06 9:59 AM, "MARK SEGAL" wrote:
Sometimes it is worthwhile reasoning from the end-game
back to the beginning.
In this case Wai-hong's end-game is hard prints using a
RelCol sRGB colour
space. For this end-game, I see no reason why he
shouldn't convert his RAW
files in ACR at sRGB 8-bit mode and process them in
Photoshop soft-proofed -
if he can obtain their profile - to his lab's printer.
IF he has a lab output profile, there1s no reason he
has to be concerned with sRGB. He can use the most appropriate working
space as a gamut container for his images and convert to the final output
color space (gamut).
Labs that supply an output profile for their process to
soft proof but don1t want you to use it are kind of clueless and dangerous.
I1ve seen this crop up on other lists and I don1t get it. The lab suggests
the profile defines their output process so its fine for soft proofing but
don1t use it for the conversions (send sRGB). That means the user has no
control over rendering intent, CMM, Black Point Compensation (in ACE) nor
can they edit the numbers based on the output color space. Silly workflow.
Next one may argue - why assume Wai-hong's lab is the
only end-game forever
after? Well, we don't really need to assume that. But
we do need to assume he
keeps his raw files stored as raw files. Remembering -
that unless by
deliberate acts of destruction - raw files remain raw
files with all their
original data either intact or easily
"resettable" to such, if the time comes
that he buys a printer and wants to make 30*40 inch
prints from 16 bit
ProPhoto versions, all he needs to do is reconvert the
same raw files
accordingly.
How much RAW processing do you do? Going back to the
RAW simply to re-encode into a bigger color space (assuming you can save
the original rendering instructions) is a LOT of work. Far more than simply
converting from a wider to a narrower RGB working space for a lab. RAW
processing is work, its time consuming. It1s as if you are suggesting
someone rescan a piece of film instead of resizing it smaller from a larger
original scan. What happens if he does a few hours of editing on the
rendered file?
Andrew Rodney
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Raphael Bustin"
Date: Wed Aug 9, 2006 6:33 am (PDT)
At 06:49 AM 8/9/2006 -0600, Andrew Rodney wrote:
How much RAW processing do you do? Going back to the
RAW simply to re-encode
into a bigger color space (assuming you can save the
original rendering
instructions) is a LOT of work. Far more than simply
converting from a wider
to a narrower RGB working space for a lab. RAW
processing is work, its time
consuming. It1s as if you are suggesting someone rescan
a piece of film
instead of resizing it smaller from a larger original
scan. What happens if
he does a few hours of editing on the rendered file?
A few hours per frame in a RAW image converter? Did I
get that right?
Has ACR or RawShooter replaced Photoshop as the image
editor of choice?
Seriously, the idea that the RAW decode process is
"a LOT of work" (your emphasis) surprises me. It's about
1/100 the effort of film scanning, in my experience.
I agree that for a casual "down-conversion"
(wide space to narrower one) it's seriously overkill to go back to the RAW
scan -- and far more straightforward to let the CMM handle it. But
there's no equivalent "up-conversion" -- for that you'd have to
go back to the RAW.
Raphael Bustin
www.terrapinphoto.com
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Mark Segal"
Date: Wed Aug 9, 2006 1:14 pm (PDT)
Several points on this:
(1) Re-processing a RAW file is generally alot less
painful than re-scanning film. I do both and wouldn't begin to compare
them. Different talk-shows.
(2) Wai-hong doesn't own a printer, doesn't know if
he'll buy one, will continue making new photographs as time goes on, so
what is the hypothetical number of older files he'll re-render sometime in
the unknown future if and when he buys a printer?
(3) If he starts with ProPhoto 16 bit, he'd need to
separately save the processed files in this format before creating another
image according his lab specs (and then handle the resulting image editing
most likely required on that one, which also consumes time); this would be
fine depending on how much storage he wants to buy and the answer to #2.
But in principle IF the answer to #2 is "many files", I would
agree with you that starting big and down-sizing is most likely in
aggregate to be less onerous than what I suggested.
Mark Segal
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Wai-hong Chung"
Date: Wed Aug 9, 2006 5:56 am (PDT)
Hello Stephen Marsh,
I've talked to the person in the lab. He gave me
an ICC profile of his minilab and he said its a working space profile. I
asked him whether this profile is matrix-based or table-based but he said
he don't know. He said this is the last ICC profile used by his minilab
before printing.
I then tested this profile by toggling between
perceptual and RelCol in the Convert to Profile dialog box and I found that
it has response to perceptual intent (i.e. the brilliant green (G=255) in
my test file changed color during the toggling).
I've sent this profile separately to your
personal email account as an attachment. I would be grateful if you would
check whether it is table-based. Also, can you check the gamut width of
this profile ? Most grateful if you could help because I don't know how to
check ICC profiles.
Best regards,
Wai Hong Chung
___________________________________________________________________________
. Frontier mini-lab profile
Posted by: Stephen Marsh
Date: Wed Aug 9, 2006 6:48 am (PDT)
Wai-hong Chung wrote:
Hello Stephen Marsh,
Hello again Wai-hong,
I've talked to the person in the lab. He gave me
an ICC profile of
his minilab and he said its a working space profile.
Technically, it is an output profile, but just as SWOP
CMYK is an output profile - it is also a working space profile. It is both
at the same time, or not. Anyway...
I asked him whether this profile is matrix-based or
table-based but
he said he don't know. He said this is the last ICC
profile used by
his minilab before printing.
You are fortunate that he knows what an ICC profile is
and where to find it to give to you. It is my guess that they have a system
set with no human control that simply assumes sRGB as the source, with the
Frontier profile as the destination with the intent set to perceptual.
If you wish to make the conversions yourself (change
sRGB or other wider gamut spaces RGB numbers into Frontier RGB numbers) -
then the lab has to handle your files differently with no conversions and
simply send the numbers down the print pipeline.
I've sent this profile separately to your
personal email account
as an attachment. I would be grateful if you would
check whether it is
table-based.
It is table based.
Also, can you check the gamut width of this profile ?
Most grateful
if you could help because I don't know how to check ICC
profiles.
There are two ways to "check" profiles. With
Photoshop (either with conversions or assigning and info palette viewing).
Another way is to use the curvemeister.com Photoshop
action gamut plots.
More commin is with third party ICC profile software.
Unlike some on this list, I am not into colour
management in a big way.
I don't have access to many tools or software for ICC
profiles.
Using the MS XP Color applet, I can view and compare
sRGB to the Frontier profile in 3D (like a poor man's ColorThink).
I also have couple of less visual 2D profile inspection
tools*.
The Frontier profile mostly fits well inside sRGB
without wasting too much space on colours that are outside of the Frontier.
Both profiles contain areas that are out of gamut when compared to each
other. There is no perfect match, but sRGB does not seem like a poor choice
given that the ouput is mostly smaller in gamut than sRGB.
In the recent post by Sterling, there was mention of a
website. One page on that site has a gamut plot/projection of a Frontier
profile compared to sRGB and Adobe RGB (three luminance slices in 2D).
http:
//www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm
*(it is amazing the eye candy value of 3D gamut plots -
oops looks like I am a colour geek [I hope I don't have to pay royalties to
Bruce Fraser] ).
Regards,
Stephen Marsh.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "David Riecks"
Date: Wed Aug 9, 2006 4:17 pm (PDT)
At 08:11 AM 8/9/2006, Raphael Bustin wrote:
A few hours per frame in a RAW image converter?
Did I get that right?
Raphael:
That's not my take. In the post you are referring to,
the writer said, "What happens if he does a few hours of editing on
the rendered file?" I assumed "rendered" meant it had
already gone through the RAW converter, and they were tweaking the file
with layer adjustments, global and local contrast adjustments, spotting,
and other forms of retouching. It's not uncommon at all to use the RAW
converter to get the base file and then go from there. If you first
exported to a smaller color gamut and need to go to a larger one, there are
consequences either way you go.
Has ACR or RawShooter replaced Photoshop as the
image editor of choice?
ACR is a RAW converter, it's not an image editor in the
same way that Photoshop is. I've only used RawShooter a few times and only
for the RAW conversion so I'm not sure if it has other pixel tweaking
capabilities. Pixmatec (the parent company of RAW shooter) was acquired by
Adobe a month or two ago, with the rumor that it was going to be integrated
into LightRoom.
Seriously, the idea that the RAW decode process is
"a LOT of work" (your emphasis) surprises me.
It's
about 1/100 the effort of film scanning, in my
experience.
It's certainly less effort than film scanning, however
it's not exactly an "easy" process, as there are many, many
switches and sliders that can be used, all of which affect the final output
of the image. IMHO it's no harder work that learning photoshop, but let's
face it... there are a lot of people that consider Photoshop to be hard
work as well.
But there's no equivalent "up-conversion" --
for that you'd have to go back to the RAW.
In a perfect world, sure. In the "real" world
where clients are paying for your time and need it yesterday it's certainly
a judgement call. If you have the time, and can convince the client it's
better to go back to the RAW, plus redo all your retouching, AND get them
to pay you for this...more power to you.
David
----
David Riecks (that's "i" before
"e", but the "e" is silent)
http://www.riecks.com , Chicago Midwest ASMP member
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Matthew Rigdon"
Date: Wed Aug 9, 2006 4:27 pm (PDT)
If you don't do hours of editing on every photo,
though, it's not a big deal. It obviously depends on what you shoot and how
you use it. Nature scenes, landscapes, still life, shouldn't require a lot
of editing if setup right, just adjustments for exposure or color, things
to make the image pop and fit whatever artistic vision you see.
The argument for going back and redoing work is that
your technique improves over time. Mr. Chong didn't say how advanced a user
he is, but I would imagine he's closer to the front end of this learning
curve than the end, so if he has an image that he wants redone in a few
years, he may get a much better result by starting over. I know that I'd
probably choose to redo an image from scratch anyway, as I keep adding to
my knowledge and add new techniques over time that may be more appropriate.
I guess some of it has to do with workflow, too. I
imagine some of these issues will recede when tools like Lightroom and
Aperture mature as you'll be able to transplant image adjustments from file
to file, just tweaking for gamut but not having to redo all your
sharpening, color balancing, etc, from scratch.
Matthew Rigdon
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Ric Cohn"
Date: Wed Aug 9, 2006 4:33 pm (PDT)
I feel safe in saying that Andrew was talking about the
time spent on the file AFTER it was converted in ACR.
Ric Cohn
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was
CM for RAW Workflow)
Posted by: "J Walton"
Date: Wed Aug 9, 2006 4:33 pm (PDT)
On 8/9/06, Raphael Bustin wrote:
A few hours per frame in a RAW image converter?
Did I get that right?
Umm...no. Andrew wasn't saying that it will take a few
hours to convert RAW. He was supposing that after converting to sRGB there
are further edits to the image. Balancing highlight, removing
imperfections, correcting colors – I don't think that's unrealistic
at all. For my images there tend to be many hours of corrections after
image capture.
To suggest that you can always go back to the RAW and
it's only a few minutes requires that NOTHING is done to the file after
conversion. Is that really a rational strategy?
J Walton
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was
CM for RAW Workflow)
Posted by: Andre Dumas
Date: Wed Aug 9, 2006 6:39 pm (PDT)
Hello Andrew,
I use ProPhoto and Adobe RGB as a destination color
space for most of my images because I seldom convert to sRGB, but
when I must and when the image warrants it, then I will go back to the
original RAW and re-edit the image in the sRGB color space.
Do you agree that sometimes one can get better sRGB
images when editing the RAW image in the destination color space of sRGB ?
And compared to this workflow,do you agree that converting a
"Prophoto-
from-RAW" image to sRGB as a last step before
sending the file to an output device may yield an inferior image ?
I ask because (taking into account my "just
average" level of expertise) I have found this to be true when dealing
with images that I wish to output at their maximum brilliance and
saturation like red petunias for instance.
Andre Dumas
___________________________________________________________________________
ACR Histogram, Rendering & Encoding (was CM for RAW
Workflow)
Posted by: Andrew Rodney thedigitaldog
Date: Wed Aug 9, 2006 6:39 pm (PDT)
On 8/9/06 7:11 AM, "Raphael Bustin"
wrote:
A few hours per frame in a RAW image converter?
Did I get that right?
You did not. It could be 20 minutes or less in the
converter and then a hour later in Photoshop from that rendered file (or
several hours). The RAW conversion can be a fast beginning to hours of
work, even days that you don1t want to redo just because you were careless
in the working space encoding.
Has ACR or RawShooter replaced Photoshop as the
image editor of choice?
Yes in many ways. If you are not shooting and editing
RAWs, this may come as a shock. This is why Aperture, Lightroom and a slew
of other products for handling RAW files are on the market.
While most of my images need a trip from RAW converter
to Photoshop, Aperture and Lightroom are pushing the needs to be less and
less so since they function from end to end of a task (conversion to final
output to print).
Look at the myriad of rendering differences a group has
produced from a single RAW file:
http:
//www.openphotographyforums.com/forums/showthread.php?t=637
Photoshop is a pixel editor for rendered images. RAW
converters are used to build rendering instructions and don1t produce
pixels until the final OK button is pressed. There1s a HUGE difference in
both the workflow and the capabilities. Photoshop is a 3one image at a
time2 pixel polisher. RAW converters are completely different.
Seriously, the idea that the RAW decode process is
"a LOT of work" (your emphasis) surprises me.
It's
about 1/100 the effort of film scanning, in my
experience.
It CAN process a lot of work yes. Once you know the
rendering instructions for every image. If you have 300 identical images,
its very fast. But you have to decide how to render the image first.
I agree that for a casual "down-conversion"
(wide space
to narrower one) it's seriously overkill to go back to
the
RAW scan -- and far more straightforward to let the
CMM handle it. But there's no equivalent
"up-conversion" --
for that you'd have to go back to the RAW.
Exactly so why start with limited data?
If you can render a 12 megapixel RAW and the lab only
needs 6, get all the data, resize for the lab and leave the RAW converter
alone.
Andrew Rodney
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was
CM for RAW Workflow)
Posted by: "Henry"
Date: Wed Aug 9, 2006 6:39 pm (PDT)
On Aug 9, 2006, at 8:49 AM, Andrew Rodney wrote:
Labs that supply an output profile for their
process to soft proof but don1t
want you to use it are kind of clueless and
dangerous. I1ve seen this crop
up on other lists and I don1t get it. The lab
suggests the profile defines
their output process so its fine for soft proofing but
don1t use it for the
conversions (send sRGB). That means the user has no
control over rendering
intent, CMM, Black Point Compensation (in ACE) nor can
they edit the numbers
based on the output color space. Silly workflow.
I don't understand what you meant by the "clueless
and dangerous" bit. This sounds counter to the notion that
soft-proofing is worthwhile.
Also, when one is soft-proofing, how is editing by the
numbers meaningful? Aren't the numbers only meaningful within the
context of that particular output device, and as such are not the kind of
numbers that would hold much understandable meaning for traditional color
correction - by the numbers?
Thanks,
Henry Davis
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was
CM for RAW Workflow)
Posted by: Mark Segal
Date: Wed Aug 9, 2006 6:39 pm (PDT)
I think it is important, when giving colleagues
requested advice, to think of these issues not only in respect to theory -
which is valid in its own right and therefore necessary, but not sufficient
- but also advise in relation to practicalities. Very often, contrary to
the indications of theory alone, we find it beneficial to do things based
on judgments about practicality that depend as much on probabilities and
future uncertainties as they do on present theory. That is the mindset from
which I asked what would be wrong with the fairly simple and direct
approach to Wai-hong's workflow issue that I laid out in my previous post.
I can amplify best from my own experience. Back in
1999/2000 before I owned a digital camera I photographed with colour
negative film, scanned the negatives in a 2400 DPI scanner, processed the
files in Photoshop 6 and printed the results on an Epson 2000P. Save for
the scanner (I could have bought a drum scanner for umpteen thousand
dollars I suppose) that was all reasonably "state-of-the-art: stuff
only 6 years ago. Of course I still have all those prints as well as the
original negatives, and I have the scanned digital files saved on CD ROMs.
When I compare those prints with what I am producing
now be it from film or digital capture (because I have alot of recent
material from both), there is, quite simply, no comparison. Night and
day.Technology has grown, I've up-graded alot, my skills have grown with
the new technology, etc. Meanwhile, I keep creating new stuff all the time.
So what will happen with all those images from "the turn of the
century"? IF time ever permits, I'll go back to them, make a small
selection of the cream of the crop AND START FROM SCRATCH - rescan,
re-process, re-print - because that is the only way to take full advantage
of the quantum leap in technical potential throughout the workflow chain
that has occured just over the past several years. And I am willing to bet
if I came back to this website 5 years from now on the same topic I would
be saying the same things in relation to today's work.
Moral of the story: let us not get too hung-up on
theoretical propositions about insurance policies against the drudgery of
future workflow. Too much changes in life - often very quickly - to be so
sure that one set of practices is necessarily more efficient and effective
than another in all circumstances and for all time.
Mark Segal
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Raphael Bustin"
Date: Wed Aug 9, 2006 8:51 pm (PDT)
Someone please correct me if I'm wrong but isn't a
working space presumed to be "perceptually neutral?" Ie., black,
gray and white should all have equal values of R, G and B.
All I can say is that I've been working under that
general assumption since day one -- regardless of whether I was working in
an "ICC-color-managed" environment or not.
Raphael Bustin
www.terrapinphoto.com
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Andrew Rodney thedigitaldog
Date: Thu Aug 10, 2006 9:07 am (PDT)
On 8/9/06 12:02 PM, "colorman042000"
wrote:
Do you agree that sometimes one can get better sRGB
images when
editing the RAW image in the destination color space of
sRGB ?
IF the output is to an sRGB device (a CRT display) yes.
You can do that in ACR (the output is right in front of you). Be the only
sRGB output device is a display in a calibrated state which behaves as the
sRGB specification outlines (down to the ambient light conditions around
the display).
And compared to this workflow,do you agree that
converting a "Prophoto-
from-RAW" image to sRGB as a last step before
sending the file to an
output device may yield an inferior image ?
No I don1t, I1ve never seen that to be the case.
I don't understand what you meant by the "clueless
and dangerous" bit.
This sounds counter to the notion that soft-proofing is
worthwhile.
Because the device in this example (some printer)
doesn1t produce sRGB. So you1re not soft proofing for it but rather using
some profile that isn1t being used to convert the final numbers. And you
the user should have the control over this conversion to output color space
using the profile that indeed produces the optimal numbers that will be
sent to the output device.
Andrew Rodney
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Stephen Marsh
Date: Fri Aug 11, 2006 6:39 am (PDT)
Andre Dumas wrote:
Hello Stephen,
I have been doing some tests on a workflow that Andrew
mentioned
before, working with ACR-ProPhoto, opening the image in
Photoshop
then converting to PhotoGamutRGB with perceptual
rendering (as an
intermediate step) before finally converting to sRGB.
Ah, but how does PhotoGamut compare to sRGB in
size/shape?
The conversion to sRGB would be RelCol, would it not?
The results on
real-world photos seem to be better than when
converting directly
from ProPhoto to sRGB.
This does not seem a surprise, if the original had
enough wider gamut colours in important areas - it makes sense in theory to
me. However, going from PhotoGamut RGB to the output profile without ever
seeing sRGB would be ideal.
But not everybody is in an ideal situation, so they may
have to use sRGB to supply the files to the lab for them to do the final
conversion.
The display shows a very different picture and
the numbers are also very different. Do you have an
opinion on that,
and has anyone tried that?
Sure I have an opinion, but if you are looking for
controversy or earth shattering revelation, then you will be disappointed.
Sincerely,
Stephen Marsh.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Stephen Marsh
Date: Fri Aug 11, 2006 6:41 am (PDT)
Mark Segal wrote:
Sometimes it is worthwhile reasoning from the end-game
back to the
beginning. In this case Wai-hong's end-game is hard
prints using a
RelCol sRGB colour space. For this end-game, I see no
reason why he
shouldn't convert his RAW files in ACR at sRGB 8-bit
mode and process
them in Photoshop soft-proofed - if he can obtain their
profile - to
his lab's printer.
The majority of these shots fit well in sRGB and sRGB
is the destination space (before a conversion takes place to the output
device).
The output profile seems to have been obtained, so
perhaps we will hear how things go, for both regular images and ones which
have a wider gamut.
Suggesting this means one is trusting ACR to do the
best gamut
compression mathematically achieveable for any colours
in his original
image file that may be out of sRGB gamut.
I hate to nit pick, and only do so becuase it is
important - but did you really mean to use the term gamut compression when
talking of rendering from RAW to a flavour of RGB in ACR?
Is this trust well-placed? If so, seems to me - end of
story and
very simple - why should he agonize about anything
else? If the trust
is not well-placed, it means that by all these
manipulations between
colour spaces, somehow or other Wai-hong will himself
be able to
improve upon the results of ACR's mathematics by the
time he gets back
into sRGB for sending to the lab. What is the realistic
probability of
that being the case?
The output space is smaller than sRGB, sRGB has wider
gamut blues and sRGB is infamous for having problems with blue.
In the old workflow that sparked this thread, even when
using PhotoGamut RGB and perceptual, the final delivery move to sRGB would
still clip and who knows what the final device conversion does?
Now that the output profile has been obtained, perhaps
the above question will be answered.
Next one may argue - why assume Wai-hong's lab is
the only
end-game forever after? Well, we don't really need to
assume that. But
we do need to assume he keeps his raw files stored as
raw files.
Remembering - that unless by deliberate acts of
destruction - raw
files remain raw files with all their original data
either intact or
easily "resettable" to such, if the time
comes that he buys a printer
and wants to make 30*40 inch prints from 16 bit
ProPhoto versions, all
he needs to do is reconvert the same raw files
accordingly.
Very true, and the majority of the renders are fine in
sRGB. It is only less rare images that are a concern for Wai-hong. So it is
a small percentage that is being spoken of here.
Bottom line - I think we can help Wai-hong keep
his life very
simple with all this, at no cost to the quality of his
images relative
to their final destinations now or in the future. Am I
making sense,
or are there some deep-dark technicalities that have
by-passed me?
Complete sense Mark, I think all the technicalities
have been discussed for now, perhaps there will be new ones when Wai-hong
kicks things around for a bit.
Regards,
Stephen Marsh.
___________________________________________________________________________
ACR Histogram, Rendering & Encoding (was CM for RAW
Workflow)
Posted by: Mark Segal
Date: Fri Aug 11, 2006 3:31 pm (PDT)
Stephen,
Please explain the importance, if relevant after the
following clarification. What I was getting at, whether the term
"gamut compression" is correct or not, is that when making a
conversion from RAW to any particular flavour of RGB, the resulting
conversion will have less gamut in sRGB than in ARGB98 than in ProPhoto.
Mark Segal
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Larry Wangelin"
Date: Fri Aug 11, 2006 3:31 pm (PDT)
Stephen,
I think that one technicalities that could be lurking
in the shadows is the drift of the output device. Getting repeatable
results over time is going to be a crap shoot from tests I have been doing
checking results with a single file over time with five different labs
there are going to be changes in output from one day to the other. Some
days not very bad IMHO, sometimes it is remarkable how much change there
is. Labs that I am using have systems that say their printers allow NO
CORRECTION. I have found that if you don't bring the image in to their
store at some labs that your online instructions are not honored all of the
time. Go figure.
Larry Wangelin
________________________________________________________________________
6e. Re: ACR Histogram, Rendering & Encoding (was CM
for RAW Workflow)
Posted by: Andre Dumas
Date: Fri Aug 11, 2006 3:32 pm (PDT)
Thanks Stephen,
You may recall that Wai Hong Chung mentioned that type
of workflow following Andrew's suggestion but nobody commented on the
subject.
As far as I can see, PhotoGamut has a larger footprint
but it looks like sRGB does better with bright, unsaturated blues and
purples. The trip through PhotoGamut seems *at first sight*, to be
advantageous for images with a lot of red and yellow and I would like to
know if someone has experience with that workflow. Who knows? There
might be drawbacks that are not obvious to less experience persons like me.
That, not controversy, was the purpose of my question
...!
Andre Dumas
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Stephen Marsh
Date: Fri Aug 11, 2006 4:58 pm (PDT)
Mark Segal wrote:
Stephen,
Please explain the importance, if relevant after the
following
clarification. What I was getting at, whether the term
"gamut
compression" is correct or not, is that when
making a conversion from
RAW to any particular flavour of RGB, the resulting
conversion will
have less gamut in sRGB than in ARGB98 than in
ProPhoto.
As has been demonstrated in this thread, gamut
compression is a big thing for some images (if not plate blending or doing
other tricks in sRGB to provide detail) and not all profiles have it, and
when they do one never knows how the 'secret sauce' is applied until it is
tested.
Very quickly and simply put - two different but out of
gamut colour values in the original are converted using RelCol and one flat
area of colour results. With perceptual gamut compression, the final
conversion still has two distinctly different colours.
It is an important technical difference in how the OoG
colours are rendered which I am attempting to establish, does ACR behave
like ICC profiles using perceptual when mapping the wider gamut colour to a
smaller space, or does it simply clip the OoG colour.
As I said, it is nit picking the use of the term.
I am not disagreeing with you that a larger colour
gamut space can contain colours that a smaller can't.
Best,
Stephen Marsh.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Stephen Marsh
Date: Fri Aug 11, 2006 4:58 pm (PDT)
Larry Wangelin wrote:
Stephen,
I think that one technicalities that could be lurking
in the shadows is
the drift of the output device. Getting repeatable
results over time is
going to be a crap shoot from tests I have been doing
checking results
with a single file over time with five different labs
there are going
to be changes in output from one day to the other. Some
days not very
bad IMHO, sometimes it is remarkable how much change
there is. Labs
that I am using have systems that say their printers
allow NO
CORRECTION. I have found that if you don't bring the
image in to their
store at some labs that your online instructions are
not honored all of
the time. Go figure.
Very true Larry.
In my previous post/s - I did note that one should
probably inlcude the baseline test image to compare against the other
conversion methods and workflows (if not colour bars etc).
This is a concern, when making evaluations to base
future workflows on.
Stephen Marsh.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Mark Segal
Date: Fri Aug 11, 2006 11:35 pm (PDT)
Stephen,
OK - I see, but you're making a point that I think goes
beyond nit-picking -- this is an operational matter that perhaps makes a
difference to results. Maybe only the author of ACR knows for sure - or
perhaps one can learn what's happening by experimentation. I don't know the
answer to it. That said, I would be surprised if ACR simply clipped OoG
colours - it has to be more sophisticated than that!
Mark Segal
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "john
castronovo"
Date: Sun Aug 13, 2006 8:29 pm (PDT)
From: "Larry Wangelin"
I think that one technicalities that could be lurking
in the shadows is
the drift of the output device. Getting repeatable
results over time is
going to be a crap shoot from tests I have been doing
checking results
with a single file over time with five different labs
there are going
to be changes in output from one day to the other. Some
days not very
bad IMHO, sometimes it is remarkable how much change
there is. Labs
that I am using have systems that say their printers
allow NO
CORRECTION. I have found that if you don't bring the
image in to their
store at some labs that your online instructions are
not honored all of
the time. Go figure.
All true. Getting technicians and equipment to turn off
all corrections so that a profiled image isn't altered on output is a far
bigger challenge than people imagine and that's often ignored in these
discussions.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Stephen Marsh
Date: Mon Aug 14, 2006 3:57 am (PDT)
Mark Segal wrote:
Stephen,
OK - I see, but you're making a point that I think goes
beyond
nit-picking - this is an operational matter that
perhaps makes a
difference to results.
This is why I brought it up Mark. I meant that I hate
to nit-pick two of your words, but I had to in an effort to establish the
true meaning.
Maybe only the author of ACR knows for sure - or
perhaps one can
learn what's happening by experimentation.
On the first agreed, on the second, I agree again I
will add this to my "to do list". Don't wait up for an answer,
there are a few jobs booked in ahead.
I don't know the answer to it. That said, I would be
surprised if
ACR simply clipped OoG colours - it has to be more
sophisticated than
that!
Hmmm, what about the ACR histogram and sRGB? Wai-hong's
parrots seemed to suffer from clipping going from RAW to sRGB, if I am not
mistaken.
Being mostly into print design and prepress, I don't
have the chance to play with RAW conversions very often (except my own very
rare shots). I don't know enough about camera raw conversions and ACR to
answer.
It would be nice to know, I am sure somebody out there
can tell us in words and point us to a Camera Raw image and workflow that
verifies this point, we have so many camera raw users and industry experts
that always comment on ACR, why the silence now?
Best,
Stephen Marsh.
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Dan Margulis
Date: Mon Aug 14, 2006 7:20 am (PDT)
Stephen writes,
t would be nice to know, I am sure somebody out there
can tell us in
words and point us to a Camera Raw image and workflow
that verifies
this point, we have so many camera raw users and
industry experts that
always comment on ACR, why the silence now?
Well, because it's so obvious that you should use
Camera Raw whenever possible that it is not necessary to run any tests, so
they don't know.
In my tests for my chapter on raw acquisition, I
checked three images with strong reds and yellows that were well out of the
sRGB gamut. In each, I acquired using the same settings in Camera Raw, one
file each in sRGB and ProPhoto RGB. Then I made two more variants in
Photoshop by converting the ProPhoto version to sRGB and the sRGB version
to ProPhoto, always without dither.
My results are that the Camera Raw>sRGB and the
Camera Raw>ProPhoto>sRGB versions are pixel-for-pixel identical in
two cases and vary insignificantly in a third. The Camera Raw>ProPhoto
and Camera Raw>sRGB>ProPhoto versions are different, as expected.
Since I often use the ProPhoto channels for blending,
if I see that there is a problem with detail in brilliant colors, I acquire
in ProPhoto, convert a copy to my working space, apply the blend, and ditch
the ProPhoto version.
Dan Margulis
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Mark Segal
Date: Mon Aug 14, 2006 7:59 am (PDT)
Dan, this is most interesting.....
and also a bit surprising, as you have in the past
argued strongly against the need for using colour spaces as vast as
ProPhoto. I must admit that I'm puzzled and intrigued at the same time.
Anyhow, that aside, what I really want to ask you about
this... when you acquire in ProPhoto and convert to your working space what
rendering intent do you use, or do you vary it to suit the image?
Mark Segal
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was
CM for RAW Workflow)
Posted by: "Ric Cohn"
Date: Mon Aug 14, 2006 11:47 am (PDT)
On Aug 14, 2006, at 10:33 AM, Mark Segal wrote:
Dan, this is most interesting.....
and also a bit surprising, as you have in the past
argued strongly
against the need for using colour spaces as vast as
ProPhoto. I
must admit that I'm puzzled and intrigued at the same
time.
Actually Mark, I remember some months ago I mentioned
the possibility of using ProPhoto channels for blending and I believe Dan's
response made it clear he thought this was a fairly obvious use. Just
another example of how one person's epiphany is another person's ho-hum.
Ric Cohn
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: Andre Dumas
Date: Mon Aug 14, 2006 2:03 pm (PDT)
Hello Dan,
Another aspect to consider: when in Camera RAW (if I
know that a photo will be outputted directly to sRGB without further work)
I have found that if I optimizes a photo with strong reds specifically for
the sRGB space, that photo will often end up better than if it had been
*optimized for the ProPhoto space* and converted later on to sRGB.
But, like others have mentioned, if I'm going to spend
a lot of time on a photo then I am sure it's better to work on a Camera
RAW>ProPhoto version and convert later on to sRGB if that's what's
needed.
Could this be a valid point or am I just deceiving
myself.
Andre Dumas
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Dan Margulis" j
Date: Mon Aug 14, 2006 4:47 pm (PDT)
Mark Segal writes,
Dan, this is most interesting.....and also a bit
surprising, as you have
in the past argued strongly against the need for using
colour spaces as vast as ProPhoto. I must admit that I'm puzzled and
intrigued at the same time.
No, I have argued against *correcting* in ultra-wide
RGB spaces like ProPhoto. Here, I'm just using it to feed the real
correction, which is taking place elsewhere.
In my books, I show assigning a false profile of Wide
Gamut RGB primaries with a gamma of .8, and also a false separation where
the black ink limit is set to 70% maximum. That doesn't mean that I
advocate *correcting* in .8 gamma colorspace or one with pathetically
limited black ink. It just means that I have a temporary copy in one of
these spaces, usually as the source for a channel blend.
In the next edition of Professional Photoshop, I have a
file that came in as a JPEG, no raw file available, where there was a big
area of bright purple with little detail. I made a copy, made a false
conversion to ProPhoto, and used one of the resulting channels to blend
detail back into the original.
Dan Margulis
___________________________________________________________________________
Re: ACR Histogram, Rendering & Encoding (was CM for
RAW Workflow)
Posted by: "Dan Margulis" j
Date: Tue Aug 15, 2006 7:32 am (PDT)
Andre writes,
But, like others have mentioned, if I'm going to spend
a lot of time
on a photo then I am sure it's better to work on a
Camera
RAW>ProPhoto version and convert later on to sRGB if
that's what's
needed. Could this be a valid point or am I just
deceiving myself.??
From my testing, the latter. If there were a way to
acquire into LAB, or into CMYK, in certain cases that might be the way to
go, because these spaces have advantages over RGB in some corrections. But
one RGB has the same strengths and weaknesses as another--you're better off
correcting in the one with the narrower gamut.
As to whether it might be sensible to acquire into
ColorMatch or Adobe RGB, correct there and then go to sRGB, I haven't seen
an example and doubt that one exists. With respect to ProPhoto, I have an
example that some theoretician is using to "prove" that Adobe RGB
is not adequately wide. Since there are no real images that would
demonstrate this, he resorts to sabotage: he has a raw capture of a red car
with the hood open. In Camera Raw, he jacks up the red saturation so far
that not only does the car itself become a blob, the darker area *inside
the hood* goes far out of gamut for any known printing condition.
It seemed to me irrelevant whether ProPhoto or Adobe
RGB should be the capture space, since nobody in the real world would ever
sabotage an image in this way, However, as an exercise, assuming that one
had no choice but to open in that way, I tried acquiring and correcting the
image both in ProPhoto and in sRGB. My conclusion was that it made no
difference to ultimate quality or to the time spent doing the work. As a
matter of convenience only, I would acquire in ProPhoto, and convert a copy
to sRGB so as to retain a ProPhoto copy for blending purposes. But this is
not a necessary step.
Dan Margulis
___________________________________________________________________________
ACR and "secret math"...
Posted by: "Richard Chang"
Date: Mon Aug 21, 2006 1:16 pm (PDT)
In response to Don Shaefer's post:
Now that we're deep into this discussion, I have a
further question.
Aren't most camera manufacturers keeping key
information about their
sensor "mathematics" proprietary, so that
Adobe engineers are mostly
guessing about what's the best
"interpretation" for each
manufacturer's chips?
I don't buy this notion, and I don't believe it can
stand up to scrutiny.
The reason why, is the Bayer pattern, which is used to
distill color information from the filtered luminance. The Bayer
pattern isn't secret sauce, it's a known factor. Yes, there are
different ways to interpolate the implied color data and turn it into RGB
channels, but each camera maker's result is just that, a version of how
that manufactures thinks the color and the shape of the picture should
look. Choose the look you like by choosing the application that makes
what you like to look at.
To suggest that a manufacture is trying to keep sensor
math proprietary, in my opinion, is nonsense. Each maker sends data
through the analog-to-digital converter and stacks that data into a RAW
file, which is now, for better or worse, an Adobe .dng specification.
Nikon or Canon, ACR or CaptureOne, has access to the same RAW data.
The jpg out of the camera gets the same data too, it's developed on
the fly and its attributes are determined by the camera maker.
While some RAW formats don't allow access to a third
party developing, those that do allow developing, must be able look at the
RAW data in order to develop the image. The difference in the
developed files from these applications is evident in each maker's opinion
on how best to develop the image. One RAW app may favor low noise,
another may like smoother edges at the cost of adjacent contrast along
those edges, and a third may like a specific sharpening. Good apps
allow you to turn functionality on and off, you should get to decide.
Post processing of RAW data is not insignificant, it's
applied mathematics of high intellectual value and it's a top priority for
any developer of RAW files. It's also the vehicle to better pictures
in the future, especially in concert with CMOS' ability to report info from
each sensor site.
so that Adobe engineers are mostly guessing ...
Adobe's guessing is just that; guessing. At
MegaVision we're guessing too and we've decided on what attributes our
images want to contain, and which attributes we think are worth
compromising. I'm sure that all companies who develop RAW have things
they'd like to add, and others they'd like to try. The marketing of
these RAW factories is tugging at your wallet, to get your money. The
notion that the Adobe engineers are somehow being "held back" by
camera makers is laughable to me (our RAW files are .dng's, having just
done the dance with Adobe). With Adobe's budget, I expect their
products to be pretty darned good and if I were going to complain about
Adobe's RAW efforts I'd complain about the lack of a luminance report in
the ACR dialog box instead of a lack of access to "secret math".
The idea that any third party can develop a better
image than the maker of the camera is also somewhat amusing; similar to the
idea that a third party automobile product is better than the manufacture's
specification. There is of course, cheaper, and there is better; you
shouldn't confuse the two, regardless of who's doing the marketing or
complaining.
There's nothing stopping the trumpeting of "we're
better" in the photo sector in the search for market share. And
let's not forget that getting RAW data should allow you to decide what
attributes the "digital emulsion" developing should include.
Your craft of the developing is what's important here, not Adobe's
lack of access to secret math.
Richard Chang
MegaVision, Inc.
PS If Adobe is truly "held back", they
ought to consider jumping into the fray and develop their own camera; no
more excuses, and that way they can "hold back" info to other
companies :-).
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Iliah Borg"
Date: Mon Aug 21, 2006 3:09 pm (PDT)
Dear Richard,
The idea that any third party can develop a better
image than the
maker of the camera is also somewhat amusing
So you claim that maker of the camera uses the best
demosaicing algorithm possible; and best possible colour transform? They
also know the best possible way to address noise, do they?
Best regards,
Iliah Borg
___________________________________________________________________________
ACR and "secret math"...
Posted by: "Richard Chang"
Date: Mon Aug 21, 2006 4:37 pm (PDT)
Regarding Iliah's comment:
So you claim that maker of the camera uses the best
demosaicing
algorithm possible; and best possible colour transform?
They also
know the best possible way to address noise, do they?
Any RAW converter choosing to develop a RAW file gets
to choose how they will distill the hi-bit information in the RAW file.
Linear data stores any pixel's data count for any pixel from 0 to
4095 (12 bpc). Only the camera maker gets to decide how to quantize
the electron counts into that RAW file. Developing a linear RAW file
redistributes the data according to the desires of the user, with the tools
allowed by the converter application.
Each application maker's opinion of what the developed
image should look like, embodies in the development; density range,
ISO/exposure, and chrominance handling. Some applications use a
rendering intent and some embed display profiles. The application
maker gets to choose what attributes are important to their notion of what
a picture ought to look like and what they think the user is competent to
wiggle.
Best is relative of course, depending on the user's
notion of what is best. Where I might think that local contrast is of
the highest order, another user might think that subduing low valued noise
with the toe of an "S"curve, is best. Since we have
different ideas of what's best, there probably isn't a consensus on what's
best.
Some folks on this list think Capture One is best and
others like ACR. Apple's Aperture was marketed as a superior
converter at one point in time. If you asked any of the company reps
involved with these apps, which was best, I think we could predict the
responses, and you may not have agreed with them.
I know that I like our Photoshoot's developing and I'm
sure that the Phase people think their handling of developing is of a high
order. Is ACR better? You get to decide with your wallet.
Richard Chang
___________________________________________________________________________
1a. Re: ACR and "secret math"...
Posted by: "Iliah Borg"
Date: Mon Aug 21, 2006 6:50 pm (PDT)
Dear Richard,
Linear
data stores any pixel's data count for any pixel from 0
to 4095 (12
bpc). Only the camera maker gets to decide how to
quantize the
electron counts into that RAW file.
IMHO here you present a contradiction.
Camera maker decides to quantize it to record a linear
raw file. That is, to distribute data in a linear manner, sans floor and
ceiling. He may further compress that linear data, making it non-linear in
some cases (Nikon "lossless"; but we then restore linearity again
before applying colour transform.
Each application maker's opinion of what the developed
image should
look like,
I named objective parameters, sharpness (resolution),
accurate colour transform, noise. We can argue "accurate", of
course; but not within most of current methods of applying colour
transforms which are mainly based on reproduction of synthetic targets.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "clic!o"
Date: Mon Aug 21, 2006 6:50 pm (PDT)
Iliah and Richard,
That is not absolutely true, considering my experience
with Canon digital cameras.
*To my taste*, ACR, Raw Developer and C1Pro usually
will give me more control options and better color/noise results than
Canon´s proprietary raw software.
Clicio Barroso
www.clicio.com.br
___________________________________________________________________________
ACR and "secret math"...
Posted by: "Richard Chang"
Date: Tue Aug 22, 2006 3:38 am (PDT)
IMHO here you present a contradiction.
Camera maker decides to quantize it to record a linear
raw file. That
is, to distribute data in a linear manner, sans floor
and ceiling.
Linear doesn't delete the ceiling, that's controlled by
the user with exposure. Linear can chop off the least significant
bit, but since that always contains noise, no one is complaining.
What a camera company does with the transition between the least
significant bit up to threshold is up to them, which can address my notion
of noise reduction.
Camera makers take the well capacity of the pixel, and
turn it into linear data. A pixel may have 50,000 to 100,000
electrons (depending on the sensor and the pixel size) just below
saturation in higher end cameras. Full well capacity is less for
higher ISO's. At the end of the camera's throughput, you end up with
a linear RAW file representing the light energy in the scene, as focussed
by the lens onto the sensor. If the lens focusses through a low pass
optical filter, there's often some effort made to mitigate the filter
softening used to avoid color aliasing errors, which may be different for
various RAW converters.
What the camera companies can do is know the sensor
design and choose how they distill the shadow-to-full well signal, into a
0-4095 linear file (12bpc in a 16 bit register). Does this give them
an advantage in converting over Adobe or Apple? Not everyone agrees.
Some will argue that they're better while they complain that they
don't have all the "secret math".
Third parties can and do market that they're the
superior workflow. Clicio Barroso's opinion on this subject suggests that
he agrees, he likes the third party solution for his Canon. I know
others who like the Canon pictures.
He
may further compress that linear data, making it
non-linear in some
cases (Nikon "lossless"; but we then restore
linearity again before
applying colour transform.
Lossless compression of RAW data is a relatively new
advancement, but it shouldn't change the nature or the progression of
tonality in a RAW (linear) file. The real advantage of a RAW file is
that it is linear and you're allowed to develop it with the attributes you
consider important, rather than with what someone else has decided you
need. Assuming you know what to do with the developing, that's a huge
step forward in photography.
I named objective parameters, sharpness (resolution),
accurate colour
transform, noise. We can argue "accurate", of
course; but not within
most of current methods of applying colour transforms
which are mainly
based on reproduction of synthetic targets.
Sharpness and spatial resolution are separate
attributes. Accuracy is a completely different issue. And in my
opinion, the best color isn't based on synthetic targets, it's based on
real targets, rendered on specific paper surfaces, viewed by real people.
This list has been influential in communicating the idea that
crafting color isn't simple, it isn't a ritual, and it isn't finished being
invented. What's nice is that Dan's approach allows traditional craft
to hold us over until Andrew and Chris' technology can cover us in every
circumstance.
Richard Chang
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Richard Chang"
Date: Tue Aug 22, 2006 3:47 am (PDT)
Iliah and Richard,
That is not absolutely true, considering my experience
with Canon
digital cameras.
*To my taste*, ACR, Raw Developer and C1Pro usually
will give me more
control options and better color/noise results than
Canon´s
proprietary raw software.
Then I guess you don't buy the notion that "secret
math" is holding Adobe hostage.
Richard Chang
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Iliah Borg"
Date: Tue Aug 22, 2006 8:49 am (PDT)
Dear Richard,
Linear doesn't delete the ceiling,
IMHO we are going here into details that are far beyond
the scope of this list.
In certain designs (Kodak, Canon) ceiling is enforced
during ADC stage and depends on ISO setting.
Same about the floor. Up to 7+ bits can be stripped.
Lossless compression of RAW data is a relatively new
advancement,
I put lossles in "". It is not lossles in
fact.
Sharpness and spatial resolution are separate
attributes...
Once again, that was not the point. The point was that
if we are going to compare raw convertors we need to have an objective set
of parameters additionally to subjective.
I'm not very concerned with colour or tonality issues
which I can address in Photoshop. Noise, sharpness, reduced number of
levels / posterization, moire, clipped highlights etc. - that is my list of
comparison criteria.
As a developer of a raw converter myself I know a
little about secret math. The list of essential information hidden in raw
files - information that is essential for development of a high quality
image - is *very* long.
Most important, a lot of information is not even there,
like sensor spectral response.
But as I said, that's not for this list IMHO.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "clic!o"
Date: Tue Aug 22, 2006 8:50 am (PDT)
Richard,
You can bet on it!
There´s no such a thing as a "secret
math", in my humble opinion.
Clicio Barroso
www.clicio.com.br
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Roger Howard"
Date: Tue Aug 22, 2006 9:03 am (PDT)
On Aug 21, 2006, at 10:57 PM, Richard Chang wrote:
What the camera companies can do is know the sensor
design and choose
how they distill the shadow-to-full well signal, into a
0-4095 linear
file (12bpc in a 16 bit register). Does this give them
an advantage
in converting over Adobe or Apple? Not everyone agrees.
Some will
argue that they're better while they complain that they
don't have
all the "secret math".
I believe the argument is they are better *despite* the
secret math, as you call it, but that it would sure be easier, and better
for long-term preservation, if there weren't such secrets. I don't see the
contradiction - camera makers make things harder on third-party developers,
and make folks (like me) working in digital preservation quite nervous, but
through ingenuity, reverse engineering, and overall better software
engineering, third-parties still deliver better products. It doesn't mean
we shouldn't have better documentation on the raw data, even if life goes
on without it. And it doesn't mean that third-party products couldn't be
even better with more information from camera makers - especially, I would
suggest, for less common models.
You even support this by claiming that camera makers
have the advantage:
The idea that any third party can develop a better
image than the
maker of the camera is also somewhat amusing; similar
to the idea
that a third party automobile product is better than
the
manufacture's specification. There is of course,
cheaper, and there
is better; you shouldn't confuse the two, regardless of
who's doing
the marketing or complaining
While I hate car analogies and don't think this one is
apt (many aftermarket car products are in fact better than OEM/stock
parts), you support the claims widely made that camera makers hamstring
software developers by not providing sufficient details. However, like many
others, I dispute your suggestion that third parties cannot make better raw
developers, even without these details - the market is full of such
products. But that doesn't mean the details aren't useful, or
philosophically that they shouldn't provide them.
Adobe is not whining simply for their own displeasure,
they have the resources to support all the cameras they'd like to. But they
have raised awareness of an important issue that will only become more
important as raw files age.
-Roger Howard
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: Mark Segal
Date: Tue Aug 22, 2006 9:57 am (PDT)
Iliah,
I'm at a disadvantage here because I am not a
mathematician and I never had the experience of developing a raw converter
- wouldn't know where to begin, but just as a matter of curiosity on your
criteria, why would you include noise and sharpness for comparative
evaluation of raw converters? I was under the impression that these two
variables can also be handled in Photoshop or with good Photoshop plug-ins
currently available. Are you suggesting that beyond certain limits of noise
and softness in the converted image one should reject a converter because
the PS tools won't be able to optimize the image?
Mark Segal
___________________________________________________________________________
Re[2]: [colortheory] ACR and "secret math"...
Posted by: "Iliah Borg"
Date: Tue Aug 22, 2006 10:38 am (PDT)
Dear Mark,
why would you include noise and sharpness for
comparative
evaluation of raw converters?
Well, if the difference in resolution can be as much as
30%, and using poor converters I lose the advantage of high-grade lenses.
If poor raw converter depreciates my investments into high resolution
camera. If with a good raw converter I can use Nikon D100 with a 70-210/4
lens and beat the output from D2X with 70-200/2.8 stopped to f/4 with poor
converter.... That is too much of a difference to deal with in Photoshop.
The cleaner is the input into Photoshop the cleaner is the output; is that
right in general?
Noise: If the file somes into Photoshop with ugly
blotches, what are our options? To plug shadows, to desaturate Red or Blue,
to add fine-granular luminance noise, to oversharpen a and b channels and
to sharpen L channel LORAHIAM? Still we are not there in many cases.
I do use all those, even with good converter they do
help. But today 8am morning I shoot and in an hour from now (3pm) I need to
submit 43 proofs, printed. Add 2 hours in traffic.
--
Best regards,
Iliah Borg
___________________________________________________________________________
ACR and "secret math"...
Posted by: Andrew Rodney thedigitaldog
Date: Tue Aug 22, 2006 4:59 pm (PDT)
No question I1d rather do noise removal in the
converter but so far my experience with those I1ve tried is they are OK at
best. Have you checked out Noiseware from Imagenomic? It1s absolutely
astoundingly at noise removal from rendered images:
http://imagenomic.com/
Andrew Rodney
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Iliah Borg"
Date: Wed Aug 23, 2006 5:06 am (PDT)
Dear Andrew,
It is not about noise *removal*, it is about
demosaicing that generates less noise. To the point that it makes ISO640
Kodak SLR shots usable. I'm quite sure that better methods are possible in
near future.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Re[2]: [colortheory] ACR and "secret math"...
Posted by: "Bartlomiej Walczak"
Date: Wed Aug 23, 2006 5:12 am (PDT)
Hi,
You write:
IMHO we are going here into details that are far beyond
the scope of
this list.
No, please go on. I am very much interested.
IB> In certain designs (Kodak, Canon) ceiling is
enforced during ADC
IB> stage and depends on ISO setting.
IB> Same about the floor. Up to 7+ bits can be
stripped.
So does ISO setting force normalization post-recording
or actually switch the input circuitry?
IB> I put lossles in "". It is not lossles
in fact.
Can you elaborate on the compression? I'm interested.
IB> As a developer of a raw converter myself I know
a little about secret
IB> math. The list of essential information hidden
in raw files -
IB> information that is essential for development of
a high quality image
IB> - is *very* long.
I'm a physicist, aware of how detectors work. I would
be interested in learning more about this. If you feel this is too much for
this list, could you email me privately?
Thanks for all the information!
best regards
Bart Walczak
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "v_yelis"
Date: Wed Aug 23, 2006 5:00 pm (PDT)
Dan,
I have photo of the flower with bright yellows and dark
saturated purple-reds. I converted it from Raw to Tiff with Camera profile
embedded. Gamut warning shows that practically all yellows are outside of
aRGB gamut, but within gamut of my printer (epson 4000, premium semigloss
paper, printed with imageprint). After I converted this image to aRGB, I
got just a black blob in B in this area. The difference was not very
visible on the monitor, but it was very obvious when I printed both the
original and aRGB version.
Vladimir Yelisseev
NOTE: This image is one of two used as the base for
experiments discussed in a November 2006 thread, archived here as
___________________________________________________________________________
Re: Color Management Workflow for RAW files Editing
Posted by: "Dan Margulis"
Date: Sat Aug 26, 2006 1:23 pm (PDT)
Vladimir Yelisseev writes,
I have photo of the flower with bright yellows and dark
saturated
purple-reds. I converted it from Raw to Tiff with
Camera profile embedded.
Gamut warning shows that practically all yellows are
outside of aRGB gamut,
but within gamut of my printer (epson 4000, premium
semigloss paper, printed
with imageprint). After I converted this image to aRGB,
I got just a black
blob in B in this area. The difference was not very
visible on the monitor, but
it was very obvious when I printed both the original
and aRGB version.
This sounds like the type of image that would show the
problem, if one ever exists--yellows and purples, not reds, greens, or
blues. Certainly I'd like to have a look at it, but I'll need the raw
image. If you can post it somewhere (it will not fit in the list Files or
Photos section, it's too large) or e-mail it, I'll take a look at it as
soon as the book project completes.
Speaking of which, I still have your 16-bit
demonstration file. As indicated earlier, I am saving the resolution
chapter for last because it is the easiest one in which to add pages if any
space is available. I'm on the second-to-last chapter now, so will probably
be working with that file late next week before going to Photoshop World.
Dan Margulis
___________________________________________________________________________
Re[2]: [colortheory] Re: Color Management Workflow for
RAW files
Posted by: "Iliah Borg"
Date: Sat Aug 26, 2006 1:56 pm (PDT)
Dear Vladimir,
With Dan's permission, I will love to have that raw
file too, and can host it for the list if you wish so.
Best regards,
Iliah Borg
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Bob Frost"
Date: Sun Sep 3, 2006 12:18 pm (PDT)
Mark,
Not sure if this helps, but just as Photoshop has two
interpolation algorithms called Bicubic Sharper and Bicubic Smoother that
vary the sharpness of the interpolated product, and a program such as
QImage offers another dozen or so interpolation algorithms that vary in
speed, quality, sharpness, etc, so raw conversion has many interpolation
algorithms to choose from that vary in speed, quality, sharpness, etc. Have
a look at this comparison of about a dozen different bayer interpolation
algorithms -
[LINKDELETEDASOBSOLETE]
People sometimes forget that the main thing a raw
converter does is invent the two missing red, green or blue values for each
pixel by looking at the surrounding pixel values. Lots of different ways of
doing that, just as with normal interpolation to upsize an image. And
usually the best quality is given by the slowest algorithm, and vice versa.
Bob Frost.
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Michael
Plack~Metro"
Date: Sun Sep 3, 2006 1:39 pm (PDT)
Bob,
The link doesn't work. Would you mind rechecking
and updating?
Thanks.
Michael Plack
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Bob Frost"
Date: Mon Sep 4, 2006 4:30 am (PDT)
Mmmm! It did work, but trying links to it from several
different websites all fail now, as you say.
However, on this website - http:
//www.dalibor.cz/minolta/raw_file_format.htm
if you scroll down to the bottom, about three lines up,
it mentions Ting Chen's comparison and provides a pdf mirror source -
http:
//www.dalibor.cz/files/Ting%20Chen%20-%20Interpolation.pdf That works for
me and may work from this email.
Bob Frost.
___________________________________________________________________________
Re: ACR and "secret math"...
Posted by: "Richard Wagner"
Date: Mon Sep 4, 2006 4:01 pm (PDT)
On Sep 4, 2006, at 1:01 PM, "Bob Frost" wrote:
Bob actually cited a classic paper - too bad the
Stanford web site changed and killed everyone's links.
Ting Chen's current site can be found here. If
you're interested in digital imaging and raw conversion, it's a site worth
exploring. Bayer demosaicing is fundamental to raw image conversion.
http:
//scien.stanford.edu/class/psych221/projects/99/tingchen/main.htm
If you're the engineering type and are interested in
questions like, "How small should pixel size be?" check out his
other paper.
http://white.stanford.edu/~brian/papers/pdc/
pixelSize_SPIE00.pdf#search=%22tingchen%20stanford%22
--Rich Wagner
Receive Schedule
and Pricing updates.
If you let us know how to contact you, we will enter you into our monthly drawing for a free 2-day class (A $895 value).
- Get free video training
- Get free tips, tricks and shortcuts
- Get special sale pricing and free seminar invitations
Sterling Ledet & Associates, Inc. 4100 Perimeter Park South Atlanta, GA 30341
work sales@ledet.com work administration@ledet.com work webmaster@ledet.com
P work 770.414.5007 P work 877.819.2665 F fax 312.896.9094
- Authorized Training Provider
Copyright 2012. Sterling Ledet & Associates. All Rights Reserved.
Design by Digital Scientists, a Conversion Optimization Company.
