Dan Margulis Applied Color Theory
16-Bit Summation, 2005
Date: Thu, 1 Sep 2005 10:18:38 -0700
From: Richard Chang
Subject: 16 bit printing
A recently posted question wondered:
A question with a look to the future: I have
heard some speculation
that at some point printers might support
16-bit files directly. Would that be a case
where there might be some advantage?
The bigger question in my mind is how many bits can be
seen (or measured, for that matter) on a reflective rendering?
We can use a traditional reflection densitometer to
derive a D log value for any paper and inks combo. Bits can be
mathmatically related to the D log values. Measurements made by
MegaVision back in the late 80's when they were considering the making of
the first Tessera digital capture device, returned 6.5 bits for a high
performing sheet fed press.
It might be interesting to measure some reflective
targets to see how they perform with today's technically advantaged
rendering methods. Yes, we can send 16 bit files to some devices, but can
we really see a difference between an 8 bit and a 16 bit file on the print?
Just because the driver will accept the 16 bit file, doesn't
necessarily mean that the viewer can see it. It could however, have
marketing advantages to the folks who are selling the technology.
If we consider how many individually seperable tones
we can see reflected from a print, common sense should tells us we should
send a prudent amount more, to make sure we've sent enough. Sending a
16 bit file sounds a lot like printing in 2880, versus 1440. Does
this mean that we're going to have to use the 2880 setting to see the 16
bits?
Richard Chang
____________________________________________________________________________
Date: Sat, 03 Sep 2005 09:56:47 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/2/05 9:33 PM, "Dan Margulis"
wrote:
DM: "I repeatedly asked him whether he had
ever personally run a test (or
seen anyone else perform such a test) where the
same exact corrections were
applied in both 8- and 16-bit modes to a
real-world color photograph, and
compared
I have such a file which I posted on my site for
anyone to download. Unless I1ve suffered a major brain fart (or once again,
the rules change), its quite clear to me that the 16-bit file is showing
vastly superior quality with respect to noise and artifacts compared to the
8-bit file.
The image was shot with a Canon 350D (ISO 100).
I used Adobe Camera RAW 3.X with all defaults and auto settings OFF. No
sharpening in ACR either. The file was brought into Photoshop in 16-bit in
ProPhoto RGB from ACR. Then I duplicated the file and converted the dupe to
8-bit. I applied levels corrections (nothing super radical), USM and a
boost in saturation (+20 in Hue/Sat). The IDENTICAL corrections were made
on the high bit file (hold down option key and the other key command to
call levels, USM etc to get exact values) or drag and drop history from one
to the other.
Cache is off In histogram. The 8-bit Histo isn1t awful
like I see in Bruce1s book. But there is a very noticeable amount of noise
in the 8-bit file not seen in the high bit file. I also converted from
ProPhoto into LAB and did the same corrections (well not exactly since
levels in LAB can1t be duplicated exactly as you would from an RGB file).
Again, the 8-bit file shows severe noise introduced by the corrections that
simply don1t show up in the high bit file. At 200% zoom, it shows up like a
sore thumb.
I1ve taken a section of the image since in high bit,
it1s quite large and cropped it down as the 16-bit ProPhoto RGB file. In
the zip archive are screen dumps of the corrections made. I also generated
a Photoshop action; one duplicates the 16-bit file, converts to 8-bit and
applies the three corrections. The 2nd would be used on the original
(doesn1t duplicate) making a bit easier to apply both sets of corrections.
After that, zoom into the green (slightly out of focus) bird feeder
at 200% and look at the differences. The biggest issues in the 8-bt file
appear to show up in shadows which makes sense. This is another reason why
even superior quality would be produced on linear encoded data within ACR.
It also illustrates the need to 3expose to the right2 for RAW data since
the first 2048 steps of data are all within the first stop of highlights.
This is a real world image and the corrections are not
severe and identical on each. The Zip archive is about 1.8mb.
I1m seeing this effect on other files shot and
processed in this manner. I can of course supply the RAW data but it1s
pretty large. If anyone wants it, let me know and I'll put it on my public
idisk.
The file is here:
http://www.digitaldog.net/files/16bitchallange.zip
Andrew Rodney
____________________________________________________________________________
Date: Sat, 3 Sep 2005 16:28:41 -0700
From: Lee Varis
Subject: Re: Eighteen Questions about Dan's new LAB
book
Thanks Andrew, I've been looking for a file that
demonstrated why it is a bad idea to work in ProPhoto RGB - now you've
provided a perfect demonstration.
Unfortunately its not really that clear to me that
this demonstrates "vastly" superior quality for a 16 bit workflow
unless you need to lighten and saturate severely underexposed images in
ProPhoto RGB.
What we have here is a file in ProPhoto RGB that
contains no colors that would fall outside of Adobe RGB. Most of the bits
available in ProPhoto RGB are not being used in this image. When I convert
the 16bit ProPhoto RGB file into 16bit Adobe RGB and run your test I see no
difference between the 16bit and the 8bit version!
I've posted a screenshot here:
http://www.varis.com/ColorTheory/16bitchallenge.jpg
What is interesting is that you can see a difference
when this operation is conducted in ProPhoto - the fact that the difference
is not noticeable in print at a reasonable output size works against your
claim that it shows a "vastly" superior quality with respect to
noise and artifacts. When shown prints (Epson R2400, image at 240 ppi print
@ 2880) of the two versions my 17 year old son (who happens to have better
eyesight than me) picked the 8 bit version as better because it seemed a
tiny bit sharper!
I will admit though that if you insist on using a
workspace that is vastly larger in color gamut than you really need for any
type of printed output you'll have smoother results if you do your
adjustments in 16bit.
Here is a screenshot demonstrating the difference side
by side:
http:
//www.varis.com/ColorTheory/16bitchallengeProPhoto.jpg
It is interesting to note how much worse the 8bit
ProPhoto file looks than the 8bit AdobeRGB file. I think that its quite
possible that if you output a continuos tone print (like a Lightjet) and
put a loupe on the print you could see the noise and artifacts on the
ProPhoto version.
Here is a screenshot showing ProPhoto vs AdobeRGB
versions:
http:
//www.varis.com/ColorTheory/8bitProPhotoVS8bitAdobeRGB.jpg
The bottom line -- if you must use ProPhoto RGB stay
in 16bits for major adjustments. Otherwise, use Adobe RGB and you can do
everything in 8bits.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Sat, 03 Sep 2005 19:12:24 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/3/05 5:28 PM, "Lee Varis" wrote:
Thanks Andrew, I've been looking for a file that
demonstrated why it
is a bad idea to work in ProPhoto RGB - now
you've provided a perfect
demonstration
Bad? Works fine in high bit. If you happen to shoot in
RAW, you'll find lots of images that fall way outside say Adobe RGB (1998)
but within ProPhoto. So if you are OK clipping color from your capture
device go that route. Otherwise, ProPhoto RGB is a better space to contain
those colors.
Unfortunately its not really that clear to me
that this demonstrates
"vastly" superior quality for a 16 bit
workflow unless you need to
lighten and saturate severely underexposed
images in ProPhoto RGB.
Lighten, sure. Saturate why not? And if you try
corrections other than saturation (like just lighten), you'll see the
benefits of the high bit file in reduced noise.
The original argument was, using 8-bit versus high bit
on a file (color space not defined nor should it be necessary), show an
example where there's a benefit to to doing the same exact corrections on
each. Do you see that or not?
What we have here is a file in ProPhoto RGB that
contains no colors
that would fall outside of Adobe RGB.
The color in the file is immaterial. I'll be happy to
shoot a saturated image that also contains dark shadows (gee, that's not
hard to find) and illustrate noise in the shadows from the 8-bit
corrections that are not produced in high bit.
Most of the bits available in
ProPhoto RGB are not being used in this image. When I
convert the
16bit ProPhoto RGB file into 16bit Adobe RGB and run
your test I see
no difference between the 16bit and the 8bit version!
Agreed, as I tried this in Adobe RGB (1998) as well
and like you, saw far less issues. But that's not what the challenge is
about, it's to show the benefit of using high bit versus 8-bit identical
corrections. Plus why limit the color gamut? Did you try this on a LAB
file? It shows the same issues. LAB's going to be also very large and
produce the same issues in a different way. The high bit corrections do not
exhibit the noise.
What is interesting is that you can see a difference
when this
operation is conducted in ProPhoto - the fact that the
difference is
not noticeable in print at a reasonable output size
works against
your claim that it shows a "vastly" superior
quality with respect to
noise and artifacts.
You printed it on what device at what size? You've got
a tiny section of a full rez file.
When shown prints (Epson R2400, image at 240 ppi
print @ 2880) of the two versions my 17 year old son
(who happens to
have better eyesight than me) picked the 8 bit version
as better
because it seemed a tiny bit sharper!
Sure it does, look at the noise which produces on
edges the look of more contrast. But that's non image data that's being
formed due to the edits in 8-bit and it's not a good thing! We're seeing
the effects of the edits causing aliasing in the form of noise.
I will admit though that if you insist on using a
workspace that is
vastly larger in color gamut than you really need for
any type of
printed output you'll have smoother results if you do
your
adjustments in 16bit.
Yes, I and many need this large a working space to
contain colors their capture devices produce. Looking at the gamut of my
Imacon scanner, it too produces colors outside of Adobe RGB (1998) in many
areas. I'd like to keep those colors since I can illustrate output devices
that have gamuts that can use some, certainly not all, but some of that
gamut. I also want a working space that has a large enough size to define
dark colors that can't be kept in something like Adobe RGB (1998). That's a
major benefit of such a space. Unlike output devices, the gamut shape of a
working space is such that it tapers rather radically as it moves to darker
tones. Output devices generally have a much wider gamut shape. When you use
a smaller gamut working space, you crunch a good deal of data in those
areas and end up printing blobs instead of detail in images that would have
say very dark brown tones.
It is interesting to note how much worse the 8bit
ProPhoto file looks
than the 8bit AdobeRGB file. I think that its quite
possible that if
you output a continuos tone print (like a Lightjet)
and put a loupe
on the print you could see the noise and artifacts on
the ProPhoto
version.
I've got a Fuji Pictrography 4500 and I agree with
you, it can be seen.
But that isn't the issue. The issue is I don't have to
worry as much about this in high bit by applying the identical edits to
this and many other images from this capture device. And I can do even more
work with less damage using Adobe Camera RAW in linear encoded editing on
high bit. That wasn't even accounted for here since the original post by
Dan discussed how in Bruce's book, the two edits on page 24 were apples and
oranges. We should see even better quality data first doing the tone
mapping I did on the gamma corrected data in high bit instead in ACR.
The bottom line -- if you must use ProPhoto RGB stay
in 16bits for
major adjustments.
So you agree that there's some advantage of high bit
editing, all corrections being equal? I suspect the forum host doesn't
agree with that or at least, has been asking for side by side comparisons.
I don't recall the working space being part of this challenge.
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Sat, 3 Sep 2005 21:02:39 EDT
From: Dan Margulis
Subject: Re: Eighteen Questions about Dan's new LAB
book
Andrew Rodney writes,
The image was shot with a Canon 350D (ISO 100).
I used Adobe Camera RAW 3.X
with all defaults and auto settings OFF. No sharpening
in ACR either. The
file was brought into Photoshop in 16-bit in ProPhoto
RGB from ACR.
First of all, thank you for posting it, I agree that
it is a real-world picture with real-world corrections. I have played with
it a little bit but won't have any final comments until I get a chance to
manipulate it more, which will be after Photoshop World. At that time, I
will probably take you up on the offer to provide the raw file, provided
you are willing to give me permission to publish it.
It would not surprise me if this or a similar file
containing mostly dull colors, if left in ProPhoto RGB, would get a better
result from 16-bit correction than 8-bit. I have tested Adobe RGB,
ColorMatch RGB, LAB, and sRGB files enough to be highly doubtful that there
are any natural color photographs at all where the extra bits would be
helpful in any real-world context. However, I've always pointed out that I
have *not* extensively tested exotic alternatives, such as 1.0 gamma files,
or ultra-wide gamut RGBs such as ProPhoto. The reasons they are not tested
are 1) they have limited market presence and 2) I strongly recommend
against their use in color correction.
I do have another ProPhoto file where 16-bit
definitely produced a better result than 8-bit. However, it was not a
real-world exercise in that the file was intentionally sabotaged in Camera
Raw by moving the exposure slider all the way to the left when the actual
final intent was to lighten the file. We did repeat the same exercise,
including the sabotage, with the same file output to Adobe RGB, and there
was no problem with the 8-bit correction.
During the tests for the LAB book I was working with
Wide Gamut RGB rather than ProPhoto, and it did astonishingly badly in all
manner of conversions, from which I surmise that ProPhoto might as well.
In any case, if it turns out that in some cases 16-bit
correction works better in ProPhoto RGB, I have no problem admitting it and
adding that to the long list of reasons why one should avoid adjusting
images in such a space.
Dan Margulis
____________________________________________________________________________
Date: Sat, 03 Sep 2005 21:40:54 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/3/05 7:02 PM, "Dan Margulis"
wrote:
I will probably take you up on the
offer to provide the raw file, provided you are
willing to give me permission
to publish it.
Actually I1d like to find an image that is
photographically more interesting! You1re only seeing a tiny section but
trust me, it1s not at all much to look at in total. I should have no
difficulty finding or shooting images with this camera in RAW that shows
similar, perhaps even better demonstrations of the two options in
processing. I1d also like to see the effects with different ISO settings.
With 100 ISO, I1m producing the best possible image quality from this
sensor. Lastly, exposure could play a big role here (using the expose to
the right dogma).
It would not surprise me if this or a similar file
containing mostly dull
colors, if left in ProPhoto RGB, would get a better
result from 16-bit
correction than 8-bit. I have tested Adobe RGB,
ColorMatch RGB, LAB, and sRGB files
enough to be highly doubtful that there are any
natural color photographs at
all where the extra bits would be helpful in any
real-world context.
ProPhoto is certainly a space that contains colors
that are way out there. In fact, I1d agree in this context that some of the
colors it can define are actually imaginary colors, a term you use in your
new book that outside of ProPhoto RGB is a lose term I don1t agree with. In
LAB (well CIEXYZ of which LAB is based) as well as the spaces you mention
above, the colors are not imaginary but they can certainly be outside of
the gamut of a lot of devices. In ProPhoto, there are blues that are
outside human gamut which I think are absolutely imaginary (and of course
unprintable). There are so called 3imaginary2 colors in Adobe RGB (1998) if
the device trying to 3imagine2 them is a four color press.
The reason ProPhoto RGB is so large and why it1s
necessary is we are often trying to fit square pegs in round holes if you
forgive the analogy. The gamut of a digital camera (which arguably has no
real color gamut) can be quite large. There are many, many real world
scenes and thus images that fall far outside the gamut of Adobe RGB (1998)
but can be contained in ProPhoto RGB. While there are those that say a
histogram is an over used diagnostic tool, and I would not totally
disagree, the histogram in Adobe Camera RAW provides a very non ambiguous
way to see if the scene data falls outside Adobe RGB (1998) but within
ProPhoto RGB. One could argue we need a working space with a gamut between
the two. However, when I capture a scene, I want to have at my disposal all
the color that device can provide. Today, the only way I can do this with a
great deal of images is to use ProPhoto RGB. Even though it1s gamut is so
large that it falls in some portion outside of human gamut, the other
larger areas are necessary to contain other useful and I would submit
non-imaginary and reproducible colors (to some devices).
If you have a decent DSLR and Adobe Camera RAW, it
isn1t too hard to open an image and find clipping of some or all primary
colors in Adobe RGB (1998) by viewing the ACR histogram. Toggle to ProPhoto
RGB and those colors can be contained when rendered and encoded into that
working space.
Many of us have advised the use of high bit color with
very wide gamut editing spaces and based on this one test, I think that1s a
good call. It also shows the advantages of high bit data!
However, I've always pointed out that I have *not*
extensively tested exotic alternatives,
such as 1.0 gamma files, or ultra-wide gamut RGBs such
as ProPhoto.
I don1t think ProPhoto RGB (previously known as ROMM
RGB and around almost as long as Adobe RGB (1998)) is exotic. Anyone
working with RAW files from digital cameras can find it a useful color
container. It1s one of the four options in Adobe Camera RAW. As more images
are captured digitally in RAW, if anything, the use of such a space will
grow.
The reasons they are not tested are 1) they have
limited market presence and 2) I strongly
recommend against their use in color correction.
ROMM RGB has been thoroughly tested and has been used
for years. With the exception of using it with 8-bit files, the real
downside I see is it could contain colors that fall well outside display
gamut. But that1s true for 98% of every display on the market when you
substitute Adobe RGB (1998) for ProPhoto RGB. I1d also rather have colors I
might be able to use on output and perhaps not fully see on a display then
throw away colors I know my various output devices can use just to see
every color. And we both know that even with wide gamut displays, there are
CMYK colors they can1t reproduce even if we started with a much smaller
color space. In this context, those colors are imaginary but reproducible
on press.
I do have another ProPhoto file where 16-bit
definitely produced a better
result than 8-bit. However, it was not a real-world
exercise in that the file
was intentionally sabotaged in Camera Raw by moving
the exposure slider all the
way to the left when the actual final intent was to
lighten the file.
In this file, I simply used the default settings but
without the auto check boxes. The file does look dark on the Artisan but I
didn1t have to do anything radical with levels to make the image look
better. I would certainly have done this in ACR but then if I made the RAW
to rendering file look as good as I could by simply clicking on the auto
check boxes or using a custom setting, the data, even in 8-bit would look
great and there would be little need to edit the file.
We did repeat the same exercise, including the
sabotage, with the same file output to
Adobe RGB, and there was no problem with the 8-bit
correction.
As Lee pointed out, in Adobe RGB from the RAW data,
the same corrections do not produce the level of obvious noise in 8-bit.
But I want and do use ProPhoto RGB for reasons discussed as do many other
users.
In any case, if it turns out that in some cases 16-bit
correction works
better in ProPhoto RGB, I have no problem admitting it
and adding that to the
long list of reasons why one should avoid adjusting
images in such a space.
Well that1s certainly a good step forward. NOW we need
to test what ProPhoto brings to the party but we have to do so with current
output technology (meaning more than four color ink on paper) and with an
eye on future print technology.
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Sun, 04 Sep 2005 00:32:55 -0400
From: Ric Cohn
Subject: Re: Eighteen Questions about Dan's new LAB
book
Andrew,
Thanks for posting this. As one of those who have
looked at the 16bit/8bit issue in some depth I know how difficult it is to
put this information together. I also experienced myself the problems (and
some pitfalls) in doing my tests and so wanted to look at yours closely.
I'll leave it to others to debate whether this shows a benefit to editing
in 16 bits, although I was surprised at how much sharpening separated the 2
files. It certainly shows a difference (although this isn't contested
anyway), and I do think the dark greens look better in 16 bits at high
magnifications. Here's what I see:
1). Unedited: 8 bit converted w/ & w/out dither
preference. Based on your seeing a difference between the unedited 16 and 8
bit files I assume you had dither on. At 1600% I can see a difference
between the two 8 bit files. The 8 bit file converted w/out dither looks
virtually identical to the 16 bit file (to my eyes).
2). There is a much bigger difference after editing,
of course: @ 400% can see big difference in dark greens. If go back to step
before sharpening the difference is more subtle. @ 1600% the difference is
more obvious. However, the 16 bit file looks softer. I'm not sure you would
sharpen a 16 bit file and an 8 bit file identically if you were looking at
both on screen? Surprisingly to me, the sharpening step makes the biggest
difference, and going back one step they are more similar.
At 800% looking at just the 16 bit file and the
"no dither" 8 bit file, I would say the 16 bit file looks softer,
but with more discrete tones. I would say the darkest greens look more
"realistic" in the 16 bit file. however the midtones look softer
and I would suspect might not look as sharp in a print. At 400% the tones
driven darker are very obvious in the 8 bit file. However, as I said the 16
bit file always looks softer. If I do as little as add 2 levels of
Threshold the files become much more similar.
3. The image at 240 dpi is only about 2 x 2.3 inches.
I doubt any repro method would show a difference. However, I know some
people need to interpolate up their digital files. So assuming someone had
this image and needed it reproduce it at a reasonable size I upsized 400%
using Bicubic Smoother. Here I would say the dark greens would probably
look better in a print from the 16 bit file. However, I still think the
midtones look sharper (and better) in the 8 bit file. Now we're getting
into the area of whether we could do a better looking correction for both
files which I think is the real point. There are many unexplored variables
in this test. For example, I would not normally consider ProRGB to be a
suitable 8 bit editing space. What happens if both files are converted to
AdobeRGB before editing? Perhaps I'll look at this later.
I looked up the Canon 350D and I believe it's the
Rebel version of the 20D (which I've used). I know it's a very nice camera,
but not up to the D1s, which isn't up to the top medium format single shot
backs, which aren't quite as good as the 4 shot capture backs (because of
uninterpolated color) which probably aren't quite as good as a scanning
back (although I don't use these because I believe the limitations aren't
worth dealing with except perhaps for museum archiving work). My point
being that it's the images that count. If you want to agonize over a few
lost bits then go for the best capture to begin with. This reminds me of
when I first started to do photography as a hobby. I loved the work I saw
that was shot with large format cameras. I wanted to take pictures like
that but all I had was a 35mm camera. I shot with slow film on a tripod and
processed in fine grain developers. I spent hours in the darkroom working
to bring out a widest tonal range I could. My landscapes still looked like
shit compared to something shot in 4x5 or 8x10. However, when I stopped
trying to make my pictures look like large format and started taking the
kinds of pictures that 35mm was suited for my pictures got a lot better.
Later when I had a chance to work with large format film I could achieve
the results I was looking for.
I'll be interested in hearing other's views.
Ric Cohn
____________________________________________________________________________
Date: Sun, 4 Sep 2005 13:14:47 +0200
From: "Francisco Bernal"
Subject: Re: Eighteen Questions about Dan's new LAB
book
Prhophoto is a space excesivaly big to be usefull
¿Don't you think so? It has far more number for colors than usefull
colors, so the actual amount of "numbers" you can "assign to
real colors" is prerttysmall. Wide gamut spaces are so unpractical!!
/*--------------------------------------*/
"If quality is important, sRGB is not an
option"
(From the European Color Initiative web page
www.eci.org)
Francisco Bernal Rosso
Luz-color-fotografia
Redacción y traducción
____________________________________________________________________________
Date: Sun, 04 Sep 2005 08:55:39 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/3/05 10:32 PM, "Ric Cohn" wrote:
1). Unedited: 8 bit converted w/ & w/out dither
preference. Based on
your seeing a difference between the unedited 16 and 8
bit files I
assume you had dither on.
Dither is used for color space conversions which can
be turned on or off in color settings and only affects 8-bit data. I
did no color conversions. The file went from RAW to ProPhoto RGB in ACR.
You might want to try converting after the edits on both to some output
color space to see if things in 8-bit get even worse.
At 1600% I can see a difference between the
two 8 bit files. The 8 bit file converted w/out dither
looks virtually
identical to the 16 bit file (to my eyes).
Strange effect I've never noticed before. While this
looks like dither is introduced, it's not the same as above and unless
Adobe is doing something as they convert to 8-bit, I'm at a loss to explain
it. But you can see it when you toggle between the two bit depths at 1600%.
However, the 16 bit file looks softer.
The effect of the aliasing (which is not good)
produces the appearance of sharpness due to the increase in contrast. But
this isn't something we want! I have similar captured files where I see
this in dark gray clouds and it's pretty ugly. This isn't a contrast of
edges as we'd see in typical USM, it's banding that is somewhat
uncontrollable and affected by tone (and I suspect some colors as well).
Take an unsharpened file, use the Add Noise filter and I'll bet it appears
a bit sharper. I don't know anyone advocating the use of noise to make
images look sharper <g>
I'm not sure you
would sharpen a 16 bit file and an 8 bit file
identically if you were
looking at both on screen? Surprisingly to me, the
sharpening step
makes the biggest difference, and going back one step
they are more
similar.
In this case no because sharpening would make the
noise even more visible. This is why the discussion of using masks from the
image itself to sharpen was something I raised before. ANY global
sharpening no matter the color mode is pretty discriminant. An image mask
can hold back sharpening in smooth areas or dark areas like the one's we
are seeing that have noise. The noise is there in 8-bit far more than
16-bit which is the issue. At this point, sharpening should be conducted on
either or both with the utmost control. Using a true Grayscale image mask
made from the image can accomplish this.
At 800% looking at just the 16 bit file and the
"no dither" 8 bit file,
I would say the 16 bit file looks softer, but with
more discrete tones.
Exactly. That's what I'm seeing. That explains why the
8-bit looks "sharper" and why it's a problem because subtle
continuous tone is now going away. What happens when we use other edits or
convert to an output color space? Compounded issues are possible and the
reason proponents of high bit editing exist! We don't know how much worse
this will all get down the line.
The image at 240 dpi is only about 2 x 2.3 inches. I
doubt any repro
method would show a difference. However, I know some
people need to
interpolate up their digital files.
...or further edit the file, output to a high rez,
continuous tone device and so forth. Bottom line is, the high bit file has
more editing potential. Something Bruce mentions in his book.
I looked up the Canon 350D and I believe it's the
Rebel version of the
20D (which I've used).
More or less yes. The CMOS chip may be a bit newer but
its the same size. The processing may be different too. They should be
pretty close. Yes, there are substantially better quality digital capture
devices which may show the benefits of high bit more (or not). Keep in mind
that only 3-4 years ago, this was state of the art in DSLR technology.
Andrew Rodney
____________________________________________________________________________
Date: Sun, 04 Sep 2005 08:56:02 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/4/05 5:14 AM, "Francisco Bernal"
wrote:
Prophoto is a space excesivaly big to be usefull
It1s very useful if you want to contain colors your
capture device (in this case my Canon) is able to capture. I can provide
many images that fall outside of Adobe RGB (1998) that are fully contained
in ProPhoto RGB. I can also show you output devices (the new Epson 2400 at
a mere $800 is one) that can reproduce colors that fall outside Adobe RGB
(1998) but are fully contained in ProPhoto RGB.
There are no prefect working spaces or we1d only need
one! The advantage of bigger spaces is holding onto colors we can capture
and ultimately reproduce. To do this, we need in big honking gamut spaces
to hold colors that fall outside the simple shapes of all working
spaces. All RGB working space are synthetic constructions and have
simple shapes, especially compared to output color spaces. If you want to
hold all the captured colors you can possibly output (even to a device made
in 2005), you need a really big working space shape and ProPhoto fits the
bill. Just do the editing in high bit, the point of this discussion.
Andrew Rodney
____________________________________________________________________________
Date: Sun, 4 Sep 2005 09:49:48 -0700
From: Lee Varis
Subject: Re: Eighteen Questions about Dan's new LAB
book
On Sep 4, 2005, at 7:56 AM, Andrew Rodney wrote:
It's very useful if you want to contain colors your
capture device (in this
case my Canon) is able to capture. I can provide many
images that fall
outside of Adobe RGB (1998) that are fully contained
in ProPhoto RGB. I can
also show you output devices (the new Epson 2400 at a
mere $800 is one) that
can reproduce colors that fall outside Adobe RGB
(1998) but are fully
contained in ProPhoto RGB.
Unfortunately ProPhoto RGB is like using a sledge
hammer to drive finishing nails. Besides, all this discussion about
containing very saturated colors is a little bit like talking about how
many angels fit on the head of a pin.
Everybody is obsessing over a small subset of very
saturated colors!
For the most part we should be more concerned with
color relationships and tonal compression. Until we have high dynamic range
backlit displays being used for final output, images printed on paper
should be our primary concern. Images printed on paper are evaluated in the
context of that paper! Making images that have a range of tones and colors
that look good to a human observer does not require working in ProPhoto RGB
or 16bits. Advocates of wide gamut/high bit color spaces always end up
talking about real colors that you could capture and "contain" -
humans respond much more to contrast than color. Color contrast is more
important than color gamut or hue. Wasting data by spreading it out in a
huge erratically shaped color space just to "hit" a saturated
color that falls well outside of an editing environment seems to me to be
counter productive because it does nothing to make it easier to work within
the constraints of fairly small output spaces.
I've never seen anyone complain about the colors of a
Lightjet photographic print yet the Lightjet has a color gamut slightly
smaller than sRGB!
We're not trying to "contain" color but to
translate it so that it works in a completely different context.
To that end the only thing I find "useful"
about ProPhoto RGB are the individual channels for the purpose of B+W
conversions and luminosity blending NOT color "containment".
Having a huge color space helps to render grayscale channels with more
tonal detail (avoids clipping highlight and shadow detail in saturated
colors) and this tonal detail IS more easily manipulated for grayscale
images and luminosity blending techniques into smaller color workspaces.
The ProPhoto grayscale channels CAN be brought into 8bit very successfully
when you're not concerned with color!
So the best thing about ProPhoto RGB is grayscale
imaging not color!
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Sun, 04 Sep 2005 13:08:07 -0400
From: Iliah Borg
Subject: Re: Eighteen Questions about Dan's new LAB
book
On Sun, 4 Sep 2005 09:49:48 -0700 Lee Varis wrote:
So the best thing about ProPhoto RGB is grayscale
imaging
not color!
Dear Lee, have you tried taking images of flowers, red
roses, for example?
Best regards,
ib
____________________________________________________________________________
Date: Sun, 04 Sep 2005 11:48:23 -0600
From: Andrew Rodney
Subject: Re: Eighteen Questions about Dan's new LAB
book
On 9/4/05 10:49 AM, "Lee Varis" wrote:
Unfortunately ProPhoto RGB is like using a sledge
hammer to drive
finishing nails. Besides, all this discussion about
containing very
saturated colors is a little bit like talking about
how many angels
fit on the head of a pin.
Sorry Lee but that's just silly talk. Surely you have
RAW digital files you can examine in ACR to show you saturated colors
captured that fall outside Adobe RGB (1998) but could and can be output on
an $800 ink jet printer among others. If you want such RAW files from a
lowly $900 Canon 350 Rebel let me know.
Everybody is obsessing over a small subset of very
saturated colors!
That's like saying a photographer who prefers the look
of Velvia is obsessing over saturated colors that can't be produced on
Ekatchrome. Are you really proposing that? Because I think I can fill a
room at PhotoPlus Expo with shooters who would gladly obsess over that
added saturation in a chrome they can't possibly place on a four color
press (but might on a Ciba). Digital capture can represent a far wider
color gamut than any E-6 film.
For the most part we should be more concerned with
color
relationships and tonal compression. Until we have
high dynamic range
backlit displays being used for final output, images
printed on paper
should be our primary concern.
I need all the colors to DECIDE what to compress. If
you throw them away from the start, I can't do that.
Images printed on paper are evaluated
in the context of that paper! Making images that have
a range of
tones and colors that look good to a human observer
does not require
working in ProPhoto RGB or 16bits.
No but at this point, I have the option of containing
the colors or throwing them away forever. In ProPhoto, I can decide today
or in the future how I want to hand out those colors. In Adobe RGB (1998)
it's gone. Yes I can go back to my RAW file but that's akin to going back
to my color negative and making another custom print, spotting it and so
forth. Why do this twice?
Wasting data by spreading it out in a huge erratically
shaped color
space just to "hit" a saturated color that
falls well outside of an
editing environment seems to me to be counter
productive because it
does nothing to make it easier to work within the
constraints of
fairly small output spaces.
There's no waste. Throwing away the color is a waste.
It's not erratically shaped. It's shaped this way for a very good reason.
My proposition in photo centric terms is, if you shoot an 8x10, it's silly
to now process the image and take scissors to the it and crop it down to
4x5.
I've never seen anyone complain about the colors of a
Lightjet
photographic print yet the Lightjet has a color gamut
slightly
smaller than sRGB!
And you did this with a ProPhoto RGB image as well
with a scene that contained data outside of sRGB? If not, I can fully
understand why no one would complain. Talk about imagery colors!
And Lee, whatever profile you used to compare the
Lightjet to sRGB is crap. It's absolutely not smaller. I have
profiles made for a Lightjet at Pictopia. There's quite a nice slice of
many colors that fall outside sRGB like yellows, greens and magentas. Less
so in Adobe RGB (1998) but even with that color space, the Lightjet
produces colors outside it's gamut (yellow and magenta).
We're not trying to "contain" color but to
translate it so that it
works in a completely different context.
If you can't contain them, you can't use them or
translate them.
Andrew Rodney
____________________________________________________________________________
Date: Sun, 04 Sep 2005 12:58:39 -0600
From: Andrew Rodney
Subject: Eighteen Questions about Dan's new LAB book
(16-bit challenge)
On 9/3/05 7:02 PM, "Dan Margulis"
wrote:
I will probably take you up on the
offer to provide the raw file, provided you are
willing to give me permission
to publish it.
I1ve uploaded this RAW file (CRW_0775.CRW) to the same
location as the other files (I1ve over-written the original ZIP archive and
it is now 9.5mb). The ZIP archive still contains all the other files in
addition to this RAW file and the XMP data used to define it in ACR (you
should be able to import this to set my ACR settings on this RAW or simply
turn everything off there). The full image isn1t quite as ugly in total
(it1s a shot of my new office being constructed). I still want to shoot
other scenes but this should do for the time being.
To download:
http://www.digitaldog.net/files/16bitchallange.zip
The other interesting item is while this doesn1t at
all appear to be a scene containing saturated colors, in ACR, I do see
clipping when I set the output color space to Adobe RGB (1998) but not
ProPhoto RGB. You1ll see that there1s a pretty large blue clip on the far
left of the histogram in Adobe RGB (1998), none when you toggle to ProPhoto
RGB. This is the yellow flowers in the foreground. The camera is rendering
the RAW file such that these colors are outside the gamut of Adobe RGB
(1998).
An interesting exercise in this respect can be seen
using the new crop tool. Crop a small area of the total image (say 25%),
move it around from the yellow flowers to the blue sky as you toggle the
various color spaces while viewing the histogram. A solid color clipping
will show the complementary color falling out of gamut. White would be full
clipping (all three color channels). Lower the saturation slider and see
how the fully saturated colors that clip are affected. Another poster asked
of Lee 3do you shoot flower2? This isn1t by any stretch of the imagination
a scene one would say has bright, saturated colors and yet, if the goal is
to at the very least contain and possibly use colors captured, encoding
into Adobe RGB (1998) would clip our yellow flowers.
Then next logical question would be, can you use those
yellow colors? The answer is, it depends. I converted the RAW in both Adobe
RGB (1998) and ProPhoto and using ColorThink, I can actually plot the
colors of an actual image on top of the gamut of an output device. Very
cool feature. Anyway, using my Epson 2400, there1s a significantly larger
amount of yellow I can actually use from the ProPhoto file. I1ve placed a
screen capture in the Zip archive. You1re seeing the gamut of the Epson
2400 in actual color. In the bottom you can see the yellows. The red dots
are the gamut of the image (cropped to just flowers) in Adobe RGB (1998).
The green is the same image but in ProPhoto RGB. You1ll see there ARE
yellow colors that fall outside the printer gamut. Yet far more
greens dots (ProPhoto RGB) fall within gamut compared to Adobe RGB (1998)
which can1t hold colors that the wider gamut file can use for output.
If the yellow in this image isn1t important to you,
then neither is the use of ProPhoto. However, if the yellow (and other
colors) are important, the output device can use them with the wider gamut
color space. You can also see the amount of yellow gamut we would throw
away by going directly to Adobe RGB (1998) instead of simply holding onto
them by using ProPhoto RGB.
Enough color theory, time to grill burgers.
Andrew Rodney
____________________________________________________________________________
Date: Sun, 4 Sep 2005 20:05:14 -0700
From: Lee Varis
Subject: Re: Eighteen Questions about Dan's new LAB
book
On Sep 4, 2005, at 10:08 AM, Iliah Borg wrote:
Dear Lee, have you tried taking images of flowers, red
roses, for example?
Yes.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Sun, 4 Sep 2005 20:19:28 -0700
From: Lee Varis
Subject: Re: Eighteen Questions about Dan's new LAB
book
On Sep 4, 2005, at 10:48 AM, Andrew Rodney wrote:
Sorry Lee but that's just silly talk.
I'm not going to respond to any more of your
objections as you pointedly refuse to understand the points I'm making and
instead reiterate your first and only rant about color gamut, throwing away
colors, etc... We get it... we've all heard this time and time again -
someday sometime in the future it might mean something - right now I've got
work to do getting some images to look good on a piece of paper. Don't
worry, I'm holding on to my raw files though I expect that the carefully
crafted prints I'm saving for my grandkids will be worth more money 30
years from now when they're considered collectable because they are done
using some antique process by the original artist!
Over and out!
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
From: Werner Tschan
Date: MonÊSepÊ5,Ê2005Ê 4:53 am
Subject: Re: [colortheory] Eighteen Questions about
Dan's new LAB book
Andrew Rodney wrote:
So you agree that there's some advantage of high bit
editing, all
corrections being equal? I suspect the forum host
doesn't agree with that or
at least, has been asking for side by side
comparisons. I don't recall the
working space being part of this challenge.
I've been following this forums discussions about bit
depth for some time. I am gald that after all you found one situation that
proofs you right. I have great respect for your knowledge, only, I wonder
where you guys take the time to go through such length to prove your
(religious) beliefs.
Thanks anyway for the entertainment you offer to the
readers of the list! I have to stop here. Got to correct 63 files for print
until this afternoon. I guess I'll go for 8 bit this time...
Werner Tschan
____________________________________________________________________________
From: Ric Cohn
Date: MonÊSepÊ5,Ê2005Ê 12:30 pm
Subject: Re: [colortheory] Eighteen Questions about
Dan's new LAB book
On Sep 4, 2005, at 10:55 AM, Andrew Rodney wrote:
Dither is used for color space conversions which can
be turned on or off in
color settings and only affects 8-bit data. I did no
color conversions. The
file went from RAW to ProPhoto RGB in ACR. You might
want to try converting
after the edits on both to some output color space to
see if things in 8-bit
get even worse.
Indeed the preference does say it's for 8 bit
transforms, but my experience and my results suggest that Photoshop applies
the dither in the 16 bit to 8 bit conversion if this preference is checked.
I'd say this behavior should at least be acknowledged. It's not always bad
as I personally experienced the advantages in reducing banding when I did
my 16 Bit vs. 8 Bit comparison a few years ago.
Take an unsharpened file, use the Add Noise filter and
I'll bet it appears a bit sharper. I don't know anyone advocating the use
of noise to make images look sharper <g>
Not sharper per se, but I sometimes add noise to my
digital captures. I frequently find that the digital captures smoothness
(I'd say Unnatural smoothness) rather ugly. I like variations and
imperfections and believe that a smooth histogram can be a sign of trouble,
but not in the way that those that hate gaps mean. What would be
interesting to me would be to look at the histograms of images (both
paintings and photographs) I find beautiful or emotionally affecting. I
remember a similar study of music tonal variations from my college days
that was very revealing.
Ric Cohn
___________________________________________________________________________
Date: Wed, 07 Sep 2005 17:41:38 -0400
From: Ric Cohn
Subject: Ideal 8 bit working space?
Thanks to Andrew's test pointing out the dangers of
wide gamut working spaces when working in 8 bits, I've been thinking again
about which space is best for working in 8 bits. I'm interested in
containing enough color gamut for any existing process without getting any
bigger than needed. Since very little of my work is high croma with super
saturated colors I don't buy into the "capture everything and stay in
16 bit" argument. IMO AdobeRGB is OK, but it's mostly an accidental
working space and I can't help feeling there are others that are better
shaped. I have used Bruce Lindblooms BestRGB http://brucelindbloom.com/
when doing scans and it might fit the bill. I know CIE has an RGB space and
there's a space called (I think) LStarRGB. I don't know enough about the
ramifications of any of these spaces to evaluate their superiority to
AdobeRGB.
BTW, when I am shooting for clients and the images
color fits within ColorMatchRGB, and I'm supplying RGB files, I use that.
Sometimes just sending clients images in a wider gamut space even when the
captures are well contained can cause problems if they muck with the files-
too easy to make something that looks good on screen and can't be printed.
I think this is less of a problem now that more retouchers and printers are
getting used to RGB.
What do people think would be the chosen working space
for 8 bit if we could all start over without the existence of any current
working spaces? ProRGB seems fine for 16 bits. It has almost all the lab
colors- of course, it also has a big area outside even LAB.
Ric Cohn
___________________________________________________________________________
Date: Mon, 19 Sep 2005 14:07:43 +0200
From: Ben Richardson
Subject: 8 vs. 16 bit and banding
My first post, so I've picked a nice thorny subject -
bit depth!
I work mainly in 8 bit, largely because of the
high-resolution and multi-layered nature of my work. Even on fast G5s with
lots of RAM I still find Photoshop bogs down in 16 bit. Plus, I've never
seen visible improvements through wrestling with a 16 bit workflow - except
for one little detail...
My clients generally want major changes from reality -
masked and multi-layered retouches, composites and colour changes. Towards
the end of a given job some smooth-ish gradients - artificially added or
enhanced flare, dark or darkened natural skies and shadow areas on skin,
for example - can exhibit banding. Usually a little noise in the right
spots does the trick, but sometimes it's more stubborn.
I've found that almost all of these problems can be
safely ignored while working and then totally eliminated by simply
promoting the finished, multi-layered 8 bit PSD work-file to 16 bit BEFORE
flattening, THEN flattening, then going straight back to 8 bit. It only
costs you the time to do one simple calculation in 16 bit (the
flattening) and I have seen real, visible improvements in problem areas of
the same file flattened normally in 8 bit and then flattened this way. (At
least, improvements on screen and Matchprints - I've always treated problem
files in this way before going to print.)
Are these problems caused purely by 8 bit rounding
errors? In my work- around, is the 16 bit math really helping, or am I just
seeing the result of two applications of the fine dithering Photoshop adds
during mode changes?
Does Photoshop do any kind of dithering during normal
flattening?
Would these problems even make it through to press?
I understand that certain moving-picture
film-compositing packages allow the user to force the math into a higher
depth than the working image data, or even to "float", where
values can temporarily exceed the usual 0 and 255 clipping points. Would
Photoshop benefit from doing something like this internally by default?
Ben Richardson
P.S. I note that Dan generally recommends getting
source files from scanners, etc. in their native 16 bit and then converting
to 8 bit in Photoshop as a first step (rather than taking scanner 8 bit
output - see Professional Photoshop 4th ed. pp. 316-318). Might this make
an occasionally useful and equivalent last step?
____________________________________________________________________________
Date: Mon, 19 Sep 2005 12:02:05 -0700
From: "Mike Russell"
Subject: Re: 8 vs. 16 bit and banding
From: "Ben Richardson"
...
I've found that almost [banding] problems can be
safely ignored
while working and then totally eliminated by simply
promoting the
finished, multi-layered 8 bit PSD work-file to 16 bit
BEFORE
flattening, THEN flattening, then going straight back
to 8 bit.
...
This is almost certainly due to the fact that
Photoshop adds about 1/2 bit of noise when converting from 16 bit to 8 bit.
...
I understand that certain moving-picture
film-compositing packages
allow the user to force the math into a higher depth
than the working
image data, or even to "float", where values
can temporarily exceed
the usual 0 and 255 clipping points. Would Photoshop
benefit from
doing something like this internally by default?
Certainly. For example, using the RGB or CMYK
composite curve introduces a level of quantization, caused by an additional
table lookup. This can be avoided by combining the curves using
floating point before generating a single look up table. People who
work on software worry about this sort of thing, and the result may be
beneficial, from a mathematical standpoint, but it is doubtful whether
anyone will see this in the final image.
Personally, I use 8 bits and sRGB for almost all of my
work, but as a tool writer I fully support those who chose to do otherwise,
for whatever reason.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Mon, 19 Sep 2005 16:07:07 -0400
From: Ric Cohn
Subject: Re: 8 vs. 16 bit and banding
On Sep 19, 2005, at 8:07 AM, Ben Richardson wrote:
Are these problems caused purely by 8 bit rounding
errors? In my work-
around, is the 16 bit math really helping, or am I
just seeing the
result of two applications of the fine dithering
Photoshop adds
during mode changes?
Does Photoshop do any kind of dithering during normal
flattening?
Would these problems even make it through to press?
All good questions. Some answers don't seem to be
fully documented for PS.
How PS handles gradients in things like Masks and
Alpha Channels is of interest to me. I noticed some of issues you raised
about working with these in 8 bit and also when converting these from 16
bit to 8 bit. I'm particularly interested in your statement:
I've found that almost all of these problems can be
safely ignored
while working and then totally eliminated by simply
promoting the
finished, multi-layered 8 bit PSD work-file to 16 bit
BEFORE
flattening, THEN flattening, then going straight back
to 8 bit.
If this is indeed the case, then moving to 16 bit when
creating certain kinds of masks might make sense for me when working with
files that require this. Perhaps like Lab we'll discover that 16 bit has
unexpected uses! I'd like to hear more from others who agree or disagree.
Ric Cohn
____________________________________________________________________________
Date: Tue, 20 Sep 2005 22:23:18 +1000
From: Stephen Marsh
Subject: Re: 8 vs. 16 bit and banding
Ric Cohn wrote in reply to the post from Ben
Richardson :
If this is indeed the case, then moving to 16 bit when
creating certain
kinds of masks might make sense for me when working
with files that
require this. Perhaps like Lab we'll discover that 16
bit has
unexpected uses! I'd like to hear more from others who
agree or
disagree.
Generating a CG radial mono gradient seems to be the
most taxing test in Photoshop, if not real world photographic. I have not
tested in CS2, but this should show banding, with or without the
gradient tool dither option, if anything would (not sure if video card
plays an issue or if it is in output too).
On a similar point, but more real world than a CG
gradient:
An old technique to alter tone, is to desaturate a RGB
duped layer, invert it, blend in overlay at X% opacity and apply a large
gaussian blur to suit. This blurred monotone channel can show banding when
performing the large blur (again, not sure if a monitor artifact in all
cases). Again, if memory serves me correct, this time blurring in high bit
does help smooth things out a little compared to regular bit processing
(and one has dither added going back to 8bpc).
An alternative to blurring in high bit, would be to
add minor noise to the blurred layer (perhaps protecting the endpoints).
This is more aggressive noise when compared to the bit switch dither, but
one can make it minimal or strong to suit without having to process in high
bits.
Stephen Marsh.
____________________________________________________________________________
Date: Tue, 20 Sep 2005 11:31:25 -0400
From: Ric Cohn
Subject: Re: Re: 8 vs. 16 bit and banding
On Sep 20, 2005, at 8:23 AM, Stephen Marsh wrote:
An alternative to blurring in high bit, would be to
add minor noise to the
blurred layer (perhaps protecting the endpoints). This
is more aggressive
noise when compared to the bit switch dither, but one
can make it minimal or
strong to suit without having to process in high bits.
This is what I've always done when banding of these
channels is a problem. I usually use the Blend-If sliders to keep pure
blacks and whites clean (i.e. protect the endpoints). This almost always
does it, but there are rare occasions where the noise creates its own
problems and protecting the endpoints can take longer than switching in and
out of 16 bit if this would fix it. The question is whether it would. I
haven't done extensive tests myself, but would like to hear others
experiences.
Ric Cohn
____________________________________________________________________________
Date: Fri, 23 Sep 2005 12:54:31 EDT
From: Dan Margulis
Subject: Response to Andrew Rodney's test
Prior to my trip to Photoshop World, Andrew Rodney
posted a link to an image as part of his never-ending attempt to explain
how his business partners can say that correcting in 16-bit is what
differentiates a professional from a recreational user, how it creates a
night and day difference, how the advantage is totally obvious to everyone
who looks, etc., etc. Lee Varis posted a response with which I concur, but
I did not myself have time to look at the image closely and said I would do
so in future weeks.
As I indicated in my first brief response, the example
is meaningless, because it assumes a condition that I have always excluded,
and that wasn't even known at the time his partners said those things. I
have always made clear that exotic RGB definitions, such as 1.0 gamma, or
ultra-wide gamut RGBs, are not tested because, first, almost nobody uses
them, and second, those knowledgeable about color correction would be
unlikely to edit in them except under very unusual circumstances.
Andrew's test depends on using such a space, an
ultra-wide gamut RGB known as ProPhoto. This space was not installed in
Photoshop until 2003, and since his partners made the remarks about night
and day differences and professionals and recreational users long before
that, they cannot possibly have been referring to it.
The image is an outdoor scene. A laborer, on his
knees, is laying a cement deck or patio. There is greenery and yellow
flowers in the foreground; the patio takes up almost a third of the
picture. The laborer is relatively small. His face is in shadow. The
background ground cover is yellowish. On the whole one would describe the
colors as subdued. The picture isn't ridiculously dark but it certainly
needs to be lightened.
Lee Varis correctly characterized such RGB spaces as
"like using a sledge hammer to drive finishing nails". By that,
he meant that the are too imprecise to be used in serious image
manipulation, because most of their possible color values are either well
out of any reproduction gamut or totally imaginary. This image is a perfect
example: the large patio is basically gray, however there is a certain
amount of variability, with some parts slightly redder and others cooler.
During the correction process, we need to be sure that these colors don't
get out of hand so that the patio looks like a rainbow rather than cement.
Doing so is no sweat in any rational RGB. We just try to have the three RGB
values be approximately equal throughout the area, understanding that
exactly equal isn't going to happen.
But in an ultra-wide gamut RGB, it's much more
difficult, as the values have to be kept much closer to absolute equality,
because colors get brilliant very rapidly in such a space. Consequently,
maintaining neutrality in such an image during correction is a nasty
problem in an ultra-wide gamut RGB and no problem at all in LAB, CMYK, or a
rational RGB.
Because any small variation in an ultra-wide gamut
RGBs is actually a huge variation in output color, the tiny differences
between a file prepared in 8-bit and one in 16-bit are magnified. In
realistic RGBs, these differences are so slight that nobody notices them no
matter how much they are affected by later edits. But in an ultra-wide
gamut RGB, it is at least conceivable that certain images will look better
if they are worked on in 8-bit and others will look better if done in
16-bit.
In Andrew's procedure the image is not edited in
Camera Raw, but is exported to 16-bit ProPhoto. The test calls for making a
second copy which is then converted to 8-bit. Then, to both, one
master-channel Levels command is applied, followed by one increase to
master saturation in the Hue/Saturation command, followed by one unsharp
mask filter.
In examining the image, I looked at not just these two
variants, but several others in ProPhoto, as well as 8-bit and 16-bit Adobe
RGB using exactly the same commands, and 8-bit sRGB where I used the same
commands but attempted to strengthen them to match the look of the ProPhoto
files.
The error in Andrew's method is in his final step.
After the levels and Hue/Sat moves, the two versions can't be told apart
without great difficulty. However, his sharpening settings have a Threshold
(noise reduction) of 0. This causes a problem specific to ultra-wide gamut
RGBs.
Any file corrected in 8-bit will be very slightly
grainier than one corrected in 16-bit. In rational RGBs, this difference is
so imperceptible that it makes no difference in the sharpening process. In
an ultra-wide gamut RGB, it can be seen IF you specifically use a zero
threshold. In that case, you will see two definitely different images, as
we do in this case. (Andrew concedes that when these same moves are applied
in Adobe RGB, the two images are the same for all practical purposes).
In the ProPhoto version the difference manifests
itself in a more active-looking 8-bit file. It has more noise in shadow
areas, particularly in the worker's face and in an area of the background.
I agree that these things are bad. However, it has slightly more
believability in the foreground greenery and in the concrete, which are
more prominent items. I believe that this is the reason that when Lee Varis
printed out the two files and showed them to another observer without
explaining which was which, the observer picked the 8-bit version as being
better.
While it's arguable whether the image taken as a whole
is better or worse, certainly Andrew is entitled to object to the
graininess. What he is not entitled to do is, when there are several
equivalent ways available with no extra effort, intentionally choose the
one that magnifies the effect that he says he doesn't like. In the sharpen
filter, the Amount and Threshold commands work in tandem. A higher
Threshold slightly diminishes the sharpening effect, and we compensate by
raising the Amount. Minute changes are possible, so that there are, in
effect, many different ways of creating substantially the same effect. By
raising the Threshold even to 1 (although I would choose 2) and adding a
corresponding increase in Amount, the 8-bit and 16-bit images are again
qualitatively equal regardless of which of the three settings is used for
the 16-bit file. I also experimented with much larger sharpening Amounts
with the same result.
It should also be pointed out that the graininess is
more a function of the ultra-wide gamut RGB than it is of the bit depth. As
noted, I did another version in 8-bit sRGB. It's impossible to duplicate
the 16-bit ProPhoto exercise exactly, as much stronger corrections are
required in sRGB to achieve the same look. But I got as close as I could,
including sharpening with a zero Threshold. The 8-bit sRGB file looked
smoother than the one done in 16-bit ProPhoto.
In short, this image does not show an advantage,
because the part of it that Andrew complains about could have been avoided
with no extra effort and no loss in quality. Intentionally choosing an
inappropriate sharpening setting is not a real-world move.
What *would* constitute an advantage? As I indicated
in my first post, a list member showed one. An overly dark image needed to
be lightened. However, it was deliberately sabotaged in Camera Raw by
turning the exposure control all the way down. Then, it was exported into
8- and 16-bit ProPhoto and Adobe RGB, where simple curves were applied to
lighten the image grossly. In Adobe RGB there was no preference between the
two versions. In ProPhoto, however, serious noise developed in the sky in
the 8-bit version that wasn't present in the 16-bit. Now, unlike Andrew's
image where it might reasonably be argued that the 8-bit version was
*better,* in this one everybody would agree that it was worse, no question.
And, unlike Andrew's image, there was no means of avoiding the problem in
the same number of steps. The 8-bit picture would have to be corrected
further to match the quality of the 16-bit.
The image showing 16-bit superiority isn't real-world
because it was sabotaged in Camera Raw. Andrew's image, which wasn't so
sabotaged, doesn't show superiority. OTOH, it wasn't corrected particularly
brutally either. So, I would have to suspect that it would be possible to
find a real-world image that is somewhere in the middle--that is, no
sabotage, but a more extreme correction, causing clear superiority in the
16-bit version. Similarly, one would expect to find certain files that
would correct better in 8-bit than 16-bit.
If you are misguided enough to work in an ultra-wide
gamut RGB, that is.
To summarize: working with actual images is a useful
exercise, and we should thank Andrew for making this one available. It does
not actually show an advantage for 16-bit manipulation in ProPhoto RGB, but
in all probability he could have constructed an image that did if he had
worked harder at it. If somebody wishes to produce such an image, I will be
happy to note it parenthetically in the next edition of Professional
Photoshop, but I am not interested in further testing of ultra-wide gamut
RGBs as correction spaces myself, as their disadvantages are such that
their use can be recommended only in highly specialized situations.
At bottom, though, it's just another attempt to blow
smoke over the inability to back up his partners' extravagant claims.
Granted, this time it's not a histogram or a gradient or a sabotaged image.
But still, it requires a certain revision of the original 2001-2002 claims.
Perhaps Andrew will allow us to revise them: instead of saying that there
is a night-and-day, totally obvious to everyone who looks, professional vs.
recreational user difference when correcting color photographs in 16-bit,
we can modify it as follows:
"If you correct in 8-bit rather than 16-bit, you
are not currently a recreational rather than professional user, and you
will not currently see a night-and-day, totally-obvious-to-anyone-who-looks
difference, but if you continue to do so, in two or three years when
ProPhoto RGB is introduced into Photoshop, you *will* be a recreational
rather than professional user, by God, and you *will* see a night-and-day,
totally-obvious-to-anyone-who-looks difference, unless you are one of the
99.9% of users intelligent enough not to attempt major edits in an
ultra-wide gamut RGB."
If Andrew can live with that as a resolution, I
certainly can.
Dan Margulis
____________________________________________________________________________
Date: Fri, 23 Sep 2005 11:49:50 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/23/05 10:54 AM, "Dan Margulis"
wrote:
I have always made clear that
exotic RGB definitions, such as 1.0 gamma, or
ultra-wide gamut RGBs, are not
tested because, first, almost nobody uses them, and
second, those
knowledgeable about color correction would be unlikely
to edit in them except under very
unusual circumstances.
With all due respect Dan, thatxs nonsense. Nobody uses
the? The edits here are unusual? Many professional users, many digital
photographers use ProPhoto RGB. Every edit in Adobe Camera RAW no matter
what color space encoding you select or what bit depth happens in ProPhoto
RGB with a 1.0 gamma prior being presented to the user.
I can (and I think did) illustrate that to anyone that
wants to examine the image in Adobe Camera RAW, the scene gamut cannot be
fully exploited in Adobe RGB (1998) and can in ProPhoto in 16-bit (as it
can in 8-bit with obvious appearing noise).
I didnxt expect this scene or any additional scenes I
can capture with this sub $1000 camera to xfitx your criteria since once
again, that seems to be a moving target. So Ixve come to the conclusion
that no matter what one does to try to show the advantage of high bit
editing, it will fall on at least two deaf ears. Others who wish to
download the image can clearly see for themselves the downside of using
8-bits compared to high bit with the example I posted. They can decide for
themselves that there ARE real world, non synthetic images that fall
outside Adobe RGB (1998) gamut (as does my $800 Epson 2400) that benefit
from high bit editing.
The error in Andrew's method is in his final step.
After the levels and
Hue/Sat moves, the two versions can't be told apart
without great difficulty.
However, his sharpening settings have a Threshold
(noise reduction) of 0. This
causes a problem specific to ultra-wide gamut RGBs.
Dan, you can see the effect of the noise in the 8-bit
version without any USM. NONE was applied in ACR, the image is in serious
need of sharpening but none the less, the noise is present without it. More
editing will produce a greater effect of showing this. We have no idea what
will happen with future editing, conversions to other color spaces for
output, resizing etc. As Ixve stated in the past, the use of high bit
simply provides more editing headroom. To dismiss the obvious effect of
this noise by saying that xthis or that editx isnxt kosher when the edits
do not show degradation in the high bit file is simply another effect of
sticking onexs head in the sand. This is and has always been the advantage
of high bit editing!
Any file corrected in 8-bit will be very slightly
grainier than one corrected
in 16-bit.
Noiser in shadows with a very odd speckling? Yes, I
see that. Thatxs not a useful attribute to induce on a file unless you want
such an effect. Itxs not seen on the high bit file.
(Andrew concedes that
when these same moves are applied in Adobe RGB, the
two images are the same
for all practical purposes).
Yes I do, with a significant amount of color
information I can use tossed away in the process. It sounds like youxre in
favor of using ultra-small gamut RGB working spaces in 8-bit.
Dan, you can apply a Gaussian blur to the image and
remove the noise but no one is suggesting this is a good way to remove the
noise or smooth out a histogram. Bottom line is one editing routine doesnxt
produce this effect of noise, the other does. I want the color available
for output without the noise, I can accomplish this in high bit.
In the ProPhoto version the difference manifests
itself in a more
active-looking 8-bit file. It has more noise in shadow
areas, particularly in
the worker's face and in an area of the background. I
agree that these things are
bad.
While it's arguable whether the image taken as a whole
is better or worse,
certainly Andrew is entitled to object to the
graininess.
Well I consider that some progress <g>
It should also be pointed out that the graininess is
more a function of the
ultra-wide gamut RGB than it is of the bit depth.
Indeed it is. The scene and the file require this wide
gamut space since I can, will and want to use those colors to the output
devices I have available today. In the future, I would expect even wider
gamut devices to be at my disposal. Other than the file being twice the
size, whatxs the problem?
If you are misguided enough to work in an ultra-wide
gamut RGB, that is.
The same effect can be seen in LAB which is a ultra
wide gamut space! I can clearly see similar noise issues in 8-bit LAB
versus high bit LAB.
At bottom, though, it's just another attempt to blow
smoke over the inability
to back up his partners' extravagant claims.
Anyone other than Dan taking this statement at face
value should consider looking at the RAW file, converting both ways and
using whatever corrections they wish. Therexs no smoke here. The data is
there for anyone to see. But since once again, the rules of this silly
challenge have changed, I have to join the ranks of those such as Bruce
Lindbloom as someone that finds more smoke in Danxs challenge than anything
else. So know we have to show a difference between the two using what gamut
working space?
"If you correct in 8-bit rather than 16-bit, you
are not currently a
recreational rather than professional user, and you
will not currently see a
night-and-day,
totally-obvious-to-anyone-who-looks difference, but if you
continue to do so, in two or three years when ProPhoto
RGB is introduced into Photoshop,
you *will* be a recreational rather than professional
user, by God, and you
*will* see a night-and-day,
totally-obvious-to-anyone-who-looks difference,
unless you are one of the 99.9% of users intelligent
enough not to attempt major
edits in an ultra-wide gamut RGB."
I think that quote about recreational users is someone
else's however, I still agree that itxs pretty obvious in the current
example that therexs a visible and obvious benefit of the high bit editing
versus the 8-bit editing. And if you can back up the statement that 99.9%
of users do not use ProPhoto RGB, Ixd love to see some empirical data to
back that up. Once again, you appear to the one blowing smoke by implying
you have the xear of the industryx by saying that less than 1% of users are
working in this space. I have no statxs to provide but I do know of many
digital photographers are working in this space. I certainly would not go
on record as you have to say itxs a mere 1% and all of them are lacking
intelligence.
Once again, Ixve provided empirical data to show that
many scenes captured with just a prosumer digital camera fall way outside
Adobe RGB (1998) gamut as does a number of Prosumer desktop printers. If
those colors are not important to you, fine. The challenge is so undefined
and moving that you should really add that the xtestsx have to be done in
this or that space, using this or that edit, using this or that RAW
converter. The effects of the edits on an 8-bit file ARE visible in
synthetic images and have always been so but that didnxt wash with you.
Now, with a real world image that is basically a snapshot, the issue is the
working space. What next?
Andrew Rodney
____________________________________________________________________________
Date: Fri, 23 Sep 2005 14:36:10 -0400
From: Ric Cohn
Subject: Re: Response to Andrew Rodney's test
Dan,
Thanks for the thorough and thoughtful posting.
However, I fear the fox is already among the chickens. ProPhotoRGB is now
essentially a "sanctioned" Photoshop workspace. It is one of the
4 output choices for Camera Raw, and I have seen it heavily promoted as a
digital output space since it loses no potential capture colors. I have
seen few warnings about using it in 8 bit, which isn't that surprising
since virtually everyone who advocates this workspace also advocates
editing in 16 bits. I suspect it's very presence in Camera Raw is somewhat
related to the power (good or bad I don't really know) that this group has
over the Photoshop development team. AFAIK, there is no warning if you want
to process Raw files to 8 Bit ProRGB although I think it's clear from
Andrew's test that working with ProRGB in 8 Bit is a dangerous thing to do.
I would not be surprised to see it added at one of the choices from the
Color Preferences dialog box. In any case, it's presence in Camera Raw
virtually guarantees that significant numbers of Amateurs with digital
cameras will be doing most or all of their image editing in ProRGB.
Your contention that small moves in ProRGB make very
large and less controllable changes to a file make it sound like Lab. Of
course, for Lab you have always stated that it is excellent for making
large changes, but that for maximum quality you should expect to make final
adjustments in RGB or CMYK. Andrew, Bruce Fraser, and other ProRGB
advocates must either be ignorant of this or disagree with you on this
because it is quite clear from their writings that they stay in ProRGB all
the way through to output or conversion. I'm sure if they disagree we will
hear from them, and I look forward to another educational exchange of
ideas- hopefully without vitriol from either side!
I've looked at ProRGB with Lab conversions and it
seems totally unsuitable to the manipulation of imaginary colors as
discussed in Canyon. Since ProRGB also contains these imaginary Lab colors
they get converted back to white or near white! From my limited testing I'd
say a ProRGB workflow and using Lab for these kinds of corrections
are mutually exclusive.
Finally, this brings me back to my question about an
"ideal" RGB working space. I think it is reasonable to find sRGB
and ColorMatchRGB unsuitable for some images. They both limit colors that
are viewable on existing good monitors and printable with existing output
devices. AdobeRGB does get most of these colors, but I'm not convinced it's
an ideal space either. It was created by accident and it seems possible to
construct a space that is both smaller and contains virtually all currently
printable colors. A number of color geeks have created other working spaces
which attempt to address these issues. However, no space is likely to get
wide acceptance unless it is adopted by Photoshop the way ProPhotoRGB has
been. Do any color space/gamut experts on this list feel one space is
clearly superior? The ones I can think of off the top of my head are:
L-StarRGB, BetaRGB, BestRGB and DonRGB, I'm sure there are many others.
Ric Cohn
____________________________________________________________________________
Date: Fri, 23 Sep 2005 13:30:04 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/23/05 12:36 PM, "Ric Cohn" wrote:
Finally, this brings me back to my question about an
"ideal" RGB
working space.
No such space exists or wexd all be using one.
It was created by accident and it seems possible to
construct a space that is both smaller and contains
virtually all
currently printable colors.
It was created by accident, a funny story but a bit
off topic. Since 1988, itxs behaved quite well despite the mixup in
chromaticity values. Anyway, there are output devices whoxs gamuts fall
outside of Adobe RGB (1998). As I mentioned I have one sitting here that
cost less than $800.
Do any color space/gamut experts on this list
feel one space is clearly superior?
Depends on your goals. If you want to contain all the
colors you can capture, itxs ProPhoto RGB. If you are sending files to
a PC user how hasnxt a clue about ICC aware applications, sRGB. For a
Mac user, ColorMatch RGB. As you can see, there is no one size fits all,
prefect space. If I begin with ProPhoto RGB to attempt to have a file I can
actually work with from RAW data, I can then convert to a smaller space. I
canxt go the opposite direction.
Andrew Rodney
____________________________________________________________________________
Date: Fri, 23 Sep 2005 16:57:32 -0400
From: "Iliah Borg"
Subject: Re: Response to Andrew Rodney's test
On Fri, 23 Sep 2005 13:30:04 -0600 Andrew Rodney wrote:
If you want to contain all the colors you can capture,
I'm afraid I do ot understand that. We capture colours
with digital cameras as gray levels. We reconstruct those colours at
raw convertion stage. This reconstruction often includes inventing colours,
as far as I see it.
Best regards,
ib
____________________________________________________________________________
Date: Fri, 23 Sep 2005 17:13:42 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
The rendering produces colors based on the color
mixing function of the chip from the RAW Grayscale data.
You can easily see if the rendering exceeds or doesnxt
exceed the gamut of the working space you select in Adobe Camera RAW by
looking at the Histogram as you toggle from one to the other supported
space. I find all kinds of scene data rendered such that therexs one or
more colors clipping in a smaller working space like Adobe RGB (1998) and
fully contained in ProPhoto. Of course you can alter the rendering before
the color space encoding all you wish. If you saw clipping in Adobe RGB
(1998) you could lower the saturation. Or the opposite; raise the
saturation to an ugly level such that you might very well produce one or
more colors clipping even in ProPhoto RGB. But I donxt know why youxd make
the file over saturated and ugly on purpose. Point is, the scene data and
the color mixing function is such that you can produce a color appearance
you desire in any of the working space supported but introduce clipping in
sRGB, ColorMatch RGB and Adobe RGB (1998) but NOT in ProPhoto RGB. Youxve
now contained the colors in that working space you would have toss away in
the other three. I donxt see why thatxs a useful practice if you want to
use those colors. Of course, I would suggest you do so in 16-bit, the point
of this entire post.
Andrew Rodney
____________________________________________________________________________
Date: Fri, 23 Sep 2005 18:56:40 -0600
From: Ron Kelly
Subject: Re: Response to Andrew Rodney's test
Andrew:
This sounds analagous to shooting everything with a
wide angle lens because "you never know if you might need it in the
future for cropping purposes" type of thing. Your final quality is
hurt by the fact that you had to crop the picture so much.
Obviously the analogy is not apt in that as
photographers we can shoot things many ways but we're unlikely to use
multiple workspaces.
However, I think that it is applicable in that there
is some truth to the idea that using an overly wide gamut space has it's
downsides. Capturing all the colours that a device can get is not as
important for the type of work that I do as getting good control of the
colours I have.
In other words, I'd rather not obsess over potentially
missing mice in my picture(s) when I'm trying to concentrate on the
elephants walking through it.
Ron Kelly
____________________________________________________________________________
Date: Fri, 23 Sep 2005 18:02:33 -0700
From: Peter Figen
Subject: Re: Response to Andrew Rodney's test
There seems to be an obsession with range of colors,
as if that were the only thing that validated the image. Maybe that's why
most of my favorite images have been shot on Tri-X.
Peter Figen
____________________________________________________________________________
Date: Fri, 23 Sep 2005 19:20:28 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/23/05 6:56 PM, "Ron Kelly" wrote:
This sounds analagous to shooting everything with a
wide angle lens
because "you never know if you might need it in
the future for
cropping purposes" type of thing.
As a Photographer, I find that a poor analogy. I would
most certainly lose something by using a wide angle and then cropping like
crazy when I could have used a longer lens.
A better analogy would be always shooting in 8x10
because you have one big honking piece of film. While thatxs true, there
are all kinds if scenes I simply canxt shoot in 8x10 and in fact, 35mm with
a motor drive is the way to go (I shot the 84 Olympics for the LAOOC and
without fast lens, motor drives and 35mm, Ixd have lost a lot of good
shots).
However, I think that it is applicable in that there
is some truth to
the idea that using an overly wide gamut space has
it's downsides.
In 8-bit, yes which has been my point. There are
colors that fall outside display gamut you canxt see. Thatxs getting better
with wide gamut technologies but I donxt know wexll ever see something as
wide as ProPhoto. But the alternative is to toss away the colors which can
be output. If you look at the 3D plots I made of that scene and ProPhoto
using ColorThink, youxll see that the scene isnxt approaching the edges of
that huge working spaces gamut. But itxs larger in some areas than the
edges of Adobe RGB (1998). The colors outside that space still fall within
the Epson gamut. So while I might be able to use something slightly larger
than Adobe RGB (1998) and quite a bit smaller than ProPhoto, Ixm not going
to build custom working spaces based on every image. I can stick with the
larger gamut working space in high bit and only suffer a file thatxs twice
the size.
Capturing all the colours that a device can get is not
as important
for the type of work that I do as getting good control
of the colours
I have.
Ixm not proposing that ProPhoto RGB or any similar
super wide gamut space is ideal for all or has no downside. But I will say
that therexs a benefit of using high bit editing which my samples clearly
show. If all we had to work with was ProPhoto or Adobe RGB (1998) itxs
possible we could dictate that 8-bit editing is safe with that space
although since we have no idea how a file might be edited in the future and
that by keeping the file in high bit, we donxt have to worry about anything
other than a file thatxs twice as large. Like Ixve said from day one, high
bit editing is about headroom and possible insurance.
This argument is two fold. One says that therexs no
examples of real world images that show the benefit of high bit editing. So
far, no one has said thatxs not being illustrated with my simple example.
Now the rules are changed and saying xit canxt be a wide gamut working
spacex which is unfair. There are those that work with spaces larger than
Adobe RGB (1998) and smaller than ProPhoto and until someone goes about
doing a heck of a lot of science, we donxt know where to draw the line. Or
we can simply edit in high bit, live with the file size and not worry. And
as yet, Ixve yet to hear how converting a file into LAB circumvents what
could be called a wide gamut editing space. Itxs very, very large. If you
convert the RAW file into ProPhoto and then go into LAB, the issues still
show up. If you convert from RAW into sRGB and into LAB, well youxve tossed
a lot of colors away that were in the original. So itxs quite possible to
pretend that therexs no benefit to high bit editing and as yet, aside from
file size, I havenxt seen it fail to produce better data in this example.
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Fri, 23 Sep 2005 23:57:33 -0400
From: Ric Cohn
Subject: Re: Response to Andrew Rodney's test
Andrew,
So far no one has addressed the issues I raised here:
On Sep 23, 2005, at 2:36 PM, Ric Cohn wrote in
response to Dan's post:
Your (Dan's) contention that small moves in ProRGB
make very large and less
controllable changes to a file make it sound like Lab.
Of course, for
Lab you have always stated that it is excellent for
making large
changes, but that for maximum quality you should
expect to make final
adjustments in RGB or CMYK. Andrew, Bruce Fraser, and
other ProRGB
advocates must either be ignorant of this or disagree
with you on this
because it is quite clear from their writings that
they stay in ProRGB
all the way through to output or conversion. I'm sure
if they disagree
we will hear from them, and I look forward to another
educational
exchange of ideas- hopefully without vitriol from
either side!
I've looked at ProRGB with Lab conversions and it
seems totally
unsuitable to the manipulation of imaginary colors as
discussed in
Canyon. Since ProRGB also contains these imaginary Lab
colors they get
converted back to white or near white! From my limited
testing I'd say
a ProRGB workflow and using Lab for these kinds
of corrections are
mutually exclusive.
I am very interested in your response to this. Dan's
suggestion that edits in ProPhotoRGB are inherently less accurate (or at
the very least requiring more accurate placement of edit points?) is to me
a fairly serious one. If more colors are created at the expense of control
I'd say this is important. If it is a false claim I'd like to hear it
disputed.
You said "But I will say that theres a benefit of
using high bit editing which my samples clearly
show."
Well, this is not strictly true. What your test shows
is that there are changes to an 8 bit file that are not desired and that it
does not happen to a 16 bit file. Now we're in the realm of deciding what
makes a better picture- which is always a more subjective decision. I'm not
saying it's not possible that an artistically better result can result from
16 bit editing- from your test I suspect there may be examples out there
for which this would be true- I'm just saying that I don't think the
argument for working in ProPhotoRGB and using 16 bit editing has been made.
You also said "Ive yet to hear how converting a
file into LAB circumvents what could be called a wide gamut
editing space. Its very, very large."
Actually, Dan goes into considerable detail on this
topic in "Canyon". Perhaps you wouldn't agree with his analysis.
He seems convincing to me, but I don't claim to be an expert. If you have
access to a copy I'd be very interested in your response.
Finally, I'm not familiar with your finest
photographic work. Maybe your work is absolutely incredible and would
clearly show the merits of working with an extended tonal range. Maybe you
know others who's work is vastly superior because of working in 16 bit to
anyone who is using only 8 bits. I think the proof would be in the
images. I don't want to be blind to the advantages, but so far I
don't see them for 99.9% of the images being produced. On the other hand I
suspect that 90% of those using ProRGB aren't either knowledgeable enough
or careful enough to avoid making edits that are worse than they would make
in a smaller space. What's needed is probably impractical: A group of
equally talented image makers in a classroom situation creating, editing
and outputting images in 8 bit or 16 bit and seeing if the 16 bit images
are found better than the 8 bit images. Something like what Dan describes
for his classes perhaps. Now, would the participants also be the judges?
Although I've addressed this to Andrew, I hope anyone
with knowledge or opinions will chime in- including Dan!
Regards,
Ric Cohn
____________________________________________________________________________
Date: Sat, 24 Sep 2005 12:49:40 +0100
From: "Bob Frost"\
Subject: Re: Response to Andrew Rodney's test
Dan,
As one of the 'misguided', I felt I should comment on
one or two points you made.
Bruce Fraser was using ProPhotoRGB back in 2000 (http:
//www.creativepro.com/story/feature/8582.html), as was I (a mere
enlightened or misguided amateur).
It seems that the space was actually produced in 1999
by Kodak as their ROMM (Reference Output Medium Metric), and was designed
to be compatible with Photoshop 5 and to work closely with the ICC
PCS.(http:
//www.kodak.com/global/plugins/acrobat/en/professional/products/software/colorFlow/romm_rgb.pdf).
I downloaded it from the Kodak website back in 2000, I
believe.
Bob Frost.
____________________________________________________________________________
Date: Sat, 24 Sep 2005 10:32:35 EDT
From: Dan Margulis
Subject: User practices--RGB definitions
From time to time, the question arises of what people
are actually using as their RGB definition, setting aside the question of
whether their practices make any sense.
I am interested in this topic, too, so I have surveyed
my classes at the last two Photoshop Worlds with a view to finding out what
the current trends are in terms of sRGB v. Adobe RGB. In each case, I would
estimate that I asked around 500 people. In each case, around a third of
the audience identified themselves as being professional photographers
either now or in the past.
These are of course guesstimates of the response. When
I say "1%", though, it's pretty accurate--somewhere between 2 and
6 people.
The question was: What is your customary RGB
workspace, as defined in your Color Settings dialog?
Answers Vegas, 3/05
Don't Know, or Don't Understand the Question: 18%
sRGB: 40%
Adobe RGB: 40%
Anything Wider Gamut than Adobe RGB: Nobody
None of the Above: 2%
Answers Boston, 9/05
Don't Know, or Don't Understand the Question: 8%
sRGB: 40%
Adobe RGB: 50%
Anything Wider Gamut than Adobe RGB: 1%
None of the Above: 1%
Personally, I was mildly surprised at the sRGB v.
Adobe RGB vote, because I thought that it might be more like 60-40 in favor
of sRGB. I was *really* surprised by the poor showing of None of the Above,
because I thought a lot of people were using either ColorMatch RGB or
something home-cooked. The Don't Know and wide gamut responses were about
what I thought they would be.
Dan Margulis
____________________________________________________________________________
Date: Sat, 24 Sep 2005 08:35:00 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/23/05 9:57 PM, "Ric Cohn" wrote:
I am very interested in your response to this. Dan's
suggestion that
edits in ProPhotoRGB are inherently less accurate (or
at the very least
requiring more accurate placement of edit points?) is
to me a fairly
serious one.
ProPhoto RGB like all working space is a container (a
color space). Images don't have to fill it but you need a set boundary (the
scale of the three primaries) to fit a range of color. So an image might
have colors that fall outside saturated green in Adobe RGB (1998) that fit
within ProPhoto or a larger space. Sorry if this is obvious but it's
important. FWIW, LAB is also a huge space but falls into the same rules.
If you're working with an 8-bit file, the space
between the bits in sRGB is much smaller (tighter) than ProPhoto RGB.
That's why you need high bit. The discussion here is going in two
directions one of which is the pluses (and one is saying issues) with wider
gamut spaces.
There's nothing false about the color and the
container has to be a size in which you either contain it and hopefully use
it or toss it away. With the 3D gamut maps I produced in ColorThink, you
can see actual image colors and how they compare to the gamut of the output
device. What's false about such colors?
Well, this is not strictly true. What your test shows
is that there are
changes to an 8 bit file that are not desired and that
it does not
happen to a 16 bit file.
Exactly, the original challenge. That's the first part
of this long set of posts (see my summary below because we're getting to
the point of beating a dead horse).
Now we're in the realm of deciding what makes
a better picture- which is always a more subjective
decision.
Yes especially if you prefer random noise
<g>
I'm not saying it's not possible that an artistically
better result can result
from 16 bit editing- from your test I suspect there
may be examples out
there for which this would be true- I'm just saying
that I don't think
the argument for working in ProPhotoRGB and using 16
bit editing has
been made.
Working in ProPhoto RGB in these examples (I have
plenty) shows random noise in 8-bit and not in 16-bit. Now the question is,
should you use a wide gamut space like ProPhoto RGB? My response is yes if
you want to output colors in the scene that are reproducible and important
to you that can't fit in a smaller working space.
You also said "I‚ve yet to hear how
converting a file into LAB
circumvents what could be called a wide gamut
editing space. It‚s very, very large."
Actually, Dan goes into considerable detail on this
topic in "Canyon".
Perhaps you wouldn't agree with his analysis. He seems
convincing to
me, but I don't claim to be an expert. If you have
access to a copy I'd
be very interested in your response.
I have not got that far but will skip ahead. But I
have said if you start with a smaller gamut original and go into LAB,
you're going to find a much bigger difference than starting with a larger
gamut original. You can see this using my RAW file.
Finally, I'm not familiar with your finest
photographic work. Maybe
your work is absolutely incredible and would clearly
show the merits of
working with an extended tonal range.
Kind of immaterial.
Maybe you know others who's work
is vastly superior because of working in 16 bit to
anyone who is using
only 8 bits.
Like the extra colors I can capture and use that are
important to me, not producing random noise in shadows is also important to
me. It might not be for others. That's a judgment call. It doesn't change
the facts, the math and the evidence that producing the edits in high bit
DOES NOT PRODUCE THE NOISE! That's been the debate since the earth started
cooling around this list.
I think the proof would be in the images.
I don't want
to be blind to the advantages, but so far I don't see
them for 99.9% of
the images being produced.
That's very possible. I'd ask if you're processing RAW
digital files. I'd ask that if that 1% is important to you at the expense
of a larger file. I'd ask if the edits and output in the future are well
defined or not. Again for the 99th time, high bit editing is insurance and
headroom. If you don't care about that, don't use it. But saying there's no
cases where using high bit editing on real world images produces a benefit
compared to 8-bit isn't true and I've illustrated it.
On the other hand I suspect that 90% of
those using ProRGB aren't either knowledgeable enough
or careful enough
to avoid making edits that are worse than they would
make in a smaller
space.
Well those of us, including DM should be telling them
to edit in high bit! Or we can continue to believe that this space will go
away, your an idiot for using it and that all high bit editing provides no
benefit. I don't see that being something educators should do.
This idea that with some special odd captures and
working spaces and users that high bit editing is voodoo rings of a digital
imaging "higher intelligence" mind set.
The signal to noise ratio here is such that I feel I
need to paraphrase where we’ve been. There are two issues here; the
benefit of high bit editing versus it’s downside and the benefit of
wide gamut working space and their downside. The two are linked but
let’s not confuse the original challenge.
DM: Show us a real world image where editing in 16-bit
provides a benefit. AR: Here's a snapshot in it’s truest sense from a
$900 digital camera which shows less noise.
DM: Yes I see that.
DM: Your edits are poor, it’s a wide gamut
space, doesn’t count.
AR: The space allows me to contain colors I can output
on my $800 ink jet of which there are probably tens of thousands sitting on
users desktops. Lots of people edit files in lots of ways, some better than
others. The high bit file doesn’t show the noise, the 8-bit does.
There might be ways to edit the file so less noise (perhaps no noise) is
seen. Unless every edit is done to the high level of DM, we have to assume
that it’s possible the edits on an 8-bit file will produce this noise
and yet, by simply accepting a file twice as large, it’s no longer an
issue. But we don’t live in a prefect world and the high bit file
allows more headroom in the edit and doesn’t show the noise.
DM (and others): There’s no reason to use ultra
wide gamut working space and those that do are not intelligent plus far and
few between.
AR: The scene and many such scenes contain these
colors, I can use them and I want them. If you don’t, fine. But in
using these colors, there’s a visual difference in quality using high
bit. If you’re scanning images and you want something that can hold
the Ektachrome gamut, ProPhoto RGB is it.
Bottom line. There are no prefect working spaces,
there are probably fewer prefect Photoshop users. There are images that can
exhibit image degradation in 8-bit that don’t show this in high bit
with the downside being a larger file. You’ll see less issues with a
smaller gamut working space but you also have potentially less color than
you can output. If you don’t mind this fact, fine.
One other point. All the edits could have been done in
the RAW converter, saved out in a wide gamut space in 8-bit with no noise.
Why? The converter is working on linear encoded data in high bit and all
editing is global using what could be considered a proxy image. It’s
very fast and very flexible. So while my original example needed some
tweaks, I could have done this all in the RAW converter faster to produce
even better image quality. IOW, why take a RAW file, bring it into
Photoshop in high bit or 8-bit and edit it? Yes, the editing in high bit
produces superior quality. Again, not a prefect world and we have to accept
that some will provide files that need global editing after RAW conversion.
Andrew Rodney
____________________________________________________________________________
Date: Sat, 24 Sep 2005 10:35:40 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
Andrew Rodney writes,
Dan, you can see the effect of the noise in the 8-bit
version , etc.
Irrelevant. I conceded in that post that *in an
ultra-wide gamut RGB,* it is probably possible to have a real-image series
of corrections that demonstrate an advantage for correcting in 16-bit. I
concede the same thing about correcting in 1.0 gamma. That's why I don't
bother to run extensive tests on either one, and why they don't qualify for
the challenge.
Since I have conceded this for at least five years, it
should not be terribly surprising, but if you need to quote me on it, there
it is.
There1s no smoke here. The data is there for anyone to
see. But
since once again, the rules of this silly challenge
have changed...
You and your business partners were hyperaggressively
touting 16-bit as the only sensible approach to editing, and bashing as
unprofessional fools any users who dared to disagree, in roughly the period
2000-2001, which is when I first started asking for any evidence that
16-bit was even slightly superior, let alone the enormous difference that
you and your partners were claiming.
Now, you come up with an example that depends
completely on the use of a color definition that didn't even exist in
Photoshop until three years later, and accuse *me* of changing the rules.
So know we have to show a
difference between the two using what gamut working
space?
In view of the clear move in the marketplace since
then toward either sRGB or Adobe RGB, I would suggest one of those.
And if you can back up the statement that 99.9% of
users do not use
ProPhoto RGB, I1d love to see some empirical data to
back that up.
I made no such statement. I said that 99.9% of users
do not make MAJOR EDITS in ProPhoto RGB. And, if you'd like to see some
empirical data, yes, I have some, but as the question of what people *do*
use is not the same as what they *ought to* use, I've posted it as a
separate message with a different header.
Dan Margulis
____________________________________________________________________________
Date: Sat, 24 Sep 2005 11:11:20 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
Ric writes,
Thanks for the thorough and thoughtful posting.
However, I fear the fox
is already among the chickens. ProPhotoRGB is now
essentially a
"sanctioned" Photoshop workspace.
Not yet. By default, it isn't even visible as an
option within Color Settings--you have to check More Options to see it.
I have seen it heavily promoted as a digital output
space since it loses no potential capture colors. I
have seen few
warnings about using it in 8 bit, which isn't that
surprising since
virtually everyone who advocates this workspace also
advocates editing
in 16 bits. I suspect it's very presence in Camera Raw
is somewhat
related to the power (good or bad I don't really know)
that this group
has over the Photoshop development team.
The speculation is probably correct. The fantasy of an
ultra-wide gamut RGB as a solution to imaging ills was heavily touted by
Kodak in the late 1980s-early 1990s, using exactly the same naive arguments
that Andrew Rodney and his partners make today: you're throwing away
colors! Irretrievable data loss! By 1996 you're going to want those colors!
And, best of all, once you have the file containing all these colors that
will be available in 1996, there's no problem repurposing it for something
that's much narrower-gamut, like a newspaper--you just press a button, and
presto, there's your newspaper file!
That editing in such a space would be exceedingly
difficult was not seen as a problem. Kodak's workflow assumed NO editing at
all. The perfect scan goes into the perfect RGB, and then is converted by
the perfect algorithm into the perfect CMYK file. This was the workflow
that was referred to by me at the time as "calibrationism" and by
admirers of the system as "pushbutton color".
This solution in search of a problem was a
laughingstock by the time of Photoshop 4, for obvious reasons. It was
therefore not heard of until Kodak reemerged with it five years later and
hired one of Andrew's partners, who happened also to have Adobe's ear, to
help them promote it.
Your contention that small moves in ProRGB make very
large and less
controllable changes to a file make it sound like Lab.
Of course, for
Lab you have always stated that it is excellent for
making large
changes, but that for maximum quality you should
expect to make final
adjustments in RGB or CMYK.
Yes. In a wide-gamut colorspace, there isn't enough
editing precision to set perfect endpoints, among other things. In that
respect, ultra-wide RGBs and LAB are alike. The difference is that LAB
allows certain types of moves that aren't available in any RGB, and allows
easy control of neutrality throughout the entire range of the image,
somethiing that, as Iliah Borg has pointed out, is notoriously difficult in
any RGB. An ultra-wide gamut RGB operates like any other RGB, except that
all moves need to be cut in half to avoid major color shifts, something
that is easier said than done.
Similarly, the danger of an ultra-wide gamut
colorspace is that colors can be thrown out of gamut. In LAB, an
experienced user is not troubled by this--the color is kept separate, and
it's easy to see potential problems as they develop. In an ultra-wide gamut
RGB it's much more difficult.
So, yes. LAB has certain advantages and certain
disadvantages. So does sRGB. An ultra-wide gamut RGB combines all the
disadvantages of LAB and most of the disadvantages of sRGB into one bloated
package without giving us anything in return, which is why it was so
decisively rejected in the early 1990s.
Finally, this brings me back to my question about an
"ideal" RGB
working space.
There isn't one. It depends on the user's needs. It
also depends on the era. Something like ColorMatch RGB made a lot more
sense ten years ago than it does today. If the only thing you ever output
to is newspaper CMYK, it still *does* make sense.
I think it is reasonable to find sRGB and
ColorMatchRGB
unsuitable for some images. They both limit colors
that are viewable on
existing good monitors and printable with existing
output devices.
AdobeRGB does get most of these colors, but I'm not
convinced it's an
ideal space either. It was created by accident and it
seems possible to
construct a space that is both smaller and contains
virtually all
currently printable colors.
All very true. Nevertheless, as I point out in a
separate post, sRGB and Adobe RGB together account for well over 90% of
Photoshop users today. There is a lot of merit in sticking with the same
definition that other people use, even if it's clearly second-best.
A number of color geeks have created other
working spaces which attempt to address these issues.
However, no space
is likely to get wide acceptance unless it is adopted
by Photoshop the
way ProPhotoRGB has been.
Be careful what you ask for. Photoshop is a great
program, but its history of making changes in color handling is not a happy
one. A lot of your reasoning is the same as what was used by Adobe in 1998,
when they torpedoed the existing standard. That existing standard wasn't a
particularly good one, but thanks to the way it was replaced, we now have
*two* standards, one of which is clearly worse than the previous standard,
and the other one a lopsided RGB designed by mistake. In the interim, we
had five years of chaos.
My view is that finally we have gotten back to a
system that actually works--not well, but it works. In view of history, if
Adobe plus Andrew and his partners try to make it better, there's a high
likelihood that we'll get something that *doesn't* work, as we have in the
past. So, I would leave well enough alone.
Dan Margulis
____________________________________________________________________________
Date: Sat, 24 Sep 2005 10:59:24 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/24/05 8:35 AM, "Dan Margulis"
wrote:
Irrelevant. I conceded in that post that *in an
ultra-wide gamut RGB,* it is
probably possible to have a real-image series of
corrections that demonstrate
an advantage for correcting in 16-bit.
Not probably, absolutely. The math (not theory) and
now the images make this pretty clear.
I concede the same thing about
correcting in 1.0 gamma. That's why I don't bother to
run extensive tests on
either one, and why they don't qualify for the
challenge.
So when the tree falls in the forest and no one is
around, the sound is non existent....
You and your business partners were hyperaggressively
touting 16-bit as the
only sensible approach to editing, and bashing as
unprofessional fools any
users who dared to disagree, in roughly the period
2000-2001, which is when I
first started asking for any evidence that 16-bit was
even slightly superior,
let alone the enormous difference that you and your
partners were claiming
There have been wide gamut spaces from some digital
cameras and certainly high end scanners well before 2001. As already
posted, ROMM RGB predates that. That ProPhoto RGB didnxt get installed in
Photoshop prior to that date is again, an attempt to hide from the reality.
As for hyperaggressively touting 16-bit I can say that both myself and
Bruce Fraser have always said that using such a file provides editing
headroom. Thatxs always been backed up by simply science but if you must
use the intelligent design mindset to ignore the math, at least we have
actual images today that show this. Ixm not going to try to defend what I
feel is an enormous difference versus what you or anyone else feels is
enormous. Some would find the noise in the image I present an enormous
issue, others would totally ignore it. Should you be the former user, you
can reduce or eliminate it using more than 8-bits.
Now, you come up with an example that depends
completely on the use of a
color definition that didn't even exist in Photoshop
until three years later,
and accuse *me* of changing the rules.
Yes I do. At least Ixd expect you to:
1. Admit that real world images exist and are common
that show degradation in 8-bit that do not in high bit (youxve actually
said this recently).
2. That there are those that for whatever rational
find it necessary to use wide gamut spaces (the Kodak engineers didnxt
design it to entertain themselves).
3. That high bit files provide editing headroom
illustrated in my example and by virtue of simple math. In certain
workflows, even ones YOU many never use, the higher bit data provides a
lack of (in this case) random noise.
I will admit:
If you work with a small(er)gamut space, the need for
high bit editing is reduced and possibly a non issue. I'll add that since I
donxt have a crystal ball, have no idea who might edit that file and at
what skill level that it is possible they could introduce data loss that
might be visible on some output devices. All insurance comes at a cost. In
the case of high bit, itxs a bigger file. IF this is a severe problem for
you AND you are working in a small gamut space AND know itxs very, very
unlikely if impossible youxll gain any benefit from high bit, please donxt
use it.
With the right tools, you CAN edit an 8-bit wide gamut
file with no degradation getting the best of both worlds (do the work in
your RAW converter which of course is doing the job behind the scenes in
high bit).
I said that 99.9% of users do not make MAJOR EDITS
in ProPhoto RGB.
Ixd love to know how you can come up with such stats.
Is a major edit a simple color space conversion? Applying USM? Why even
worry about what might cause the noise issue when it can be ignored by
working a file twice itxs 8-bit size?
And, if you'd like to see some empirical data, yes, I
have
some, but as the question of what people *do* use is
not the same as what they
*ought to* use, I've posted it as a separate message
with a different header.
I saw it, donxt find it all empirical and would
suggest you donxt give up your day job to become a pollster <g>.
Ixm not sure we need to go much farther in this
discussion unless we both agree to the points above. Real world, non
synthetic images exist that show a benefit to high-bit editing but there
are also images (many) that do not. In the end, each user has to decide if
they want to use one process versus the other. But I hope you are not
suggesting that there are no workflows, images or users who would benefit
from high bit editing IF they donxt mind the larger file size.
Andrew Rodney
____________________________________________________________________________
Date: Sat, 24 Sep 2005 13:17:07 -0400
From: "Iliah Borg"
Subject: Re: Response to Andrew Rodney's test
I'm afraid that we are discussing design decisions
made for ACR programming. It is hard for me to understand why ProPhoto is
needed to be the destination space for conversion of raw data, but if Adobe
had chosen so, we are to face both sides of the coin.
Best regards,
ib
____________________________________________________________________________
Date: Sat, 24 Sep 2005 13:31:49 -0400
From: "jc castronovo"
Subject: Re: Response to Andrew Rodney's test
Well - we've come to some kind of agreement I think,
but I'd like a clarification on one point: Is there any scenario where it
would be necessary to temporarily take an 8 bit file into 16 bits for
editing?
____________________________________________________________________________
Date: Sat, 24 Sep 2005 16:11:13 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
Bob Frost writes,
Bruce Fraser was using ProPhotoRGB back in 2000
Yes, he was. This has zero bearing on the statement
that you appear to be trying to refute, which reads: "This space was
not installed in Photoshop until 2003".
Bruce was using ProPhoto then because Kodak had hired
him to help in its design and promotion. Prior to that, he had been
advocating a narrower-gamut space known as BruceRGB. Photoshop users did
not have access to ProPhoto unless they downloaded it from somewhere, as it
was not installed by Photoshop itself until Photoshop CS (2003).
In 2001, Bruce wrote, "If you really start out
with a RAW image in high-bit form and a raw image downsampled to 8 bits,
the difference really is night and day...it's totally obvious to anyone who
looks that it's very advantageous to do the big moves on high-bit
data." His partners wrote even more emphatically, flaming any
users who challenged their view. These comments offer no indication that
the night-and-day, totally-obvious-to-anyone-who-looks advantage is limited
to an RGB that wouldn't appear in Photoshop for two more years.
Dan Margulis
____________________________________________________________________________
Date: Sat, 24 Sep 2005 17:09:59 EDT
From: Dan Margulis
Subject: Re: Andrew Rodney's test--consensus
Andrew Rodney writes,
I will admit:
If you work with a small(er)gamut space, the need for
high bit editing is
reduced and possibly a non issue.
As also noted by John Castronovo, it appears that for
all the noise, we may actually be getting close to a consensus, which would
be a useful thing.
Therefore, I will back off the thread for the moment,
and hope to post again about what was said in a few days.
Dan Margulis
____________________________________________________________________________
Date: Sat, 24 Sep 2005 23:06:32 -0400
From: "Michael Demyan"
Subject: RE: Andrew Rodney's test--consensus - My One
Vote
I for one - photograph, scan, work and edit in 8 bit
Adobe 1998. (sometimes detour into LAB :) )
I also print using an Epson 4000 using Ultrachrome
inks that have a gamut close to Adobe 1998.
Michael Demyan
Fine Photography & Digital Graphic Design
www.mikedemyan.com
610-758-9769
____________________________________________________________________________
Date: Sun, 25 Sep 2005 02:20:21 -0400
From: Ric Cohn
Subject: Re: Andrew Rodney's test--consensus
On Sep 24, 2005, at 5:09 PM, Dan Margulis wrote:
As also noted by John Castronovo, it appears that for
all the noise, we may
actually be getting close to a consensus, which would
be a useful thing.
I fear that the usefulness of ProPhotoRGB will be the
next horizon: Assume a Wide Gamut RGB workflow makes sense and you
need 16 bit.
Despite Dan's insistence that using ProRGB as your
general RGB working space makes no sense, I am still on the fence. I'm
afraid wide gamut editing spaces must be taken into consideration in coming
to a consensus on 8 bit vs 16 bit editing, and may actually prove to be a
more important question. I believe Dan's strongest argument against wide
gamut RGB workspaces it that it's difficult-to-impossible to place edit
points as accurately as in smaller workspaces (maybe there are also other
important questions). I'd like to see this proven or disputed with facts
that can be tested. It's interesting that while Dan very convincingly shows
the error in accepting a purely mathematical explanation for the benefits
of 16 bit editing or for the insanity of editing in Lab and needing to
convert back and forth between color spaces, I believe I've only seen a
mathematical explanation for why Wide Gamut RGB spaces make no sense.
Unlike editing in 16 bit which is mainly inconvenient, I believe there is a
very real possibility that working In ProPhotoRGB could, if these arguments
are valid, actually lead to a generally lower quality of images even with
expert editing. However, if these arguments are not valid and the benefits
really do matter then there is also a potentially much greater benefit from
working in ProPhotoRGB than from working in 16 bits.
IMHO testing whether there are benefits (that outweigh
the disadvantages) to working in a wide gamut color space for a
"maximum quality" workflow seems much more difficult than it was
for me to look at 16 bit vs. 8 bit editing. Image quality that matches my
vision is obviously important to me. I spent a good bit of time a few years
ago looking for a 16 bit advantage because I wanted it to be true- who
wouldn't want significantly better quality for just the price of bigger
files? However, I was able to prove to my own satisfaction that, for my
workflow at least, there is no benefit to working in 16 bit as long as I
first got the images into the ballpark of my final version (I believe this
last part may be where I differ with Dan?). For me this mainly means
scanning flat in 16 bit (due to the limitations of my scanner) and making
my first corrections in 16 bit. Sometimes (rarely) if I will be making
major changes to a digital shot I also output my digital files in 16 bit
and do my first corrections there. I know Andrew will argue that one never
knows if major changes will be made later, but I believe that a clean 8 bit
file can take virtually anything that a 16 bit file can take and that it
doesn't make a difference whether a poor scan or digital capture is in 16
or 8 bits.
For me to do all my layering, blending, retouching,
saving, backing up, etc. etc. on a needlessly bloated file does not make
sense to me. Considering the loss in image quality now or in the future has
been shown to be at the most very slight, and virtually always correctable,
even if the time saved from working in 8 bit only saved the time to do one
more picture a year I think it's a waste not to do that one more picture!
When I look at pictures I corrected only a couple of years ago (sometimes
days ago ;-)) I frequently see areas I would treat differently today. When
I have reason to output these images again for a new use I will frequently
rework parts of them. The idea of using 16 bit because it is "more
perfect" doesn't make sense here and the idea of leaving headroom for
later also IMO doesn't hold up because I'm much more likely to either
rework the image in ways that are less damaging rather than more damaging
(as I get better) or make such radical changes that whether it's 16 bit or
8 bit is immaterial.
Unfortunately, AFAIK none of these arguments work for
ProPhotoRGB. And if one accepts ProRGB as a reasonable space, then I
believe you're pretty much stuck with 16 bit. For example, maybe there are
colors which would be important to me that I can't get with AdobeRGB. Since
I probably can't see the colors on my screen it's hard to say. Bright
super saturated color is not typical in my images, but I think there may be
colors I might want that are not in AdobeRGB. Maybe my pictures would be
better... insecurity works wonders.
This is, in a sense, a subtler argument than the 16
bit issue and unless the sense of working in ProPhotoRGB can be proven or
disproved I fear it's just the beginning of another round of heated
discussions. Doing identical big sets of corrections on 2 versions for a 16
bit vs 8 bit test is one thing-- and we've seen how difficult that can be!
Doing 2 sets of very subtle corrections on 2 files and then outputting them
to look for subtle differences isn't so easy. Especially since, if you
don't see a difference, it could just be due to the way your printer has
been profiled. I guess first you need to output targets in the larger space
and build excellent profiles, then confirm that if the image's colors are
within the smaller space's gamut the prints are identical. Then print
images where you believe the wider gamut is important and have unbiased
viewers rate the different pictures. What if you first edit in 16 bit and
repeat in 8 bit and the 16 bit files look better? Well, maybe the 8 bit
file only needed some subtle differences in the edits to be superior. Or
suppose you first edit in 8 bit and then repeat the moves in 16 bit- if
there's no difference or the 8 bit images are preferred the same argument
applies. Maybe by reworking the files several times we can come to a
consensus and maybe ProPhotoRGB edited images will turn out to be preferred
a significant percentage of the time, in that case working in ProPhotoRGB
would be vindicated for some work flows. Of course, even if there is no
consistent pattern it doesn't mean that a benefit doesn't exist, it could
just be that our test uses the wrong output device or the wrong images, or
the wrong profiles... Now we're getting into the realm of faith--
"evolution vs Intelligent Design".
I'd really like to see it proven that ProPhotoRGB
makes no sense (or sense under only certain limited and predictable
circumstances) so I can ignore it and move on to more important things-
like making pictures.
My (long winded) 2¢.
Ric Cohn
____________________________________________________________________________
Date: Sun, 25 Sep 2005 09:00:49 -0400
From: "jc castronovo"
Subject: Re: Andrew Rodney's test--consensus
Thanks for your thoughts Ric. I believe that
ProPhotoRGB is far too large a space to be useful for the vast majority of
images that are dealt with, yet I've seen to my satisfaction that many
saturated colors would be clipped by using sRGB or even Adobe1998. Possibly
this doesn't matter for typical output, but I feel that we shouldn't
knowingly and automatically limit the color gamut of what we archive. For
many years, we've used Don Hutcheson's DonRGB which is a wide gamut color
space, but not nearly as wide as ProPhotoRGB and I think it's been an
excellent compromise as it allows a wide gamut without the problems that
have been associated with ProPhotoRGB.
____________________________________________________________________________
Date: Sun, 25 Sep 2005 09:06:20 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
John Castronovo writes,
Well - we've come to some kind of agreement I think,
but I'd like a
clarification on one point: Is there any scenario
where it would be
necessary to temporarily take an 8 bit file into 16
bits for editing?
Yes, but most of them are very obscure. Doing it can
be helpful in certain LAB maneuvers, but I didn't even mention it in the
book because anybody who's capable of figuring out when those maneuvers are
necessary is also capable of figuring out that converting to 16-bit may
help.
The most common everyday reason for doing it is, you
are given an 8-bit RGB file containing computer-generated gradients,
particularly blue ones. You have to convert it into CMYK. No, it's not the
way the client should have done it, but too late now, this is the file you
have.
In that case, it's helpful to convert the file to
16-bit, do something innocuous to fill the extra bits with random data
(e.g. Gblur radius .1; upsample the file by 5%; rotate the file by 5% and
then rotate it back) and THEN convert to CMYK and back to 8-bit.
Dan Margulis
____________________________________________________________________________
Date: Mon, 26 Sep 2005 01:00:12 -0700
From: Richard Wagner
Subject: RE: Andrew Rodney's test--consensus - My One
Vote
Boy, it's been tough to sit back and even follow this
thread... Most pro photographer colleagues of mine shoot with
high-end cameras in RAW, process in 16-bit into ProPhoto or Adobe RGB
depending on the primary intended use (AdobeRGB for stock sales/agency work
and ProPhoto for fine art printing), and convert to sRGB for web use. Most
of us are also comfortable converting to/working in CMYK. As for the
results of the polls from Dan's workshops, I'd be interested to know how
long those attendees have been shooting digitally, because they sound like
a very inexperienced and uneducated group. I highly doubt that you would
get comparable answers from, say, the Nikon D1scussion listserve membership
or a poll on Rob Galbraith's forums.
Michael, the gamut of Ultrachrome inks clearly exceeds
that of Adobe RGB (1998), as does the gamut of Fuji Velvia film. You might
get even better results than you're getting now if you changed your
workflow, although if you're satisfied with what you have, great. I
would suggest that you read the scanning guide referenced below.
I have actually been going back through my files and
re-scanning in high-bit, then assigning a custom G-M ProfileMaker profile
generated from a HutchColor HCT target, and converting to ProPhoto (rather
than AdobeRGB). The improvement I get in prints on my Epson 9600 is
often dramatic and justifies the effort. Of course, Don Hutchison also
recommends scanning in 16-bit, but what does he know about color...
(http://www.hutchcolor.com/PDF/Scanning_Guide.pdf)
If you're happy with 8-bit sRGB, so be it. There
are a lot of us, however, who won't even waste our time with the
high-bit/wide-gamut discussion, nor would we be likely to attend a workshop
where an 8-bit, small gamut workflow is advocated. It simply doesn't make
sense. Andrew, you should have taken Bruce Lindbloom's advice!
I don't anticipate spending any more time on this discussion, but I
felt bad lurking and not voicing a vote.
I haven't finished reading Canyon yet (fortunately the
binding is still holding up), nor have I even started reading Andrew's new
book, which on a quick look appears to be well-written and well-bound. I
have my own book to get through publication (on venomous animals, not
digital technique), and my hope is that it will be well-bound as well.
--Rich Wagner (certified ColorTheory lurker)
<><><><><><><><><><><><><><>
Richard Wagner
WildNaturePhotos, L.L.C.
www.WildNaturePhotos.com
Member ASMP | NANPA | PIA/GATF
<><><><><><><><><><><><><><>
____________________________________________________________________________
Date: Mon, 26 Sep 2005 07:57:28 -0700
From: David Cardinal
Subject: RE: RE: Andrew Rodney's test--consensus - My
One Vote
Richard--One thing I've learned from running a site
& forums for pro & serious amateur photographers is that there are
few statements that apply to most of them.
In the case of color & workingspaces, they are all
over the map. Many of the top Wedding & Event photographers shoot Raw
& go straight to sRGB because they find it works most easily &
quickly with their output workflow.
Obviously many use the two options you describe above
(Raw->16-bit->AdobeRGB or ProPhoto), especially those in the high-end
of the commercial or fine art fields, but many also never leave 8-bit
because of size & speed issues (some shoot upwards of 1000 images/day
covering sports/events/wildlife so it adds up). For the same reason, quite
a few make a living shooting nothing other than JPEGs.
Personally I've found that my workflow has grown more
splintered over the last couple years. I love the flexibility of shooting
JPEG+Raw on the new Nikons and I love what I can do with Raw files, but
there are a lot of projects where JPEG is quicker & works well. On
working spaces, I'm one of those waffling. I tend to look at the particular
image in ACR and decide whether I feel I need to use ProPhoto/16-bit to
capture the colors I want or I can live with AdobeRGB/8-bit and keep the
file smaller and faster.
--David Cardinal
http://www.nikondigital.org
____________________________________________________________________________
Date: Mon, 26 Sep 2005 08:51:54 -0700
From: J Walton
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
I think we need to differentiate between scanning and
editing.
To be fair, I believe Dan recommends scanning in
16-bit as well, if the scanner allows it. The question in front of us
is not scanning, but *correcting* in 16-bit.
Don Hutcheson is certainly a respected expert in his
field, which is why my company hired him as a consultant a few years ago.
Although he did want us to use the working space he named after
himself :-), he did not push 16-bit editing. I don't know if he's
changed his tune since, but I rather doubt it.
8-bit editing in AdobeRGB is fine with me, if we're
tallying votes or something.
I remember another color guy we hired mentioned
something about making an RGB working space that is just big enough to
contain SWOP, but not much bigger. I'd probably go with GRACOL, but
it sounds like a good idea to me.
J
____________________________________________________________________________
Date: Mon, 26 Sep 2005 12:52:56 EDT
From: Dan Margulis
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
J writes,
To be fair, I believe Dan recommends scanning in
16-bit as well, if
the scanner allows it. The question in front of
us is not scanning,
but *correcting* in 16-bit.
Right. Scanning and correcting are two different
animals.
Dan Margulis
____________________________________________________________________________
Date: Mon, 26 Sep 2005 13:57:54 EDT
From: Dan Margulis
Subject: Re: Andrew Rodney's test--consensus
Ric writes,
I'd really like to see it proven that ProPhotoRGB
makes no sense (or
sense under only certain limited and predictable
circumstances) so I
can ignore it and move on to more important things-
like making
pictures.
This is exactly backwards.
Whoever is advocating adopting a workflow that has
obvious disadvantages bears the burden of making a compelling case that
there are advantages that outweigh them. I say you should sometimes work in
LAB. It is inconvenient to do that, because you have to make two color mode
shifts and work in a dangerous color environment. It is not up to anybody
else to prove that you *shouldn't* work in LAB. It is up to me to prove
that you *should*, by showing compelling examples of how its benefits
outweigh its disadvantages. If anybody else doesn't like my examples, they
can try to shoot them down.
Camera Raw has disadvantages, too. It takes a lot
longer to open the image and the controls are crude. If anybody says that
we should use Camera Raw rather than just a JPEG from the camera, it isn't
up to you or me to prove that we shouldn't--it's up to that person to prove
that we *should*, by compelling examples of how its benefits outweigh its
disadvantages.
To the great detriment of the community at large,
Andrew Rodney and his partners believe that this simple concept does not
apply to them. They claim the right to dictate inconvenient workflows
without any backup at all. They have explicitly said that they do not have
to demonstrate the validity of their claims and that it is up to the rest
of the world to prove them wrong--which the rest of the world has a history
of doing.
And so, we got the claim that multiple adjustment
layers give a better output result than multiple applications of simple
commands. We got the claim that converting from RGB to LAB causes
"catastrophic damage" to the file. We got the claim that editing
in 16-bit creates a "night and day" "totally obvious to
anyone who looks" difference and that anyone who doesn't do it is not
a professional. We were advised that combed histograms produce inadequate
reproduction.
In each case, we now know better, but meanwhile we've
wasted a whole lot of everybody's time trying to prove negatives, which is
notoriously difficult. Nobody can ever show that these claims of data loss
are *never* valid unless they work on every type of image that could
possibly be produced multiplied by every possible kind of edit. Yet people
get taken in by these claims and as a result I've had to blow some 20 full
pages in my last three books showing samples large enough to back up my own
position, which is that AFAIK there's nothing to worry about.
It's not clear to me whether they are advocating
ultra-wide gamut RGBs as exchange spaces or storage spaces. If the latter,
no problem--they'll do as well as any other reasonable alternative. If, as
I suspect, they are advocating actually doing major edits in them, this is
a naive workflow that has been thoroughly discredited for more than a
decade.
If you're faced with that claim, you should say, look.
You guys have provided a lot of valuable services to the industry for which
we all should be grateful. However, every time you've gotten involved with
matters involving arithmetic or color theory or anything that looks to you
like data loss, you have been proven wrong time and again. Plus, you're
heavily tied in with various of the vendors who happen to benefit from your
claims. So, if you have anything to back up these statements besides
theoretical mumbo-jumbo that you've proven you don't understand, let's see
it, and then we'll see whether we think it makes up for the obvious
disadvantages of editing in so clumsy a space, let's see it.
But for God's sake, Ric, now that this 16-bit
nightmare is almost over, don't even think about saying that somebody has
to prove that editing in an ultra-wide RGB *isn't* useful. The burden is on
the other side to prove that it *is.*
Dan Margulis
____________________________________________________________________________
Date: Mon, 26 Sep 2005 10:11:28 -0600
From: Ron Kelly
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
On 26-Sep-05, at 8:57 AM, David Cardinal wrote:
For the same reason, quite a few make a living
shooting nothing other
than JPEGs.
Yes, there are quite a few of us I suspect.
We believe that the advantages of shooting RAW do not
stack up against the crushing disadvantages.
We believe that care taken at the time of image
capture is time far better spent than time spent fixing/fiddling with
everything downstream. Couldn't be bothered to set a good white balance
when you're shooting? No problem, camera RAW will fix it. Couldn't be
bothered to get a good exposure? No problem,. . . etc.
Shooting in RAW and editing in 16 bit are similar in
that there is little or no advantage real-world advantage to doing so.
For some reason, quite a few are willing to accept any
myth that software authors and equipment vendors are willing to foist on
them, without testing to see if it makes any difference.
Ron Kelly
____________________________________________________________________________
Date: Mon, 26 Sep 2005 14:32:09 EDT
From: Dan Margulis
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
David Cardinal writes,
One thing I've learned from running a site &
forums for pro &
serious amateur photographers is that there are few
statements that apply to
most of them.
Plus, these two groups constituted Photoshop *users*,
the universe of which does not begin and end with serious photographers.
Professional photographers constituted, as I said, only about a third of
the group.
Nevertheless, a thousand Photoshop users is a fairly
substantial sample, and it certainly shows that neither sRGB nor Adobe RGB
is going away in the foreseeable future.
Dan Margulis
____________________________________________________________________________
Date: Mon, 26 Sep 2005 14:11:08 -0400
From: Denton Taylor
Subject: Re: My One Vote
Hi Ron:
I completely agree with you about getting the image
right in the first place, and that applies whether you are using RAW, JPEG,
or film. (years of shooting color chromes taught me that!) But
assuming one does this, I see nothing but disadvantages in shooting
jpegs, particularly given the lossy compression vs. non-lossy in RAW. I
don't want algorithms messing with my image and tossing out data. Unless
you are converting the jpegs to tiff or PSD to edit, then back to jpeg. And
if you do that, you may as well go RAW=>TIFF.
I don't even use the RAW capabilities in PShop, I use
the camera mfgr's RAW software to view the images and send the ones I like
to Pshop in TIFF format, where I can do my work.
Because I try and get it right the first time, I try
and do as little photoshop work as possible, which is probably why I am not
an expert. A little levels, maybe a black or white point set, maybe minor
curves, a bit of cropping and sharpening. If I spend more than five minutes
on an image, it generally means I didn't get it right the first time.
That's actually why I'm getting a big kick out of
Dan's LAB book; the ability to do a lot in a little time.
Denton
____________________________________________________________________________
Date: Mon, 26 Sep 2005 11:38:28 -0700
From: "Mike Russell"
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
From: "Ron Kelly"
....
For some reason, quite a few are willing to accept any
myth that
software authors and equipment vendors are willing to
foist on them,
without testing to see if it makes any difference.
Absolutely. These are interesting times, and
many of the workflow ideas that are accepted as common wisdom are destined
to simply vanish.
Not too long ago, on Adobe's ACR forum, I read a post
from a studio photographer who batch converts 1800 raw images to tiff each
and every day. It took hours. His question was not about the validity
of this workflow (which AFAIK takes no advantage of raw edit capabilities),
but whether he should buy a second G5, or upgrade his existing system to
dual processor.
I like to say you can't see the woods for all the
naked emperors. One of said emperors has literally sold us all a
bridge :-)
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Mon, 26 Sep 2005 13:32:09 -0600
From: Ron Kelly
Subject: Re: My One Vote
It *would* seem to be a bad idea to toss out data.
However, as I'm sure you and everyone else on this
list is aware, there are levels of jpeg compression. I am of course
referring to the highest quality (least compression).
The point is simply this: why keep bigger files than
necessary? In the top quality jpeg I can find no loss of image quality. Try
it for yourself, if you haven't already.
Let's put it another way: if you're so concerned about
quality, why don't you get a better lens, camera, scanner etc.? These
things *will* have an effect on image quality.
My guess is that real world results are the
determining factor for only some. Time and again when referring to an
indistinguishable differences (ie one that therefore is nil) people will
say something like "I'm keeping my date intact because someday when
the Smithsonian want to access my files the extra data will be
relevant." Meanwhile, they get to carry around an extra 10 pounds of
lead in their shorts.
Ron Kelly
____________________________________________________________________________
Date: Mon, 26 Sep 2005 12:58:37 -0600
From: Andrew Rodney
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
On 9/26/05 12:38 PM, "Mike Russell"
wrote:
Not too long ago, on Adobe's ACR forum, I read a post
from a studio
photographer who batch converts 1800 raw images to
tiff each and every day.
It took hours.
The actual processing or hours for the photographers
sitting in front of the computer? There is a difference. From the
standpoint of the user, I could process 1800 similar images in a few
minutes and let the computer process all the RAWs over night. In the batch,
I could add EXIF data, sharpen, rename, resize etc without touching the
computer. So I think we need to define processing.
With Bridge and Adobe Camera RAW, you can crank
through RAW processing and in some respects, do this far faster than
opening individual JPEGs and applying corrections. And I could be working
in Photoshop all while ACR and Bridge do the work.
The tools are there, we just need to define what needs
to be down and some of the better ways to conduct the work. Computers are
supposed to do routine, multiple tasks for us and they can. Of course,
there are all kinds of imaging tasks that only a human can produce.
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Mon, 26 Sep 2005 14:58:23 -0600
From: Ron Kelly
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
If all these 1800 images are similar?
That sounds like they were shot at the same time in
the same conditions. If they aren't, then the potential advantages of
processing them automatically are lost. You'd have to sit there overnight
along with your computer, making choices.
If they were shot in similar conditions, then it would
have been better to capture them more carefully. Many professional cameras
have auto white balance which works very well, and when it doesn't there
are usually other options that need to be selected at the time of the
photography. A simple test shot can help you here.
So, if you're getting chased by a grizzly bear, then
auto white balance is likely to work well in that environment even if you
can't take time to think about it. On the other hand, if you are
shooting in an area that is lit by flourescent lights, you're not likely to
be eaten by grizzlies and you should be able to take a little more care
with the white balance. Time spent at image capture can save you tons of
downstream effort.
Automated RAW workflows seem to me to be akin to the
eject button on the DVD player.
You don't get the supposed benefit that RAW promises,
because you're automating the batching. And if you are determined to try
for every ounce on every image, you have to sit there and fiddle each and
every time because if you don't, you'll quite likely get a result that may
be worse than using auto-white balance and jpegs.
Ron Kelly
____________________________________________________________________________
Date: Tue, 27 Sep 2005 10:26:43 +1000
From: Dean Wilmot
Subject: Re: User practices--RGB definitions
Hi Guys,
Ive been reading all your responses, with interest,
the last few days.
As a photographer (fairly new to high end digital
systems- 22MP multishot backs) I must say I am still abit daunted about
what colour space I should be viewing images in.
I have calibrated my Apple 20" cinema display
(first version) using the Gretag Macbeth Eye One Photo screen calibration
unit...I thought this would get me in the ballpark...and let my pre-press
retoucher tweak the final Master files.
However since reading all this info I wonder if I
should be using the profile this Eye one unit has generated or use the
Photoshop built in color setting of Adobe RGB (1998) or ProPhoto....since
all my RAW hi res files come in off my digi camera systems as 16 bit RAW
RGB TIFF files.
The difference between both profiles is Huge.
Please forgive my ignorance but can someone point me
in the right direction.???
Another point of note is that recently Most of the
biggest magazine publishers and Advertising agencies in Australia are
demanding that photographers ONLY supply RAW RGB files, as there have been
some photographers who profess to supply pre-press ready CMYK files, but in
truth they are not set-up properly and thus these clients want to do
everything themselves.
These same Advertising agencies and Publishers are
also implementing a new consortium Proofing system (very expensive) called
3DAP...its Australia specific...to combat any "color CMYK
cowboys" so the point of the sword of responsibility lies with the
photographer.
Any thoughts??
Alot of clients don't trust photographers as they are
not color Guru's (such as you guys) with extensive pre-press knowledge of
CMYK (although there are some photogs who are realising the scope of
knowledge now required), would you suggest that supplying clients (often
ignorant to current technology) RGB files and let them do the CMYK
conversions?
Or take the bull by the horns and supply CMYK and a
proof for ALL shoots that are going to be supplied to a client as digital
files?
Thanks for your feedback.
From my own point of view I wish I could afford to
bring Dan Margulis to Australia (ive looked in to it) to educate the Entire
Australian photographic world, but currently the local market has to find
some depth in their pockets.
Kind Regards
Dean Wilmot
Sydney, Australia
____________________________________________________________________________
Date: Mon, 26 Sep 2005 15:29:27 -0600
From: Andrew Rodney
Subject: Re: RE: Andrew Rodney's test--consensus - My
One Vote
On 9/26/05 2:58 PM, "Ron Kelly" wrote:
That sounds like they were shot at the same time in
the same
conditions. If they aren't, then the potential
advantages of
processing them automatically are lost. You'd have to
sit there
overnight along with your computer, making choices.
Absolutely. However, even if all the images are
dissimilar, you can still in many cases apply a similar camera RAW
correction and produce quite acceptable color appearance. Just as you can
ask the in-camera processing to do this and toss the RAW files. It all
depends on how much adjusting you need to do on an image by image basis
from the RAWs. Plus the new Auto settings in ACR, especially when tweaked
by the user (calibrate tab) can produce pretty good looking images. I1m
assuming that the multiple scenes are well exposed. The issue then becomes
the white balance. If the camera embeds a decent white balance with EXIF
data and it1s something ACR can read, better yet.
Many professional cameras have
auto white balance which works very well, and when it
doesn't there
are usually other options that need to be selected at
the time of the
photography.
Right and hopefully that1s not encrypted and kept from
ACR. It can still apply it1s own 3auto2 (as shot) white balance or you can
override this. So it1s kind of like having the benefits of in camera
processing but you can tweak, go back to the RAW and end up with high bit
or 8-bit files and not necessarily in JPEG.
In camera processing is what it is, we hope it1s good.
That1s all up to the manufacturer. But you1re stuck with what you get. You
can apply the same rules to RAW and with a converter like ACR, you have a
lot of options.
Automated RAW workflows seem to me to be akin to the
eject button on
the DVD player.
Why would the auto adjustment on a RAW converter be
worse than in camera processing? At least you can go back and redo it if
you like. With in-camera processing, you1re stick with a certain rendering
based on the white balance and you1re stuck with an 8-bit JPEG. In the
converter, you can adjust anything you wish; only exposure plays a role.
Seems to be infinitely more flexible. And with ACR, you have very good
highlight recovery which isn1t available with the in camera processing. You
can turn off sharpening, you can convert into a number of color spaces and
you can pick the resolution. Go back to the RAWs and alter all of those
anytime you wish. Like high bit editing, it1s all about flexibility and
headroom. That isn1t to say there are not those who can benefit from a JPEG
workflow. It is still faster no question. But it1s highly inflexible with
no safety net.
The beauty of making multiple ACR corrections is these
are simple text files. The RAW data is never touched. So you can select 400
images in Bridge and pick one saved setting. The thumbnails update and the
EXIF data that will define the ultimate corrections are all there but no
processing. Then pick 300 other images and select another setting. When
you1ve roughed this all out, you can apply all corrections and batch
process while you are watching Desperate Housewife1s and the computer does
all the work. You don1t even have to open Photoshop (or any of those 700
files). They are all processed into a folder you wish.
Be cool if you could select the same images from JPEG
in Bridge and apply corrections this way; you can1t. That1s what1s so cool
about RAW. You pick the rendering edits, see the effects but you1re never
touching, at least at this point the full rez data. You1re never touching
the RAW so if you do something dumb, the original data is all there to work
with. It can be a fast process but it1s certainly a very safe and flexible
process.
Andrew Rodney
____________________________________________________________________________
Date: Mon, 26 Sep 2005 18:56:07 -0600
From: Andrew Rodney
Subject: Re: User practices--RGB definitions
On 9/26/05 6:26 PM, "Dean Wilmot" wrote:
However since reading all this info I wonder if I
should be using the
profile this Eye one unit has generated or use the
Photoshop built in color
setting of Adobe RGB (1998) or ProPhoto....since all
my RAW hi res files
come in off my digi camera systems as 16 bit RAW RGB
TIFF files.
The two are totally separate and do different things.
The display profile defines how your display behaves. Photoshop uses it to
produce it1s previews of all files in all color spaces (RGB, CMYK, you name
it). Just leave it alone (well, update you calibration and build a new
profile once a month or so).
The working space profile defines the color space of
the image. That information AND your display profile are both used to show
you the file. So, you could have a file in sRGB, ProPhotoRGB, U.S. Web
Coated (SWOP) v2 all open at the same time and each window is being
previewed using the display profile and the embedded profile within each
document.
Another point of note is that recently Most of the
biggest magazine
publishers and Advertising agencies in Australia are
demanding that
photographers ONLY supply RAW RGB files, as there have
been some
photographers who profess to supply pre-press ready
CMYK files, but in truth
they are not set-up properly and thus these clients
want to do everything
themselves.
Boy, I1m not comfortable giving clients a RAW file.
It1s like giving them your negs. I will say if they have you over a barrel,
I1d convert to the .DNG format. For one, you can embed all kinds of useful
metadata like your copyright and other stuff. You can apply a default
rendering for Adobe applications like Bridge or Camera RAW so at least you
could provide the RAW file with a 3look2 you like. Otherwise, it1s a
digital neg so to speak. Otherwise, you can1t embed any information into a
RAW file (its read-only). The .DNG file allows you to write some data into
that format.
Or take the bull by the horns and supply CMYK and a
proof for ALL shoots
that are going to be supplied to a client as digital
files?
Possible as long as you1re proofing the work
correctly. Sending a nice RGB file to your ink jet isn1t based on any CMYK
reality. So it1s useless. IF you have a profile for the CMYK process, you
CAN produce a very close color match to an ink jet. The key is that CMYK
description that is used to make your printer (say an Epson) simulate
another print process. Useful!
From my own point of view I wish I could afford to
bring Dan Margulis to
Australia (ive looked in to it) to educate the Entire
Australian
photographic world, but currently the local market has
to find some depth in
their pockets.
Well I'll be there speaking in December (in my
favorite city; Sydney).
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Mon, 26 Sep 2005 20:59:21 -0400
From: "Gene Palmiter"
Subject: Re: User practices--RGB definitions
Can I take a stab at some of this? It's sort of
learning by teaching. I may get it all wrong and by doing so will raise
more questions and clear up some points I don't have down yet. Like
previsualisation with film a lot depends on final use. Can we assume that
with that set-up you are shooting for glossy magazines? A step back from
that is your pre-press retoucher...he will need, in the best of all worlds,
a profile for the printer that is to be used. Assuming its an off-set press
then all he really needs is a color space that will be just enough to
provide what the printer can print. I would suppose that a bit bigger color
space is better than a bit smaller...and almost any color space is bigger
than an offset press can handle. My guess would be AdobeRGB as its pretty
standard and will do the job. If you have to repurpose then your RAW files
still have all the information they ever had.
How an image looks to you is unimportant as you have
no say in how it will look printed...that's up to the retoucher. So...don't
make your job any harder than it has to be...send them what they want and
take their checks. This will all change when you want to show some of your
work in a gallery and have to retouch it and print it yourself. But, right
now you have experts (supposedly) doing the part we are discussing so they
should be the ones reading all this.
(I work differently as I am the photog, retoucher,
photoeditor, and paginator for a small mag. Still only get one check
though...darn it!)
____________________________________________________________________________
Date: Mon, 26 Sep 2005 18:46:58 -0700
From: David Cardinal
Subject: RE: RE: Andrew Rodney's test--consensus - My
One Vote
Why would the auto adjustment on a RAW converter be
worse
than in camera processing?
At least in the case of high-end Nikon D-SLRs, there
is at least one structural reason:
The camera has the advantage of an external WB sensor
which is not accessible to any current third party software (I'm not even
sure whether it is recorded in the image or merely an input to the camera's
algorithm and discarded)
As smarter CMOS cameras evolve additional WB sensing
technology will be incorporated, which might make this issue even more
apparent.
This isn't an argument against Raw or ACR, just a
comment on one reason why the camera does have some "advantages"
in the current system.
--David Cardinal
____________________________________________________________________________
Date: Mon, 26 Sep 2005 18:38:14 -0700
From:David Cardinal
Subject: RE: User practices--RGB definitions
Otherwise, you can1t embed any information into a RAW
file
(its read-only).
Well, not entirely. Several different programs
including ours (DigitalPro for Windows) will caption Raw files with
IPTC meta-data since they are often mildly modified TIFF formats. There is
some thin ice involved because the formats are not documented, but it is a
very popular capability for many photographers who archive their raw files
and use them as their image catalog.
Adobe (probably wisely given their position in the
market) chooses not to caption the Raw files because they are not
documented.
Perhaps more upsetting to those who think that by
getting a Raw file they have some assurance of "truth", it isn't
all that hard to synthetically generate a Raw image (we do this for
testing) or to modify a raw image. We don't ship those capabilities since
they don't have many valid uses, but I'm sure we'll read of raw file spoofs
and hacks before too long.
--David Cardinal
Pro Shooters LLC
http://www.nikondigital.org
http://www.proshooters.com
____________________________________________________________________________
Date: Mon, 26 Sep 2005 20:19:54 -0600
From: Andrew Rodney
Subject: Re: User practices--RGB definitions
Yes, I stand corrected. I should have been more clear
by saying that Adobe doesn1t modify files it can1t directly write to. This
is based more on a philosophical rather than a technological reason. Once
you create a .DNG file, they are fine modifying the metadata.
Andrew
____________________________________________________________________________
Date: Mon, 26 Sep 2005 20:49:51 -0700
From: Alain Briot
Subject: Re: Digest Number 1556
Dan,
And so, we got the claim that multiple adjustment
layers give a better output
result than multiple applications of simple commands.
We got the claim that
converting from RGB to LAB causes "catastrophic
damage" to the file. We got the
claim that editing in 16-bit creates a "night and
day" "totally obvious to
anyone who looks" difference and that anyone who
doesn't do it is not a
professional. We were advised that combed histograms
produce
inadequate reproduction.
It's interesting to note that I've never heard this
statement, or anything close to it, from a fine art photography printer. I
myself follow the exact workflow you seem to despise: multiple layers.
I read all your books but there comes a time when global adjustments
just stop working and when local adjustments are necessary. If you
disagree, I am willing to send you one of my files, complete with local
adjustment layers, and you can prove me wrong by doing it all with your
approach. Personally, I can't. What better evidence is there
that your system is the better approach?
--
Alain Briot
Beaux Arts Photography
http://www.beautiful-landscape.com
800-949-7983 or 623-561-1641
____________________________________________________________________________
Date: Tue, 27 Sep 2005 13:20:54 EDT
From: Dan Margulis
Subject: Re: Adjustment Layers
Alain writes,
It's interesting to note that I've never heard this
statement, or
anything close to it, from a fine art photography
printer.
Nor have I, only from professional "experts"
with close ties to various vendors.
I myself follow the exact workflow you seem to despise:
multiple layers.
At some point I will understand, although I do not as
yet, how a book that is so obviously full of adjustment layers, layer
blending options, and layer masks provokes people into saying that I am
against the use of layers.
Be that as it may, reading your "multiple
layers" to mean "multiple adjustment layers", because my
statement referred only to them, then if you, like me, use multiple
adjustment layers because you think that you may need the flexibility to be
able to edit them at a later time, it is not a despicable but a commendable
practice.
If you, however, do *not* require such future
flexibility, and are going to the trouble of saving the extra layers solely
because you have read that flattening a file containing multiple adjustment
layers provides better data than a file in which the adjustments were
applied consecutively without layers, then I do not despise this either,
but permit me to advise that the two resulting files would in fact be
identical, not varying from one another by so much as a single pixel.
I do not despise people who misunderstand certain
aspects of Photoshop, as I am but a poor sinner in that respect myself, and
I do not despise authors who occasionally dispense advice that is later
proven to be incorrect, as I have been guilty of that also. I look down my
nose at, but do not despise, the practice of dispensing incorrect advice in
print when the correctness of the advice can easily be proven or disproven
but the person giving it is too lazy to do so.
I *do* despise the practice, however, of calling
nonexpert users fools, unprofessionals, or other unpleasant names based on
concepts that the namecaller has been too lazy to test for himself,
particularly if it turns out that the namecaller is wrong.
I read all your books but there comes a time when
global adjustments
just stop working and when local adjustments are
necessary.
There does indeed, which is why I spend so many pages
in my latest book discussing selection technique. I do, however, adhere to
the view that as one's skill increases the amount of local selection that
is needed decreases, and respectfully suggest the following guidelines:
1) When starting work on an image, it should be
immediately apparent whether local corrections seem likely to be necessary.
Discovering midway through the process that one needs to correct locally is
a mark of bad technique.
2) All the local corrections in the world will not
make a competitive image out of one whose global values are inadequate.
3) The objective is to improve the image, not to
frighten it to death by one's knowledge of Photoshop technique.
Dan Margulis
____________________________________________________________________________
Date: Tue, 27 Sep 2005 14:13:04 -0600
From: Chris Murphy
Subject: Re: Response to Andrew Rodney's test
On Sep 23, 2005, at 10:54 AM, Dan Margulis wrote:
The following two statements comprise a single full
paragraph. I separate them for effect.
But in an ultra-wide gamut RGB, it's much more
difficult, as the values have
to be kept much closer to absolute equality, because
colors get brilliant very
rapidly in such a space.
Consequently, maintaining neutrality in such an
image during correction is a nasty problem in an
ultra-wide gamut RGB and no
problem at all in LAB, CMYK, or a rational RGB.
This two statements present seemingly conflicting
facts:
You state a correlation between gamut size and the
increasing difficulty of maintaining neutrality. That is, larger gamut
space means it will be more difficult to maintain neutrality. You've
previously said ProPhoto RGB is an ultra-wide gamut space.
Yet you then say this maintaining neutrality problem
does not occur at all in LAB. How do you explain this in lieu of the fact
that encoded LAB defines a gamut that is larger than the ultra-wide gamut
ProPhoto RGB?
Either the neutrality problem relates to gamut, or it
relates to something else. You seem to imply, simultaneously that it does
and does not depend on gamut. If it depends on gamut it would be at least
as much a problem in LAB as in ProPhoto RGB.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Tue, 27 Sep 2005 13:47:56 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Sep 26, 2005, at 11:57 AM, Dan Margulis wrote:
But for God's sake, Ric, now that this 16-bit
nightmare is almost over,
don't even think about saying that somebody has to
prove that editing in an
ultra-wide RGB *isn't* useful. The burden is on the
other side to prove that it *is.*
In the context of a photographer using Adobe Camera
RAW, there are advantages to editing in a wide gamut RGB space. I consider
it like walking on a balance beam at 15 feet above the ground. Will you die
if you fall? Unlikely. Will you get hurt? Maybe. The better you get at
walking the beam the less likely you will fall. So it's going to take some
getting use to, in order to make lighter, less aggressive edits than in
another space. Perhaps in a few days?
Camera RAW uses an internal linear gamma color space
with ProPhoto RGB primaries. Thus all edits done in Camera RAW are by
definition performed in a wide gamut space. Even if you select sRGB within
Camera RAW, *all* edits are performed in 1.0 gamma ProPhoto and then
converted to sRGB after the edits are applied, and some of the most useful
and basic features of Camera RAW easily constitute "major edits",
but to my knowledge there is no agreed upon definition or metric for what
is or is not a major edit. The implicit workflow here is to do any
necessary major edits in Camera RAW, and have far fewer edits to do in
Photoshop proper once the RAW file is processed.
Clearly it's not inherently dangerous to edit in wide
gamut spaces or there'd be many hundreds of thousands of totally screwed up
images as a result of such a workflow that you say:
If, as I suspect, they are advocating actually doing
major edits in
them, this is a naive workflow that has been
thoroughly discredited
for more than a decade.
I agree that the burden of proof must be placed on
those who make a claim, and those who claim that editing in wide gamut RGB
spaces has merit should present a compelling case demonstrating the
usefulness of a technique. The use of a wide gamut RGB space for editing is
a technique. But likewise someone who makes a statement as you have, that
it's a naive and discredited workflow, has set himself up for an
substantial burden to cite or demonstrate such a grand, thesis-level
statement. You say it despite the large number of Camera RAW users doing
exactly what you describe has been discredited, as though it is or ought to
be common knowledge.
Now it's possible I've extracted this quote out of
context, but it was in a short paragraph with no other qualifiers related
to major edits in a wide gamut RGB space. Perhaps the qualifiers are found
in other email postings? The output of wide gamut images has various
problems depending on the output device (and profiling technology) used,
but the context wasn't output. So this statement is quite a revelation.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Tue, 27 Sep 2005 18:45:26 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
Chris Murphy writes,
You state a correlation between gamut size and the
increasing
difficulty of maintaining neutrality. That is, larger
gamut space
means it will be more difficult to maintain
neutrality.
Yes, it does, *within the same color model*. An
imaginary CMYK that has the same approximate gamut as ProPhoto RGB
nevertheless controls neutrality much more effectively, because the
presence of a permanently neutral channel, the black, acts as an anchor.
This imaginary CMYK, however, is harder to control than ordinary CMYK.
Adobe RGB is slightly harder to control than sRGB but much easier than
ProPhoto RGB.
Yet you then say this maintaining neutrality problem
does not occur
at all in LAB. How do you explain this in lieu of the
fact that
encoded LAB defines a gamut that is larger than the
ultra-wide gamut
ProPhoto RGB?
The problem occurs in LAB as it does in any
colorspace, but LAB controls neutrality more effectively than either CMYK
or RGB because color is treated independently of contrast, so you can
flatten the color reproduction curve near the center, a move that has no
analog in other colorspaces.
Dan Margulis
____________________________________________________________________________
Date: Tue, 27 Sep 2005 17:54:03 -0700
From: "Mike Russell"
Subject: Re: Response to Andrew Rodney's test
From: "Chris Murphy"
...
Yet you then say this maintaining neutrality problem
does not occur
at all in LAB. How do you explain this in lieu of the
fact that
encoded LAB defines a gamut that is larger than the
ultra-wide gamut
ProPhoto RGB?
ProPhoto's primaries define a larger gamut than Lab.
This is not subtle, and may be demonstrated by creating any white to
pure red, green, or blue gradient in ProPhotoRGB, and viewing color values
in Lab mode.
You'll see the a or b channel hit the wall well before
the gradient reaches 100 percent saturation. The same is true for
pure cyan, magenta, and yellow.
Labmeter also shows this. As you adjust the
bright end of the "Click to set L" adjustment layer, you'll see
various areas, notably blue and yellow, where ProPhoto RGB extends outside
of Lab.
http:
//www.curvemeister.com/downloads/LabMeter/CurvemeisterLabMeter.zip
Either the neutrality problem relates to gamut, or it
relates to
something else. You seem to imply, simultaneously that
it does and
does not depend on gamut. If it depends on gamut it
would be at least
as much a problem in LAB as in ProPhoto RGB.
Although neither color space is that suitable for fine
color adjustments, Lab is actually a more finely grained gamut than
ProPhoto RGB.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Tue, 27 Sep 2005 20:19:15 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/27/05 6:54 PM, "Mike Russell"
wrote:
ProPhoto's primaries define a larger gamut than Lab.
The blue primary yes, the others no.
Although neither color space is that suitable for fine
color adjustments,
Lab is actually a more finely grained gamut than
ProPhoto RGB.
I1m not so sure. Maybe. But if you1re working with a
RAW file, going from ProPhoto to LAB doesn1t appear to be a great idea just
to confine the blue primary inside human gamut. There are a lot of colors
outside ProPhoto RGB in Lab. It1s not an apples to apples comparison. The
overall shape of each is quite different. Lots of colors within ProPhoto
RGB are in a smaller gamut compared to LAB.
Andrew Rodney
____________________________________________________________________________
Date: Wed, 28 Sep 2005 13:10:57 EDT
From: Dan Margulis
Subject: Re: Andrew Rodney's test--consensus
Chris Murphy writes,
Camera RAW uses an internal linear gamma color space
with ProPhoto
RGB primaries. Thus all edits done in Camera RAW are
by definition
performed in a wide gamut space.
By your definition, not mine. To me, it's roughly like
declaring that when you assign a profile to an RGB file you have edited it
in LAB.
The implicit workflow here is to do any
necessary major edits in Camera
RAW, and have far fewer edits to do in Photoshop
proper once the RAW file is
processed.
Right. As I understand Andrew's position, in a logical
workflow one would tend not to make major edits in ProPhoto once the file
hits Photoshop proper, because it would have been done in Camera Raw.
Clearly it's not inherently dangerous to edit in wide
gamut spaces or
there'd be many hundreds of thousands of totally
screwed up images
There are many hundreds of thousands of totally
screwed up images that got that way without the benefit of ultra-wide gamut
RGB.
Photoshop 2.5 is capable of creating outstanding
images even though it doesn't allow layers. Outstanding images can also
result from large edits to ProPhoto RGB files. Neither approach is sensible
if a rational alternative is available.
Dan Margulis
____________________________________________________________________________
Date: Wed, 28 Sep 2005 12:35:46 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 9/28/05 11:10 AM, "Dan Margulis"
wrote:
Right. As I understand Andrew's position, in a logical
workflow one would
tend not to make major edits in ProPhoto once the file
hits Photoshop proper,
because it would have been done in Camera Raw.
In 8-bit, probably not based on the files I provided.
In high bit, not an issue. From a 3logical2 workflow, you1d do the
major global corrections in Camera RAW because it1s faster, you have some
benefits of working with a linear encoded gamma in high bit and you can do
a lot of this in a batch.
I find that working in Camera RAW to do the 3big
edits2 a bit like doing the corrections at the scan stage. It1s fast
because you1re basically working on a proxy and you can apply all the edits
and convert the RAW data while you1re sleeping. You don1t have to open
every 13 mega-pixel file to apply tone and color corrections.
I still don1t know why you feel that doing such edits
at 3the scan stage2 versus in Photoshop (the toolset being basically equal)
is different.
Andrew Rodney
____________________________________________________________________________
Date: Wed, 28 Sep 2005 13:45:38 -0700
From: "Mike Russell"
Subject: Re: Response to Andrew Rodney's test
From: "Andrew Rodney"
The blue primary yes, the others no.
All three of ProPhoto's primaries substantially exceed
Photoshop's Lab encoding range of -128 to 127 in either the a or b channel.
Green is out of range for both the a and b channels.
I1m not so sure. Maybe. But if you1re working with a
RAW file, going from
ProPhoto to LAB doesn1t appear to be a great idea just
to confine the blue
primary inside human gamut. There are a lot of colors
outside ProPhoto RGB
in Lab. It1s not an apples to apples comparison. The
overall shape of each
is quite different.
Lab will always have areas that no RGB space can
represent, but that does not mean it has a larger gamut, or even that it is
coarser grained than every RGB space. I think my point stands.
ProPhoto, has a substantially larger gamut than Photoshop's
implementation of Lab.
Lots of colors within ProPhoto RGB are in a smaller
gamut compared to LAB.
Interesting. I've spot checked a few and not
found this to be the case. Which colors would these be?
---
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Wed, 28 Sep 2005 15:29:00 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/28/05 2:45 PM, "Mike Russell"
wrote:
All three of ProPhoto's primaries substantially exceed
Photoshop's Lab
encoding range of -128 to 127 in either the a or b
channel. Green is out of
range for both the a and b channels.
Yes, the primaries are but due to it1s shape, there
appear to be lots of colors that fall within a smaller gamut, at least from
what I1m seeing in ColorThink. More of that round peg in square hole
mismatch in shape.
Lab will always have areas that no RGB space can
represent
That1s what I1m saying above.
ProPhoto, has a substantially
larger gamut than Photoshop's implementation of Lab.
Is there something unique about Lab as far as
Photoshop1s implementation?
Andrew Rodney
____________________________________________________________________________
Date: Thu, 29 Sep 2005 09:33:55 +1200
From: Nick T
Subject: RGB Working spaces
Hello List
On Sep 26, 2005, at 8:00 PM, Richard Wagner wrote:
Boy, it's been tough to sit back and even follow this
thread... Most
pro photographer colleagues of mine shoot with
high-end cameras in
RAW, process in 16-bit into ProPhoto or Adobe RGB
depending on the
primary intended use (AdobeRGB for stock sales/agency
work and
ProPhoto for fine art printing), and convert to sRGB
for web use.
Most of us are also comfortable converting to/working
in CMYK. As
for the results of the polls from Dan's workshops, I'd
be interested
to know how long those attendees have been shooting
digitally,
because they sound like a very inexperienced and
uneducated group.
I highly doubt that you would get comparable answers
from, say, the
Nikon D1scussion listserve membership or a poll on Rob
Galbraith's
forums.
Richard that has not been my experience.
I run a user group for 300 users of Imacon (now
Hasselblad) digital backs , and I think it fair to say that they are a
fairly sophisticated bunch; all full time professionals, and many supplying
CMYK. My poll is a very small sample (only 80 have replied so far) but I
would expect the results to be borne out by the remaining 220.
I certainly don't think it would be in any way
correct to label them "a very inexperienced and uneducated
group".
The question was "What RGB working space do you
use?"
The results:
Adobe RGB 1998
Users: 50 (80%)
srgb
Users: 1 (1%)
Colourmatch RGB
Users: 5 (8%)
ProPhotoRGB
Users: 4 (6%)
Other
Users: 2 (3%)
It is worth noting that two of the Prophotorgb users
actually stated that they use AdobeRGB for commercial work and Prophotorgb
only for fineart inkjet.
Regards
Nick Tresidder
Nick Tresidder Photography
http://www.nick-t.com
____________________________________________________________________________
Date: Thu, 29 Sep 2005 00:03:42 -0700
From: Richard Wagner
Subject: re: RGB Working spaces
Nick,
I think that you (and perhaps David Cardinal)
misunderstood my response. On Sat, 24 Sep 2005 10:32:35 EDT Dan
Margolis wrote, in describing his survey:
The question was: What is your customary RGB
workspace, as defined in your
Color Settings dialog?
Answers Vegas, 3/05
Don't Know, or Don't Understand the Question: 18%
I would find it astonishing that nearly 20% of a group
of pro photographers would not know what working space they used. I would
not consider them to be very experienced in digital file manipulation.
I am not at all surprised that 80% of photographers using Imacon
digital backs use AdobeRGB as their working space. What percentage of
them work in 8-bit? I would bet very few...
Photographers generally optimize their workflow for
their intended output. Other than fine-art printing, most photographic
output today does not benefit from a wide-gamut color space. But that
is very different from the claims on this list by some that there are *no*
advantages to wide-gamut color spaces, and that the people who use them are
fools. Some photographers derive benefit from shooting JPEG rather
than RAW, 6 MP rather than 20, and sRGB rather than AdobeRGB. It all
depends on what you ultimately need to do with your images and the
conditions you shoot under. As some photographers who once used Nikon's
lossy "compressed NEF" format discovered, though, once data is
thrown out you're outta luck if you later decide that you need it.
Likewise, if you archive your images in AdobeRGB and later try to output to
a device with a larger or non-overlapping gamut, you're stuck with
AdobeRGB, and you cannot take advantage of the full gamut of the output
device. This is why I've gone back to re-scan slides into ProPhotoRGB -
without question, I often get much better prints on my Epson 9600 than I
did with the image in Adobe RGB. Otherwise, I wouldn't waste the time
it takes to rescan. A significant portion of the gamut of a Velvia
scan exceeds the gamut of AdobeRGB (i.e., is out-of-gamut). Why clip or
compress this, when it may fall within the gamut of your output device?
You can see it visually here, in a page I made over a year ago:
http://www.wildnaturephotos.com/WNP/Html/GamutFS.html
The situation is even worse for digital capture, which
has a wider gamut than film. (I know, technically digital capture has no
gamut...)
--Rich Wagner
____________________________________________________________________________
Date: Thu, 29 Sep 2005 11:02:52 +0100
From: "Bob Frost"
Subject: Re: Response to Andrew Rodney's test
Mike,
Gingerly dipping a toe into this murky world of real
and non-real colors, isn't your phrase "Photoshop's implementation of
Lab' the crux of this argument? Lab has real colors and non-colors that are
outside Photoshop's cut-down version of Lab.
So isn't it correct to say that ProPhotoRGB is
contained within Lab, but not within Photoshop's 'reduced Lab'?
Bob Frost.
____________________________________________________________________________
Date: Thu, 29 Sep 2005 04:07:44 -0700
From: "Mike Russell"
Subject: Re: Response to Andrew Rodney's test
From: "Bob Frost"
Gingerly dipping a toe into this murky world of real
and non-real colors,
isn't your phrase "Photoshop's implementation of
Lab' the crux of this
argument? Lab has real colors and non-colors that are
outside Photoshop's
cut-down version of Lab.
Yes, and in sacrificing some gamut, the Lab values
become more closely spaced.
So isn't it correct to say that ProPhotoRGB is
contained within Lab, but not
within Photoshop's 'reduced Lab'?
I think that's accurate, but as a practical matter
Photoshop's tiny Lab space is what we have to work with.
In that truncated color space, Lab lavishes data
values on its color space. This is largesse compared to the diet of thin
gruel that ProPhoto RGB grudgingly gives the same colors .
I believe this has been demonstrated several ways: the
spacing of the primaries, the gradient experiment, and the fact that
ProPhoto RGB often requires 16 bits for a given operation, when Lab does
not. If anyone is not convinced, I'm all ears.
Here's an effect I have not been able to explain.
If you convert a ProPhoto white to pure blue gradient to Lab, there
is a significant dark band in the darker areas of ProPhoto. This does
not happen in green, where significantly more clipping occurs, or red,
which is about as bad as blue. Can anyone explain this?
.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Thu, 29 Sep 2005 07:54:43 EDT
From: Dan Margulis
Subject: Re: Re: Response to Andrew Rodney's test
Dennis writes,
One of my favorite techniques for editing color and
tonality is to use 2 Curves
adjustment layers, one set to "color"
blending and the other set to
"luminosity". I am curious if this gives me
a decent approximation of the ability
you mention below even though I am editing in an RGB
color space.
This is a highly sophisticated workflow that in many
cases surpasses what LAB has to offer and in many cases doesn't. In this
particular case (nearly gray object that varies a lot in darkness, and
which already shows a certain amount of color variation), LAB is better.
Even if you are on a color layer in RGB, the object
falls in a relatively long range in the curve. All three curves need to
interrelate; if the blue is correct but you change the green, you may have
to readjust the blue. And, if you adjust the green, you likely will also
change the color of trees, which are of the same darkness as the gray
areas.
In LAB, these problems don't exist. The grayish areas
occupy a tiny area of the A and B curves, isolated from the green. Plus,
the channels are independent. If you get the A right, you don't have to
worry about it any more. Nothing you can do to the B will change it, as
would be the case in RGB.
Nevertheless, it's still a powerful workflow.
Dan Margulis
____________________________________________________________________________
Date: Fri, 30 Sep 2005 09:29:12 +1200
From: Nick T
Subject: Re: re: RGB Working spaces
On Sep 29, 2005, at 7:03 PM, Richard Wagner wrote:
I would find it astonishing that nearly 20% of a group
of pro
photographers would not know what working space they
used. I would
not consider them to be very experienced in digital
file
manipulation.
Hi Richard
That sample was of Photoshop users not just
Photographers:
Here's what Dan wrote on the 27th of September:
Plus, these two groups constituted Photoshop *users*,
the universe of which
does not begin and end with serious photographers.
Professional photographers
constituted, as I said, only about a third of the
group.
Regards
Nick-T
Nick Tresidder Photography
http://www.nick-t.com
____________________________________________________________________________
Date: Thu, 29 Sep 2005 15:58:31 -0700
From: Steve Upton
Subject: Re: Response to Andrew Rodney's test
Lab does have "real" colors outside of the
-128->127 a/b limitations in the Lab that Photoshop uses.
This is NOT an inherent Photoshop limitation, however,
but one imposed by the ICC in their choice of the Lab coordinates for the
profile connection space (PCS). The fact that Adobe chose to follow the
same "space" as the ICC makes sense.
Yes, and in sacrificing some gamut, the Lab values
become more closely
spaced.
this doesn't make sense to me. The fact that the Lab
in Photoshop is constrained makes the values closer together? Or are you
talking about a working space here?
So isn't it correct to say that ProPhotoRGB is
contained within Lab, but
not within Photoshop's 'reduced Lab'?
I think that's accurate,
yes and no. The primaries are convertible to Lab
values but they are not perceivable colors so it doesn't really matter.
but as a practical matter Photoshop's tiny Lab
space is what we have to work with.
true, but what is so tiny about Photoshop's Lab? It
contains almost all the colors the eye can see and certainly contains all
the colors that can be produced on a metameric system. (more below)
In that truncated color space, Lab lavishes data
values on its color space.
in terms of 8 bit Lab, there is more resolution
available, yes. The Lab values are not placed any closer together though.
This is largesse compared to the diet of thin gruel
that ProPhoto RGB
grudgingly gives the same colors .
only in terms of 8 bit. in 16 bit there is plenty of
tonal resolution available.
I believe this has been demonstrated several ways: the
spacing of the
primaries, the gradient experiment, and the fact that
ProPhoto RGB often
requires 16 bits for a given operation, when Lab does
not. If anyone is not
convinced, I'm all ears.
there are a number of different reasons why the above
may occur. I am in agreement that ProPhoto cannot typically contain
gradients - all the way out to the most saturated real colors - in 8 bit.
How those gradients are going to be reproduced is another huge issue but
it's true.
Here's an effect I have not been able to explain.
If you convert a ProPhoto
white to pure blue gradient to Lab, there is a
significant dark band in the
darker areas of ProPhoto. This does not happen
in green, where
significantly more clipping occurs, or red, which is
about as bad as blue.
Can anyone explain this?
here's the danger with synthetic color tests. If we
think of primaries and gradients in terms of sRGB then 255 blue, for
instance, is a saturated but real and perceivable blue. A gradient from
there to white is not likely to occur in nature in any way (which is one
reason why I'm not a big fan of this type of synthetic gradient) but they
are all real colors and can be gamut mapped and printed.
A gradient from 255 blue in ProPhoto, however starts
in the imaginary, and on it's way to white moves into the real.
I guess the best question to ask is what color should
an imaginary blue map to? And how valid a test is a gradient that is
partially outside our vision? Is it reasonable that the range of numbers
that are not real colors doesn't necessarily fit into a normal gradient? I
would think so.
ProPhoto, has a substantially
larger gamut than Photoshop's implementation of Lab.
This merits more discussion. First I wonder about the
term substantially. It is a bit bigger but not much in terms of the gamut
of human perception. So while the primaries are "out there",
WE'RE not out there. They are only out there so that the triangle is large
enough to contain real colors that we want.
There is a calculated gamut that shows the most
saturated colors that a metameric system can create - that being a system
of 3 or more colorants that are mixed to produce a range of colors,
reflective or emissive. I'm afraid I can't show this gamut to you right now
but rest assured that it fits entirely inside the 0->100, -128->127,
-128->127 range of Lab that the ICC and Adobe use for Lab.
So, for all practical considerations - as in imagery
that we might want to capture or create and then display and/or print - the
Lab in Photoshop is fine. The rest is interesting color science but outside
the range of image reproduction.
Also, if Photoshop allowed for a larger Lab, it would
mean nothing to the rest of our workflow as the ICC PCS would truncate it
to the lower range anyway. Photoshop is not the place to look for answers.
does this make sense?
Regards,
Steve
________________________________________________________________________
o Steve Upton
CHROMiX www.chromix.com
o (hueman)
866.CHROMiX
o ColorGear ColorThink ColorValet
ColorSmarts ProfileCentral
____________________________________________________________________________
Date: Thu, 29 Sep 2005 22:08:54 -0700
From: "Mike Russell"
Subject: Re: Response to Andrew Rodney's test
Steve,
You bring up some interesting questions, but the topic
seems to have lost most of the original participants. I would suggest
that you start a thread in the sci.engr.color newsgroup, or if you wish
I'll be happy to respond offline.
BTW - the PCS is not subject to clipping.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Fri, 30 Sep 2005 10:34:56 +0100
From: "Bob Frost"
Subject: Re: Response to Andrew Rodney's test
Mike,
Why not continue discussing it here? It is the
"Colortheory" group, is it not (although ColorPractice might have
been a better choice of title for Dan to use). Just change the title to
widegamut spaces.
Bob Frost.
____________________________________________________________________________
Date: Fri, 30 Sep 2005 03:07:30 -0700
From: "Mike Russell"
Subject: Re: Response to Andrew Rodney's test
Hi Bob,
It is an interesting topic, and your questions are
good ones. I'm hitting a busy patch right now, so perhaps others will
join in.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Fri, 30 Sep 2005 12:18:55 EDT
From: Dan Margulis
Subject: Re: Response to Andrew Rodney's test
Bob Frost writes,
Why not continue discussing it here? It is the
"Colortheory" group, is it not
(although ColorPractice might
have been a better choice of title for Dan
to use).
You have brought up the point of the name of the list
previously, and Stephen Marsh replied that it is called the *APPLIED* Color
Theory list. Over the last two or three years, the conventional wisdom has
changed rather greatly as "experts" have discovered that how
color theory is applied and how it might work in a vacuum are very
different things.
This particular thread discussed characteristics of
LAB vs. ProPhoto RGB, a wide-gamut RGB space. It was noted that both
contain many colors that either can't be reproduced or don't exist at all,
yet can be defined. These are certainly topics of concern to us as they
have important ramifications for color correction. It then turned to the
question of exactly which of the definition-only colors that don't in fact
exist may theoretically appear in one colorspace and not the other. That
question has no relevance to practical image manipulation, so Mike was
right to suggest taking it to another group that concerns itself with color
science.
This month has already broken the list's previous
record for the number of messages, which I do not consider a good thing.
I'd rather stay tightly focused, with a more manageable number of posts.
OTOH, unlike past months with high message volumes where there has been a
lot of off-topic stuff and posturing, it doesn't seem to me that any of it
has been so lengthy or so off-topic that we needed to step in and stop it.
The sort of self-policing exemplified by Mike is most welcome. (That's also
why I haven't posted anything further on 16-bit, waiting for volume to die
down.) I trust we will also see some self-policing on the User
practices-RGB definitions thread, which seems to have run its course and
has become more of a woulda-shoulda-coulda thread, not to mention overly
personal.
For the next week, I'm off and the list will largely
be handled by Darren, Andrew, and Stephen.
Dan Margulis
____________________________________________________________________________
Date: Fri, 30 Sep 2005 18:35:36 +0100
From: "Bob Frost"
Subject: Re: Response to Andrew Rodney's test
Dan,
You have brought up the point of the name of the list
previously, and Stephen
Marsh replied that it is called the *APPLIED* Color
Theory list.
Your memory is very good. But it isn't actually called
the 'AppliedColorTheory' list according to Yahoo or the messages that I
get. It is called 'ColorTheory'. So that, to my mind, entitles us to talk
about theoretical spaces, theoretical advantages of highbit working, etc,
etc.. If you really do want to confine it to Applied topics, why not change
the name. Other lists change their names to update themselves every now and
again.
This particular thread discussed characteristics of
LAB vs. ProPhoto RGB, a
wide-gamut RGB space. It was noted that both contain
many colors that either
can't be reproduced or don't exist at all, yet can be
defined. These are
certainly topics of concern to us as they have
important ramifications for color
correction.
But what I was suggesting is that there might be more
than one 'Lab'. As far as I can see, there is 'theoretical' LAB and
'practical' LAB, and I thought, perhaps misguidedly, that this might have
accounted for some of the discrepancies between the arguments in previous
posts. OK, 'practical' LAB is what we have to work with in PS/CS, as Mike
pointed out, but the more I read of the ICC specification of the PCS, the
more variable it all seems to become.
I'm not trying to be awkward; I read this list to try
and find out more about the finer nuances of the theory behind what we do
in PS/CS, not what one has to do to print on a printing press. There are
loads of lists that talk about the practical aspects of color management; I
thought this was the only one (or nearly) that discussed the current theory
behind all these recipes for color processing that we find in book after
book after book.
That question has no relevance to practical image
manipulation, so Mike was right to suggest taking it
to another group that concerns
itself with color science.
What is the difference then between a group on 'color
theory' and a group on 'color science'?
Bob Frost.
____________________________________________________________________________
Date: Fri, 30 Sep 2005 12:00:55 -0600
From: Andrew Rodney
Subject: Re: Response to Andrew Rodney's test
On 9/30/05 11:35 AM, "Bob Frost" wrote:
What is the difference then between a group on 'color
theory' and a group on
'color science'?
A color science list would spend more time discussing
how many ICC profiles can dance on the head of a pin and lots of math would
be involved.
A color theory, especially an applied color theory
list in my mind should discuss LAB, various flavors of LAB and so forth (as
we1re doing now).
I don1t know why there needs to be some limit on the
number of posts per day as long as they don1t go OT or get nasty. Is there
a bandwidth issue? It1s quite easy to unsubscribe, filter emails and so
forth so I personally would love to hear others discuss this topic (like
most, I1ve still got LOTS to learn on the subject).
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Fri, 30 Sep 2005 12:04:32 -0600
From: Chris Murphy
Subject: Re: Response to Andrew Rodney's test
On Sep 28, 2005, at 2:45 PM, Mike Russell wrote:
All three of ProPhoto's primaries substantially exceed
Photoshop's Lab
encoding range of -128 to 127 in either the a or b
channel. Green is out of
range for both the a and b channels.
Apparently ColorThink displays either ProPhoto or LAB
incorrectly as it shows ProPhoto as fitting entirely within LAB. Converting
the XYZ values in ProPhoto to LAB yield bogus values (at least for 8-bit
integer encoding), for all three primaries. Interestingly enough, Apple's
3D gamut viewer built into the ColorSync Utility appears to do this
correctly. I'd characterize the red primary as being slightly outside of
LAB, and green and blue as being substantially outside of LAB. I would not
characterize ProPhoto RGB in its entirely as being substantially larger
than LAB, or vice versa, rather the gamut shape is considerably different.
Visually, if this plot is to be trusted, the gamut volume favors LAB by
quite a bit.
Lab will always have areas that no RGB space can
represent, but that does
not mean it has a larger gamut, or even that it is
coarser grained than
every RGB space.
Well, not really. RGB spaces use XYZ as the PCS, not
LAB. XYZ and LAB are different. You can think of LAB as being a subset of
XYZ, based on how they get encoded. There isn't a direct or overlapping
relationship between the two spaces. So I think you could conceivably
define an RGB space with a volume larger than encoded LAB.
I think my point stands. ProPhoto, has a
substantially
larger gamut than Photoshop's implementation of Lab.
I'd like to know what metric you are using to come to
this conclusion.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Fri, 30 Sep 2005 14:26:49 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Sep 28, 2005, at 11:10 AM, Dan Margulis wrote:
By your definition, not mine. To me, it's roughly like
declaring that when
you assign a profile to an RGB file you have edited it
in LAB.
It's not my definition, but by definition of how the
application was designed and works. It's a fact, not an opinion. All of the
edits that can be applied are performed after demosaicing, on data that's
in a linear ProPhoto RGB space. Your analogy totally doesn't work.
There are many hundreds of thousands of totally
screwed up images that got
that way without the benefit of ultra-wide gamut RGB.
Photoshop 2.5 is capable of creating outstanding
images even though it
doesn't allow layers. Outstanding images can also
result from large edits to
ProPhoto RGB files. Neither approach is sensible if a
rational alternative is
available.
I say "cars get people from point A to B safely
all the time, they aren't inherently dangerous" and you response with
"people get hurt by cars all the time, cars 40 years ago were capable
of hurting or not hurting people." You haven't said anything
relevant at all, and have actually totally skirted the issue at hand.
You've implied, but not directly stated, that editing
in wide gamut RGB spaces is inherently dangerous and has been completely
rejected the better part of a decade ago. I say such a statement has to
date been unsupported. Clearly it's not inherently dangerous or there would
be hundreds of thousands of totally screwed up images *traceable* to the
fact they were edited in a wide gamut RGB space.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Sat, 1 Oct 2005 09:07:07 EDT
From: Dan Margulis
Subject: Re: Andrew Rodney's test--consensus
Chris Murphy writes,
It's not my definition, but by definition of how the
application was designed and works. It's a fact, not an opinion.
That it looks like a duck, walks like a duck, and
quacks like a duck is fact. That it is actually a moose is your opinion.
If you wish to see why it's not a moose, perform the
following simple test:
1) With a copy of the image, go into preferences and
change the internal computation space of Camera Raw from ProPhoto to LAB or
some rational RGB.
2) Call up the channel by channel curves and apply
edits to your taste.
3) Return the preference to Prophoto and duplicate the
test as best you can with the original image. Then, if it's truly an
editing program, you should be able to see the difference.
I would do the test for you, but I am having a little
trouble finding where commands 1 and 2 are located in Camera Raw, and I'm
going to be off for a week starting now.
You've implied, but not directly stated, that editing
in wide gamut
RGB spaces is inherently dangerous and has been
completely rejected
the better part of a decade ago.
It's no more dangerous than LAB, but unlike LAB, it
has no advantages. What I stated directly is that it is a naive approach, a
solution in search of a problem, that was completely rejected *more* than a
decade ago, because it was found that its Kodak proponents' histograms and
promises of greatly increased color gamuts by 1997 for which existing RGBs
wouldn't be good enough, did not quite make up for saddling the world with
such a clumsy editing space. Also, the Kodak promise of the magic profile
that would convert wildly out of gamut colors accurately into any output
condition never quite was fulfilled.
Dan Margulis
____________________________________________________________________________
Date: Sat, 01 Oct 2005 08:19:20 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 10/1/05 7:07 AM, "Dan Margulis"
wrote:
1) With a copy of the image, go into preferences and
change the internal
computation space of Camera Raw from ProPhoto to LAB
or some rational RGB.
Not possible! You can change the encoding from
ProPhoto to three other RGB
working spaces. You cannot change the internal
processing. As Chris and I
both pointed out, all internal process is done in 1.0
gamma encoded ProPhoto
RGB.
I would do the test for you, but I am having a little
trouble finding where
commands 1 and 2 are located in Camera Raw, and I'm
going to be off for a week
starting now.
There are no such commands.
Andrew Rodney
____________________________________________________________________________
Date: Sat, 01 Oct 2005 14:59:18 -0000
From: "dmargulisnj"
Subject: Re: Andrew Rodney's test--consensus
Andrew Rodney writes,
There are no such commands.
I am shocked--shocked!!! to find that GAMBLING is
going on here!
Dan Margulis
____________________________________________________________________________
Date: Sat, 1 Oct 2005 12:50:35 -0400
From: Terry Wyse
Subject: Re: Andrew Rodney's test--consensus
On Oct 1, 2005, at 9:07 AM, Dan Margulis wrote:
1) With a copy of the image, go into preferences and
change the internal
computation space of Camera Raw from ProPhoto to LAB
or some rational RGB.
How/where can you do this? Never mind changing the
internal space, you can't even change the external/rendering space to LAB
as far as I know.
Terry
____________________________________________________________________________
Date: Sat, 1 Oct 2005 10:43:03 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
Hi all,
I was getting a bit tired of this thread but it seems
like some things need to be clarified here regarding camera raw:
Chris Murphy writes:
All of the edits
that can be applied are performed after demosaicing,
on data that's
in a linear ProPhoto RGB space.
I see no reason to suspect that this is not true - it
makes perfect sense. The camera chip captures high-bit luminance data
through red, green and blue "filters". That data could (and often
does) have a higher scene referenced (real world) dynamic range than can
normally be encoded in any RGB workspace. A linear gamma ProPhoto RGB
colorspace would ensure that you have enough room to perform color edits
and transforms to arrive at the best idealized color data for the standard
gamma encoded colorspaces in Photoshop proper.
Dan writes:
That it looks like a duck, walks like a duck, and
quacks like a duck is fact.
That it is actually a moose is your opinion.
and
1) With a copy of the image, go into preferences and
change the internal
computation space of Camera Raw from ProPhoto to LAB
or some rational RGB.
2) Call up the channel by channel curves and apply
edits to your taste.
3) Return the preference to Prophoto and duplicate the
test as best you can
with the original image. Then, if it's truly an
editing program, you should be
able to see the difference.
Sorry Dan, while this is kind of humorous, its not
particularly relevant. First, regarding steps 1 & 2 this is not
possible in Camera Raw. Second, When you select different color spaces in
Camera Raw you are only determining what colorspace you are transforming
the raw data into not what colorspace you are conducting calculations in.
You can think of Camera Raw more like a scanner that is capturing an image
and opening it into Photoshop in the workspace of your choice.
You do have some powerful control over color but the
original data transforms occur in a kind of black-box operation involving
interpolation between 2 color temperature extremes and de-mosaicing
algorithms, sort of rocket science kind of stuff. In practice the main
color controls in ACR (Adobe Camera Raw) behave in a similar manner to LAB
moves - color temp changes occur along a blue-yellow axis using a slider.
Fine tuning uses a "tint" slider which adjusts along a
magenta-green axis. There are crude luminance controls in exposure (white
point) brightness (levels) and contrast sliders. There is now a very nice
luminance "curve" control as well as more fine tuning slider
controls that adjust RGB hue and saturation kind of like the Hue/Saturation
adjustment in PS.
The fact that all of this operates in a high dynamic
range, wide gamma, high-bit colorspace is besides the point and does not
pertain to the question of whether one should stay in a wide gamma, hi-bit
colorspace for further editing in Photoshop. That's like saying that you
should edit your files in wide gamma 16 bit because your scanner scans in
16 bit. AFAIK, no one questions the validity of scanning in 16 bit to
arrive at a good 8 bit file.
(Andrew, the following is a rhetorical question and
does not require your standard response)
Once you are in a gamma encoded standard colorspace
the question becomes: Is there any advantage, beyond bragging rights, to
staying in a colorspace that lavishes bits on colors that are not visible
on your monitor or printable on any output space? Does holding on to
invisible colors while you are editing help you achieve better control over
printable colors especially if you can't see them, or evaluate them during
edits? The exact methods that Camera Raw uses in its internal color
transforms really have no bearing on this question.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Sat, 01 Oct 2005 17:06:10 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 10/1/05 11:43 AM, "Lee Varis" wrote:
(Andrew, the following is a rhetorical question and
does not require
your standard response)
I'll try a non standard response since you seem to be
missing a key point:
Once you are in a gamma encoded standard colorspace
the question
becomes: Is there any advantage, beyond bragging
rights, to staying
in a colorspace that lavishes bits on colors that are
not visible on
your monitor or printable on any output space?
The colors ARE printable, that1s the entire point. At
least with ACR, I1ve demonstrated for anyone that wants to look at the
gamut plots of actual image and working space in ColorThink that there ARE
colors contained in ProPhoto RGB I can output to my 2400 that are lost in
Adobe RGB (1998). This isn1t theory, it1s fact.
Does holding on to
invisible colors while you are editing help you
achieve better
control over printable colors especially if you can't
see them, or
evaluate them during edits?
I don1t need to seem them on screen. I can, do and
want to use them on the output device. Again, examine the gamut plots. In a
very simple and not exotic image lacking what most would consider a very
saturated scene, there are colors I can output to my $800 ink jet but ONLY
if I use ProPhoto from RAW.
Andrew Rodney
____________________________________________________________________________
Date: Sat, 01 Oct 2005 18:12:18 -0700
From: Marco Ugolini
Subject: Re: Re: Andrew Rodney's test--consensus
In a message dated Sat, 01 Oct 2005 14:59:18, Dan
Margulis wrote:
I am shocked--shocked!!! to find that GAMBLING is
going on here!
Then it might very well be the beginning of a
beautiful friendship...
--------------
Marco Ugolini
Mill Valley, CA
____________________________________________________________________________
Date: Sat, 1 Oct 2005 22:48:01 -0500
From: "Maris V. Lidaka Sr."
Subject: Re: Re: Andrew Rodney's test--consensus
Time for a Google search for the casino nearest to
Mill Valley, CA <g>
Maris
____________________________________________________________________________
Date: Sun, 2 Oct 2005 00:37:14 -0700
From: "Mike Russell"
Subject: Re: Re: Andrew Rodney's test--consensus
LOL. Someone give the man his winnings!
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Sun, 2 Oct 2005 06:15:41 -0700
From: Richard Wagner
Subject: Re: Andrew Rodney's test--consensus
Lee Varis wrote:
I was getting a bit tired of this thread but it seems
like some
things need to be clarified here regarding camera raw:
Lee, you are absolutely correct, and you did an
outstanding job of summarizing the functionality of ACR.
Once you are in a gamma encoded standard colorspace
the question
becomes: Is there any advantage, beyond bragging
rights, to staying
in a colorspace that lavishes bits on colors that are
not visible on
your monitor or printable on any output space?
Perhaps not, but there *are* colors in ProPhoto that
are outside the gamut of AdobeRGB (1998) and sRGB that *are* within the
gamut of some current output devices. Does one want to throw those
colors out, or not? In addition, there are a lot of colors present
within the gamut of scanned films like Fuji Velvia that are out of gamut in
AdobeRGB and sRGB that are in gamut in ProPhoto **as well as many current
output devices.** Are these colors important to you, or not? If they are,
therein lies one very good justification for using a wide-gamut colorspace
like ProPhotoRGB. Unlike the internal computational module of ACR,
this is not rocket science.
If someone doesn't believe this, the data is right
here, with thanks to Steve Upton for making the comparisons so easy using
ColorThink.
http://www.wildnaturephotos.com/Public/Gamut.html
--Rich Wagner
____________________________________________________________________________
Date: Sun, 2 Oct 2005 13:19:30 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
Warning - long post ahead!
On Oct 1, 2005, at 4:06 PM, Andrew Rodney wrote:
I'll try a non standard response since you seem to be
missing a key point:
He then proceeds to offer his standard response:
The colors ARE printable, that’s the entire
point.
I will try, one last time to explain the point I'm
trying to make which is not the point that Andrew keeps responding to. On
Sept 4th I wrote:
For the most part we should be more concerned with
color
relationships and tonal compression...Making images
that have a range of
tones and colors that look good to a human observer
does not require
working in ProPhoto RGB or 16bits...- humans respond
much more to contrast than
color. Color contrast is more important than color
gamut or hue...
making a point here about the relative importance of
color vs tone (lightness/darkness) Tone is something we can see and make
decisions about in almost any color space but it becomes hard to see
accurately in wide gamut color spaces because color clipping (on the
display) distorts the rendering of lightness and darkness in the more
compressed color space. Because we can't see the tonal shape in colors that
are outside the gamut of our display we have to guess- this is what I mean
by saying that wide gamut colorspaces do...
nothing to make it easier to work within the
constraints of
fairly small output spaces.
To which Andrew responds:
I need all the colors to DECIDE what to compress. If
you throw them away
from the start, I can't do that.
This thread started in the context of processing from
digital camera raw files - since I never advocated throwing away the raw
data I'm not sure what he's talking about here but apparently Andrew can
make decisions about colors he can't see (some sort of faith in intelligent
design) because he also says:
I don’t need to seem them on screen.
pretty sure he means "see" them on screen...
I offered a creative use of the individual grayscale
channels in ProPhoto RGB as a way of controlling the rendering of
out-of-gamut colors into a more compressed color space. I'm merely
advocating that you arrive at that colorspace earlier rather than later so
you have the opportunity to exercise some control over the rendering of
your colors. The point here is that if you follow the "wide gamut
until the bitter end workflow" you won't know what happens to the
color until you make the print. If the color "relationships"
don't work out the way you guessed they would you have to make some kind of
blind edit and try again.
Andrew has faith that the out-of gamut colors that
"are not printable" on the output device will "not"
affect the rendering of the colors that "are printable" during
the gamut re-mapping that occurs in the profile conversion. I have seen too
many instances of tonal compression in saturated colors (especially greens)
in Adobe RGB going to an Epson printer to have the same kind of faith. I'm
certainly wary of ProPhoto RGB if there's any chance that any colors may be
out-of-gamut for the output device. Colorthink gamut maps don't tell you
which parts of an image are out-of gamut and by how much - you have to
guess. This is a kind of gambling that I'm not good at.
Apparently, Andrew's decision making process revolves
around whether to use perceptual rendering or relative colorimetric - both
things are hard-wired into the profile and offer no user intervention
beyond the basic choice. Thats fine, I just require more.
This kind of decision making is comfortable for
photographers - a group that I must admit I'm also a member of. In the good
old days of film we shot what we got from Kodak or Fuji and handed it off
to the lab- what you got was what you got. You never had any opportunity to
see colors until it was too late to do anything about it. Once you had your
film that was it unless you re-shot it. Your only control was over exposure
or a crude color filter- all of you creative decisions were made before you
pressed the shutter release. Photographers do develop an ability to
pre-visualize the result but generally exercise very little control
"during" the process.
Over the years of development of photography most
photographers developed a reverence for the rendered image. It was way
better than a painting at capturing a realistic image. Somehow the photo of
a thing carried a kind of truth that was sacrosanct. We don't dare
challenge (or change) it. This is an accepted attitude that finds its way
into news photography where no one is allowed to modify the image in
Photoshop (beyond traditional darkroom controls). Many photographers
like Ansel Adams went to herculean efforts to exercise control over the
rendering of the image but nobody had the kind of control available to the
average photographer today. I think that many photographers have yet to
learn the extent of that control and remain content with a system that
approximates what they learned from the past.
The fantasy that the colors "contained" in
ProPhoto RGB are somehow truthful to the original scene leads one to treat
these colors as if it was of the utmost importance to preserve them at all
costs. We struggle to somehow get a one-to-one mapping between these scene
referenced colors into a print referenced context with scientific accuracy.
It has been my observation that the more successful you are in maintaining
this accuracy the more likely you are going to get a boring image. Of
course there are exceptions, brilliant exceptions, where the struggle pays
off. We can guess at the situations where this is likely to be true. Most
of the times the exact hue/saturation rendering of a specific color in an
image is less important that the emotional impact that color and tonal
"relationships" within the image have. I find it impossible to
judge color/tone relationships that are not at least close to visible and I
prefer to make these decisions before I get to a finished print as I have
to pay for all my ink and paper.
I guess it all depends on your comfort level with
things unseen. Over the years Photographers have learned to be comfortable
with the latent image. I am not so comfortable nowdays but I don't have the
benefit of faith that Andrew has. Please forgive me. If you are going to
have faith in wide gamut RGB colorspaces you should do all editing in 16
bits because you never know whether some move you make might generate some
unseen artifact that might find its way into a more constrained printspace!
This has been demonstrated very effectively in Andrews examples.
I am working on providing some visual examples to help
illustrate the concepts outlined above but you'll have to wait a little
while longer.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Sun, 02 Oct 2005 17:26:51 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
Lee, there are all kinds of colors in CMYK (as well as
about any output color space) that you can't see, that fall way outside
sRGB (the gamut of about 99.5% of every display in the world). Lab too. So
this isn't a compelling argument.
Andrew Rodney
____________________________________________________________________________
Date: Sun, 02 Oct 2005 17:40:06 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 10/2/05 2:19 PM, "Lee Varis" wrote:
The fantasy that the colors "contained" in
ProPhoto RGB are somehow
truthful to the original scene leads one to treat
these colors as if
it was of the utmost importance to preserve them at
all costs.
ProPhoto RGB is output referred by it's very nature
and design (as is very working space) and not scene referred. I've never
implied nor should you assume I'm saying that ProPhoto RGB or any such
rendering and encoding is Colorimetrically correct (which IS ugly and not
what most users want). In no way is ProPhoto or for that matter any color
space that doesn't look quite ugly truthful to the scene (I don't even know
what truthful means but I do know and can define what colorimetric color
means).
We struggle to somehow get a one-to-one mapping
between these scene
referenced colors into a print referenced context with
scientific
accuracy.
We struggle to render the image in our mind into
output referred color. Your idea of what that should look like is probably
quite different from mine just as with the same color neg, we are unlikely
to produce the same color appearance on print in a darkroom.
I find it impossible to judge color/tone relationships
that are not at least close to visible and I prefer to
make these
decisions before I get to a finished print as I have
to pay for all
my ink and paper.
The reference media of your display and your print are
not the same.
If you are going
to have faith in wide gamut RGB colorspaces you should
do all editing
in 16 bits because you never know whether some move
you make might
generate some unseen artifact that might find its way
into a more
constrained printspace!
We are in total agreement here and this has always
been my original point (this discussion of wide gamut spaces like ProPhoto
RGB started due to the my point about editing in high bit, something that a
few here have said isn't necessary nor can be proven in a real world
image).
Andrew Rodney
____________________________________________________________________________
Date: Sun, 2 Oct 2005 16:42:52 -0700
From: "Mike Russell"
Subject: Re: Andrew Rodney's test--consensus
Well said, Lee.
I would add that, with all the talk of wide gamuts,
the importance of touching terra firma once in a while, in the form of
actual image examples that use these colors, is as rare as it is important.
I look forward to your examples.
Consensus in any interesting topic, by definition, is
not possible, but cordiality is. Iit is possible to clearly state a
position, as you have done, and be content that those individuals who are
ready for it will pick up on it.
Mike Russell
www.curvemeister.com
____________________________________________________________________________
Date: Sun, 2 Oct 2005 22:46:46 -0600
From: Ron Kelly
Subject: Re: Andrew Rodney's test--consensus
In following this thread I'm wondering if these
statements are true:
1. If you clip colors because your editing space is
too small that could be bad and you could lose detail that would be
difficult or impossible to regain by further manipulation so you should use
a wide enough editing space to retain detail;
2. If the gamut of the picture you're working
with is smaller than a wide editing space then a smaller editing space is
better, which is "tighter" to the gamut of the subject;
3. Same as number 2, except that the gamut of the
picture *is* clipped but the lost colours are unimportant to the picture
and so you are better off editing in a smaller space even if you've lost
some detail which is insignificant.
Ron Kelly
____________________________________________________________________________
Date: Mon, 03 Oct 2005 01:56:35 -0700
From: Marco Ugolini
Subject: Re: Andrew Rodney's test--consensus
The problem of working with images some of whose
colors one cannot see -- but are still being affected by one's edits in
ways that are not directly verifiable on-the-fly -- is one which we have
all experienced and banged our heads against on more than one occasion.
I agree with Lee that it is definitely a *real*
problem to work with colors that one cannot see on one's display, and that
it becomes a matter of disorienting guesswork to figure out what happens to
them as a consequence of an edit, all the more so in a wide-gamut
colorspace.
Hence I understand that many photographers would feel
safer working in AdobeRGB using, say, a profiled NEC SpectraView LCD
monitor, which is able to display most -- or perhaps even all -- of the
colors in the AdobeRGB space. There is comfort in knowing that what one is
seeing bears close resemblance to what one is to expect.
I also perfectly understand, and respect, Andrew's
justified concern with preserving all the colors present in an image,
specially a particularly important one that one hopes to be able to produce
more effectively using technologies that have not yet been developed, but
may be in a near future. We should not dismiss this as empty
"perfectionism": there is nothing wrong with
"perfectionism" that is used capably and with a conscious vision.
This can be transformed into an obsession, though,
just as rapidly. When I printed my personal B&W in the darkroom many
years back, I did not spend tons of time going around around trying *all
possible combinations* of paper, developer, enlarger, lens, filters, and
god knows what other countless variables. To make my life as simple as one
must make it if anything at all is eventually to get made within one's
lifetime, I made a choice of enlarger, paper and developer relatively early
on, and stuck with it for a long time. And, as an artist, I also remained
happy with the results for a long time.
As a recent Ansel Adams retrospective made amply
clear, printing is very subjective even for the same person at different
times in one's life: a print that Adams created with certain results early
on in his life he made again with visibly different results years later (a
few such examples were on view). Adams kept experimenting, but my point is
that even if one sticks to one particular combination, the results change
over time because one's sensibility itself, along with technical prowess,
change and evolve even if nothing else does.
I wish to make very clear that I am *not* advocating
that the master of an important image is better preserved in a
narrower-gamut RGB space. What I *am* saying is that real-world limitations
such as *monitors that cannot display colors that we can print* make many
people understandably uncomfortable, and unwilling to risk wasting time and
money on tedious and often confusing print tests, whereas a smaller color
space may prove more "user-friendly," and still give them results
that have the desired artistic integrity, although they may be
scientifically short of a perfect ideal.
I will never need to go back to a traditional
darkroom, and I sincerely love the boundless control afforded in today's
digital darkroom. But I also know from personal experience that it's easy
to lose oneself in the pursuit of things that only a few years back never
caused us to lose much sleep, even as artists. But, to make it all more
confusing, it's also true that the newer technologies can be, and indeed
are being, used as artistic tools by those who wish to do so, opening new
vistas that did not exist in earlier times.
I hope not to be misunderstood and seen as taking
sides. I'm not. If anything, mine is a call to consider the ramifications
of both the "AdobeRGB solution" and the "wide-gamut
solution": each offers advantages and presents shortcomings, so that
which is suitable for one's particular needs is a choice still to made on
an individual basis, the way one used to choose whether to shoot
Ektachrome, or Velvia, or Cibachrome. Some of us shoot catalogs, for which
gamut and fidelity may be the foremost values, while others create very
personal art, for which the rules are often there to be broken. Obviously,
one size does *not* fit all.
--------------
Marco Ugolini
Mill Valley, CA
____________________________________________________________________________
Date: Mon, 03 Oct 2005 09:09:49 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 10/2/05 10:46 PM, "Ron Kelly" wrote:
1. If you clip colors because your editing space is
too small that
could be bad and you could lose detail that would be
difficult or
impossible to regain by further manipulation so you
should use a wide
enough editing space to retain detail;
Yes. And this is especially true for detail in dark
areas of an image, not just super saturated colors you might be able to
reproduce.
Bruce Fraser as usual, elegantly summed it up here
(the last paragraph is key):
-----------------------
Bruce Fraser - 12:02pm Jun 3, 05 PST (#11 of 46)
If you look at RGB matrix spaces (i.e., those defined
by a white point,
primaries, and gamma-defined tone curves) in a 3D lab
plot like those
offered by the ColorSync utility or Steve Upton's
indispensable ColorThink,
you'll see that they all reach their maximum
saturation at a fairly high
luminance level. The gamut narrows dramatically at
lower luminances,
tapering to a point at black.
Print spaces plotted the same way have a different
shape, where maximum
saturation is achieved at lower luminance levels. (In
an RGB space, you make
more saturation by adding light, on a printer you make
more saturation by
adding ink, so this makes sense.)
So an RGB matrix space that has a wide enough gamut at
lower luminances to
hold the printer gamut has to have extremely wide
primaries that may not
represent anything that's physically possible.
Obviously, that leads to the
space containing non-realizable colors. It's the
trade-off you make when you
want to create an RGB matrix space that contains all
the realizable colors
from your printer, and that's why ProPhoto is so
large.
Then there's the question of clipping. It's not at all
hard to capture
colors that are outside Adobe RGB. Many of the dark
greens and yellows that
are prevalent in nature are outside Adobe RGB, and if
you convert to Adobe
RGB, or a smaller space, gradations of those colors
get clipped to solid
blobs. There's already been at least one such problem
image posted on this
forum. So the advantage of ProPhoto isn't about
retaining all those
out-of-gamut colors per se, it's about maintaining the
distinctions between
them, so that you can map them into printable space as
gradations rather
than blobs.
http:
//www.adobeforums.com/cgi-bin/webx?128@521.6gG0eygTNGy.52@.3bbabc37
---------------
2. If the gamut of the picture you're working
with is smaller than a
wide editing space then a smaller editing space is
better, which is
"tighter" to the gamut of the subject;
I'd say yes to that.
Andrew Rodney
____________________________________________________________________________
Date: Mon, 3 Oct 2005 12:48:33 -0600
From: Ron Kelly
Subject: Re: Andrew Rodney's test--consensus
Could you elaborate a bit more? Why is it better to
have an edit space that is big enough, but not any bigger than necessary?
Ron Kelly
____________________________________________________________________________
Date: Mon, 3 Oct 2005 12:15:52 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 1, 2005, at 11:43 AM, Lee Varis wrote:
The fact that all of this operates in a high dynamic
range, wide
gamma, high-bit colorspace is besides the point and
does not pertain
to the question of whether one should stay in a wide
gamma, hi-bit
colorspace for further editing in Photoshop.
Yes to everything in this post except one item in the
above paragraph with respect to high dynamic range. ProPhoto RGB has a
considerable gamut, but it isn't a high dynamic range space. Minimum we
need 16bpc *floating point* for that, although at least in Photoshop and
elsewhere the trend appears to be toward 32bpc floating point for HDR
support.
This has the potential to get confusing rather
quickly, as we can have values blacker than black and whiter than white,
and color values outside of the primaries, of a color space. The ICC also
has no support for HDR at the present time either, so there are some
workarounds for the moment. (If you save out an HDR image with Adobe RGB
(1998) as the profile for example, what's embedded are just the primaries.
The image gamma goes to 1.0 in any case.)
Anyway, HDR is a different world and is in many
respects beyond the capability of ICC-based color management for the time
being. We'll have to see how this plays out in terms of the popularity of
HDR, what new tools we will see to manage the display and printing of such
images where such dynamic range isn't reproducible, etc.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Mon, 3 Oct 2005 12:45:47 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 2, 2005, at 10:46 PM, Ron Kelly wrote:
1. If you clip colors because your editing space is
too small that
could be bad and you could lose detail that would be
difficult or
impossible to regain by further manipulation so you
should use a wide
enough editing space to retain detail;
The tense is subjunctive, therefore the answer is
always yes because there will always be someone who will have an edit space
that's too small, given the prevalent spaces of today. It "could"
be bad - absolutely it could be. Is it? Well, that's another question. You
might not care about the detail or color lost. But that is not a technical
question, rather an artistic one.
2. If the gamut of the picture you're working
with is smaller than a
wide editing space then a smaller editing space is
better, which is
"tighter" to the gamut of the subject;
With the controls we have today, it will give you
finer control because moderate moves in a small space can have less of an
effect on the image than small moves in a very wide space. If such editing
behavior is "better" in your view, then it's better. If you have
the granularity you need in a wide space, then it's no better or worse in
this example.
If the exact same image colors are in ProPhoto RGB
(wide gamut space), or sRGB (small gamut space), the color conversion
yields the same result. The CMMs used today defer gamut compression
entirely to the destination profile (when they are tabled based, such as
output device profiles). Since the pixel data of the ProPhoto RGB and sRGB
versions of the same image have the same equivalent LAB values, the
destination profile will convert them the same. It's not like you get more
gamut compression because the source space is bigger. This is what I mean
by prebaked output profiles. The gamut compression is precomputed, at the
time the profile is built, not at the time the profile is used.
3. Same as number 2, except that the gamut of the
picture *is*
clipped but the lost colours are unimportant to the
picture and so
you are better off editing in a smaller space even if
you've lost
some detail which is insignificant.
Same as the answer for 2. If you don't care about the
lost data, then the question is about the editing behavior of the smaller
versus larger space, and the granularity difference implied by each.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Mon, 03 Oct 2005 13:40:43 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
First off, I seriously doubt youxll find a perfect
(even near perfect) mate between the two based on the unique shapes of
synthetic working spaces. In a perfect world, the working space and output
space would be as close as possible, especially in 8-bit. Yes, there are
colors in a lot of color spaces that fall outside display gamut. It would
be nice if we could see all colors we are editing. As I mentioned to Lee,
there are colors in something relatively small like SWOP CMYK that you
canxt see on about 99%+ of every display in existence. The smaller the
working space, the closer the same 256 data points are to each other so
again, bigger space, more need for high bit capture/editing. Then therexs
the issue of gamut mapping from working space to output space. What intent?
Do you use gamut clipping or gamut compression? The closer the two are to
each other, the less all of this becomes an issue (issue probably isnxt the
right word).
We donxt live in a perfect world. We sometimes know we
will edit a file once and only once for a certain output. Ixd be perfectly
happy to work in even ColorMatch RGB in 8-bit if I knew the image was only
going to SWOP. Personally, many of the images I shoot are going out to a
much larger gamut printer and I donxt know where I'll print them in the
future. I can see scene color captured that falls outside Adobe RGB (1998)
on an image by image basis, so I select ProPhoto RGB in 16-bit due to my
unknown goals for the file. But I donxt always use that space and I donxt
think too many are advocating using only such a space.
Andrew Rodney
____________________________________________________________________________
Date: Mon, 3 Oct 2005 17:11:05 -0600
From: Ron Kelly
Subject: Re: Andrew Rodney's test--consensus
"Granularity"? What does this mean?
Ron Kelly
____________________________________________________________________________
Date: Mon, 3 Oct 2005 14:15:34 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 1, 2005, at 7:07 AM, Dan Margulis wrote:
I would do the test for you, but I am having a little
trouble finding where
commands 1 and 2 are located in Camera Raw, and I'm
going to be off for a week
starting now.
The test is useless and you know it. But you have
demonstrated that you don't know how Camera RAW works.
*All* edits, regardless of settings occur after
demosaicing in a 16bpc integer RGB space with ProPhoto RGB primaries and a
1.0 image gamma. This is the internal editing space of Camera RAW and there
is no user selectable option to change it.
The choice of color space and bit depth is a
*destination* profile after all edits are applied, thus a conversion occurs
from ProPhotoRGB' (which is ProPhoto RGB primaries using a 1.0 image gamma)
to whatever you've selected.
Edits do not occur in the selected destination profile
space.
It's no more dangerous than LAB, but unlike LAB, it
has no advantages.
That's more clear, but actually one step back and a
fair two steps sideways from the previous statement:
September 26th, Dan Margulis writes:
It's not clear to me whether they are advocating
ultra-wide gamut RGBs as
exchange spaces or storage spaces. If so, no
problem--they'll do as well as any
other reasonable alternative. If, as I suspect, they
are advocating actually
doing major edits in them, this is a naive workflow
that has been thoroughly
discredited for more than a decade.
Rephrased: If wide gamut RGB is used for exchange or
storage, there is no problem, for such a purpose they do as well as another
suitable space. However if edits are being done, they will not do as well
(i.e. inferior to), and such a workflows has been discredited for more than
a decade.
By singling out exchange/storage as doing as well as
alternatives, but not putting editing in the same context, you've poo poo'd
editing in wide gamut spaces, and using as your example wide gamut RGB
workflows which depended on heavy use of 8bpc because good 16bpc support is
recent. What's been discredited isn't editing in wide gamut RGB spaces
alone.
Also, the
Kodak promise of the magic profile that would convert
wildly out of gamut
colors accurately into any output condition never
quite was fulfilled.
Converting wide gamut RGB images to print space does
present challenges depending on the output device, and this is an area I
suspect we will continue to have problems until there is a smarter color
management system for converting such imagery rather than what we have now,
which is prebaked rendering tables in device profiles. This needs to become
dynamic.
There are three such technologies on the horizon, two
of which are shipping:
ColorIQ is a company making a smart CMM for Mac OS X.
The Tiger version isn't out yet.
Imation CMM has been resurrected and the Tiger
version should be shipping by now or any day now.
And Microsoft's proposed WCS which not only appears to
include pluggable gamut mapping models but also pluggable color appearance
models.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Mon, 3 Oct 2005 14:15:34 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 3, 2005, at 5:11 PM, Ron Kelly wrote:
"Granularity"? What does this mean?
Fineness of control. You can make finer edits in a
smaller gamut space, than a very larger one where small moves make big and
perhaps unwanted changes. Since the space is big, there is a limitation on
how fine the edits can be. This is related to bit depth. Even if the image
is 16bpc, you lack the granularity at least in Photoshop because the tools
use an interface that's still based on working on 8bpc images. If there
were a "fine tune" mode when working in 16bpc, this would
solve the problem.
For example, even when working in 16bpc, the curves
dialog still uses a 0-255 scale even though the actual scale behind the
scenes is 0-32768 (15bpc+1 is Photoshop "16bcp").
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Mon, 3 Oct 2005 23:05:07 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
On Oct 3, 2005, at 11:15 AM, Chris Murphy wrote:
ProPhoto RGB has a considerable
gamut, but it isn't a high dynamic range space.
Yes... sorry, I wasn't implying that ACR is doing any
kind of HDR processing just that digital cameras typically capture a wider
dynamic range than can be reproduced comfortably in normal workspaces and
it can help to have a 1.0 gamma workspace to carry out calculations in. Its
definitely not true high dynamic range.
This has the potential to get confusing rather quickly
Agreed... probably the less said about HDR in this
context the better
Anyway, HDR is a different world and is in many
respects beyond the
capability of ICC-based color management for the time
being.
Yes... again, sorry for the confusion.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Mon, 3 Oct 2005 23:23:42 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
On Oct 3, 2005, at 1:15 PM, Chris Murphy wrote:
ColorIQ is a company making a smart CMM for Mac OS X.
The Tiger
version isn't out yet.
Imation CMM has been resurrected and the Tiger
version should be
shipping by now or any day now.
And Microsoft's proposed WCS which not only appears to
include
pluggable gamut mapping models but also pluggable
color appearance
models.
This is very interesting - I always thought the
Imation CMM was a step in the right direction as it gave you some control
over how black generation occurred in profile conversions -it disappeared
before it had an adequate chance to develop. I'm even more intrigued by
"pluggable color appearance models". Soft proofing or appearance
simulation needs a serious overhaul - is anyone doing any interesting work
in this area?
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Mon, 3 Oct 2005 23:17:13 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
On Oct 3, 2005, at 11:45 AM, Chris Murphy wrote:
The CMMs used today defer gamut compression entirely
to
the destination profile (when they are tabled based,
such as output
device profiles). Since the pixel data of the ProPhoto
RGB and sRGB
versions of the same image have the same equivalent
LAB values, the
destination profile will convert them the same. It's
not like you get
more gamut compression because the source space is
bigger. This is
what I mean by prebaked output profiles. The gamut
compression is
precomputed, at the time the profile is built, not at
the time the
profile is used.
I've always been confused by this. What kind of gamut
compression is assumed in the destination profile. I've noticed the effect
where if colors are reasonably in gamut in even a wide source space they
don't shift as much as I'd expect- certainly not with say ProPhoto to CMYK
with perceptual rendering. So what IS going on? Do profiles effect some
kind of sliding scale compression based on how far out of gamut the color
is or do they simply assume a one-size-fits all compression. It bugs me
that I can't really predict what's going to happen with an out-of-gamut
color.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Tue, 4 Oct 2005 10:57:38 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 4, 2005, at 12:23 AM, Lee Varis wrote:
This is very interesting - I always thought the
Imation CMM was a
step in the right direction as it gave you some
control over how
black generation occurred in profile conversions -it
disappeared
before it had an adequate chance to develop. I'm even
more intrigued
by "pluggable color appearance models". Soft
proofing or appearance
simulation needs a serious overhaul - is anyone doing
any interesting
work in this area?
Microsoft of all companies. We'll just have to see
what gets delivered. I think it will be a step in the right direction.
Essentially what they've released publically at the last two WinHEC
conferences is a color management system that uses measurement data only
profiles, and pluggable color appearance and gamut mapping models. So
instead of having a separate application for building profiles in, you have
pluggable gamut mapping and color appearance mapping models. Presumably
Microsoft includes a few of each sort for at least RGB and CMYK transforms,
but leaves the door open for vendors to build their own. We'll just have to
wait and see how all of this plays out. If it doesn't work well, then it
will be ignored. If it works well, then color management implementation is
going to get really different in such a paradigm, and will be really
contingent on the user interface.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Tue, 04 Oct 2005 22:45:55 -0000
From: "dmargulisnj"
Subject: Re: Andrew Rodney's test--consensus
Chris Murphy writes,
The test is useless and you know it. But you have
demonstrated that Ê
you don't know how Camera RAW works. *All* edits,
regardless of settings
occur after demosaicing in a 16bpc integer RGB space
with ProPhoto RGB
primaries and a 1.0 image gamma. This is the internal
editing space of
Camera RAW and there is Êno user selectable option to
change it.
Holy Lecherous Leg-puller, Batman, whaddaya mean there
isn't an option? If that were true, and Camera Raw were an "editing
package", then it wouldn't be a question of "editing" in
Camera Raw in a sensible colorspace vs. an inferior one, it would be a
question of using an inferior one vs. not using Camera Raw at all, in which
case your whole post would make no sense. So the command is obviously
there, and you just haven't found it yet.
Similarly, with respect to the color curves: you're
the one whose saying Camera Raw is a serious editing tool, as opposed to
something more like a profiling or a scanning tool. Now this ultra-wide RGB
that you seem to be advocating was obsolete more than ten years ago, so it
would be unfair to compare Camera Raw to state-of-the-art editing packages
in 1995. But surely, if it's really a serious editing tool, it has to be
competitive with packages of *twenty* years ago!
Call Camera Raw an "editing package" if you
like, Batman, but Holy Outdated Oxymoron, you can't have an editing package
without curves! They would have laughed at such a thing even in 1985!
Photoshop can edit text, but that doesn't make it a word processor.
So again--that command is certainly there. You need to
go back and look for it.
Rephrased: If wide gamut RB is used for exchange or
storage, there Ê
is no problem, for such a purpose they do as well as
another suitable Ê
space. However if edits are being done, they will not
do as well Ê
(i.e. inferior to), and such a workflows has been
discredited for Ê
more than a decade.
Fair enough summary.
By singling out exchange/storage as doing as well as
alternatives, Ê
but not putting editing in the same context, you've
poo poo'd editing Ê
in wide gamut spaces, and using as your example wide
gamut RGB Ê
workflows which depended on heavy use of 8bpc because
good 16bpc Ê
support is recent.
Bit depth has nothing to do with it. The problem is
that when half the colorspace is taken up by nonexistent colors only half
can be devoted to those that do exist, so that any curve or similar
adjustment being applied has to be twice as accurate to avoid an
unacceptable result. That makes serious color correction very difficult. At
a minimum, if one wanted to achieve the precise control of endpoints that
is needed for professional-quality color, one would have to do the first
edits in an ultra-wide gamut RGB and then convert and fine-tune in a more
rational RGB, which would suggest the question of why not save a step by
working in a rational RGB from the get-go.
I'm back to vacationing.
Dan Margulis
____________________________________________________________________________
Date: Tue, 04 Oct 2005 19:21:24 -0400
From: "Gene Palmiter"
Subject: Re: Re: Andrew Rodney's test--consensus
I'm back to vacationing.
Dan Margulis
Well...you may be good a color theory...but you don't
seem to be very good at vacationing. GETOUTAHERE!
____________________________________________________________________________
Date: Wed, 5 Oct 2005 13:42:33 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 4, 2005, at 12:17 AM, Lee Varis wrote:
I've always been confused by this. What kind of gamut
compression is
assumed in the destination profile. I've noticed the
effect where if
colors are reasonably in gamut in even a wide source
space they don't
shift as much as I'd expect- certainly not with say
ProPhoto to CMYK
with perceptual rendering. So what IS going on? Do
profiles effect
some kind of sliding scale compression based on how
far out of gamut
the color is or do they simply assume a one-size-fits
all
compression. It bugs me that I can't really predict
what's going to
happen with an out-of-gamut color.
It's one size fits all gamut compression. At the time
the output device profile is built, there is a reference color space,
proprietary to each vendor, that they use to predicate gamut compression.
If they make it too aggressive, such as for a large source space, it will
do well with large gamut source spaces but will over compress images that
are in smaller spaces such as sRGB. This is one of the reasons why
RelCol+BPC works best with most kinds of images, whereas with others,
notably those that are ProPhoto RGB, perceptual can sometimes work better.
But it does depend on image content.
If you have an image completely contained in sRGB,
then make a copy, convert to ProPhoto RGB, by definition the ProPhoto RGB
version contains a "LAB equivalent" of the sRGB version. The
color appearance of the two is the same, even though one is in a larger
space. If you convert both to a particular destination, they will be
converted the same so long as you use the same CMM and rendering intent.
However, if there are substantially out of gamut
colors in a ProPhoto RGB image, it is possible those colors are so
far out of gamut that the gamut compression assumptions made by the
profiling software didn't take them into account and you can get a variety
of odd renderings. You can get very saturated blues that render to near
black, or you can get posterization, etc.
Because an ICC output device profile has to work with
so many sources, and therefore make so many compromises, is why I've been a
big proponent of dumping that whole method of color management and getting
to a point where we have measurement only device profiles and gamut
compression and color appearance mapping on a per image basis. That way the
amount of gamut compression is specific to the colors in the image as well
as the capabilities of the output device.
This could still be done in an ICC construct but the
ICC improves things at a glacial pace. Supposedly major improvements occur
in half-decade increments, which take another half-decade to disseminate
and maybe another half-decade for it to affect the mainstream users. Color
management improvement measured in decades is impressive, but not in a good
way.
The ICC now has the v4 specification which supposedly
does more to define the colorimetric intent as being closer to measurement
data than it is now (which it can't be exactly because the measurement data
has to be interpolated in order to get it to fit into a uniform grid), and
also defines a perceptual reference medium so that perceptual intents can
work more consistently regardless of the source space. Yet I have yet to
see any difference between v2 and v4 profile performance in practice.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Wed, 5 Oct 2005 18:09:33 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
On Oct 5, 2005, at 12:42 PM, Chris Murphy wrote:
It's one size fits all gamut compression. At the time
the output
device profile is built, there is a reference color
space,
proprietary to each vendor, that they use to predicate
gamut
compression.
Thanks Chris, that explains a lot! So the compression
assumptions made by the various venders can account for, say, one vender
does a better job with Adobe 98-> SWOP v2 but another handles ProPhoto
-> Epson better.
Because an ICC output device profile has to work with
so many
sources, and therefore make so many compromises, is
why I've been a
big proponent of dumping that whole method of color
management and
getting to a point where we have measurement only
device profiles and
gamut compression and color appearance mapping on a
per image basis.
That way the amount of gamut compression is specific
to the colors in
the image as well as the capabilities of the output
device.
I heard similar things proposed by others - I not sure
that I understand what is meant by "measurement only device
profiles" but it sure would be nice to get gamut compression specific
to the colors in an image by image basis sooner rather than later.
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Wed, 05 Oct 2005 21:28:56 -0700
From: Marco Ugolini
Subject: Re: Andrew Rodney's test--consensus
In a message dated Wed, 5 Oct 2005 18:09:33, Lee Varis
wrote:
I heard similar things proposed by others - I not sure
that I
understand what is meant by "measurement only
device profiles"
I would assume that "measurement-only device
profiles" would mean storing inside the profile nothing but the
spectral measurements for each patch measured with one's spectrophotometer,
probably at a resolution of either 10 or 20 nanometers.
Currently the values stored inside a device profile
for each measured patch are Lab-referenced LUTs (one A2B-B2A set for each
of 3 rendering intents), specific to a particular device. Using Lab values
lacks the much more detailed and flexible description that spectral
measurements provide.
*Some* profiles already *do* store spectral values.
Both "Default" and "Large" device profiles made with
ProfileMaker 5 contain the reference data (tag DevD) as well as the
spectral measurement data (tag CIED), the latter from 380 to 730nm, at
intervals of 10nm. That is convenient, because one can drop a ProfileMaker
profile back into an open PM application window, and all the data necessary
to create a fresh profile are there already, without any need for separate
measurement or reference data.
Apparently, though, those spectral values are not yet
being used in ways meaningful to the color management workflow by the
current ICC procedures. They seem to be there more for the benefit of the
profiling software -- to make it easier to re-create the profile -- than
for other reasons, like for example creating Lab equivalents on-the-fly
that are more appropriate to a specific situation than the pre-baked,
one-size-fits-all ones we get in today's ICC profiles.
That would be my understanding of what constitutes a
"measurement-only device profile." Perhaps Chris would care to
either confirm or correct me.
--------------
Marco Ugolini
Mill Valley, CA
____________________________________________________________________________
Date: Thu, 6 Oct 2005 02:22:57 -0400
From: "jc castronovo"
Subject: Re: Andrew Rodney's test--consensus
Yes Lee. Maybe Chris can tell us more about this
method of profiling?
I've got an image that I'm working on right now that
depends on the differentiation between very saturated greens. ProPhotoRGB
can contain the necessary colors, but I'd like to have better control over
how it gets translated to the printer's gamut. Neither relative nor
perceptual rendering can do the job of translating these greens properly.
One clips and the other squishes everything together which is just as bad.
I know that the printer can't reproduce the greens exactly, but we should
be able to represent the relative differences better, even if it's at the
sacrifice of color accuracy on the other side of the spectrum, which would
be acceptable in this case.
john castronovo
____________________________________________________________________________
Date: Thu, 06 Oct 2005 07:18:42 -0600
From: Andrew Rodney
Subject: Re: Andrew Rodney's test--consensus
On 10/5/05 10:28 PM, "Marco Ugolini"
wrote:
Apparently, though, those spectral values are not yet
being used in ways
meaningful to the color management workflow by the
current ICC procedures.
Exactly. It1s just to make it easier to rebuild
profiles without having to dig up the measured data or do it over again.
ProfileMaker Pro does use the spectral data in some unique ways to build
the profiles (like detecting optical brighteners). It will also import
other1s profiles (how I1m not sure but it works).
Andrew Rodney
http://www.digitaldog.net/
____________________________________________________________________________
Date: Thu, 6 Oct 2005 07:52:42 -0700
From: Lee Varis
Subject: Re: Andrew Rodney's test--consensus
Bringing this thing a little more back into the realm
of this list:
On Oct 5, 2005, at 11:22 PM, jc castronovo wrote:
Neither relative nor perceptual rendering
can do the job of translating these greens properly.
One clips and the other
squishes everything together which is just as bad. I
know that the printer
can't reproduce the greens exactly, but we should be
able to represent the
relative differences better
This is why I use ProPhoto primarily for grayscale
info in the various channels. You can do various luminosity calculations
back into a duplicate image, after it is converted into a more limited
gamut colorspace, to retrieve some separation in tones that got squished or
clipped together - the biggest problem for ProPhoto-> Epson (or just
about any normal workspace)! This is sort of a manual perceptual conversion
to repair the damage caused in the initial translation from the wide gamut
space to output gamut space. Most of the time I can avoid doing too much of
this by simply adjusting/processing raw digital camera files into something
a little more constrained like Adobe RGB - the gamut compression handled in
the adjustment from the raw data into RGB. Occasionally, if you suspect the
presence of important out-of-gamut colors (that are just too far out to
convert properly) you can resort to the ProPhoto conversion/repair thing.
I'm going to try and work up some examples to
illustrate this but it will have to wait until after next week!
regards,
Lee Varis
http://www.varis.com
888-964-0024
____________________________________________________________________________
Date: Thu, 6 Oct 2005 13:53:38 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
Incidentally the gamut compression is contingent on
the CMM when converting between simple matrix-based profiles like editing
spaces. All of those dinky 4k profiles are matrix profiles. The v2 variety
don't have separate rendering intent tables in them, so the gamut
compression (or lack thereof) isn't based on the profiles themselves
because that information isn't in them. They defer to the CMM. So changing
CMM's will get you different results with such conversions.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Thu, 6 Oct 2005 13:44:07 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 5, 2005, at 7:09 PM, Lee Varis wrote:
Thanks Chris, that explains a lot! So the compression
assumptions
made by the various venders can account for, say, one
vender does a
better job with Adobe 98-> SWOP v2 but another
handles ProPhoto ->
> Epson better.
Yes exactly. And there was a product a while ago,
Color Savvy (? it was the company bought by Pictographics, anyone?) that
would let you choose the reference space before building an output profile.
So you could predicate gamut compression on a particular space. The problem
with doing this though, is that in a case of ProPhoto RGB, it's so frigging
huge that the software doesn't know that real captures are unlikely to fill
even 1/2 of ProPhoto yet it would presumably attempt to compress all of
ProPhoto.
One of the changes in ICC v4 is that there is a
defined perceptual PCS reference medium, which means there is
"something much closer for profile vendors to agree on." It's
more technical than that, but the idea is for ICC v4 profiles to allow
image state changes (scene-referred to output-referred) when using the
perceptual intent, and not do image state changes (as is currently the
case) with either colorimetric intent.
So instead of one size fits all, you get a smarter
conversion based on source and destination profiles used if both of them
are v4 profiles. But I still think this is going to be insufficient. A CMS
really needs the ability to know what volume within a color space a
particular image takes up, as well as surrounding colors that AREN'T part
of the image (such as a background). That's why a gamut mapper separate
from color appearance is important.
You can have a company logo on four different colored
backgrounds using the exact same logo artwork and each will appear
different because of simultaneous contrast and other visual effects. We
know how those effects work and they can be predicted by color appearance
models. Apply a CAM to this process would cause each logo to have slightly
different renderings so that they all *appear* to look the same despite
being printed with different background colors.
I heard similar things proposed by others - I not sure
that I
understand what is meant by "measurement only
device profiles" but it
sure would be nice to get gamut compression specific
to the colors in
an image by image basis sooner rather than later.
A measurement only device profile has no gamut
mapping performed. The data is raw, measurement data, it's not massaged by
a profiling application to make it fit into a matrix grid. There's a lot
going on when building a profile. 1000 measurements is maybe 14k of data.
That's 16-bits per channel for 7 channels (CMYK + LAB). An ICC profile is
not 14K in size, they're much bigger because there's interpolation and
creation of data points. You only measure 1000 patches, but a 33 x 33 x 33
matrix used in large profiles contains over 35,000 entries. Not all get
filled, but the grid holds that many points so there's a lot of
interpolation to get from 1000 entries to maybe 10,000-15,000.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Thu, 6 Oct 2005 13:50:44 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 6, 2005, at 12:22 AM, jc castronovo wrote:
Yes Lee. Maybe Chris can tell us more about this
method of profiling?
I've got an image that I'm working on right now that
depends on the
differentiation between very saturated greens.
ProPhotoRGB can contain the
necessary colors, but I'd like to have better control
over how it gets
translated to the printer's gamut. Neither relative
nor perceptual rendering
can do the job of translating these greens properly.
One clips and the other
squishes everything together which is just as bad. I
know that the printer
can't reproduce the greens exactly, but we should be
able to represent the
relative differences better, even if it's at the
sacrifice of color accuracy
on the other side of the spectrum, which would be
acceptable in this case.
The dilemma of prebaked gamut mapping. Is this a
custom profile? Do you have the measurement data? If you have a profiling
package or access to one, rebuild using a different perceptual rendering
setting. Both gmb ProfileMaker Pro and Monaco Profiler have such options.
Otherwise, consider converting it to some other space
first, like Adobe RGB (1998), and then to printer space. The destination
profile is clearly making the wrong assumptions about the colors actually
contained in the image, and it can only make assumptions because these
profiles don't work intelligently at all at the present time. If I wasn't
running Tiger, I'd run it through ColorIQ's IQMatch CMM and see what it can
do, but they are still working on a Tiger version last time I checked.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Thu, 6 Oct 2005 13:46:26 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 5, 2005, at 10:28 PM, Marco Ugolini wrote:
That would be my understanding of what constitutes a
"measurement-only
device profile." Perhaps Chris would care to
either confirm or
correct me.
That's correct.
A profile containing measurement data only could be
either spectral or XYZ or LAB or any combination thereof. The main idea is
not so much what form the data is in, but rather it's based on actual
measurements, not interpolation or extrapolation.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Thu, 6 Oct 2005 19:55:59 -0700
From: "Paul D. DeRocco"
Subject: RE: Andrew Rodney's test--consensus
From: Chris Murphy
A CMS
really needs the ability to know what volume within a
color space a
particular image takes up, as well as surrounding
colors that AREN'T
part of the image (such as a background). That's why a
gamut mapper
separate from color appearance is important.
I agree, but it's non-trivial. I used ColorThink to
examine the colors in an image, and was surprised to find some very
saturated colors that I couldn't actually see anywhere. Turns out it was
just speckles of color noise. Some level of averaging would be needed.
You can have a company logo on four different colored
backgrounds
using the exact same logo artwork and each will appear
different
because of simultaneous contrast and other visual
effects. We know
how those effects work and they can be predicted by
color appearance
models. Apply a CAM to this process would cause each
logo to have
slightly different renderings so that they all
*appear* to look the
same despite being printed with different background
colors.
Is that really the domain of color management? It
would seem to me that one would expect to look at the company logo on those
backgrounds in Photoshop, see what those differences are, and then manually
edit them to deal with the psychovisual effects. When printing, you
basically want the print to look as much like what you see while editing as
possible, not do your editing for
you.
Ciao,
Paul D. DeRocco
____________________________________________________________________________
Date: Fri, 7 Oct 2005 06:54:41 -0500
From: Bob Smith
Subject: Re: Andrew Rodney's test--consensus
On Oct 6, 2005, at 2:44 PM, Chris Murphy wrote:
And there was a product a while ago, Color Savvy (? it
was the company bought by Pictographics, anyone?) that
would let you
choose the reference space before building an output
profile.
ColorSynergy is the package you're thinking of.
You picked an assumed origination space as part of the profile
building process and that would determine how much gamut compression would
be applied in the perceptual rendering part of the profile.
Bob Smith
Accurate Image • Bob Smith Photographer •
Waco Texas USA
http://www.accurateimage.org
____________________________________________________________________________
Date: Fri, 7 Oct 2005 11:14:52 -0700
From: "Andrew Engelhardt"
Subject: request to end thread - Andrew Rodney's
test--consensus
Hi group, on behalf of the moderators, we request also
that this thread is brought to an end in the next 24 hours or so, as it too
has become more of a discussion of the merits of third-party profiling
packages, and is of little or no relevance to the purpose of this group.
Your co-operation is appreciated. Thanks
Andrew Engelhardt
Group Co-moderator
____________________________________________________________________________
Date: Fri, 7 Oct 2005 12:56:53 -0600
From: Chris Murphy
Subject: Re: Andrew Rodney's test--consensus
On Oct 6, 2005, at 8:55 PM, Paul D. DeRocco wrote:
Is that really the domain of color management?
It hasn't really ever been about color management, but
appearance management. What's lacking in color management is predicting
what we actually see. It's not uncommon for "color management" to
say two color samples match when they don't. They do in isolation, but
human beings don't work with colors in isolation, we work with color in
context. Color appearance better predicts color in context; color
management doesn't at all.
It would seem to me that one
would expect to look at the company logo on those
backgrounds in Photoshop,
see what those differences are, and then manually edit
them to deal with the
psychovisual effects. When printing, you basically
want the print to look as
much like what you see while editing as possible, not
do your editing for
you.
Today you do the editing manually because that's the
only way to get it done, not because it's the best way to solve the
problem. If there were another way, that didn't involve ten people to get
it done, three hours, and five proofs, then I think people will choose the
faster method.
And this isn't really a case for an edit because the
logo isn't being reproduced incorrectly. The "problem" is that
the appearance is different in context. If a CMS can predict the effect
correctly, why would you not want it to take care of it in such a context?
I suppose if you really want to manually edit the logo four times for four
different backgrounds, pull four proofs and not get it right the first,
second or third time...
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________
Date: Fri, 7 Oct 2005 17:26:45 -0400
From: Henry
Subject: Re: Andrew Rodney's test--consensus
On Oct 7, 2005, at 2:56 PM, Chris Murphy wrote:
Today you do the editing manually because that's
the only way to getÊ
it done, not because it's the best way to solve
the problem. If thereÊ
were another way, that didn't involve ten people
to get it done,Ê
three hours, and five proofs, then I think
people will choose theÊ
faster method.
Rounds of editing are expected when trying to achieve
printed color accuracy of a logo. If a method were developed to avoid
this, well then I would love to see this. People(1st variable)
evaluate the results in Context(s)(2nd variable(s)) including Lighting(3rd
variable). Never mind the practical aspects of the drifting during a
run that occurs even with tight process control (theory vs. practice).
I seem to recall that it has been recently asserted by
respected folks on this list that such an undertaking is not within the
realm of profiling and color management - even given sufficient gamut of
ink etc. Something big must have been discovered.
Even an approach that limits these variables so that
recipes for colorimetric matches can be accurately produced under specified
conditions would be a huge advance.
Henry Davis
____________________________________________________________________________
Date: Fri, 7 Oct 2005 16:38:24 -0700
From: "Paul D. DeRocco"
Subject: RE: Andrew Rodney's test--consensus
From: Chris Murphy
And this isn't really a case for an edit because the
logo isn't being
reproduced incorrectly. The "problem" is
that the appearance is
different in context. If a CMS can predict the effect
correctly, why
would you not want it to take care of it in such a
context? I suppose
if you really want to manually edit the logo four
times for four
different backgrounds, pull four proofs and not get it
right the
first, second or third time...
Because you have the same "context", meaning
the background color, whether you're looking at the print or at the screen.
It seems to me that the purpose of a color management engine that uses
profiles to translate from one color space to another is to reduce
differences between the different image domains (display, print, scan,
etc.), not deal with psychovisual effects that occur equally in all
domains. But then, all I do is edit and print photographs, not logos.
Ciao,
Paul D. DeRocco
____________________________________________________________________________
Date: Sat, 08 Oct 2005 10:42:17 -0400
From: Lee Clawson
Subject: Re: Andrew Rodney's test--consensus
on 10/7/05 2:56 PM, Chris Murphy wrote:
...but human beings don't work with colors in
isolation, we work with color
in context. Color appearance better predicts
color in context; color
management doesn't at all.
I'm with Paul on this. Human beings may not see or
work in isolation but we think about using this as a design concept.
Today you do the editing manually because that's the
only way to get
it done, not because it's the best way to solve the
problem. If there
were another way, that didn't involve ten people to
get it done,
three hours, and five proofs, then I think people will
choose the
faster method.
Your other way could easily have ruined 4 projects we
did in the last year. I use this all the time.
And this isn't really a case for an edit because the
logo isn't being
reproduced incorrectly. The "problem" is
that the appearance is
different in context. If a CMS can predict the effect
correctly, why
would you not want it to take care of it in such a
context? I suppose
if you really want to manually edit the logo four
times for four
different backgrounds, pull four proofs and not get it
right the
first, second or third time...
For each example you see "problem" I can
show you 3 times more that I've used this in graphic and packaging designs
as a color effect. Anyone who had to sit through 1 semester of Alber's
Color probably uses it to the good as well. This is one thing I don't want
running behind the scenes trying to out guess my color intent.
Lee
____________________________________________________________________________
Date: Fri, 07 Oct 2005 21:10:54 -0700
From: Marco Ugolini
Subject: Re: Andrew Rodney's test--consensus
In a message dated Fri, 7 Oct 2005 17:26:45, Henry
Davis wrote:
Rounds of editing are expected when trying to achieve
printed color
accuracy of a logo. If a method were developed to
avoid this, well
then I would love to see this. People(1st variable)
evaluate the
results in Context(s)(2nd variable(s)) including
Lighting(3rd
variable). Never mind the practical aspects of the
drifting during a
run that occurs even with tight process control
(theory vs. practice).
I seem to recall that it has been recently asserted by
respected folks
on this list that such an undertaking is not within
the realm of
profiling and color management - even given sufficient
gamut of ink
etc. Something big must have been discovered.
Color Appearance Models (CAMs), while not yet actively
present in current color technologies (except for the yet unverified claims
of Microsoft's Windows Color System for the Vista operating system), are at
an advanced state of research.
Wonder no more whether whether "something big
[has] been discovered." It has, and the person foremost in the
conceptualization and refinement of CAMs, Mark D. Fairchild, of R.I.T.,
describes the subject at length in the book "Color Appearance
Models" (2nd edition, Wiley & Sons, 2005). <http:
//www.amazon.com/exec/obidos/tg/detail/-/0470012161/qid=1128743646/sr=
2-1/ref=pd_bbs_b_2_1/002-6344868-1680045?v=glance&s=books>
You can also visit Dr. Fairchild's site at:
<http://www.cis.rit.edu/fairchild>
Please click on the "iCAM" link for more
info, and for free downloads of specialized studies.
Best regards.
--------------
Marco Ugolini
Mill Valley, CA
____________________________________________________________________________
Date: Fri, 13 Jan 2006 11:53:02 EST
From: Dan Margulis
Subject: Call for 16-bit example
I don't wish to reopen discussion on a very sore
topic, but in preparation for the next edition of Professional Photoshop, I
feel I must ask if anyone can produce a real-world color photograph where
16-bit correction is demonstrably better than the same corrections in
8-bit. If such an example exists, I will make room for it in the book.
I am not expecting any examples to show up, because if
such images existed, they would have at some time in the last six years. I
have run many pages of examples in Professional Photoshop 4E and in Canyon
Conundrum comparing results of massive corrections in 8- and 16-bit. I do
not wish to waste that amount of space on them this time. Unless something
comes up, I will put copies of the all the pertinent threads from this list
on the book's CD, refer to it in text, and simply state that while nobody
says that working in 16-bit does any harm, there is no reason to think that
it does any good either when color-correcting photographic images.
**********
If you wish to try to refute this, the following are
the requirements.
1) You must be willing to release the image for
publication for the limited purpose of discussing 16-bit vs. 8-bit
correction, including allowing it to go on the book CD so that others can
test it for themselves.
2) The image(s) must be real-world color
photograph(s). This means any photograph that could conceivably be used in
any professional context. If it is a cropped piece of a larger photograph,
the piece must be large enough that it could conceivably be used on its
own.
3) Any correction method can be used, but the moves
must be such that they can by any stretch of the imagination be interpreted
as an attempt to improve the image. The corrections do not have to be
competently executed but there cannot be outright sabotage. That includes
deliberately acquiring the image in a known incorrect fashion, or moves
that are plainly designed to damage rather than improve the image, such as
repeated lightening followed by repeated darkening.
4) All corrections should be documented so that I can
reproduce them.
5) You should have applied identical corrections to an
8-bit and a 16-bit file, and it should be your opinion that almost everyone
would agree that the 16-bit image is better *overall*, not in some small
area.
**********
The following types of images are not of interest.
1) Black and whites. It has been demonstrated that the
smoother appearance of 16-bit corrections can be perceived in real-world
corrections of B/W images. I have some B/W images that actually look better
if corrected in 16-bit, although more look better if corrected in 8-bit.
They don't tell us much about doing the work in color, because the effect
is hidden by having more channels.
2) Computer-generated artwork such as gradients, or
any photograph that has been modified to such an extent that it is
effectively computer-generated.
3) Images worked in an exotic colorspace definition,
such as a nonstandard gamma, or an ultra-wide gamut RGB.
4) Images that have been placed into 8-bit by scanner
or camera software, as opposed to converting 16-bit to 8-bit in Photoshop.
We know that certain acquire modules convert into 8-bit badly, and we have
examples where identical corrections to such an 8-bit file compared to the
same module's 16-bit look worse. However, in all cases, where the 16-bit
was converted to 8-bit in Photoshop, there has been no significant
difference.
5) Images that the user hasn't tested himself but is
sure will show the effect.
6) Images that are deliberately acquired incorrectly
in Camera Raw or similar module. (Photographs that are actually
underexposed by the photographer are welcome.)
**********
The following types of *discussion* are not of
interest.
1) Assurances that the speaker personally knows that
16-bit works better in certain types of image and has seen the effect for
himself. I have probably corresponded with a hundred such individuals in
the last six years. Not a single one has ever run a side-by-side test. Not
a single claim can be verified, and I and others have spent weeks trying.
While I enjoy the dialog, at this point I would have to regretfully say
that unless someone has actual images with which to demonstrate a
superiority, any argument they may have in favor of it is irrelevant.
2) References to websites or books that purportedly
prove it. I've been to every one. They're all histograms and gradients.
3) Histograms and gradients, or other explanations of
why it is mathematically certain that 16-bit is better.
Anyone who wishes to participate needs to at least let
me know by the end of the month so that we can arrange shipping.
Dan Margulis
___________________________________________________________________________
Date: Fri, 13 Jan 2006 13:05:58 -0700
From: Ron Kelly
Subject: Re: Call for 16-bit example
On 13-Jan-06, at 9:53 AM, Dan Margulis wrote:
I don't wish to reopen discussion on a very sore
topic, but in preparation
for the next edition of Professional Photoshop, I feel
I must ask if anyone can
produce a real-world color photograph where 16-bit
correction is demonstrably
better than the same corrections in 8-bit.
I read your invite with some interest, although I have
no intention of participating by providing files.
You've overlooked one point, however: how is *better*
determined? I don't see that you've addressed this point specifically, and
maybe you feel it's implied.
It has to be printed. It has to show up on the page,
and not just be something visible on the screen.
We can see all kinds of insignificant
"detail" in scans and digital files that make no difference in
the final print. Conclusion - insignificant detail is insignificant.
So whether it's inkjet, lightjet, or some kind of
off-set, it doesn't matter. On screen - not a definitive example.
I would therefore add the proviso that any improvement
in 8 vs. 16 bits should have to show up *in printed form* to be considered
real and conclusive.
Ron Kelly
___________________________________________________________________________
Date: Fri, 13 Jan 2006 15:47:51 -0500
From: "Warren L. Parsons"
Subject: Re: Call for 16-bit example
Hi Ron,
I have to take some issue with this position. I don't
believe that whether something shows up in print is the "final
word" on whether a difference between methods is
"significant." It is becoming increasingly common for digital
display to be the "final form" of an image, in which case readily
visible differences in output *are* significant, regardless of whether they
show up in print.
That said, I do not expect any advantage to working in
16-bit will make itself known. As Dan stated, if 16-bit were demonstrably
better, it would have been demonstrated by now.
Regards,
Warren L. Parsons
___________________________________________________________________________
Date: Fri, 13 Jan 2006 14:27:46 -0700
From: Ron Kelly
Subject: Re: Call for 16-bit example
With respect, Warren, I disagree.
On-screen images usually have been and still
substantially an intermediate product. They're something you show to
someone so they can get a sense of it. Once they see something they like,
they buy a print.
The exception to this is pictures that are made for
the web, or a presentation. Such pictures are scrutanized far, far less
critically than most printed images. In these cases image quality is still
important, but the pictures typically don't appear for long because the
viewer in these mediums demand movement, lest they be bored.
How many times have you sat and looked at a picture on
the web for more than a few seconds? How long do you show a single image in
a presentation? Two seconds? Three? Five maybe, if you use some panning a
la Ken Burns. Not much time to really see more than: "What's
this?" and "Do I like it, or not?"
Contrast that with how much time you'd spend on a fine
photograph in a gallery, pore over a movie poster or magazine spread, or
even examine an interesting newspaper photo.
Ron Kelly
___________________________________________________________________________
Date: Fri, 13 Jan 2006 18:18:43 -0500
From: "Mark Segal"
Subject: Re: Call for 16-bit example
Dan,
There are a couple of problems with your rules. What
is your definition of an ultra-wide gamut RGB? Does ProPhoto fit that
definition? If it does I can't send you anything because I work in
ProPhoto. I work in ProPhoto because an Epson 4800 can reproduce certain
colours that are outside ARGB98 gamut but inside ProPhoto. It has been
claimed that 16 bit depth is preferable to 8 bit depth in such a colour
space in order to mitigate banding and posterization risk (more levels
relative to the space size). So if you rule out the one editing context
where 16 bit may show some superiority, it would seem that the rules
pre-determine the result.
Secondly, I am confused about item (4) below. A
professional DSLR (e.g. a 1Ds) acquires images in 12 bit (4096 levels) -
not 8, not 16. In Camera Raw, one then has the choice to convert them into
8 or 16 bit for further processing in Photoshop. So this first
decision about bit depth is made at the Camera Raw stage, not the Photoshop
stage, and either choice differs from the bit depth the RAW file contains.
Anyone using a RAW converter would make the 8 versus 16 decision once and
for all at the raw conversion stage, and not tinker with it thereafter in
Photoshop except at the end of the adjustment process for printing or web
output - if even then in the case of printing. Hence what you say in item
(4) below does not reflect this reality and makes it very unclear what
workflow process qualifies or disqualifies for sending you samples.
I shall be grateful if you would clarify.
Cheers,
Mark Segal
___________________________________________________________________________
Date: Fri, 13 Jan 2006 14:47:36 -0800
From: Marco Ugolini
Subject: Re: Call for 16-bit example
In a message dated 1/13/06 1:27 PM, Ron Kelly wrote:
On-screen images usually have been and still
substantially an
intermediate product. They're something you show to
someone so they
can get a sense of it. Once they see something they
like, they buy a
print.
FYI, filmless, or virtual proofing (i.e., proofing
using displays, without laminated proofs, for output that goes directly to
plate) has become mainstream already. Time Magazine, for one, already--and
famously--does its business this way.
The exception to this is pictures that are made for
the web, or a
presentation. Such pictures are scrutanized far, far
less critically
than most printed images. In these cases image quality
is still
important, but the pictures typically don't appear for
long because
the viewer in these mediums demand movement, lest they
be bored.
I don't wish to sound either preachy or testy, but
imaging is a rapidly evolving field, and statements that may have been
supportable even recently have to be constantly requalified and
reformulated.
Yes, pictures destined for the web are meant to be
viewed on displays, and are indeed scrutinized less closely than ones for
print. But it's not a sound logical leap to go from that to saying that the
only people interested in using a display to evaluate images are solely
those whose content is aimed for the web. At least not any longer.
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Date: Fri, 13 Jan 2006 23:02:11 +0000
From: Francis Corvin
Subject: Re: Call for 16-bit example
In order for the 8 v. 16 bit debate to be fruitful, it
should be established that the additional 8 bits do effectively contain
useful information --- significantly more than noise. Is this now an
accepted point, or is there still some debate on this? Sorry if the
question appears quite basic, this stuff is still new to me, and apologies
if it's going over old ground.
Regards,
Francis Corvin
___________________________________________________________________________
Date: Fri, 13 Jan 2006 20:31:14 -0800
From: J Walton
Subject: Re: Call for
16-bit example
Time Magazine is using virtual proofing as a
replacement for conventional contract proofs. They aren't charging
people two dollars to come read the magazine on a monitor.
Ron's statement that on-screen images are now
substantially an intermediate product is not disproven by Time's workflow,
but rather proven. They use the monitor to show what the ad is supposed to
print like, and then they print it and sell it all over the world. It is
that printed piece which is the end product and that will be examined more
carefully.
I do agree that our field is a rapidly changing one.
It is difficult to make a statement and not have to adjust it later. The
evolution of Dan's conditions on the 8-bit vs. 16-bit test is an example of
this. The core argument is still sound, but workflows change so much that
small segments on the edge of his focus find some exceptions.
J
___________________________________________________________________________
Date: Fri, 13 Jan 2006 21:48:38 -0800
From: Marco Ugolini
Subject: Re: Call for 16-bit example
In a message dated 1/13/06 8:31 PM, J Walton wrote:
Time Magazine is using virtual proofing as a
replacement for
conventional contract proofs.
Yes. I said that myself. So we agree?
They aren't charging people two dollars to come read
the
magazine on a monitor.
Geez... Should I call that a low blow or just silly?
Ron's statement that on-screen images are now
substantially an intermediate
product is not disproven by Time's workflow, but
rather proven. They use the
monitor to show what the ad is supposed to print like,
and then they print
it and sell it all over the world. It is that printed
piece which is the end
product and that will be examined more carefully.
What is seen on the display in this sort of workflow
is assumed to reflect and accurately preview the printed results. Millions
of dollars' worth of work hinges on that assumption and on keeping the
system in good enough working order to guarantee those results. The printed
piece is the result, but the virtual proofing is the terrain on which
decisions are made.
Bottom line:
Monitor displays (a) of good enough quality, (b)
properly calibrated and profiled, and (c) in the hands of skilled operators
(d) working in concert with properly color-managed applications, *are* good
enough to make decisions which directly affect and very closely reflect the
printed results.
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Date: Sat, 14 Jan 2006 09:09:28 -0800
From: J Walton
Subject: Re: Call for 16-bit example
On 1/13/06, Marco Ugolini wrote:
Yes. I said that myself. So we agree?
On most things, yes.
Geez... Should I call that a low blow or just silly?
I'd go for the latter, since I have nothing against
you. It merely makes the point that the monitor is an intermediate step,
that's all.
Bottom line:
Monitor displays (a) of good enough quality, (b)
properly calibrated and
profiled, and (c) in the hands of skilled operators
(d) working in concert
with properly color-managed applications, *are* good
enough to make
decisions which directly affect and very closely
reflect the printed
results.
All of that is true, and a good reflection of the
statement you made earlier, that our industry has changed quite a bit and
will continue to change.
Let's not forget the context of this conversation. It
is not about color or contrast or saturation or the quality of monitors
these days. It is about 16-bit editing and whether or not results on a
monitor should be included in a discussion on the superiority of one over
the other.
Virtual proofing does show that what things look like
on a monitor is becoming increasingly important, but does not relate to our
16-bit discussion right now. No one at Time is evaluating the difference
between 8-bit and 16-bit edits on screen.
J Walton
___________________________________________________________________________
From: Dan Margulis
Date: Sat Jan 14, 2006 8:38 am
Subject: Re: [colortheory] Call for 16-bit example
Ron Kelly writes,
You've overlooked one point, however: how is *better*
determined? I
don't see that you've addressed this point
specifically, and maybe
you feel it's implied.
"Better" in real life is determined by
whether your client thinks it's better.
For purposes of our discussion, if disinterested
parties look at alternate versions of an image in the setting and size for
which they are intended, without being told which version is which, and 90%
or more pick one version as being better, I conclude that that version is
better. If the vote is not as decisive I conclude that it's a matter of
taste.
It doesn't take a really big difference to trigger a
vote for "better". In PP4E I described a test where a jury was
given numbered originals produced by each of three models of high-end
scanner. In most cases the versions were hard to tell apart without careful
examination, yet in many cases the vote was unanimous as to which of the
three was best, including the one shown as Figure 15.3.
I would say that if there's a finding of
"better" it would probably be true in all contexts, so I don't
think we need to be specific about what type of print is needed.
Dan Margulis
___________________________________________________________________________
From: Steve Fuller
Date: Sat Jan 14, 2006 11:22 am
Subject: Re: Call for 16-bit example
I am new to this forum and I received via another
route the apparent lead message in this thread. While I have many
years of photography under my belt, I am primarily a scientist and
professor. Mr. Margulis' post defies logic. How can one posit
an apparently logical scientific question and then place rules that
effectively rule out logic and place the "proof" solely on the
subjective view of one individual?
The logical mathematical treatment is trivial as is
the practical demonstration of its truth. I have readily demonstrated
with four slider moves on PS CS2 in 8 bit and 16 bit versions of the same
image that the difference in results is apparent to anyone anywhere.
Then, on reading the "rules", there are many
subjective criteria that can be pulled from his hat to invalidate the
practical demonstration of the truth of the logic virtually at whim.
I dare say that many of the well known Ansel Adams images could not
have been printed if he had been confined to the equivalent of a truncated
8 bit processing range.
Why does anyone waste their time tilting at this
windmill? Why not add to the volume of knowledge instead of the
volume of mythology?
Regards,
Steve Fuller
___________________________________________________________________________
From: onno de jong
Date: Sat Jan 14, 2006 10:36 am
Subject: Re: [colortheory] Call for 16-bit example
Dan,
This is a general comment from having read an old copy
of your professional photoshop (I think during the time of Photoshop
version 5, possibly two or more versions behind the current one, and of
currently working though your canyon book)
You seem to paint yourself into a comfortable box,
which is fine, and works for you. There are reasons to work in 16 bit in
the creation and retouching of an image (not that I always use them or
necessarily swear by them).
1) as I work on retouching images for advertising,
there is preciously little that is still virgin photograph. I control the
entire image, often reconstructing much of it, with tools that work fine in
8 bit, but at times provide me with more flexibility in 16 while I am
working. Do you consider this a computer generated image? I
obviously go well beyond optimizing an image for print.
Printing is another matter, and once I finish I concur
with you entirely. The bandwidth of printing is so narrow that the strategy
of how to make each bit look good far outshines whatever nuanced color
information you might have gained).
2) with increase in processor speed, it really will
not matter for very much longer. Ten years from now, who cares.
Otherwise, I am greatly indebted to your having
sharing your knowledge with me, and thank you for it,
onno de jong
___________________________________________________________________________
Date: Sat, 14 Jan 2006 08:56:12 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
Mark Segal writes,
There are a couple of problems with your rules. What
is your definition of
an ultra-wide gamut RGB?
Anything significantly wider in gamut than Adobe RGB.
Does ProPhoto fit that definition?
Yes.
It has been claimed that 16 bit depth is preferable to
8 bit depth in such
a colour space in order to mitigate banding and
posterization risk (more
levels relative to the space size).
Not relevant for my purposes, as I categorically
recommend against major edits in such spaces.
So if you rule out the one editing context where 16
bit may show some
superiority, it would seem that the rules
pre-determine the result.
AFAIK it is not conceded that this is correct. It
appears that some 16-bit advocates now admit that there is no superiority
even in a wide gamut space like Adobe RGB, but some are still insisting
that there's a night and day difference when last I checked. I agree that,
since we have had so many trials in the past, it is unlikely at this point
that any image meeting the test's specifications will emerge showing 16-bit
superiority.
Secondly, I am confused about item (4) below. A
professional DSLR (e.g. a
1Ds) acquires images in 12 bit (4096 levels) - not 8,
not 16. In Camera Raw,
one then has the choice to convert them into 8 or 16
bit for further processing
in Photoshop. So this first decision about bit
depth is made at the Camera
Raw stage, not the Photoshop stage, and either choice
differs from the bit depth
the RAW file contains. Anyone using a RAW converter
would make the 8 versus
16 decision once and for all at the raw conversion
stage, and not tinker with
it thereafter in Photoshop except at the end of the
adjustment process for
printing or web output - if even then in the case of
printing. Hence what you say
in item (4) below does not reflect this reality and
makes it very unclear what
workflow process qualifies or disqualifies for sending
you samples.
The starting point is one (1) 16-bit Photoshop file.
How it got there is no concern of ours except that one is not permitted to
sabotage the acquisition process by, say, grossly darkening the image
before opening it in Photoshop.
The test is to be performed on both the 16-bit file
and on a file produced by immediately converting the 16-bit file to 8-bit
*in Photoshop*. 8-bit files that have been converted to 8-bit in any other
fashion are excluded.
Dan Margulis
___________________________________________________________________________
Date: Sat, 14 Jan 2006 14:31:12 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
Francis Corvin writes,
In order for the 8 v. 16 bit debate to be fruitful, it
should be
established that the additional 8 bits do effectively
contain useful
information --- significantly more than noise. Is this
now an
accepted point, or is there still some debate on this?
A very good question. There has been little discussion
of the point. The 16-bit advocates, who tend to be buffaloed by numbers,
never really consider the possibility that the extra numbers are
meaningless.
Cameras are more accurate in certain regions than in
others. I believe that the midrange of the green channel contains more than
8 bits of useful information. However, in the areas that are always cited
as those where 16-bit correction has an advantage, skies and deep shadows,
I think it's obvious that not even the first 8 bits are accurate, and the
extra bits are nothing but random numbers, noise. I have suggested that
this noise can have a beneficial effect in certain cases.
Dan Margulis
___________________________________________________________________________
Date: Sat, 14 Jan 2006 19:12:34 -0000
From: "colorman042000"
Subject: Re: Call for 16-bit example
Hi Ron,
Allow me to disagree with you.
--- In Ron Kelly wrote:
You've overlooked one point, however: how is *better*
determined? I
don't see that you've addressed this point
specifically, and maybe
you feel it's implied.
It has to be printed. It has to show up on the page,
and not just be
something visible on the screen.
1- If it is visible on the screen then it is
significant because it *exists*...! It might not be printable by
to-day's technology but it might be by next month's new Super Epson
Printer. It might not show up under certain printing conditions and
it might show up under others.
We can see all kinds of insignificant
"detail" in scans and digital
files that make no difference in the final print.
Conclusion -
insignificant detail is insignificant.
2- I have generally seen the opposite, I have seen
details that I could not *readily* see on the screen show up on prints. How
do you define *insignificant details* ?
So whether it's inkjet, lightjet, or some kind of
off-set, it
doesn't matter. On screen - not a definitive example.
I would therefore add the proviso that any improvement
in 8 vs. 16
bits should have to show up *in printed form* to be
considered real
and conclusive.
3- Unrealistic condition. Nobody has the time
and/or the energy to test for all the conditions where a significant
detail that is visible on the screen would (or would not) appear with
significance under certain printing conditions.
Andre Dumas
___________________________________________________________________________
Date: Sat, 14 Jan 2006 13:09:58 -0500
(EST)
From: MARK SEGAL
Subject: Re: Call for 16-bit example
Dan,
Thanks for the clarifications. I now understand
the rules and with that understanding I now know that I should definitely
not participate in this exercise because the workflow specifications are of
no interest to me.
Firstly, my own results indicate that IN
PRACTICE there is generally nothing wrong with editing in Pro Photo colour
space (and along with it in 16 bit mode); as well it insures that the
printer will deliver everything it can. There is wisdom in being pragmatic
about the choice of colour space, using ProPhoto unless problems occur that
nothing else but reversion to ARGB98 corrects. That happens, but
infrequently.
Secondly, the idea of taking a 12 bit RAW file,
opening it in 16 bit, then reconverting it back to 8 bit before image
editing seems like a circuitous procedure when Camera Raw allows one to
open the same file in 8 bit then go back to the same RAW file and re-open
it in 16 bit, then work each of those files. This way one preserves the
integrity of normal workflows that start from a RAW file in ACR and convert
directly to the mode one would use for image editing. I don't see the point
of testing a workflow one normally wouldn't adopt.
Mark Segal
___________________________________________________________________________
Date: Sat, 14 Jan 2006 15:44:10 -0400
From: Lee Clawson
Subject: Re: Re: Call for 16-bit example
on 1/14/06 12:22 PM, Steve wrote:
Mr. Margulis' post defies logic. How can one
posit an apparently logical
scientific question and then place rules that
effectively rule out logic and
place the "proof" solely on the subjective
view of one individual?
Steve,
There's much background to the simple intro when Dan
says....
I don't wish to reopen discussion on a very sore
topic, but in preparation
for the next edition of Professional Photoshop, I feel
I must ask if anyone
can produce a real-world color photograph where 16-bit
correction is
demonstrably better than the same corrections in
8-bit. If such an example
exists, I will make room for it in the book.
I don't know how this can work either. Do you have
concepts that can help
make this more objective ???
I was dismayed ( a mild expression for what I'd like
to say) when I saw this
thread begin again. You check our archives and see
what's been going on
since the end of August 2005 (Andrew Rodney's posts
restarted the thread)
through November 15.
Lee Clawson
2/\V/\7 Studio
___________________________________________________________________________
Date: Sat, 14 Jan 2006 16:42:58 -0600
From: "Steve Fuller"
Subject: RE: Call for 16-bit example
RE:
The test is to be performed on both the 16-bit file
and on a file produced by
immediately converting the 16-bit file to 8-bit *in
Photoshop*. 8-bit files
that have been converted to 8-bit in any other fashion
are excluded.
Dan Margulis
Does this imply that when Photoshop converts 16 bit to
8 bit that it dithers
the LSB? Or does it truncate at the LSB?
This is an important distinction.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Sat, 14 Jan 2006 15:13:03 -0800
From: Marco Ugolini
Subject: Re: Call for 16-bit example
In a message dated 1/14/06 9:09 AM, J Walton wrote:
...the monitor is an intermediate step, that's all.
I don't wish to be pedantic, but that is not
"all". There is more. For the sake of accuracy, one has to
remember that, no matter how often it does prove otherwise valid, this
statement is not *universally* valid. For one, in virtual proofing the
monitor is *the* point of decision. It's not intermediate.
Let's not forget the context of this conversation. It
is not about color or
contrast or saturation or the quality of monitors
these days.
It became a discussion on the use of monitor displays
when Ron Kelly stated that a file "has to be printed. It has to show
up on the page, and not just be something visible on the screen"
(message of Jan. 13, 2006).
It is about 16-bit editing and whether or not results
on a monitor should be
included in a discussion on the superiority of one
over the other.
My point is that, if one uses a properly prepared and
competently run system, the 8-bit-vs-16-bit comparison *can* be made
effectively using a monitor display (except for the colors that exceed the
monitor's gamut: but that is a different issue).
Virtual proofing does show that what things look like
on a monitor is
becoming increasingly important, but does not relate
to our 16-bit
discussion right now.
I respect that as *your* opinion, with which I
respectfully disagree.
No one at Time is evaluating the difference between
8-bit and 16-bit edits on
screen.
Do you know of anyone there who has done it and
concluded it was pointless?
Regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Date: Sat, 14 Jan 2006 21:34:25 -0000
From: "colorman042000"
Subject: Re: Call for 16-bit example
Hello Steve,
Next week our magazine is going to the printers, the
quality of our images has to be better than in the last issue and when it
hits the street I will wait with some apprehension about the comments of
our editor and the feedback from our advertising director.
This 16 bit affair means a lot more work, more copies
of my files, more disk space etc..., but I do it "just in case"
the image will turn out to be better and the editor will be proud of my
work. That's important to me.
Right now, and "just in case", I do sizing,
cropping, straightening and sharpening in 16 bit, sometimes I also do most
of my color correction also in 16 bit and when necessary I keep an extra
copy of everything in 16 bit, "just in case" I need to start over
with the image.
As far as *I* am concerned, what Dan Margulis is
trying to determine is the very opposite of mythology or any
imaginary demonstration of scientific facts, it is simply this: is it
worth my time and energy to go through all this extra work and will it make
a detectable difference in the final output of our magazine. Yes or No?
His *real world* findings on the subject are important to me.
I haven't seen your demonstration nor have I seen any
*evidence* anywhere that "the difference in results is apparent to
anyone anywhere" as you claim. Would you be willing to supply
this evidence so I may benefit from your knowledge. In some circles
it is appropriate to pontify on scientific evidence, but in my case, I'm
more worried about how my images will print and if you can show me some
actual proof of your findings I will be grateful to you for freeing me from
always having to ask myself if doing things in 16 bit is worth it or not.
Andre Dumas
___________________________________________________________________________
Date: Sun, 15 Jan 2006 00:46:32 -0800
From: J Walton
Subject: Re: Call for 16-bit example
On 1/14/06, Marco Ugolini wrote:
the monitor is an intermediate step, that's all.
I don't wish to be pedantic, but that is not
"all". There is more.
Marco, you should be ashamed of yourself. To clip a
direct quote and thereby distort its meaning is entirely unfair and
inappropriate. I normally rather enjoy reading your posts. You can do
better than that.
For the
sake of accuracy, one has to remember that, no matter
how often it does
prove otherwise valid, this statement is not
*universally* valid.
That doesn't make any sense.
For one, in virtual proofing the monitor is *the*
point of decision.
It's not intermediate.
If the monitor is one of several steps on the way to a
final destination (a magazine), that's called intermediate. Just because
you want to focus on step 4 of 15 doesn't make step 4 the finish line.
It became a discussion on the use of monitor displays
when Ron Kelly stated
that a file "has to be printed. It has to show up
on the page, and not just
be something visible on the screen" (message of
Jan. 13, 2006).
It became a discussion on the use of monitor displays
to evaluate the difference between 8-bit and 16-bit corrections. It got to
be about monitors and Time magazine and virtual proofing a bit later.
My point is that, if one uses a properly prepared and
competently run
system, the 8-bit-vs-16-bit comparison *can* be made
effectively using a
monitor display (except for the colors that exceed the
monitor's gamut:
but that is a different issue).
Funny thing, I agree with you on this. I'm not sure
how we got to circling around a point we agree on but somehow it has taken
place. I don't think it's necessary to spit out a proof to see the
difference, *provided* you are experienced enough to know what something on
a monitor is going to look like on press.
Virtual proofing does show that what things look like
on a monitor is
becoming increasingly important, but does not relate
to our 16-bit
discussion right now.
I respect that as *your* opinion, with which I
respectfully disagree.
Fair enough.
No one at Time is evaluating the difference between
8-bit and 16-bit edits
on screen.
Do you know of anyone there who has done it and
concluded it was
pointless?
I assume by that question that you believe that part
of the virtual proofing strategy at Time magazine is to identify files
on-screen that were corrected in either 8 or 16-bit. Unless you are just
being difficult.
Regards.
Yeah, yeah, yeah, we'll be friends again in no time. :
-)
J Walton
___________________________________________________________________________
Date: Sun, 15 Jan 2006 11:33:13 -0000
From: "Stephen Marsh"
Subject: Re: Call for 16-bit example
Steve Fuller writes:
Does this imply that when Photoshop converts 16 bit to
8 bit that it dithers
the LSB? Or does it truncate at the LSB?
This is an important distinction.
Not sure on LSB Steve (LHS, HSB), but yes, inside
Photoshop (not sure on ACR) - there is dither introduced in the bit depth
conversion from high to low. More on this smart dither can be found in this
archived thread:
ledet.com/margulis/ACT_postings/ACT-Banding-16%20bit-8-bit.html
For more on the long and hot debate on Dan's 16bit
challenge, follow these two archives:
ledet.com/margulis/ACT_postings/ACT-8-bit-16-bit.html
ledet.com/margulis/ACT_postings/ColorCorrection/ACT-16-bit-2002.htm
The questions being raised here are good ones: Does
the 8bpc channel RAW export contain dither, or not? Or do we have to take a
high bit processed ACR file into Photoshop and convert to 8bpc to get this
minor but valuable random noise? Does it matter?
This can be answered by running a 16bpc > 8bpc
converted lossless compressed processed image from ACR inside Photoshop
through an app that can show such info (not Photoshop). Then one would
compare the same ACR settings/file processed directly inside ACR as 8bpc
and measure that file. If one contains dither and the other does not then
this will be evident by comparing the files.
With luck somebody can say if ACR does indeed use
dither, but I am guessing that this may need to be tested as I have never
heard this mentioned before and I would think that I would remember.
You raise an important point Steve, in that the
realistic workflow for most users who do only require 8bpc output from ACR
would simply select the 8bpc option inside camera raw, rather than
processing into high bit and then dumbing it down directly afterwards
inside Photoshop on the processed data that came out of ACR. Do these users
miss out on dither? Does it matter? We can introduce dither with a colour
mode change while retaining bit depth, but this seems less ideal than the
high to low bit depth switch.
I can't speak for Dan, but perhaps he is not looking
to make things more complex than they currently are. By ruling out ACR 8bpc
generated files and only Photoshop 8bpc files from 16bpc this makes testing
easier. This is not to say that the questions here are not valid, it would
be good to know if ACR adds dither to 8bpc processed images, but this ACR
variable has never been a part of Dan's testing to this date that I know
of.
Stephen Marsh.
___________________________________________________________________________
Date: Sun, 15 Jan 2006 11:50:36 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
Onno writes,
You seem to paint yourself into a comfortable box,
which is fine, and
works for you. There are reasons to work in 16 bit in
the creation
and retouching of an image (not that I always use them
or necessarily
swear by them).
I am certainly willing to be persuaded of this, but
not by words, only by images.
as I work on retouching images for advertising, there
is
preciously little that is still virgin photograph. I
control the
entire image, often reconstructing much of it, with
tools that work
fine in 8 bit, but at times provide me with more
flexibility in 16
while I am working. Do you consider this a
computer generated
image? I obviously go well beyond optimizing an
image for print.
If you are introducing gradients, or vector graphics,
or filtering the image so savagely that it loses its essential character as
a photograph, then I'd consider it a computer-generated graphic. If you are
just doing heavy-duty retouching, then I have not been able to verify a
benefit from using 16-bit, so if you can show a side-by-side comparison
that demonstrates the superiority, I'd be very happy to look at it.
Dan Margulis
___________________________________________________________________________
Date: Sun, 15 Jan 2006 11:53:13 EST
From: Dan Margulis
Subject: Re: Re: Call for 16-bit example
Steve Fuller writes,
While I have many years of photography
under my belt, I am primarily a scientist and
professor. Mr.
Margulis' post defies logic.
Yes, it must certainly seem illogical to a scientist
that a hypothesis claiming that a certain result can be achieved with
real-world images and methodologies should be tested with real-world images
and methodologies rather than with theoretical constructs. What an
unscientific concept!
As for being a professor, things must have changed
since I was in school. Back then, when a scientist put forward a
hypothesis, it was not up to everyone else to prove it wrong, but rather it
was up to him to prove himself right. The reasons for this rule were that
a) it prevented a lot of stupid hypotheses by people who didn't understand
their field, and b) it was thought in those ancient times to be difficult
to prove negatives. I do not know why all this has changed.
The logical mathematical treatment is trivial as is
the practical
demonstration of its truth. I have readily
demonstrated with four
slider moves on PS CS2 in 8 bit and 16 bit versions of
the same image
that the difference in results is apparent to anyone
anywhere.
Let me guess, professor. It's a gradient, right? Or
else some other distraction that you are going to claim proves by analogy
what must happen in the real world? Surely you are aware that many top
experts have spent weeks working with real images under real conditions
trying to find this superiority that you say is there, and nobody has been
able to. If you find it so easy to make this demonstration with a real
image, what's so hard about sharing it with the rest of us?
Then, on reading the "rules", there are many
subjective criteria that
can be pulled from his hat to invalidate the practical
demonstration
of the truth of the logic virtually at whim.
A bit premature, wouldn't you say, professor? You
haven't actually said that you have an image that *you* think meets the
rules.
If you don't claim to have this kind of image--and
AFAIK, nobody in the world currently claims to have one--then grousing
about the subjectivity of the rules is irrelevant, an obvious effort to
divert attention from the fact that your belief is religious and not
intellectual in nature.
If you are saying that you do have such an image, but
that I can't be trusted to evaluate it, there's an easy solution. A number
of people on this list have spent a good deal of time studying this
subject, and are quite independent of me. Why don't we have one of them, or
maybe a group of three of them, examine your image to see whether *they*
think it meets the test conditions? Jim Rich, for example, is a
world-renowned expert of unquestioned probity. Why not let *him* see what
you've got?
Why does anyone waste their time tilting at this
windmill? Why not add to
the volume of knowledge instead of the volume of
mythology?
This is the typical response of an academic who knows
that he doesn't have the goods. Your hypothesis predicts one result. All
experimental evidence to date, and there's a lot of it, shows another. But
the new academic method, as I understand it, goes like this:
1) I have a hypothesis that involves how
real-world images will behave in real-world circumstances.
2) I am not obliged to test my
hypothesis by direct experimentation with the category of images that it is
supposed to apply to, because my hypothesis is obviously correct and can be
proven by analogy.
3) Any experimental evidence casting
doubt on my hypothesis is irrelevant, because my hypothesis is so obviously
correct that no amount of contrary evidence can disprove it.
Actually, now that I think of it, it isn't so new in
academe--I believe it was common doctrine 500 years ago. Come to think of
it, professor, how *would* you deal with someone who assures you that the
world is flat, says that its flatness is too obvious to require any proof,
and says that no amount of contrary evidence can ever disprove it?
Meanwhile, do let us know if you come up with a
real-world color photograph, with real-world corrections, that you believe
meets the stated requirements. You say it's trivial--now back it up.
Dan Margulis
___________________________________________________________________________
Date: Sun, 15 Jan 2006 08:19:29 -0600
From: "Steve Fuller"
Subject: RE: Re: Call for 16-bit example
Stephen Marsh wrote:
Not sure on LSB Steve (LHS, HSB), but yes, inside
Photoshop (not sure
on ACR) - there is dither introduced in the bit depth
conversion from
high to low.
If dither is being introduced by Photoshop then the 8
bit file converted in Photoshop from the 16 bit file does contain more
information than a file converted to 8 bit in an application that
truncates. That means that, per the "rules", the test will
be done on a file "better" than a truncated file. Is it that last
few dB of dynamic range that makes Dan's hypothesis viable much of the
time? Entirely possible.
As to Andre's comments, I think it is likely that most
of the commercial photography being done by experienced professional
photographers for "routine" work will not suffer appreciably from
being tweaked in 8 bit. If, however, you are trying to make a gallery
print that requires tweaking where you will move the otherwise hidden
shadow detail to where it can be seen, then use 16 bit editing.
There is a test that you can run yourself to see if
there is important detail in the lower bits. Turn on the 16 bit mode
in the Photoshop "Info" tab. In an untweaked file you will
probably see some highlights between 16,000 and 32,000. That says you
are using the high bits. Now, if you see detail below 255, then you
will know you are using the lower 8 bits. If that detail is important
to you then you must edit in 16 bit mode. I have done this and there
is detail and not noise in my D2X raw files.
The whole thing boils down to you, your photo and its
intended purpose, not an inflexible workflow or someone else's rule.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Sun, 15 Jan 2006 11:35:59 -0800
(PST)
From: Mike Bevans
Subject: RE: Re: Call for 16-bit example
As much as I fear entering into religious debates,
here I go... I have not found the grail. I have yet to see a difference
between 16 bit and 8 bit images... that is not to say it does not exist, I
just haven't seen it yet, even with extensive editing.
I have seen what happens to an image when you have
less than 8 bits.
Working with a look-up table converter, I tried lower
bit depths in order to save space and speed up processing. I used an image
with a lot of sky in the shot to test results. 7 bits is okay, with very
slight posterization in the sky. Certaily not acceptable for professional
photographers, but for consumer applications it was passable. The lower the
bit depth gets, the more posetrization with 5 bits making very crunchy
images.
From this, one could hypothesize that the greater the
bit depth, the lower the risk of posterization in gradients.
From my experience 8 bits is the magic number, but
based on the above hypothesis, 16 bits would be better, at least
theoretically. As has been mentioned in this discussion and the previous
debates, 16 bits per channel used to be daunting from a storage and RAM
standpoint, but now and days it is less of an issue.
It would still be nice to have a true believer present
a sample shot demonstrating the visual superiority of 16 bit images. It
would finally put this discussion to rest.
-Mike Bevans
www.tribecalabs.com
___________________________________________________________________________
Date: Mon, 16 Jan 2006 11:48:19 +0300
From: Vladimir Yelisseyev
Subject: Re: Call for 16-bit example
Dan Margulis wrote:
The following types of images are not of interest.
3) Images worked in an exotic colorspace definition,
such as a nonstandard
gamma, or an ultra-wide gamut RGB.
Dan,
does that also include LAB?
Vladimir Yelisseyev
___________________________________________________________________________
Date: Mon, 16 Jan 2006 09:28:39 -0600
From: "Steve Fuller"
Subject: RE: Re: Call for 16-bit example
Dan Margulis writes;
Yes, it must certainly seem illogical to a scientist
that a hypothesis
claiming that a certain result can be achieved with
real-world images and
methodologies should be tested with real-world images
and methodologies
rather than with theoretical constructs. What an
unscientific concept!
Your "real-world images" seems to be defined
as a capricious, arbitrary and time variant SUBSET of REAL WORLD IMAGES.
Do not real world images include gallery exhibition images? It
does not seem "unscientific" to use simple math to disprove an
hypothesis or to be the basis for a demonstration of the fact that math
works in the real world.
As for being a professor, things must have changed
since I was in school.
Back then, when a scientist put forward a hypothesis,
it was not up to
everyone else to prove it wrong, but rather it was up
to him to prove himself
right.
Exactly! Thank you! I think we all eagerly
await your proof of your hypothesis.
Let me guess, professor. It's a gradient, right?
Do not the great preponderance of commercial
photographic images in the "real-world" depend almost exclusively
on gradients of light and color? (It was not a non-linear gradient
process that I used for demonstration.)
A bit premature, wouldn't you say, professor? You
haven't actually said
that you have an image that *you* think meets the
rules.
If I said I had an image that meets the rules it would
be based on a subjective decision of mine since the rules are not precise
and are predicated on your subjective views of the image and the process.
This is the typical response of an academic who knows
that he doesn't have
the goods. Your hypothesis predicts one result.
Have I made an hypothesis? I think not. I
have "predicted" nothing.
1) I have a hypothesis that involves how real-world
images will behave
in real-world circumstances.
2) I am not obliged to test my
hypothesis by direct experimentation with
the category of images that it is supposed to apply
to, because my
hypothesis
is obviously correct and can be proven by analogy.
3) Any experimental evidence casting
doubt on my hypothesis is
irrelevant, because my hypothesis is so obviously
correct that no amount of
contrary evidence can disprove it.
One bit shy of truth.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Mon, 16 Jan 2006 11:00:27 -0600
From: "Sabo, Lori"
Subject: Re: Call for 16-bit example
Just curious, does the same thing hold true for hi-res
digital scanning backs (like Betterlight for a 4x5 camera), which although
usually used for reproduction of artworks, can and have been also used for
creating digital photographs as well? Certainly there is some noise,
different types depending on what iso and scan-line-time you set up
and I suppose whether it is a newer more sensitive sensor model. I
suppose the useful-bitness would be similar to a regular digital camera?
Lori Sabo
___________________________________________________________________________
Date: Mon, 16 Jan 2006 17:13:54 +0000
From: Francis Corvin
Subject: Re: Re: Call for 16-bit example
For one-pass scans, probably. Multiple-pass scans
would add useful bits (e.g., 2 passes=1 bit; 8 passes=3 bit). However, this
depends very how the averaging is done.
Regards,
Francois Corvin
___________________________________________________________________________
Date: Mon, 16 Jan 2006 10:14:05 -0800
From: "Paul D. DeRocco"
Subject: RE: Re: Call for 16-bit example
Actually, it's a square root function, so four passes
adds one bit, and 16 passes adds two.
--
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Mon, 16 Jan 2006 17:34:44 -0800
From: "marty"
Subject: RE: Directions to look for 16 bit samples
I too think the idea that 16 bits buys any significant
advantage is way overstated. However, I think people are looking in the
wrong places for examples. It's not the low luminance areas.
The most likely scenes to exhibit real differences
between 16 bit and 8 bit images are ones showing high luminance with lots
of smooth gradients. Snowdrifts in a winter scene come to mind where the
highlight detail is enhanced. Sensor noise is far lower than the 8 bit
digitization error since at high exposure levels there is effectively only
7 bits of data in the aRGB98 8 encoded bits and in 16 bit linear space the
sensor rms error is around .2% of full scale at ISO 100 on a 1DsII.
Now, if only I didn't live in SoCal.
Martin Gray
___________________________________________________________________________
Date: Mon, 16 Jan 2006 21:12:10 -0600
From: "Howard Smith"
Subject: Re: Re: Call for 16-bit example
Steve, this has been a fascinating discussion, but I
fear I've lost the point you're trying to make. Still, not being a
professor I'm not as interested in theoretical considerations as in
practical results. Your question about real world images leads me to
suspect that you either have some of these real world images with which to
establish the superiority of 16-bit editing over 8-bit, or that you have
access to such images. Disregarding Dan's limits for the moment, could you
please post some samples of these images so all of those non-theoreticians
among us can see for ourselves? As no self-respecting mad scientist
ever accepts a claim that anything is impossible, I'm genuinely intrigued
by your arguments. If you can, indeed, establish the superiority of
16-bit image editing with images that artists and photographers are likely
to encounter in their own real world, this would be a very interesting
demonstration. So far no one seems to have been able to do this other
than with the kinds of images that are so unique that most of us would have
little to gain from routinely using 16-bit images just in case we encounter
one of these rare examples. If, on the other hand, you are arguing for the
sake of argument with little concern for the practical applications, let
the arguments continue and never mind the images.
Howard Smith
___________________________________________________________________________
Date: Mon, 16 Jan 2006 22:22:13 -0500
(EST)
From: MARK SEGAL
Subject: RE: Directions to look for 16 bit samples
How does the statement below cohere with the fact that
the 1Ds MkII captures 12 bit data, not 16?
Mark Segal
marty wrote:
Sensor noise is far lower than the 8 bit digitization
error since at high exposure levels there is effectively only 7 bits of
data in the aRGB98 8 encoded bits and in 16 bit linear space the sensor rms
error is around .2% of full scale at ISO 100 on a 1DsII.
___________________________________________________________________________
Date: Mon, 16 Jan 2006 20:58:55 -0800
From: "marty"
Subject: RE: Directions to look for 16 bit samples
When the RAW file (12 bit linear samples) is converted
to, say, Adobe 16 bit, the matrix math combined with Bayer interpolation
creates samples that are actually 16 bits, not 12. One can even run a
histogram of these and get fairly large bucket fills. Of course the
information content isn't increased so one shouldn't be deceived by the
histogram. The bottom 4 bits are almost, but not entirely, noise. This is
further mangled by Gamma compression. Most understand that "16
bits" is the resolution of the colorspace, not actual information.
Marty gray
___________________________________________________________________________
Date: Tue, 17 Jan 2006 07:09:50 -0500
From: "Iliah Borg"
Subject: Re: Directions to look for 16 bit samples
Dear Marty,
Samples are not always 12 bit, they can be as low as 7
bit and as high as 16 bit. In some 12-bit cameras first 128 levels are
stripped to get rid of noise. In some 12-bit cameras lossy compression via
LUT is used, and raw data contains less then 700 levels. In some the
highest level is 3700 instead of 4095. In some it is only about 2000.
In its simplest form white balancing is multiplication
of linear raw data. Typically this can be up to 4 times on individual
channel. Exposure compensation during conversion involves another
multiplication, up o 8 times. Demosaicing does not add to the data length
usually, unless a channel is blown out. In that case it can add 1 or 2
bits, depending on implementation. So worst case we can end up with 22..23
bits of data.
Last 4 bits are not necessary noise only, it depends
on the exposure, camera hardware, and white balance.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Date: Tue, 17 Jan 2006 11:58:47 +0000
From: Francis Corvin
Subject: RE: Directions to look for 16 bit samples
That's why I asked earlier whether the debate on the
amount of useful bits has been closed: for instance, the interpolation of
the Bayer patterns causes 2/3 of the image to be an artificially generated
gradient of some sort, in one channel or another. Therefore, would it pass
the test of acceptability?
And that's before we start talking about moire filters
at the front-end and noise reduction at the back-end. ..
Regards,
Francis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 09:28:18 EST
From: Dan Margulis
Subject: Re: Re: Call for 16-bit example
Lori writes,
Just curious, does the same thing hold true for hi-res
digital scanning
backs (like Betterlight for a 4x5 camera), which
although usually used
for reproduction of artworks, can and have been also
used for creating
digital photographs as well? Certainly there is
some noise, different
types depending on what iso and scan-line-time
you set up and I suppose
whether it is a newer more sensitive sensor model.
I suppose the
useful-bitness would be similar to a regular digital
camera?
I can speak to the issue of skies because I have been
working with a lot of them this week, from a variety of different cameras.
When dealing with what we might call "a clear blue sky," the
performance in the red channel, which is the critical one, is uniformly
atrocious across all models I've tested. It's not bad enough to show under
most output conditions provided little manipulation is done to the picture,
but it's plenty bad enough to require remedial action if you want to use it
in, say, a blend.
I'm not going to name models because AFAIK the problem
is everywhere. I will be showing a page of magnified sections of skies from
two different (unnamed) current-model digicams. One is one of the most
commonly named professional cameras on this list; the other is targeted at
high-end consumers. The better camera's file is opened in Camera Raw and
the lesser camera's file is a JPEG.
In all similar skies I've looked at closely, the green
channel is reasonable. I do not believe, however, that it is accurate to 8
bits although it seems to be at least to 7. In the red channel of these
skies, however, even the *fifth* bit is of questionable validity and the
sixth even more dubious. The seventh and eighth bits are random numbers.
These comments apply to relatively flat areas of blue
sky only.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 10:42:58 -0500
From: "Iliah Borg”
Subject: Re: Re: Call for 16-bit example
Dear Dan,
In the red channel of these skies,
however, even the *fifth* bit is of questionable
validity and the sixth
even more dubious. The seventh and eighth bits
are random numbers.
But of course! Should we discuss why is it so?
--
Best regards,
Iliah Borg
___________________________________________________________________________
Date: Tue, 17 Jan 2006 09:19:46 EST
From: Dan Margulis
Subject: Re: Directions to look for 16 bit samples
Francis writes,
That's why I asked earlier whether the debate on the
amount of useful
bits has been closed: for instance, the interpolation
of the Bayer
patterns causes 2/3 of the image to be an artificially
generated
gradient of some sort, in one channel or another.
Therefore, would it
pass the test of acceptability?
Yes, it would. If that's the way the photograph is
customarily captured and presented to the Photoshop operator, then it's a
real-world image. The question is whether it can ever be advantageous to
edit a real-world color photograph in 16-bit rather than 8-bit. In
principle, how the digital file is acquired is not relevant. However, I
would not accept as real-world an image that has been purposely sabotaged
on acquisition by, for example, grossly darkening an image that is already
too dark.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 11:33:16 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
Vladimir writes,
Dan,
does that also include LAB?
LAB is not excluded by these rules, and yes, I believe
a sufficiently skilled person like yourself can probably find an example
where a legitimate (but incompetent) effort in LAB might provoke enough of
a difference for someone to like the 16-bit version better than the 8-bit,
as well as finding others where they'd like the 8-bit better than the
16-bit. Fortunately, the good folks on the other side are phobic about
working in LAB, so they're unlikely to find the 16-bit example without your
help.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 09:22:17 -0800
From: David Cardinal
Subject: RE: Call for 16-bit example
At the risk of deforming the question in some way, the
really nitty-gritty practical version of the question is for me (and many
others):
"I spend a lot of time processing, sending off to
editors, and printing Raw & JPEG images from my cameras. Life in 8-bits
is quicker and takes less disk space. But if/when 16-bits will materially
improve the quality of my product then I'm happy to use it. When &
where do I need to use 16-bit in my workflow?"
In particular, images (and an accompanying workflow)
which show when 16-bit edits make an output difference would be very
helpful, especially if it was clear _why_ 16-bit made a difference in each
case. Then photographers would have an idea when it was important and when
it wasn't.
In my case the normal "decision point" is
usually in ACR or Capture (or Bibble) when I decide whether to open the
image into Adobe RGB (normaly I use 8-bit in that case) or Pro RGB
(normally I use 16-bit for that). I realize that isn't the same as Dan's
request, but in my personal case it happens to be where I make the decision
currently. I make the decision mostly based on the colors in the image
& the color histogram shape for each colorspace.
--David Cardinal
___________________________________________________________________________
Date: Tue, 17 Jan 2006 12:04:26 EST
From: Dan Margulis
Subject: Re: Re: Call for 16-bit example
Steve Fuller writes,
Your "real-world images" seems to be defined
as a capricious, arbitrary and
time variant SUBSET of REAL WORLD IMAGES. Do not
real world images include
gallery exhibition images?
The exact quotation is:
"The image(s) must be real-world color
photograph(s). This means any photograph that could conceivably be used in
any professional context. If it is a cropped piece of a larger photograph,
the piece must be large enough that it could conceivably be used on its
own."
I am sorry that it is so unclear. I meant the word
"photograph" to mean something produced by a camera, which is a
device that records an image by focusing light through a lens into a
lightproof enclosure containing media capable of recording information. By
using the word "photograph", I intended to exclude anything that
is not produced by a camera, such as, for example, computer-generated
gradients or paintings.
Similarly, I am sorry that you seem to find "any
photograph that could conceivably be used in any professional context"
to be so limiting. It seems pretty liberal to me.
It does not seem "unscientific" to use
simple
math to disprove an hypothesis or to be the basis for
a demonstration of the
fact that math works in the real world.
Hypotheses are neither proven nor disproven by math.
Math can be used to formulate them or to suggest means of attacking them.
The experimental results are what count. The entire history of science is
filled with examples of theories where the propounder's math suggested one
result but the reality was different. Whereupon, real scientists either
revise their hypothesis or come up with new experimental data to support
it.
Almost exactly five hundred years ago, the scientific
community faced the same problem. People were beginning to measure and
predict the positioning of the sun, but at certain times the sun
inconveniently was not where the math predicted it to be. As these results
were duplicated by more and more observers, real scientists began to wonder
whether their math was incorrect, or perhaps was based on incorrect
assumptions.
Eventually, they figured out what was wrong with the
math, no thanks to the type of science that you seem to favor. If 16-bit
advocates had been in charge at the time, they would have said, the math is
perfect. As everyone knows the earth does not move in the heavens, a fact
too obvious to either require proof or be susceptible to disproof, the
experimental observations are irrelevant. The math demonstrates where the
sun is even if the telescopes find it somewhere else. Eppur si muove.
Exactly! Thank you! I think we all eagerly
await your proof of your
hypothesis.
Here we go again, with an attempt to shift the burden
away from those who advocate the inconvenient workflow. It's not up to them
to prove themselves right, but up to the rest of the world to prove them
wrong!
Nobody can ever *disprove* that 16-bit is useful, any
more than we can disprove the theory of intelligent design, or disprove a
statement that carrying a lucky rabbit's foot cancels out the benefits of
16-bit editing. All we can say is that no evidence has yet been presented
that 16-bit editing of color photographs does any good under any
circumstances. I do not advocate that
anyone who is comfortable using 16-bit stop doing so.
Here, the assertion is that 16-bit editing of color
photographs improves quality in comparison to the way things have been done
for the last 25 years. Some people make modest claims of increased quality,
but others use terms like "night and day difference",
"totally obvious to anyone who looks" or, in referring to those
who do not edit in 16-bit, "recreational, rather than professional
users." As someone who writes about how to improve the quality of
images, I have to field a lot of inquiries from baffled users as to why I
am not writing about this method that produces the night-and-day, amateur
vs. professional user difference.
All I can respond is that the people who are saying
this refuse to back it up with images, and that I and others have tried
very hard to produce the effects that they say are so pronounced, using
exactly the type of images and methodologies they are talking about, and we
get nothing of the kind even when we make corrections far more extreme than
would ever be done in real life. And that the people who advocate this
workflow offer no real backup, only theories using math that they don't
understand, and when challenged they resort to lame excuses and ad hominem
attacks to try to cover up the fact that they have no images to show.
My original post was simply due diligence. After six
years of this silly debate, I think it's unlikely that any real-world color
photograph will ever be produced that clearly shows a benefit for 16-bit
rather than 8-bit editing. But I ask the question, and make the offer to
print it, just in case somebody can pull such an example out of their hat.
I am not expecting anyone to have such an image, and certainly you don't.
Do not the great preponderance of commercial
photographic images in the
"real-world" depend almost exclusively on
gradients of light and color?
In a manner of speaking, yes, and from that you are
going to take the colossal and mathematically preposterous leap into saying
that therefore operations on a *computer-generated* gradient will have the
same effect as on a photograph. This is the same logic as saying that
castor oil is a liquid, and since Château Lafite Rothschild is also a
liquid and tastes good, it follows that castor oil must taste good as well.
If you don't believe it, print out one of your gradients, take a photograph
of it, and see how much good 16-bit does in editing it.
The claim of enormous 16-bit superiority is a claim
aimed at real-world photographers and retouchers. It is not too much to ask
that any demonstrations be done with real-world photography and not things
that are claimed to be analogous.
I will be off-line for the next week, but in view of
the fact that you have no images to offer, this exchange has ended AFAIC.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 14:44:46 EST
From: Dan Margulis
Subject: Re: Re: Call for 16-bit example
Iliah writes,
Dear Dan,
In the red channel of these skies,
however, even the
*fifth* bit is of questionable validity and the sixth
even more dubious. The
seventh and eighth bits are random numbers.
But of course! Should we discuss why is it so?
By all means, but please remember, most list members
aren't mathematicians, so try to keep the explanation simple.
However, it doesn't take much technical knowledge to
understand the implications. Skies are the area most commonly cited (along
with deep shadows) as being vulnerable to banding in 8-bit. The 16-bit
proponents say this is because of the superior data in their files.
However, as I pointed out, and Iliah, who is an expert, agrees, the data in
the critical red channel of skies is very bad. The extra bits in this area
of the 16-bit file are nothing but garbage--random numbers, pure noise.
It's conceivable that this noise may have a beneficial
effect under certain extreme conditions, because noise is the enemy of
banding. However, even if such an image exists, you wouldn't need a 16-bit
file to get the benefit. There are lots of ways of adding fine noise--in
extremis, you could convert an 8-bit file to 16-bit and get a lot of random
noise in the extra bits pretty easily.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 17:12:08 EST
From: Dan Margulis
Subject: Re: Directions to look for 16 bit samples
Marty Gray writes,
I too think the idea that 16 bits buys any significant
advantage is way
overstated. However, I think people are looking in the
wrong places for
examples. It's not the low luminance areas. The most
likely scenes to exhibit
real differences between 16 bit and 8 bit images are
ones showing high
luminance with lots of smooth gradients.
I agree that this is where any realistic difference is
likely to show up. I was not able to produce any during my 2002 testing.
However, I'll be revisiting this in the next few months as I have a
long section (parts of three chapters) on highlight recovery and
enhancement planned. I suspect that it will show that somewhat better
highlight results can be gotten out of a carefully handled Camera Raw file
than out of a JPEG, and I have the files to find out for sure. I will be
doing these tests with 16-bit Camera Raw files, and if it turns out they do
better than the JPEGs, then I'll rerun them in 8-bit Camera Raw and see how
they compare.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 17:33:50 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
David Cardinal writes,
In my case the normal "decision point" is
usually in ACR or Capture (or
Bibble) when I decide whether to open the image into
Adobe RGB (normaly I
use 8-bit in that case) or Pro RGB (normally I use
16-bit for that). I
realize that isn't the same as Dan's request, but in
my personal case it
happens to be where I make the decision currently. I
make the decision
mostly based on the colors in the image & the
color histogram shape for each
colorspace.
Just to clarify a previous recommendation. As list
members know, certain third-party capture modules (at least two of them) do
not generate satisfactory 8-bit files. In at least one case, they convert
their own 16-bit data to 8-bit by the idiotic expedient of chopping off the
last 8 bits, which means that a value of 19.99 rounds to 19 rather than to
20, which can cause trouble down the line.
In view of these problems, I had previously suggested
that, to be on the safe side, Raw users might wish to export in 16-bit and
then convert to 8-bit at their leisure although I did not know for a fact
that there was anything wrong with the way Raw makes its 8-bit files.
Having done much more testing, I haven't been able to find any problem with
exporting from Raw in 8-bit as David is doing.
Dan Margulis
___________________________________________________________________________
Date: Tue, 17 Jan 2006 21:54:40 -0400
From: Lee Clawson
Subject: Re: Call for 16-bit example
on 1/17/06 1:22 PM, David Cardinal wrote:
When & where do I need to use 16-bit in my
workflow?"
David,
For me where and when comes after I'm satisfied that
the test images have been printed and inspected (maybe even density
measurements of any perceived differences) in a (book) printing plant using
materials and techniques commonly available to anyone and under conditions
that are repeatable.
In other words I want to see the results and
differences, if any, and know that on my 4 color runs I'll get similar
results. I'm more hesitant than you; for me the efficiency of workflow can
wait.
Lee
___________________________________________________________________________
Date: Tue, 17 Jan 2006 20:40:38 -0600
From: "Steve Fuller"
Subject: RE: Call for 16-bit example
Dan Margulis wrote:
Just to clarify a previous recommendation. As list
members know, certain
third-party capture modules (at least two of them) do
not generate
satisfactory 8-bit files. In at least one case, they
convert their own 16-bit data to 8-bit
by the idiotic expedient of chopping off the last 8
bits, which means that a
value of 19.99 rounds to 19 rather than to 20, which
can cause trouble down
the line.
Just to avoid trouble down the line, there is no such
thing in either the 16 bit or 8 bit image file systems as 19.99. The
values actually used are integers, not floating point numbers (i.e. with
decimal points). If you had a value of either 19 or 20 in a 16 bit
file and changed the file to 8 bit the value would be 0 with three bits to
spare since the number 20 uses only 5 of the lowest 8 bits. In the
"real-world" there is no problem in changing such a low 16 bit
value to 8 bit. It is simply black.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Tue, 17 Jan 2006 23:00:27 -0500
From: "Iliah Borg"
Subject: noise in sky
I have a well-exposed RAW image taken with 1DsMkII
opened on my computer.
It is a daylight scene, with accurate white balance,
scene with sky, bed-sheets on a rope, closed shadows, taken at ISO 100.
For this kind of scene based on camera specifications
one would expect the values in raw file to be 0..4095.
In fact, they run from 123 to 1999. Is it a 12-bit
data? Not exactly. We have slightly less then 11 bits of data.
But are they actually data? I'm looking into deep
shadows (door opened to the barn) where I can't extract any details
whatever I try. Data variation in that area is from 0 to 17, so noise
occupies about 4 bits. Histogram of that area is nothing but combs.
We end with 8 useful bits of data at most, or maybe
only 7.
Let's have a look at channel data. Red varies from 123
to 1094, green - 123 to 1999, blue - 123 to 1572.
So, red contains about 6 bits of real data, given
values of noise it has.
Next I need to apply white balance to that raw data.
Camera recorded white balance coefficients for the
scene are 2.15, 0.93, 1.17. This is the weak red channel raw data will be
multiplied 2 times, while green and blue will essentially stay. So
underexposed and noisy red channel will be moved forward, making noise more
visible, especially in smooth blue/green highlight areas, like sky.
--
Best regards,
Iliah Borg
___________________________________________________________________________
Date: Tue, 17 Jan 2006 23:08:15 EST
From: Dan Margulis
Subject: Re: Call for 16-bit example
Steve Fuller writes,
Just to avoid trouble down the line, there is no such
thing in either the 16
bit or 8 bit image file systems as 19.99.
Reading this, I now know why Atlas shrugged.
The values actually used are
integers, not floating point numbers (i.e. with
decimal points). If you had
a value of either 19 or 20 in a 16 bit file and
changed the file to 8 bit
the value would be 0 with three bits to spare since
the number 20 uses only
5 of the lowest 8 bits.
I beg to amend my previous statement as follows:
"In at least one case, they convert their own
16-bit data to 8-bit by the idiotic expedient of chopping off the last 8
bits, which means that a value known to Steve Fuller and five other people
in the world as 0001001111111110, and to Michael Stokes and eight other
people in the world as 13FE, and to the remaining population of the planet
as 19.99, rounds to 00010011, or 13H, or 19 rather than to 00010100, or
14H, or 20, which can cause trouble down the line."
Dan Margulis
___________________________________________________________________________
Date: Wed, 18 Jan 2006 07:29:22 -0600
From: "Steve Fuller"
Subject: RE: Call for 16-bit example
Dan Margulis wrote:
I beg to amend my previous statement as follows:
"In at least one case, they convert their own
16-bit data to 8-bit by the
idiotic expedient of chopping off the last 8 bits,
which means that a value
known to Steve Fuller and five other people in the
world as 0001001111111110, and
to Michael Stokes and eight other people in the world
as 13FE, and to the
remaining population of the planet as 19.99, rounds to
00010011, or 13H, or
19 rather than to 00010100, or 14H, or 20, which can
cause trouble down the
line."
Please copy the binary number above (0001001111111110)
and paste it into the
Microsoft Windows Calculator window and press the
decimal conversion button
and you will read the number "5118", not
19.99.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Wed, 18 Jan 2006 09:07:58 -0500
From: "Iliah Borg"
Subject: Re: Call for 16-bit example
Dear Steve,
Please copy the binary number above (0001001111111110)
and paste it into the
Microsoft Windows Calculator window and press the
decimal
conversion button
and you will read the number "5118", not
19.99.
and if you divide by 256, it will be close to 19.99
--
Best regards,
Iliah Borg
___________________________________________________________________________
Date: Wed, 18 Jan 2006 10:38:27 -0800
From: "Paul D. DeRocco"
Subject: RE: Call for 16-bit example
From: Steve Fuller
Just to avoid trouble down the line, there is no such
thing in either the 16
bit or 8 bit image file systems as 19.99. The
values actually used are
integers, not floating point numbers (i.e. with
decimal points). If you had
a value of either 19 or 20 in a 16 bit file and
changed the file to 8 bit
the value would be 0 with three bits to spare since
the number 20
uses only 5 of the lowest 8 bits. In the
"real-world" there is no problem
in changing such a low 16 bit value to 8 bit. It
is simply black.
He was conceptually treating the 16 bits as 8 integer
and 8 fraction, so 19.99 would map to something like 0x13FD.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Wed, 18 Jan 2006 13:41:33 -0600
From: "Steve Fuller"
Subject: RE: Call for 16-bit example
Iliah Borg wrote:
and if you divide by 256, it will be close to 19.99
Indeed what you say is correct but that is not what
Dan said. He said nothing about dividing by 256 but said that bit
pattern was 19.99. That is why I have had trouble following his
pronouncements. If we look at what happens or can happen in the
conversion we will see that the fastest way to convert 16 bit to 8 bit is
to do a logical shift. Cheap and easy. It is quite expensive to
do division. I dare say that, when compared to division, that dither
and a logical shift would be faster and cheaper. In neither case do
we have division. In neither case do we have a number with a decimal
place. In the latter we have a result to be desired. I think we
would all agree that rounding per se is a poor substitute for dither.
If we round we still have an expected quantization error of plus or
minus one half count and if we truncate we have an expected error of plus
or minus one half count. It takes dither to reduce that expected
error below plus or minus a half count.
Regards,
Steve Fuller
___________________________________________________________________________
Date: Mon, 31 Oct 2005 14:07:03 -0000
From: Dan Margulis
Subject: 16- and 8-bit: Summing Up (Part 1 of 4)
Last month, it appeared that some the basics were
finally being agreed upon as to some of the advantages or lack thereof in
color-correcting 16-bit files vs. 8-bit files. This topic that has wasted
far more time than it could possibly merit over the last half-decade.
Because there was a lot of posturing that masked the essential agreement, I
suggested that we stop the thread, and I promised that at a later time I
would post a fuller response.
I'd like to start from scratch and explain what the
basic principles are, why the debate went on so long, and what it teaches
us for the future. I do not believe this is a topic significant enough for
a magazine article, but this post is article-length, and is therefore
divided into three parts plus an appendix. I intend this to be my last word
on the subject until the next edition of Professional Photoshop, unless
there are some new developments from images I am now studying.
DEFINITION.
A bit is the smallest addressable part of a computer's
memory. It can be seen as either 0 or 1, either on or off, either yes or
no. Each bit therefore has two possible states. Two bits taken as a pair
have four possible states. Three bits have eight, four bits 16, and so on,
with the number of possibilities doubling every time a bit is added.
Ever since the advent of digital color correction in
the early 1980s, it has been standard to devote 8 bits of computer
information to describe a single pixel in a single channel. This gives a
total of 256 possibilities. In three-channel colorspaces like RGB, 24 bits
(8x3) are required to fully define the pixel's color, meaning that there
can be 16,777,216 (256x256x256) possible colors for a given pixel.
Nobody can see that many colors. Even the most
optimistic estimates--and that's the side you find me on--say that humans
can only perceive a little more than a million colors, and most experts put
the figure considerably lower than that.
Nevertheless, some believe that it makes sense to try
to define more colors. Some digital cameras try to record 10-bit (1,024
possible values per channel, a billion possible colors). Modern drum
scanners try for 12-bit (4,096 values, 69 billion possible colors). Whether
these devices are accurate to that level of precision is very doubtful.
In the mid-1990s, Photoshop introduced limited support
for 16-bit files--65,536 values per channel, 281 trillion possible colors.
There was no intermediate level. If you had a 10-bit file and wanted to get
it into Photoshop, you had to decide whether to bloat it by making it
16-bit or compress it by making it 8-bit. Also, few important commands
other than curves would work on a 16-bit file. We could not even make a
layered file in 16-bit. As time went on more support was added, and today
almost anything we can do in 8-bit we can do in 16-bit.
THE ISSUE.
The question before us is not whether to capture in
16-bit, store in 16-bit, or output in 16-bit. The only issue is, first, is
there any advantage in *editing* files in 16-bit rather than 8-bit, and if
there is, it is so enormous as to constitute a "night and day
difference" or to justify the statement that anyone who does not edit
in 16-bit is a "recreational, rather than professional" user of
Photoshop.
16-bit files are twice as large as 8-bit files. They
take longer to store and to back up and require more disk space. Also, if
the file size is large, it may take Photoshop much longer to perform edits.
Plus, most output devices and many layout programs won't accept 16-bit
files, so we have to go to the trouble of converting them to 8-bit
eventually anyway.
For some, this isn't an issue. They process a limited
number of images in studio and, taking advantage of today's low prices,
they have an infinite amount of storage space. For others, like newspaper
photographers on deadline, doubling the file size would be so onerous as to
be out of the question even if there was a undeniable quality gain
associated with it. For everyone else, the doubled file size is an
inconvenience to some degree. The question must be whether we gain any
benefit, and if so, what, because it's possible we might want to use 16-bit
some of the time and not others.
When someone advocates doing something inconvenient,
whether converting to LAB, or using Camera Raw, or doubling one's file
size, or putting 15 layers on a file, it's up to that person to make a
compelling case for it. It isn't up to you, me, or anybody else to show
that it's *wrong* to do it. The reason that the subject has refused to die
is that the advocates of 16-bit editing claim exemption from this rule:
they take the position that whatever they recommend, whether it's 16-bit
editing or wearing garlic around the neck while writing curves, must be
taken as gospel and that they have no responsibility to back up what they
say.
AREAS WHERE EVERYONE AGREES.
Nobody AFAIK has ever doubted the following.
Extra bits are valuable in editing computer-generated
graphics, especially those that include gradients, or with image areas that
are so heavily retouched that they are essentially computer-generated as
opposed to photographic.
Scanners, digital cameras, and Camera Raw all operate
natively with more than eight bits. As there's no way to make them operate
any other way, the question of whether they *could* operate effectively
with fewer bits is irrelevant.
Certain scanners and certain camera software do not
generate 8-bit files correctly. Therefore, where possible, these files
should be brought into Photoshop in 16-bit, and converted to 8-bit at a
later time.
Most people who handle lots of images have from time
to time been burned because they failed to save a copy of the original,
untouched image. People crop the image or rez it down only to discover that
the extra information comes in handy a year later. The chances of a bug in
Photoshop or the OS inadvertently damaging a file when it is resaved are
extremely small, but they are not zero. That alone is a good reason to save
a copy of the original 16-bit file.
16-bit does no real-world harm other than the extra
space and computing time it requires.
THE INITIAL WILD CLAIMS.
While nobody has ever argued that people who are
comfortable using 16-bit for correction should stop doing it, the same is
emphatically not true of 8-bit users. Starting in 1999, a slew of
self-appointed experts, largely but not exclusively Andrew Rodney and his
business partners, began to attack anyone who didn't use 16-bit for *all*
editing. The rhetoric they used was apocalyptic. Editing in 8-bit was
"amateurish". It was "highly critical" to edit in
16-bit all the time. Those ignorant enough to edit in 8-bit proved
themselves to be "recreational, rather than professional" users
of Photoshop.
Early on, a number of users questioned this, stating
that they had compared the two approaches found little difference in the
results. Instead of accepting the possibility that they might be mistaken,
the 16-bit advocates dug in their heels. I quoted the following from a
single 2001 thread, where a squadron of "experts" were berating
their challengers. This is not a single speaker, but a group of them,
separated by ellipses.
"16 bit capability is critical during all aspects
of tone compression…The difference CAN be seen in the final output
very easily. Most definitely on the printed page, especially when using
high-quality halftoning and even more so to a film recorder…It's very
easy to see that substantial color & tone editing will eventually
result in data loss and banding…If it means the difference between
taking a 16-bit image capture and editing that to the final image and
taking that same image in only 8-bit and editing that to the final image
then there is a difference like between the day and the night…Yes, if
a histogram full of holes has no impact on final output, then throw away
the graphs and just get on with the print run. However, all of us have Real
World Output showing the superiority of superior data acquisition…My
advice? Take the information you've read here to the bank. Stop doubting
and start applying what you've learned here…If you really start out
with a RAW image in high-bit form and a raw image downsampled to 8 bits,
the difference really is night and day. …it's totally obvious to
anyone who looks that it's very advantageous to do the big moves on
high-bit data."
Nobody offered a single real-world image to show this
enormous difference. It was all histograms and gradients, gradients and
histograms.
THE "CHALLENGE".
The type of color correction I teach does not depend
on bit depth. The methods work equally well whether you choose to use 8-bit
or 16-bit. I have never written an article or a column about bit depth. I
don't even mention the topic in my classes.
There are around ten pages of Professional Photoshop
that discuss bit depth and around five pages of Photoshop LAB Color. They
are there is not because they are necessary to my message in any way, but
because the advocates of 16-bit editing were so forceful in their
denunciations of anyone not using their methods that I kept getting hit
with the question, both on this list and elsewhere. At http:
//www.ledet.com/margulis/ACT_postings/ColorCorrection/ColorCorrection.htm
there are several archived threads on this topic dating from 1999. The only
thing that I could answer was that I have nothing against others using
16-bit, and use it myself in dealing with computer-generated graphics and
in very specialized cases with color photographs. However, AFAIK there are
no real-world circumstances under which a non-expert would find it
beneficial for editing color photographs.
Before putting anything in my own books, I try to
verify that there isn't something unusual about my own files that causes me
to draw an incorrect conclusion. I therefore posted a request for people
who thought that they could demonstrate an editing superiority for 16-bit
to arrange to send me files for testing. As my own testing (see Part II,
"Where 16-Bit Can Be Better") had already established that a
grayscale file could conceivably show an advantage either for 16-bit or
(more commonly) for 8-bit editing, I specified color photographs only, in
one of the four standard Photoshop RGB definitions.
Around a dozen people have responded between 2001 and
now. They put together packages containing proofs and often several
different versions of corrections. Over a period of a full week in 2002, I
analyzed image after image trying to find any circumstances under which
16-bit editing would give superior results.
Finding none, in Professional Photoshop Fourth
Edition, I published almost ten pages of comparisons, because to illustrate
the points, pictures have to be fairly large. Six full pages were devoted
to showing images at various magnifications. Because the 16-bit advocates
had retreated to a position of claiming that the difference was only
critical when the corrections were large ones, the examples I showed ranged
from large to inconceivably huge, in one case taking a picture that was so
flat that it was unrecognizable for subject and correcting it into
something that could be mistaken for professional work. I printed each
image at high magnification, including some individual channels. They were
printed without identification and readers were invited to guess which was
which. I particularly chose images that would be the most prone to the sort
of banding that the 16-bit advocates claimed would happen.
Every person who has ever submitted files to me has
agreed with my assessments of image quality. Certain people have had
procedural mistakes that I pointed out, and they have always agreed that my
objections were correct. In the cases where I am stating that there was a
qualitative difference when done in a certain way but not in another. I
have shown the results to the person submitting the files and they have
always agreed with my findings.
Similar independent testing was subsequently performed
by Jim Rich. The main difference between his testing and mine was that
Jim's testing involved real-world corrections of images, in that his
corrections, although severe, might actually be seen on an everyday basis.
Mine, OTOH, were intentionally set up to be far more demanding than any
real-world scenario would ever entail. Anybody having to deal with the type
of challenges that I published has many more serious workflow problems than
bit depth.
Jim's testing, which was also independently reviewed
by experts, got the same results. Since that time, around a dozen people
have performed similar tests, trying to find any real-world scenario in
which 16-bit editing of color photographs might produce an advantage,
however trivial, over doing the same thing in 8-bit. Everyone has come up
empty.
In my LAB book, I had one further example, in trying
to dispose of a similar myth. In the mid-1990s, one of the same people who
now fiercely defends 16-bit editing was even more fiercely opposed to the
use of LAB. He asserted that the very conversion from RGB to LAB to do the
editing caused "catastrophic damage" to the image. This opinion
was, of course, based on analysis of histograms and gradients. In response,
in a 1997 book, I showed side-by-side images, one of which had been
converted back and forth between LAB and RGB 75 times. No difference, of
course. Nevertheless, the myth persisted, and I would several times a year
get questions about the supposed damage. So, in the LAB book, I did another
such example, 25 times back and forth. I compared it mathematically to
other conversions and demonstrated that the variation between the
RGB>LAB>RGB and the original RGB version was less than that between
many RGB to RGB conversions.
Shortly after announcing the "catastrophic
damage" theory and finding that there was no damage at all even after
multiple conversions, the theorists changed their theory. The catastrophe,
they opined, only occurred the *first* time that a file was converted;
subsequent conversions of the same file would be harmless. But, if at some
other point in the correction, there would be for some reason another
conversion to LAB, *that* would be a catastrophe. This was similar to one
of the changes in their 16-bit theory. Originally, it was "highly
critical" to do all edits in 16-bit. Then, it was changed to "big
changes". When it became clear that this theory didn't hold up either,
it was changed to "big changes done over a series of smaller
changes."
Therefore, in total disgust, I spent five pages of the
LAB book showing large-size, magnified comparisons not of two variants, but
of four, of each of two different images. The images were specifically
chosen because they had the type of smooth areas that supposedly cause
disaster in 8-bit editing and in conversions to and from LAB. One was a
16-bit digicam capture, the other 16-bit scanned film. They were compressed
into a small 16-bit range, which is far more challenging for the subsequent
edit than starting with an original limited-range capture.
To these images, I applied not one or two big
corrections but, in accord, with the theory, seven of them. These were done
in RGB. I did the test once in 16-bit, and once in 8-bit. But then I
repeated the tests with a twist--after each of the seven moves, I converted
unnecessarily to LAB and back again. Therefore, between the most
politically correct of the four variants (16-bit all the way, no
conversions) and the least (8-bit all the way plus a conversion to LAB
after each move) there were seven night-and-day,
totally-obvious-to-anyone-who-looks corrections *plus* seven
catastrophic-damage conversions.
Nobody could tell which was which even at high
magnifications.
Dan Margulis
----------------------------
In Part II, I discuss the situations where 16-bit
editing can actually be better, and review the retreat of the 16-bit
advocates from the night-and-day difference position.
___________________________________________________________________________
Date: Mon, 31 Oct 2005 13:33:13 -0000
From:Dan Margulis
Subject: 16- and 8-bit: Summing Up (Part 2 of 4)
WHERE 16-BIT CAN BE BETTER.
A 16-bit file can have very minute differences between
pixels--1/256th of the minimum difference in an 8-bit file. Anything that
small will have no impact on the final reproduction--no possible sequence
of editing events could ever create a variation that anybody could see. The
maximum initial difference between a pixel of an 8-bit and a 16-bit file
would be slightly less than half a level. That is, in a 16-bit file there
might be a value of 128.49, which would be treated as a value of 128.00 in
8-bit. That half-level difference won't do anything, either, *unless* some
unlikely sequence of commands drives it much, much further away from where
it would be if it were an 8-bit file.
For technical reasons that will be discussed later
(see What the Extra Bits Actually Do, Part III), if you look hard enough
and at a high enough magnification, the 16-bit edit always looks marginally
smoother and the 8-bit more active. To date, I know of four types of
natural photographs that, if edited to an extreme, show differences large
enough for people to prefer one or the other. (There are also some times in
retouching and image conversions where working in 16-bit helps, but they
are so esoteric that I have rarely written about them.)
1) If we apply massive edits to a grayscale file, the
difference between an 8-bit and a 16-bit correction may become noticeable.
The 16-bit version would be preferred if the image featured areas where
smoothness is desirable, like skies; the 8-bit when the subject is full of
detail. In my testing, even with very big grayscale edits, well over half
of the images showed no difference. Of the others, the result of 8-bit
editing was preferred roughly twice as often as 16-bit edits. But
definitely 16-bit editing got better results in certain images. The reason
that this does not carry over into color images is that when three channels
are superimposed on one another any variation in one is less visible.
Similar massive edits to the RGB files that were the ancestors of the
grayscale files showed no difference of any consequence.
2) Early in my testing, one list member provided a
demonstration based on applying the same edits to one 16-bit and one 8-bit
file, both generated by a scanner from a single scan. I verified that when
the edits were applied the 8-bit file looked distinctly worse. However,
when the tests were repeated on a copy of the 16-bit file that had been
converted into 8-bit not by the scanner but in Photoshop, there was no
difference in quality. I communicated this finding to the list in 2001 and
recommended that people take 16-bit files from scanners where possible.
3) A second user provided a similar exercise where
edits were applied to 16-bit and 8-bit files generated in Canon acquire
software from the same digital capture. (The original had deliberately been
acquired incorrectly in order to make the differences more apparent, which
disqualifies it as a real-world example, but in view of the interesting
nature of the problem I followed through with the testing.) Again, I
verified that there was a quality loss by editing the user's 8-bit file,
again I retested by converting his 16-bit file to 8-bit in Photoshop, and
editing that. As with Example #2 there was now no longer a quality
difference, so I recommended to the list that we avoid taking 8-bit files
directly from a camera package when a 16-bit file is available. I do not
know whether the same problem exists in Camera Raw but I will be testing it
in coming months.
4) In 2005, a third user provided a Camera Raw file of
a scene of a city at night. He sabotaged the image by moving the exposure
slider within Camera Raw all the way to the left in spite of the fact that
the image was already too dark. Then, he acquired the image in ProPhoto
RGB, an ultra-wide gamut RGB definition that is rarely used in professional
work. The image contained a large area of sky. Applying the drastic curves
that were needed to lighten the image to the 16-bit file resulted in a
perceptibly smoother and more attractive sky than the one done by
converting the file to 8-bit in Photoshop and applying the same curves
there. When the same image was captured with the same sabotage in Camera
Raw into either of the RGB definitions that most of us use--the
narrow-gamut sRGB or the wide-gamut Adobe RGB--there was no significant
difference between correcting in 8-bit or 16-bit.
THE RETREAT.
Ever since the initial assertions that 16-bit editing
would create an enormous difference, its proponents have been in full
retreat as users have asked them again and again for any example to support
the notion. They have provided a blizzard of gradients and histograms, but
never a real image. One author's idea of illustrating the concept was to
compare an *original* image to one that had been edited in 8-bit and then
showing the histogram. In a second book, he compared reasonable editing in
Camera Raw (which is 16-bit) with idiotic editing in 8-bit Photoshop, in
each case claiming that it showed the superiority of 16-bit editing.
In fairness, the demand for images placed the
advocates in a difficult position. There is no reason to doubt that they
actually believed their original wild claims were true; as has been made
abundantly clear since, they never bothered to run tests before making
them. By the time they learned that there was serious doubt that there was
any 16-bit benefit at all, let alone a night and day difference, they had
already begun to promote seminars about the benefits of the 16-bit
workflow. Furthermore, Adobe, largely at their suggestion, had begun to add
16-bit capabilities to Photoshop which were being heavily hyped. As many of
these advocates take money or other support from Adobe, it would have been
exceedingly awkward if they had abandoned the
you-are-not-a-professional-if-you-don't-use-16-bit line.
Since they could not abandon their position but could
not produce anything to back it up, they resorted to smokescreens. The
usual method was personal attacks on me. They repeatedly referred to some
mysterious "agenda" of mine. They called me lots of names, but
never could get around to showing what the people were asking for. They
asserted that I said 16-bit was worthless under all circumstances and
presented gradient after histogram to prove that it wasn't. They spent
scores of hours telling users that they were "too busy" to
prepare demonstration images that could have been made very quickly if the
difference was even a tenth as critical as what they were touting. They
constantly tried to evade responsibility by saying that the burden was on
me to prove that 16-bit doesn't have advantages, as if *I* were the one who
was saying that anyone who didn't work my way was unprofessional and *they*
were the ones who were tolerating either way.
One of the more prominent advocates, Bruce Lindbloom,
was so frustrated by his inability to produce a persuasive image that he
posted a web page that accused me of sabotaging my 16-bit images before
testing them. Also, he asserted that I kept my results private and that
nobody else could verify them. Both statements are categorically false, and
Lindbloom knew that they were false when he posted them. 16-bit advocates
Andrew Rodney and, to a lesser extent, Bruce Fraser, both of whom are well
aware that the Lindbloom page is a crock from the word go, nevertheless
repeatedly post links to it, hoping that if they post the falsehood enough
times, it will magically become true.
The gyrations that these advocates went through to
explain why they could not produce even a single real image that would
support the notion that 16-bit editing was "highly critical",
would produce a "night and day difference", and so forth are so
remarkable that they are excerpted at length in Part IV.
This list did get a glimpse of the rationale from Jeff
Schewe in 2002, in a thread that is posted in our archives. He defended his
assertion that those using 8-bit are "recreational, rather than
professional" users of Photoshop as follows (note: Jeff frequently
uses ellipses [. . .] in his messages; in the one case where I have deleted
an extraneous section of the message, I use ***):
"Nope. . .Dan and the rest of you are welcome to
continue scanning in 8 bits and doing whatever you want to do to your
images. . .but if you want absolute total control over tone and color
without the risk of breaking the image somewhere down the road. . .you
better learn to edit in 16 bits.***And yes, I'll stand by the line
'recreational' if you squander and waste your data bits just getting an
image tone/color corrected in 8 bit. . .cause if you do that, you're
working with considerably less than 8 bits/channel and deserve the banding
you are likely to incur."
I replied, "Rather than continuing to post the
same defensive bluster to every group credulous enough to listen, it must
be a better use of your time to produce even one image that demonstrates
the point. After all, this is supposed to be critical, night and day, the
difference between professional and recreational imaging. If an image
exists that shows such a dramatic difference, why not show it, rather than
just make claims?"
The evidence Jeff offered in response was,
"Pretty much all of my work the last 5 years was scanned in 16 bit for
initial tone & color correction. You are welcome to look at my work and
see for yourself, no banding. . .even after hours of editing and extreme
manipulations. I'll let my work speak for itself."
Within a year, however, others had backed off the
original claims. The new emphasis was on "flexibility for the
future." The night and day differences were no longer found in really
big edits, but only in ones with multiple big edits. We were cautioned
that, even if 8-bit is sufficient now, new types of output devices might
arise that would require more bits. The ad hominem attacks on me and my
purported motivations continued whenever users asked on-line for specific
images.
By 2004 the embarrassment was such that the
protagonists began to deny ever having made any of the apocalyptic
statements. In November, Andrew Rodney posted the following astonishing
statement to this list: "And no I've not seen any text that says
'16-bit is absolutely critical, creates a night and day difference, that
anyone who doesn't do it is an amateur, etc., etc'. It's simply a
reflection of math and physics." When Ric Cohn pointed out that
Andrew's own business partners had frequently used precisely those words,
the following day Andrew denied having denied it. Thereupon I produced
Andrew's original denial--and he denied ever denying he had denied it. And
throughout the rest of the thread he resumed the position that nobody had
ever said such things. And held to it, even after the quotes were posted.
Earlier this year, on the ColorSync list, of which I
am a member but don't normally participate, Bruce Fraser once again took
shots at my motivations when the list turned to the bit depth topic. He
wrote, "What Dan's tedious and fundamentally specious arguments
deliberately miss is that the need for greater bit depth has absolutely
nothing to do with reproduction and everything to do with
editability."
At that point I entered the thread to point out that I
did not miss that point and that on the contrary, the files that I had been
testing were edited beyond all recognition, beyond any possible claim of
real-world practice. And I pointed out how many other people had performed
similar tests with the same results, and again asked why he could not
produce any images to back up his claims of a "night and day
difference" that was "totally obvious to anyone who looks".
Bruce denied having ever said these things, whereupon
I produced the original files where he did say them. After further
exchanges in which he waffled somewhat on these phrases, I asked pointblank
whether he had ever personally run tests of 8-bit editing vs. 16-bit
editing, before or after having laid down these ukases about how the
difference would be night and day. He refused to answer. After being
further pressed, he stated that it would be a waste of time because it was
obvious that the 16-bit would look much better (if you don't believe he
said this, don't take my word for it, go to Part IV). And, having refused
to accept the possibility that something he hadn't tested might not be
true, he ended with a typical slur: "My personal opinion is that this
is a manufactured controversy--I decline to speculate on the motivation of
those who have manufactured it--and I'm utterly disinclined to waste my
time arguing the point when I have better things to do with it."
In many of these threads, other users have chimed in
claiming that they are positive from first-hand knowledge that 16-bit
editing avoids problems of banding. I'm aware of around thirty such posts,
including a couple to this list. In about a dozen cases, I've gone off-line
to ask these people how they are so sure. Without exception, they have
never performed any testing--it's all a hunch. They, like Jeff and Bruce,
merely are supremely confident that their work would show banding or other
artifacting if they did it in 8-bit. But they've never tried to do the same
things to 8-bit files that they do to their 16-bit files, so they can't
know for sure, and they refuse to accept the word of others who *have*
performed such tests.
The people who have doubted that there is a
night-and-day difference between 16-bit and 8-bit correction, or that
correcting in 8-bit is amateurish, have generally said they are willing to
be persuaded otherwise by examples, as I am. Some members of the other side
take a different tack. It is so obvious to them that their view is right
that not only do they require no proof of it, but they state outright that
they refuse to accept any proof that it is not. It has been remarked by
others that such a position is a religious rather than a rational one, and
I agree. The closest analogy I can think of would be to the person who says
that it is so obvious that the world is flat that it needs no proof, and
that any demonstrations that it is round will be ignored because they can't
possibly be right, since it is well known that the world is flat.
It actually gets better. Since that time, Bruce Fraser
has, incredibly, announced that direct comparison of 8-bit to 16-bit
editing is invalid, and conceded that side-by-side tests will show no
advantage for 16-bit. He writes, "I've demonstrated many times things
that work better in 16-bit than in 8 bit, but Dan has rejected these
because they don't fit his narrow criterion of doing exactly the same
things to a 16-bit and an 8-bit file, then comparing the results."
Separately, he clarifies, "The major problem with the methodology...is
that by making identical edits to the 8-bit and the 16-bit, you're throwing
out any benefit the extra bits may bring. They aren't useful unless you DO
SOMETHING with them!"
The extra bits may indeed be useful if you do
something, but there's no way of knowing for sure without trying to do the
something without them, and seeing if there's a significant difference. A
lot of people have done this. The answer they have unanimously come up with
is that there is not.
Dan Margulis
----------------------------
In Part III, a 16-bit advocate finally comes up with a
"real-world" example that turns out not to be so real-world, and
a consensus develops about bit-depth and choice of colorspace.
___________________________________________________________________________
Date: Mon, 31 Oct 2005 14:34:31 -0000
From: Dan Margulis
Subject: 16- and 8-bit: Summing Up (Part 3 of 4)
THE CONSENSUS.
In early September, Andrew Rodney posted his own
"real-world" example of 8-bit vs. 16-bit editing. As soon as it
appeared, it was dismissed both by me and by Lee Varis because it depended
on an exotic RGB definition, the ultra-wide gamut ProPhoto RGB, where the
perceived impact of tiny variations is much larger than in the RGB
definitions used by almost everyone. Andrew has known for at least five
years that I consider testing in such RGBs irrelevant--see "The
Attempts to Obfuscate" below.
Even if we were allow Andrew to sneak this image in,
it wouldn't show a 16-bit superiority, for two reasons. First, he
deliberately chose a zero-threshold sharpening setting for his image to
emphasize the differences between his 16-bit and 8-bit versions, when an
equivalent setting that required no additional steps was available. To back
up the premise that you have found a real-world difference, it's fair to
say "I would like to do the following or something equivalent, and I
find that there is no way to do so without getting an effect that
displeases me." That would have been the case with any of the four
examples cited in Part II, "Where 16-Bit Can Be Better". It is,
however, fatuous to say, as Andrew does, "Of many possible equivalent
settings, I have intentionally chosen the one that displeases me, and now
the test fails because I am displeased."
Second, the standard is "totally obvious to
anyone who looks," a "night and day difference." Anybody who
looked at the four examples cited above would, in my opinion, prefer the
16-bit versions. The only person known to have been shown printed versions
of Andrew's samples preferred the 8-bit version. Some areas of Andrew's
16-bit version are better than the 8-bit but larger areas are worse. I
think that a jury would rate the two versions as qualitatively equal, but
if they did not, I expect they would choose the 8-bit version as better
overall.
Andrew's edits were not particularly severe.
Conceivably more massive edits would have created a pair of images with
differences strong enough for people to have a clear preference for one as
opposed to the other. In view of my testing with B/W images, I think it's
likely that when there is an actual preference, people would tend to prefer
the version corrected in 8-bit. However, there would also be cases where
the smoothing effect of 16-bit editing would be preferable. But again, the
situation is not real-world. Anyone knowledgeable enough to take advantage
of the extra bits would be unlikely to be editing in such an RGB in the
first place. And nobody, not even Andrew and his partners, advocates making
big edits in an ultra-wide RGB in Photoshop proper. Any move big enough to
provoke a visible difference because of bit depth, they would urge making
in Camera Raw.
Lee, Andrew, and I all agreed that when the file was
put into Adobe RGB rather than ProPhoto RGB, and the same edits, including
the zero-threshold sharpening, were applied, there was no significant
difference between the 16-bit and 8-bit version. Whereupon Andrew stated,
"I will admit: If you work with a small(er)gamut
space, the need for high bit editing is reduced and possibly a non
issue."
I think that this face-saving admission is
acceptable--that for Adobe RGB and sRGB, the two spaces that we almost all
use--editing in 16-bit is no longer highly critical, no longer the
distinction between a professional and a recreational user, no longer a
matter of night-and-day difference, but rather "possibly a
non-issue."
In return for Andrew's concession, I cheerfully
respond as follows: "I categorically recommend against making major
edits to photographs in ultra-wide RGB spaces such as Wide Gamut RGB and
ProPhoto RGB when any reasonable alternative exists. If you nevertheless
insist upon doing so, you should take into account that under such
conditions the bit depth of the file may affect quality, so you should be
aware of the circumstances in which 8-bit editing may be superior as well
as those in which 16-bit may be."
THE ATTEMPTS TO OBFUSCATE.
Throughout these five years, the 16-bit advocates have
been trying to deflect attention from the basics, which are that they
bullied and berated users, calling them ignorant and unprofessional, all
because these users did not use an inconvenient workflow that has never
been shown to be of any use whatsoever.
The challenge is a simple one: to take any color
photograph that might conceivably be used in a professional setting,
operate on it in any way that a person, even an incompetent one, might try,
and demonstrate a clear superiority for 16-bit editing of that particular
image. I do not say that no such image could possibly exist. I do say that
we have not seen one yet, and a lot of people, including me, have tried
hard to find one.
The terms of the challenge are extraordinarily
permissive, and the 16-bit advocates have resorted to extraordinary
whitewashing to cover up the fact that they can't meet them. They keep
trying to sneak in obviously inapplicable stuff; when everyone laughs at it
they accuse me of "changing the rules" and click their tongues
and say, "see? No matter how hard we try, our stuff is always rejected
on a technicality! Clearly there's no image in the world that Dan would
ever accept!"
We saw this on the list last year. A member posted as
an example a Photoshop file consisting of no more than small blue area with
noise. He asserted that this was a picture of a "sky." There was
no way of verifying this as there were no clouds or other detail that might
identify it as a sky; no way of knowing that it wasn't computer-generated,
for that matter. I said that it is somewhat difficult to accept as a
"real-world photograph" something that an independent viewer
can't identify as a photograph at all, let alone what it's a photograph
*of*. Andrew Rodney immediately went ballistic, again accusing me of
changing the rules and stating that this proved that I would never accept
any image as being real-world.
Similarly, the "real-world" corrections
consisted of seven pairs of drastic actions, each designed to reverse the
other. Again, based on my assertion that there was not the slightest chance
that anyone would ever be stoned enough to *dream* of doing something as
crazy as that in the real world, Andrew again asserted that there was a
change in the rules.
In the 2005 ColorSync thread, I was again accused of
changing the rules because I should have made clear that
"photograph" and "computer-generated gradient" are two
different items and that I would not accept a gradient for testing. Also,
it was alleged that I changed the rules because my use of the words
"color photograph" did not make it sufficiently clear that
grayscale images were excluded.
Andrew's recent image saw more of the same
obfuscation. When I said that the behavior of exotic RGB definitions is
irrelevant, Andrew very piously said what he usually does when caught
cheating on such occasions: "I didn't expect this scene or any
additional scenes I can capture with this sub-$1000 camera to 'fit' your
criteria since once again, that seems to be a moving target. So I've come
to the conclusion that no matter what one does to try to show the advantage
of high-bit editing, it will fall on at least two deaf ears."
I've never accepted such files for testing. Andrew
Rodney knows this, because he complained about this condition in 2000, in a
thread that's archived on our site. He correctly pointed out, and I agreed,
that ultra-wide RGBs are more likely to show a difference. I replied
(remember, this is 2000): "To me, it's like asking how many angels can
dance on the head of a pin. Nobody to speak of is using wide gamut RGB.
There are a lot better uses of our time than to investigate the question of
whether it needs 16 bits. I *have* looked at the issue in Adobe RGB and
don't see that the extra bits are useful there. As I mentioned earlier I
would be anxious to see images from anyone that might contradict
this."
Further, in the 2005 ColorSync thread, I specifically
suggested that the ProPhoto space might sometimes show a difference between
16-bit and 8-bit editing if the edits were extreme enough. Seizing that
suggestion, Andrew created his example--and then feigned shock that I
wouldn't accept it, even though he had known for five years that I
wouldn't.
This type of behavior is only what we have come to
expect. As has already been pointed out, both Andrew and Bruce have tried
to deny that they said the wild things they did five years ago. And,
particularly, the intentional falsehoods on the Lindbloom site have been
called to Andrew's attention again and again on this list and elsewhere.
Yet he continues to pepper cyberspace with references to it. Every time he
does so, he shames himself.
WHAT THE EXTRA BITS REALLY DO.
Understanding statistical concepts is not easy even
for those with extensive training in the field. Casinos have lost hundreds
of millions of dollars to mathematically astute players because the
professors the casinos hired to advise them on probabilities failed to
comprehend certain statistical interactions. The New York Times polled
academics about a statistical-interpretation puzzle called the Monty Hall
Dilemma, and the majority of professors of mathematics gave the wrong
answer. Both of these examples are absolutely child's play in comparison to
trying to interpret what makes a picture look good.
Progress in our field has been hampered considerably
by "experts" who are so terrorized by histograms that they don't
understand that they feel they will sound more authoritative if they try to
terrorize their readers with them as well.
The calibrationism of the 1990s, the fear of applying
easy curves to images for fear of "irretrievable data loss", the
phobia of LAB, the insistence on applying profiles to things that obviously
can't be profiled, are all symptoms of the same disease. The confusion
between gradients and digital photography is one of the best examples yet.
A computer-generated gradient is a perfect file. Each
pixel gets its optimal value. Working in 16-bit gives extra precision, and
it's unconditionally better for gradients than 8-bit is. It's possible that
the two methods might give equivalent results. It's possible that the
16-bit might be better. But it's not possible that it would be worse. Also,
it's easy to come up with a demonstration that shows damage by editing such
files in 8-bit as opposed to 16-bit.
Now, contrast that to a digital capture. It is shot
through a lens that is not perfectly clean; through air that contains
particulates; it is captured by sensors whose performance varies with age
and which may not be clean themselves. The data is demosaiced by an
algorithm that we know nothing about. The vendors apply blurring to certain
areas, and generally apply contrast-
enhancing curves in certain others. Finally, the data
is written using an unseen method to a format that may contain its own
irregularities.
For all these reasons, the idea that even 128 levels
per channel, let alone 256, are being captured with any degree of accuracy
is very dubious. Yet if you open a digital file, up comes what looks like a
nice, smooth histogram. That is enough for the 16-bit advocates to put
their minds into neutral, prostrate themselves in front of it, and start
salaaming. They assume that because the histogram looks like that of a
gradient, the image will handle just like a gradient does. That's like
saying that because champagne tastes good, motor oil must, or that because
a helicopter can fly, it follows that a submarine can.
In real life, parts of what the camera captures are
much more reliable than others. The better the shooting conditions, the
more reliable the information. An underexposed image has less than 8 bits
of accurate information anywhere. A shot in studio conditions has *more*
than 8 bits of accurate information in the midrange of its green channel,
less throughout its blue channel and in the shadows of each channel, and
the rest is debatable.
CCD and CMOS devices, such as digital cameras, are
notoriously poor at extracting shadow detail. Every manufacturer tries to
fight noise by using some kind of blurring routine. Similarly, all digicams
have difficulties with noise in blue areas, such as skies, and result to
all kinds of demosaicing shenanigans to reduce it.
In these areas, the values that the camera spits out
are approximations only. In the darkest eighth of any channel, an 8-bit
file has 32 available tones. There is no digicam that I've ever seen that
is even remotely close to capturing these 32 tones reliably. An 8-bit file
allows for more precision than the camera has in shadow areas. In these
shadows, the 8-bit file therefore already consists of somewhat random
numbers. Making it a 16-bit file adds *totally* random numbers in these
areas. The histogram-worshipers are fond of using the term
"quantization error", but this merely shows their statistical
naivete. In contrast to a gradient, where the 16-bit file is mathematically
more reliable, the 8-bit file is mathematically purer than the 16-bit in
the shadows of a digital photograph. Since, in shadows, the extra bits are
random numbers, working with a 16-bit file simply adds soft noise in
transition areas. Skies behave similarly.
My apologies for lapsing into techspeak. A reminder
that this effect is so tiny as to be undetectable under real-world
circumstances. However, if the file is stressed sufficiently (as Andrew was
doing with his exotic RGB definition and his sharpening sabotage) then we
may be able to perceive it--and what we will perceive is that editing in
16-bit amounts to applying a blur to these areas--a highly sophisticated
blur that is hard to emulate by other means.
AFAIK, all of the claims about the images in which
16-bit supposedly is better involve either skies or shadows. Makes
sense--we often blur these areas separately no matter how many bits are
involved. The camera's algorithm blurs them already, but sometimes it isn't
enough.
Unfortunately, if you do enough to the 16-bit file
that its inherent blurring has an impact in shadows and in skies, it's
likely that it also may have an impact in areas where you *don't* want
blurring. That accounts for the preference one viewer had for the 8-bit
version of Andrew's file. In the shadow areas it was worse, but in the
foreground areas that were full of detail, it was better.
An even more striking example showed up in the last
two months, where another 16-bit advocate posted a demonstration at http:
//www.visual-
vacations.com/Photography/16_vs_8.htm
The image is one of a barn constructed of dark wood,
taken in normal daylight. The complaint is identical to Andrew's, namely
that correcting in 8-bit created undue noise in the shadows. The procedure
in this image is similar to Andrew's as well, but there are some
variations--especially in the result.
1) Both are definitely real-world images. This
demonstration is in sRGB, which is fine. Andrew's is in ProPhoto, which
disqualifies it right off the bat.
2) This image is intentionally sabotaged by acquiring
it in such a way that it enters Photoshop grossly dark, and is therefore
immediately disqualified, because in the real world, we do not sabotage
images on acquisition. Andrew's image, by contrast, was acquired fairly.
3) Both images now take Levels changes and, in
Andrew's case, Hue/
Saturation. Fine.
4) Now, the attempt to slip in the sabotage. Andrew
sharpens using a zero Threshold, which is clearly intended to bring out
noise and thus disqualifies it as a real-world move, since in the real
world one could achieve the same sharpening affect with a Threshold of 2 or
even 1. The other demonstration does this not just one better, but five
better: it tortures the image with four consecutive zero-threshold
sharpens, plus two applications of Shadow/Highlight, which is a form of
sharpening. Again, not real-world: in the real world, when we have two
alternatives, we choose the one that looks better, not worse. The purpose
of sharpening is to make the picture look more natural, not more noisy.
5) And the startling bottom line: while both exercises
show more undesirable noise in the shadows in the 8-bit versions, images
don't consist entirely of shadows. They need to be evaluated as a whole.
I'm familiar with how juries vote when given unidentified samples to choose
from. We have one report that with Andrew's image the 8-bit version was
chosen as better. I don't think that a jury would agree--I suspect the
verdict would be a tie. With the other, however, I have no doubt. The
shadows are worse, for sure, but a jury would pick the 8-bit version as
better overall, because the same blurring effect in 16-bit that helped the
shadows also blurred the main interest object of the image, the wood of the
barn.
If editing in 16-bit were truly "better",
there wouldn't be examples where editing in 8-bit appears to give superior
results--it couldn't, any more than editing an 8-bit gradient can possibly
produce a superior result to doing it in 16-bit. Also, it is very telling
that the examples being used always are either skies or shadows, and never
the third major category of image that we frequently have to blur:
fleshtones. I would suggest that the reason is that camera captures of
fleshtones are very much more reliable than either of skies or of shadows.
There is therefore less need to blur due to inadequacies of the original
capture. Even though the extra bit depth in fleshtones is probably real
information and not noise, it doesn't serve a useful purpose.
OTHER VIEWS.
I would like to close by quoting at some length two
other experts who have conducted their own tests.In the 2005 ColorSync
thread, Jeff Schewe emerged after I had left, and, unbothered by the
overwhelming evidence that there is no quality difference at all,
reiterated the same old silliness:
"I would argue that it [is] critical that ALL
MAJOR tone and color moves be done in 16 bit."
Jim Rich replied,
"As working in 16 bits to avoid all of these
Urban Legend pitfalls such as:
Ê The color being day and night different from 8
and 16 bit images.
That 8 bit files are fragile in terms of
color reproduction.
Or that you will get artifacts like
banding in gradients after a lot of image editing.
That 10% percent of images require 16
bits so they don't break.
Or that you need to work in 16 bit
because of device responses.
Let me say again on those points, I am
more than skeptical that you require 16 bits. My experiences with RGB
photos, CMYK print and Inkjet printing do not indicate that one should jump
to those conclusion. And we know that mileage will vary.
And until I see a test or some other
type of hard evidence that all of these problems really exist and are as
wide spread, as reported I can't buy into the notion that there is an
advantage to going to a full 16 bit workflow for a few renegade images.
It would be interesting if some one
would please show me a suite of images where the benefits of 16 bit images
jumps off the sheet and it is clear what is an 8 bits and what is 16 bit
file. Then I can really buy into the 16 bit way of life. "
It's hard to know what more could be asked. Jim admits
that it is impossible to prove that there will *never* be a case where
16-bit is beneficial, any more than one can prove that it would never be
beneficial for a righthanded person to work with the mouse on the left-hand
as opposed to the right-hand side. As indicated above, several 16-bit
advocates have said explicitly that demonstrations don't matter: it is so
obvious that 16-bit is the better way that it requires no proof.
Tim Grey, one of the rising stars in the Photoshop
field, wrote this in his September newsletter:
"In a general sense, I do indeed
agree with Dan. The way I explain this issue is that 16-bit editing
provides more 'headroom' for editing, ensuring you won't create
posterization in the final result. However, I've also tried to make it
clear that the vast majority of the time, you will never see any benefit at
all from optimizing your images in 16-bit. The simple fact is, even if you
strip out a significant number of tonal values in your image, you'll still
have an adequate range to produce what appears, to our eyes, to be
perfectly smooth gradations. I often do a demonstration in my workshops as
I posterize an image and ask students to tell me when they see
posterization. In general, I get down to about 32 levels per channel before
anything is visible, when there are 256 available in 8-bit per channel
images. So why do you need 16-bit? The short answer is, if your computer
resources can handle it, you might as well keep your images in 16-bit to
preserve as much detail as possible, especially considering that output
devices continue to improve, and at some point we may have output that
tests the limits of our 8-bit files, where you'd actually see a difference.
The only time 16-bit would make a
difference, for all practical purposes, is if you need to make extreme
adjustments to the image. If that's the case, you probably would throw the
image away, right? So 16-bit isn't a significant advantage to most of us.
Still something I recommend as a 'just in case', but not likely to provide
any practical benefit."
This is a sensible summary. Personally, I doubt that
there's a realistic possibility of benefit, but certainly you never know,
and if you care to speculate on it and have the disk space and computing
time to spare, nobody is criticizing. I believe it's more likely that some
weirdness in an output device will create a benefit than anything at the
high-end. Naturally, I also think that the most likely image to show an
advantage would be one consisting of a sky and little else, or an image
with almost no detail outside of deep shadows.
LESSONS FOR THE FUTURE.
From the perspective of people who purport to be
Photoshop authorities there is a lesson to be learned about giving
non-experts a hard time in public. You never know when it's going to turn
out that your views are mistaken, and then you look ridiculous.
Second, admitting that one has been wrong is not a
disgrace. Rather, I think it gives one more credibility. Image processing
is an infinitely complicated field. In every new edition of Professional
Photoshop I've pointed out areas where I was previously incorrect. In the
LAB book I talk about how I misunderstood some of the sharpening issues. In
at least two sections I pointed out images that I had corrected badly.
Third, we have to grant that the difference in results
between 8-bit and 16-bit editing is not trivial to comprehend, even by
people with a lot of color knowledge, even after a lot of testing. OTOH,
anybody who claims that converting to LAB causes "catastrophic
damage", that working on several adjustment layers creates better data
than applying the same corrections consecutively, or that there is a
"night and day difference, totally obvious to anyone who looks"
between 8-bit and 16-bit editing, is either too lazy or too incompetent, or
both, to do the ten minutes of testing that it would require to cast
serious doubts on these assertions.
Fourth, some sense of priorities has to be invoked.
Some of the people who have been most strongly in favor of 16-bit editing
don't know how to set highlights and shadows. Some actually edit not just
in Levels but using the master setting rather than channel-by-channel.
Under these circumstances the gain (if any) from 16-bit editing is about
#4,807 on the list of things that might help the image look better.
Remember: even if some exceptional image does show up that indicates an
advantage for 16-bit editing, in all probability the edge will be so minor
that it can easily be compensated for. But to this point, we haven't even
gotten that far.
Users aren't blameless either. The entire imaging
field is pervaded by purported experts peddling solutions, myself included.
Users tend to be properly skeptical of claims made by unknown vendors, but
a surprising number of people are buffaloed by histograms and claims of
mathematical precision. Before buying into anybody's pet theories, readers
should insist upon images, not a bunch of pseudoscientific gobbledygook. If
the speaker can't phrase the concept in a manner you can understand,
perhaps he can't understand it either.
Users would be well advised to steer clear of anyone
trying to justify conversion or color correction theories with gradients,
using terms like "quantization error", or trying to convince us
that a good-looking histogram is more important than a good-looking image.
Above all, when people come up with new nostrums, ask to see images, not
theories.
Finally, it should be remembered (as always) that
color knowledge is always evolving and that today's conventional wisdom is
likely to be considered wrong in ten years. I hope that the history of the
correction method that started out as "extremely critical", a
"night and day difference," the difference between a professional
and a recreational user," and became "possibly a non-issue"
will be an instructive one.
Dan Margulis
___________________________________________________________________________
Date: Mon, 31 Oct 2005 13:36:07 -0000
From: Dan Margulis
Subject: 16- and 8-bit: Summing Up (Part 4 of 4)
This is an appendix to my three posts on the 8-bit
vs.16-bit editing issue. Much of my post is critical of those who insist
that 16-bit editing is of paramount importance yet decline to show any
real-world images where there is any indication that editing in 16-bit is
better. I am posting here extensive excerpts of what they say in their own
defense as to why they do not.
Before turning it over to them, I have only one
remark. These individuals have argued that editing in 16-bit is
"extremely critical", that it is "the difference between
professional and recreational users of Photoshop", that doing so
results in "a night and day difference" that is "totally
obvious to anyone who looks".
If anything even remotely close to that were true, a
demonstration could be made of it almost instantaneously. For example, if I
had to argue for why gradients should be created and edited in 16-bit and
not 8-bit, I could create a convincing example showing why in less than ten
minutes. Both of the invididuals quoted here spend a great deal of
time in on-line groups. They have each, conservatively, spent tens of
hours, possibly more than a hundred apiece, explaining why they are too
busy to take these ten minutes.
Dan Margulis
********************
Note: Jeff Schewe, one of the posters here, often uses
ellipses (. . .) in his messages. Where these appear, they are in
Jeff's original and do not represent deletions. Some extraneous paragraphs
have been deleted from the beginnings and ends of messages, but there is no
editing of the text.
Jeff Schewe - 10:32pm Aug 5, 2001 Pacific
I have no interest in "Educating Dan".
That's his job. Dan is right about a lot and wrong about a lot. It's very
easy to see that substantial color & tone editing will eventually
result in data loss and banding. A lot of people have banding problems,
very few people know when and where that banding occurs, but it's due to
the fact that editing 8 bit files causes the banding.
If you start with an 8 bit file
and do tone and color adjustments, you lose levels. . .maybe only a few.
But, combined with data loss due to rounding errors running filters,
rounding errors due to layer blending, errors due to rebrushing all
accumulate to eventually produce enough loss of data from the orriginal
that eventually you get banding.
But. . .I have no interest in
debating Dan's position on the value of 16 bit editing. . .I prove him
wrong every day. If he wants to pay me to come teach him the value of 16
bit editing, I'll be happy to. . .but I'm certainly not going to do his job
for him for free <BG>.
He asked me to prove it to him. .
.I declined. If he wants to take one of my classes, he's welcome to. .
.I'll give him a discount. . .
User 1 - 11:53am Aug 9, 2001 Pacific
Jeff, I will address you here, but my point really
goes out to all. Please don't take it personally.
Regarding Margulis' challenge Jeff
writes: "He asked me to prove it to him. . .I declined. If he wants to
take one of my classes, he's welcome to. . .I'll give him a discount. . .
"
While I appreciate your humor
here, I am mystified as to why you (and others who feel as confident as you
in the matter) decline his challenge... Taking Dan's challenge would be to
our benefit, not Dan's
Here is a sampling of Dan's
challenge to you:
"…. I have for several years asked here and
elsewhere for those who advocate these methods if they might not be able to
provide me, say, two or three sample original high-bit images, with a
record of what moves were applied to them, so that I could verify that
there is a quality gain, however slight, in applying them to a 16-bit image
as opposed to an 8-bit one.
Since I have been making this
request, what I have received is a large number of histograms purporting to
prove that 16-bit is better, a large number of assurances that '16-bit has
worked better for me', and a large number of excuses for why the images in
which it has worked better are either unavailable or under NDA. As time has
gone on I have grown to suspect that perhaps the reason no one can supply
such images is that there are no such images to supply.
Can you help me out? If you or
anyone else can supply such example images and they really demonstrate the
merit of working in 16-bit, I'll be glad to let this list know and if the
differences are significant I'll print them in my column at a size large
enough for people to see. If you or anyone else has such images, just let
me know and I'll give you shipping instructions."
To my mind Dan is being very fair
in the matter, while those who decline his challenge prove his accusations
right, even if his assumptions about bit depth may be wrong. He is
certainly in the minority opinion on the subject, yet he is the only one to
my knowledge who is willing to back up his assertions with examples. Why
not back up your declarations to the degree that Dan is willing to back up
his?
Jeff Schewe - 08:16pm Aug 9, 2001 Pacific
I know Dan pretty well. . .I have ZERO interest in
being a subject of an upcoming article (I feel one coming from Dan) where
he can takes what Bruce or I may say about 16 bit and twist it around.
Suffice it to say that remaining under Dan's radar is far more comfortable
<BG>
In the old days (before learning
the value of editing in 16 bit) I suffered from slight to severe banding on
transparency and CMYK output. since switching to the 16 bit appraoch, I no
longer get banding. . .that's all the proof I need. I have no need to
"prove it to Dan". Sorry. . .I say what I say. . .I'm willing to
spend time teaching how to work in 16 bit (and do things the engineers
never dreamed of), but I have zero interest in proving anything to ol'
Danny boy. . .
I doubt Dan has ever seriously
manipulated an image or done a 6 element assembly. I seriously doubt that
Dan is after the most suprime high end quality. . .even if it's only
marginally better. . .but working in 16 bit is seriously a better habit
leading to better quality in the end. . .which is all I care about.
P.S. ask Dan about copyrights some
time. . .he's got his head firmly lodged up an oriface about that as well
<BG>.
User 1 - 09:53pm Aug 9, 2001 Pacific
Jeff,
Well, I hear ya,
but…….
I was just hoping that someone would prove the point
in the material world, rather than theoretically, or anecdotally. Somehow
this has become about Dan Margulis the man, rather than the point he makes.
It's ironic that although it's him against the world on this, he's the only
one (seemingly) willing to post evidence to support his claims. Shouldn't
the benefits of a 16-bit workflow be demonstrated anyway, regardless of the
fact that Dan has issued a challenge? Why, with all that is published about
PS in print and on the web, is such a presentation not already extant?
That's just weird.
User 2 - 08:00am Aug 10, 2001 Pacific (#37 of 52)
[Another 16-bit advocate] wrote: "What do you want someone to do?
Prepare a costly print run or film recorder output using both good image
preparation and bad image preparation so that you can be satisfied that we
know what we're talking about?"
Certainly not, that would be
unreasonable. That's why I asked if the difference could be seen on a
monitor, and you said at 100% magnification or higher it could.
Even so, I'm not asking that you supply images for
monitor viewing. Your time is valuable, and you have been very generous
with it on this forum.
OTOH, it seems that someone who
advocates a 16 bit work flow could supply a set of files for comparison.
Lots and lots and lots of time has been spent discussing this issue, here
and elsewhere, which is still unresolved in the minds of many people, and
it could so easily be put to bed by just showing us the comparisons.
Otherwise, as Rich said, it becomes tiring.
Jeff Schewe - 09:40am Aug 10, 2001 Pacific
Your points are taken. . .but proving anything is not
my job. When I do notes for classes or lectures, it takes on average about
8-12 hours to prepare them. I do have notes on editing in 16 bit on my web
site (I'm going to be changing the url this weekend for an upcomming class
but they will be in the site map), but those are just techniques for
working in 16 bit. To go through and offer scientific "proof" is
something that would require even more time-which I don't have.
------------------------------------------------------------------------
Jeff Schewe - 05:30pm Aug 12, 2001 Pacific
All this debate is pretty typical of good old Dan. You
notice he recently said that he has not taken the position that editing 16
bit is NOT better. . .only that he's never had anybody PROVE it to him.
I'm almost getting pissed off
enough by Dan's "positioning" that I might decide to "prove
it". But I don't have a great deal of time in the next week or so, so
it would have to wait a bit.
Date: Wed, 15 May 2002 22:37:56 -0500
From: Jeff Schewe
Subject: Re: 8- and 16-bit correction
I watched, with amusement, when Dan challenged anybody
to come up with a 16
bit image that could prove the benefits of editing in
16 bit over 8 bit. I
now understand there's a bounty out there of $100 if
somebody can prove that
edits in 16 bit vs edits in 8 bit is superior. . .
That's a waste of time (and believe me, $100 is no
incentive to me).
Fact is there is no image that can prove that one to
several edits in 16 bit
vs 8 bits is better. I've never advocated editing in
16 bit merely as a
method of improving a few tone/color corrections.
That's silly. The edits
done in the beginning of a tone/color correction does
not cause banding. It
does indeed "spend bits" and I advocate
spending your bits wisely. Where the
_REAL_ difference between 16 & 8 bit editing comes
is well down the road.
Well after your original edits.
Photoshop is pure math. . .everything is numbers.
Everything done in
Photoshop is the result of an algorithm. And believe
me, Photoshop's
precision is not infinite. Where the benefits of
original 16 bit editing
shows is down the road after doing corrections and
applying a filter or two
(or dozen). Add a dozen layers with various opacities
and blending modes and
maybe a layer effect or 2. Do a gradated adjustment
layer. Do any series of
extended retouching or manipulations that many image
artists do every day.
Then you'll find out that at some point in the
process, you've rounded
enough data and spent enough bits that the gradation
between point "A" and
"B" no longer has enough bits to produce a
smooth gradation of tone or
color. Guess what, you've got banding. And, guess what
else, you've just
proved that _STARTING_ with your initial tone/color
edits in 16 bits and
conserving your data bits to spend later in the
editing process allows you
to avoid the dreaded banding.
If you scan a chrome and do a slight to moderate curve
correction and
transform from RGB > CMYK, should you scan in 16
bits? Nope. If you do
slight to moderate to even substantial tone/color
edits and then plan on
assembling 1/2 dozen composited images with filters,
layer blending and
effects and maybe 20 hours in image manipulations,
will you benefit a _LOT_
from doing your original edits in 16 bits? You bet
your ass you will.
I started scanning in 16 bits because I ran into
constant problems of ending
up spending hours working on an image only to find
that at some point, a
tone gradation in an image banded. Once banded,
there's nothing you can do
to recover the lost spent data.
My point is that if you need maximum flexibility and
edit ability and you
don't want to worry about banding, start your creative
retouching in a
"perfect 8 bits/channel". That only comes
after doing initial tone/color
corrections in 16 bit.
Sure, you can use the scanner software to do
tone/color corrections in the
scanner's high bit depth and thus benefit from 10, 12,
14 or 16 bits of
data. The big problem I have with that workflow is
this. . .there ain't a
scanner on earth who's software allows you to do
"local" corrections of
tone/color. Scanners don't come with the ability to
put a lasso around an
area to adjust just that area. The other weak point of
scanner (or camera
software for that matter) is that a scanner preview
just purely isn't as
accurate as Photoshop to show exactly what the pixels
look like. Scanners
give "previews" but you don't see the full
resolution till _AFTER_ you've
applied the tone/color corrections during the scan. At
that point if you
touch it again you won't have a full 8 bit file. .
.you're spending the bits
on a wasted edit. I also think, and perhaps I'm
biased, that Photoshop is
the best "pixel viewing" application on the
planet. I know of no other app
that is as accurate in showing on screen, exactly how
a set of pixels will
look when you output. . .either photo or halftone
reproduction. So, if I
want the most accurate on screen representation of
just exactly how those
pixels will look reproduced, I'm just not interested
in using a scanner
software or camera capture software's interpretation
of those pixels.
Nope. . .Dan and the rest of you are welcome to
continue scanning in 8 bits
and doing whatever you want to do to your images. .
.but if you want
absolute total control over tone and color without the
risk of breaking the
image somewhere down the road. . .you better learn to
edit in 16 bits.
Yes, the tools are more limited and yes the files are
2x the size. . .so?
Ram is cheap and so are hard drives these days. I've
learned to edit in 16
bit to the point where even the Photoshop engineers
couldn't believe how far
one can go if you're determined. You can paint (using
history), you can
copy/paste (using clone between 2 16 bit documents),
you can use adjustment
layers (in an 8 bit duplicate and save out as a
setting), you can use color
range in 8 bit and transfer the 8 bit selection into
16 bits for
application. You can clone and heal and run enough
filters to do just about
anything you need to do to start off your imaging in
the "perfect 8 bits".
And yes, I'll stand by the line
"recreational" if you squander and waste
your data bits just getting an image tone/color
corrected in 8 bit. . .cause
if you do that, you're working with considerably less
than 8 bits/channel
and deserve the banding you are likely to incur.
Dan and others who claim 16 bit editing isn't better
than 8 bit editing for
routine scanning and corrections are correct. But, I'm
a photographer and
image manipulator. I choose to spend my data bits
wisely because because
what I do to images isn't routine. I manipulate the
heck out of images. I
choose to do all initial tone/color correction in 16
bit to avoid banding
down the road. And, personally I feel no compulsion to
prove anything to
anybody except my clients that pay me a lot of money.
Regards,
Jeff Schewe
16 bit advocate and proud of it. . .
-----------------------------
Date: Fri, 15 Apr 2005 14:36:12 -0700
From: bruce fraser
The major problem with the methodology (leaving aside
the minor ones) is that by making identical edits to the 8-bit and the
16-bit, you're throwing out any benefit the extra bits may bring. They
aren't useful unless you DO SOMETHING with them!
-----------------------------
Date: Sun, 17 Apr 2005 15:00:55 -0700
From: bruce fraser
Subject: Re: 16 bits == 15 bits in Photoshop?
At 12:39 PM -0400 4/17/05, Dan Margulis wrote:
>So, I ask if the following is a fair summary of
your position:
>
>1) Bruce states that the argument has never been
that identical edits applied
>to 8-bit and 16-bit files would produce better
results in the 16-bit version,
>but he argues that it is possible that they might.
>
>2) Bruce has not offered up any images that would
demonstrate such a
>superiority for 16-bit correction (as opposed to
identical edits
>applied to 8-bit),
>but he suggests that such images might exist.
>
>3) Bruce's comments on "night and day
difference" and "totally obvious to
>anyone who looks" are based on his experience
and perceptions; however,
he has
>never personally tested a series of corrections
done to a 16-bit
>file on a live
>image versus identical corrections done to an
8-bit one.
No, that's a when-did-you-stop-beating-your-wife
characterization.
My position is very straightforward.
I proved to my own satisfaction many (>10) years
ago that many of the problems I encountered with 8-bit files-posterizaton,
striped skies, exaggerated saturation accompanying contrast moves, and
unwanted hue shifts-largely disappeared when I edited (and converted to
output space, which is a big edit) in 16-bit instead.
I seem to be far from alone in having noticed this
phenomenon.
I quite sensibly decline to do all my work twice with
the goal of making half of it fail, and with the exception of beta-testing
procedures that need examples for bug reports, I don't make a habit of
saving the failures.
If someone wants to pay me my day rate to do so, I'm
quite certain that I can come up with real-world examples, but I decline to
donate my time to a foolish quest with whose premiss I'm in disagreement.
Anyone who sees no benefit to working in 16-bit space
simply shouldn't bother doing so. But they shouldn't come crying to me when
their images fall apart on output.
My personal opinion is that this is a manufactured
controversy-I decline to speculate on the motivation of those who have
manufactured it-and I'm utterly disinclined to waste my time arguing the
point when I have better things to do with it.
Date: Fri, 22 Apr 2005 01:29:17 -0500
From: Jeff Schewe
Subject: Re: 16 bits == 15 bits in Photoshop?
To: <colorsync-users@lists.apple.com
Jim Rich said:
It makes sense to capture everything as high bit
images.Everyone seems to
agree on this.
Save the high bit parent file in your archive.
ÊCreate derivative 8 bit files from the parent
file for production.
Use Adjustment layers.
If the 8 bit file breaks ( as they can in rare
cases), then go back to
the parent 16 bit file and use the previous
Adjustment Layers.
I agree with the capture in high bit.
But I would argue that it critical than ALL MAJOR tone
and color moves be
done in 16 bit. Ideally with Adjustment Layers for the
simple reason that
setting black & white points (unless you do it
accurately in say Camera Raw)
are the tip of the spear so to speak. Major gamma
adjustments are second,
such as when you stretch one area and compress another
area of the image's
histogram.
I would also argue that depending on the color space
you may be in while in
16 bit, it would be a good idea, if at all possible,
to do any major color
transforms while in 16 bit.
Bruce Fraser - 11:41pm Sep 16, 05 PST
If you want to work in 8
bit/channel mode, go ahead. But don't come crying to me if your file
breaks. That's really all I have to say on the subject.
OK. A little more.
Dan's "tests" are based
on applying exactly the same traditional levels-and-curves-based edits to
8-bit and 16-bit files, then looking for differences. Those will likely be
fairly hard to find. For the type of work Dan does, 8 bits/channel is
undoubtedly adequate, otherwise, being a rational person, he wouldn't do
it. Others may have different needs.
Bruce Fraser - 1:07pm Sep 19, 05 PST
I'd also suggest that you need to weigh
the consequences of working in 8-bit and finding you need 16 versus working
in 16-bit and finding you only need 8. My lack of clairvoyance is one of
the factors that leads me to work in 16-bit....
I've demonstrated many times things that
work better in 16-bit than in 8 bit, but Dan has rejected these because
they don't fit his narrow criterion of doing exactly the same things to a
16-bit and an 8-bit file, then comparing the results.
___________________________________________________________________________
Date: Mon, 31 Oct 2005 07:50:51 -0700
From: Andrew Rodney
Subject: 16- and 8-bit: Summing Up (Part 2 of 4)
On 10/31/05 6:33 AM, "dmargulisnj"
wrote:
1) If we apply massive edits to a grayscale file, the
difference between an
8-bit and a 16-bit correction may become noticeable.
Not even wanting to debate what 3massive2 implies nor
3noticeable2. Its clear there are two camps here that will never
agree. Like those who believe in evolution versus intelligent design, it1s
getting foolish to try move one group from one side to the other. If you
want to work in 8-bit, great. You are my friend. If you want to work in
high bit, again, you are welcome to do so. Drink whatever Kool-Aid pleases
you palette.
Dan seems somewhat hurt by what some have said with
respect to this debate. I will publicly apologize for anyone I happen to
have known, associated with, ate or drank wine with or even those who are
3business partners2 who may have said things that were hurtful in the
discussion of 8-bit versus 16-bit benefits. We should agree to disagree
since this debate is getting to the point where each side has what amounts
to religious beliefs.
We are getting to the point here that I1m actually
missing the old 3Mac is better than PC2 or 3Canon is better than Nikon2.
Such posts flood the net and like this set of debates seems impossible to
come to any conclusion.
Andrew Rodney
___________________________________________________________________________
Date: Mon, 31 Oct 2005 10:35:59 -0500
From: "Mark Segal"
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
Andrew,
If the two sides can't agree, it probably means that
Dan is right, because if the differences were so obvious that no one in
good faith could dismiss them, there would be no debate - and I don't think
it reasonable to accuse any one of operating in bad faith.
Regards,
Mark
___________________________________________________________________________
Date: Mon, 31 Oct 2005 10:29:50 -0500
From: "Mark Segal"
Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)
Dan,
I have a few quibbles with your summing-up.
Some digital cameras try to record 10-bit (1,024
possible values per channel,
a billion possible colors). Modern drum scanners try
for 12-bit (4,096 values,
69 billion possible colors). Whether these devices are
accurate to that level of
precision is very doubtful.
This point is not universally correct. For example,
the Canon 1Ds and the 1Ds Mark II produce 12 bit files. As for
scanners, my Minolta Dimage Scan Elite 5400 produces 16 bit files from
scans, according to its sepc sheet. You would need to prove Minolta's
published specs wrong before dimissing this spec as implausible.
"The question before us is not whether to capture
in 16-bit, store in 16-bit, or
output in 16-bit. The only issue is, first, is there
any advantage in *editing* files
in 16-bit rather than 8-bit, and if there is, it is so
enormous as to constitute a
"night and day difference" or to justify the
statement that anyone who does not
edit in 16-bit is a "recreational, rather than
professional" user of Photoshop."
This statement of the question is a bit exaggerated
relative to the merits of the choice. A difference does not need to be
"night and day" for justifying one option versus the other. As
long as there is a visible quality improvement, depending on one's
standards of excellence it could make sense to opt for the 16 bit choice.
The whole business about "recreational" versus
"professional" is vitriol - it has no operational signifigance -
the only thing that matters is whether the quality difference is visible in
a print, whatever it is.
"........they recommend, whether it's 16-bit
editing or wearing garlic around the neck
while writing curves, must be taken as gospel and that
they have no
responsibility to back up what they say.
"Nobody offered a single real-world image to show
this enormous difference. It was all histograms and gradients, gradients
and histograms."
In his latest material published on the web forums,
Andrew Rodney has presented files for downloading which he claims shows the
difference in actual printed results. I have not downloaded them, so I
can't confirm based on my own observation - but the fact is that at least
this one person has taken the trouble to offer real evidence in support of
a claim.
Remainder of the article: very thought-provoking.
Anyone with any doubts needs to do these tests for ourselves and see
whether our own minds' eyes agree with your findings!
Regards,
Mark
___________________________________________________________________________
Date: Mon, 31 Oct 2005 11:06:54 -0700
From: Andrew Rodney
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
On 10/31/05 8:35 AM, "Mark Segal"
wrote:
If the two sides can't agree, it probably means that
Dan is right, because if
the differences were so obvious that no one in good
faith could dismiss them,
there would be no debate - and I don't think it
reasonable to accuse any one
of operating in bad faith.
Not at all. With the files I uploaded and worked on,
it1s totally clear to ME that there1s an advantage. But then someone (no
names please) will say this doesn1t count because the encoding is in a wide
gamut space and no pro1s use this. Strawman arguments and simply not true.
As Dan posted, I fully admit that the effects are far less an issue with a
smaller working space. But I WANT to use ProPhoto RGB to fully contain the
colors I1ve captured. At this point, the discussion went OT about the
dangers (and there are some) of wide gamut spaces. There are advantages
too. But if you want to poo-poo this space or that edit, you can easily
mold an argument that attempts to illustrate that the other guys methods
are silly and as such there1s no advantages to his use of high bit data.
This is why I1m at the point that I feel, the
discussion is not worth continuing. At some point, no matter what
justification you have (on either side), someone else can mold the argument
in such a way as to derail the other guy.
Originally the debate was, no real world image shows
high bit advantage. Now it1s no real world image in this or that gamut
working space exhibits an advantage. Or, if you apply this or that edit,
your test is invalid. When you make up the rules as you go, it1s easy to
validate your side of the argument. Personally I find Bruce Lindblooms
analysis fair. Some others do not. In the end, it1s up to someone1s opinion
(and you know the old saying about opinions).
If everyone who ever subscribed to Dan's list believed
either his points or my points about high bit editing, it really wouldn1t
matter much in the big picture. It1s not going solve global warming or the
bird flu. I1d hope each person would test the waters for themselves but if
they1d rather read what an 3expert2 has to say and go that route, fine.
Dan says he1s never seen the benefits of high bit
editing on output (and I assume it1s to that fine halftone process he1s
using in his books). Jeff Schewe says he has. To each his own.
No one is operating in bad faith (although both sides
have supplied some bogus statements and measured the process with rubber
rulers). It1s now a religious belief system at play.
Andrew Rodney
___________________________________________________________________________
Date: Mon, 31 Oct 2005 18:25:21 -0400
From: Paco Marquez
Subject: Re: 16- and 8-bit: Summing Up (Part 4 of 4)
Hi Mr. Margulis,
I hope you take this request with the utmost respect
with which it is intended.
I would like your permission to forward these emails
to the Live Picture group. May I?
We are a small group of photographers who still make
use of this program and we are all over the world. As you may imagine, we
are all tech freaks and hungry for as much information as we can find and
learn from. This post of yours is so great that I am sure all would be
thrilled to be able to study it.
Of course, I will also phrase my request in a
different manner if I may. I would like the LP group to receive your
posts because your words are the lance that the emaciated caballero would
use to defeat those gigantic, not windmills of error, but giants of
confusion.
I know that you took a great deal of time putting it
all down on "paper" and that you have your own list so if you
deny my request I will understand and respect your wishes.
Respectfully,
Paco Márquez
661 McKinley St.
MIramar
San Juan, PR 00907
787-721-8554
787-587-7384 Cel.
http://www.pacomarquez.com
___________________________________________________________________________
Date: Tue, 1 Nov 2005 08:55:54 EST
From: Dan Margulis
Subject: Re: Permission to reuse
Paco writes,
I would like your permission to forward these emails
to the Live
Picture group. May I?
Yes, certainly. Since this is the first day of the
month, when we post list rules, I think it would be well to reemphasize the
point that this question refers to.
On-line discussion groups exist for the rapid
interchange of information that is useful to their members. I believe it is
widely accepted (and our rules state it explicitly) that those who
participate are throwing their ideas out to the public, and that their
comments can be freely re-used.
*Supplements* to the text posts--such as images that
are posted here or on other web-sites--are not covered by this. Anyone
wishing to re-use somebody's image, article, PDF, etc., should be going to
that person for permission first.
Dan Margulis
___________________________________________________________________________
Date: Tue, 1 Nov 2005 10:34:28 EST
From: Dan Margulis
Subject: Re: Matters of Opinion and Fact (was 16-bit)
Andrew Rodney writes,
Personally I find Bruce Lindblooms analysis fair. Some
others do
not. In the end, it1s up to someone1s opinion (and you
know the old saying
about opinions).
No, Andrew does not find Lindbloom's analysis fair--he
is well aware that it is bogus. Yes, many parts of this discussion have
been matters of opinion. But Lindbloom's page is based not on matters of
opinion, but of fact. Namely,
1) He asserts that I sabotage my test files by
converting them from 16-bit to 8-bit and back again to 16-bit before I test
them, which "makes it into a non-test."
2) He asserts "There is no accountability--Dan's
word is final. There has never been even a single case where the experiment
could be performed independently by anyone else to see if the same result
was obtained."
These two are *not* matters of opinion--they are
either true, or they are false. And they are the linchpins of Lindbloom's
page. The rest of what he says simply collapses without them.
Both of the above statements are categorically false.
They have been exposed on this list, and brought to Andrew's attention,
many times. Lindbloom knew that they were false when he posted them. Andrew
Rodney has posted many, many links to this page with full knowledge of its
falsity.
Dan Margulis
___________________________________________________________________________
Date: Tue, 1 Nov 2005 08:41:20 -0800
From: David Cardinal
Subject: RE: 16- and 8-bit: Summing Up (Part 1 of 4)
FWIW, when we have bench tested various current D-SLRs
(including the 1D, D1X and the D2X) the noise (combination of internal
& light scatter (aka lens flare)) is sufficiently large that the last
2-bits of precision are not typically meaningful.
The 10th bit is more controversial. Nikon reduces Raw
files to 9.5 bits (although they do gamma encoding at the same time) when
they do what they call "visually lossless" compression, but there
are many photographers who rely on detail in the highlights that the Nikon
compression flattens out (because of the gamma encoding) and find that the
compression scheme ruins their images and refuse to use it.
I don't think anyone has tried to see whether a 10-bit
linear encoding would actually be more useful than the 9.5 bit gamma
encoded version Nikon uses, but it'd be a good exercise for a grad student
someplace!
Modern zooms that we tested are also limited to about
10-stops (1000:1) total dynamic range in properly exposed scenes (due to
lens flare), which actually lines up pretty well with the sensors'
capabilities.
This is all getting trickier to measure since the very
newest cameras are doing more analog "pre-conditioning" of the
data before converting to digital so at some point the experiments are
measuring the circuitry, not the sensor or lens.--David Cardinal
http://www.cardinalphoto.com
http://www.nikondigital.org
___________________________________________________________________________
Date: Tue, 01 Nov 2005 12:19:05 -0500
From: "Iliah Borg"
Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)
That's true. I was not able to get anything more then
10 meaningful bits from any camera I tried. And I'm looking at raw data
directly.
Best regards,
ib
___________________________________________________________________________
Date: Tue, 01 Nov 2005 12:33:27 -0500
From: Tom Judd
Subject: Re: Enough Already! (was 16-bit)
Dan Margulis wrote:
No, Andrew does not find Lindbloom's analysis fair--
etc, etc, ad infinitum.
Dan, you obviously don't like these guys and the
feeling seems to be mutual. So please take your personal pissing
match offline and get this list back to something useful and informative.
ENOUGH ALREADY!!
___________________________________________________________________________
Date: Tue, 01 Nov 2005 12:03:24 -0600
From: Jeff Schewe
Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)
On 11/1/05 Dan wrote:
In the mid-1990s, Photoshop introduced limited support
for 16-bit files--
65,536 values per channel, 281 trillion possible
colors. There was no
intermediate level.
Well, you might as well get the math right
Dan...Photoshop has 15+1 bits accuracy, not 16 bits...so the total value of
bits in a "16 bit" channel is 0-32,768 for a total of 32,769
discrete levels, not "65,536 values per channel" as you stated.
As for the rest of the lengthy quotes of Andrew, Bruce
and myself-the "partnership" as you call it, well, I was worried
for a while that you may have caught me in a moment of weakness, stating
something that I would regret stating...I'm glad what you quoted me as
saying was accurate and I still stand by what I have said. Use your bits
wisely, waste them at your own risk.
So, refresh my memory...taking a nice well exposed
shot of a landscape-is it within your rules to run a gradient darkening of
the corners of the sky?
Cause it's pretty easy to break an 8 bit/channel image
where a 16 bit/channel image will not band. Ya see, using layer masks to
locally adjust tone and color is something that many if not most users of
Photoshop must do. And, high bit masks are much better than 8 bit
masks...of course, that may start yet another debate :~)
The thing some people forget is that when working in
16 bit (or high bit depth if you will-to remove the confusion about the
total levels being 15 bit + 1) is that when in high bit depth, not only are
your image pixels in high bit, but your layer masks and selection channels
are as well. So, the argument might be made that when in high bit depth,
not only are you conserving you image bits but receiving the benefit
of the higher bit depth of your masks-and even Dan seems to now admit that
higher bit depth of grayscale documents can provide an advantage...and yes,
to be accurat, "Selections" in the current Photoshop are still 8
bit, but masks and channels in high bit depth images are high bit.
As for the rest of Dan's 4 part post...I'm still
reading it...already got coffee up my nose from some of it (thanks for the
laughs Dan, other life events recently have not been so, humorous).
Regards,
Jeff Schewe
High Bit Depth Advocate (used to be 16 bit advocate)
___________________________________________________________________________
Date: Tue, 1 Nov 2005 13:03:28 -0600
From: Howard Smith
Subject: Re: Enough Already! (was 16-bit)
Tom, I think you may be confusing technical
disagreements with personal dislike. My own impression from reading
these posts for the past couple of years is that the professionals on here
do in fact have great respect for one another and undoubtedly go out
together in a friendly group when they attend national seminars etc.
Still, one can expect creative people to have strong differences of
opinion and to express them in sometimes heated arguments. As I once
commented on a bulletin board (one of those ancient communication forums
before the Internet), if you find my messages disagreeable, just skip them.
If you post any information here yourself, you may find others who
will rip into it without mercy. It's a learning experience. When
they're right, you've learned something. When they're dead wrong,
just laugh and go on to the next post. I've have seen instances of
completely uncalled for frontal assaults complete with name calling, but
not from professionals.
I might add that these guys don't need me defending
them, but I couldn't resist commenting on your post. Relax, Tom.
Post something controversial yourself if you like fireworks :)
Howard Smith
___________________________________________________________________________
Date: Tue, 01 Nov 2005 15:10:55 -0500
From: Denton Taylo
Subject: Re: Enough Already! (was 16-bit)
With all due respect, Dan owns the list (pls see his
monthly email prior). But if you don't like what Dan has to say, the delete
key is handy.
___________________________________________________________________________
Date: Tue, 01 Nov 2005 15:13:49 -0500
From: Denton Taylor
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Hi Jeff:
I would like to take Dan's pov here, which is that if
there are obvious differences, let's see them. Can you post an image with a
gradient as you say, broken and unbroken?
At 01:03 PM 11/1/2005, Jeff Schewe wrote:
So, refresh my memory...taking a nice well exposed
shot of a landscape-is it
within your rules to run a gradient darkening of the
corners of the sky?
Cause it's pretty easy to break an 8 bit/channel image
where a 16
bit/channel image will not band.
Regards,
Denton Taylor
photogallery at
www.dentontaylor.com
___________________________________________________________________________
Date: Tue, 1 Nov 2005 16:41:42 EST
From: Dan Margulis
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Jeff writes,
So, refresh my memory...taking a nice well exposed
shot of a landscape-is it
within your rules to run a gradient darkening of the
corners of the sky?
No. Computer-generated gradients have never been
permitted, as everyone agrees that they can benefit from the extra bits if
they are edited. "Recreational users" sometimes take their 8-bit
photographs into 16-bit if they need to introduce a gradient.
But, if you ever do get the time to show us an example
that doesn't have a computer-generated gradient, doesn't depend on an
exotic definition of RGB, and doesn't involve intentional efforts to
degrade the image, I'm sure a lot of people would be
interested.<g>
(thanks for the laughs Dan, other life events recently
have not been so,
humorous).
I am sorry to read the second half of this sentence.
There seems to be a great deal of that going around this year, which
suggests that there are many more appropriate things for us to get upset
over than the number of bits in an image.
Dan Margulis
___________________________________________________________________________
Date: Tue, 1 Nov 2005 15:15:23 -0800
(GMT-08:00)
From: Kevin Connery
Subject: Camera bit depths (Was: Re:16- and 8-bit:
Summing Up)
It seems to be very much camera-dependent. I've used a
number of Canon's "12-bit" dSLRs, and the amount of detail in the
darkest octave varies enormously. I photograph a lot of low key portraits,
with critical information in the darker areas / shadows, and the 1D Mark II
is much more effective than the 1D, 10D, or D60. How much that's due to
pre-processing in their DIGIC units I can't tell, but there's functional
detail that doesn't appear to be all noise. Those are almost exclusively
printed on RA-4 photo paper via Chromira or Lightjet, not to CMYK.
I've also done a little bit of retouching on product
photography (glassware) files from PhaseOne's P25 digital back, which
uses a supposedly 16-bit/channel chip. The handling of real-world
light gradients (photography was done on a shooting table, with colored
[gelled] back- and under-lighting) was much easier in 16-bit than 8-bit--it
didn't take much tone or color shifts to create visible banding in the glow
with 8-bit files. Adding noise eliminated it, but it also removed the
purity/sterility of the image as well. In LightJet transparencies, this was
very noticable; in the printed brochures, it was not--demonstrating again
that the output medium used also has an impact. Since these images were to
be printed on backlit film for use at tradeshows as well as printed CMYK
brochures, it was no longer a theoretical issue for this job--I had to redo
the work for the transparencies starting back from the originals and stay
in 16-bit. (Thank goodness for adjustment layers!)
Does anyone have measurements from the digital camera
backs from PhaseOne, Imacon/Hasselblad/Leaf? Are they functionally making
14- or 16-bit captures in real life as opposed to "technical
specifications"
Kevin Connery
___________________________________________________________________________
Date: Tue, 01 Nov 2005 17:52:32 -0500
From: Ric Cohn
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
On Nov 1, 2005, at 1:03 PM, Jeff Schewe wrote:
I was worried for a while that you may
have caught me in a moment of weakness, stating
something that I would
regret stating...I'm glad what you quoted me as saying
was accurate and I
still stand by what I have said. Use your bits wisely,
waste them at your
own risk.
Well, well we are getting to an agreement of sorts.
So, the argument might be made that when in high bit
depth, not only are you
conserving you image bits but receiving the benefit of
the higher bit depth
of your masks-and even Dan seems to now admit that
higher bit depth of
grayscale documents can provide an advantage...and
yes, to be accurat,
"Selections" in the current Photoshop are
still 8 bit, but masks and
channels in high bit depth images are high bit.
Yes, this is a new slant to the High Bit debate that
I've been hearing of late. Is this just a new way to cloud the issues and
justify the argument after the fact (think Iraq and Bush) or is it a valid
concern? It's always possible that people have seen real benefits when
working in 16 bit but misinterpreted the reason why!
I have seen instances where banding in masks can cause
problems and I've been aware that this is probably due to them being in 8
bits (although I've not done the tests to be sure the problem goes away in
16 bits). I have wondered whether there is any benefit to going to 16 bits
when making/using masks. OTOH I'm not sure whether just adding a small
amount of noise doesn't do as good a job. Dan did say that the kind of
"smoothness" (ramdomness, noise??) introduced by working in
16 bits is hard to duplicate.
Is it true that switching to 16 bits allows smoothness
in masks alpha channels that can't be compensated for in 8 bits? If this is
true then it would possibly be a reason to switch to 16 bit mode if doing
any kinds of masks- since you never know when these will band and whether
the banding will cause problems that are hard to see until it's too late to
get the supposed benefits of 16 bit. I could imagine a workflow where you
convert 8 bit images to 16 bit before creating masks.
Ric Cohn
I've looked and never seen a High Bit advantage (but I
keep looking)
___________________________________________________________________________
Date: Tue, 1 Nov 2005 21:15:19 -0200
From: Enio Leite
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Denton:
Let´s see if I got this straight:
Even a 16 bit INTEGER image only has 16 tones to
describe the darkest stop in a 12 stop image, while for the brightest stop,
32,768 tones are available. This is the opposite of human vision which is
more sensitive to shadow detail than to highlight detail. A 32 bit INTEGER
image provides more tones but has the same limitation of having a
disproportionate amount of tones for the highlights. 32 bit FLOATING POINT
images address this issue by making more efficient use of the 32 bits.
Instead of using 32 bits to describe 4,294,967,296 integer numbers, 23 bits
are allocated to a fraction, 8 bits to an exponent, and 1 bit to a sign, as
follows:
V = (-1)^S * 1.F * 2 ^ (E-127), whereby:
S = Sign, uses 1 bit and can have 2 possible values
F = Fraction, uses 23 bits and can have 8,388,608
possible values
E = Exponent, uses 8 bits and can have 256 possible
values
Practically speaking, this allows for an almost
infinite number of tones between level "0" and "1",
more than 8 million tones between level "1" and "2" and
128 tones between level "65,534" and "65,535", much
more in line with our human vision than a 32 bit integer image. Because of
the infinitesimally small numbers that can be stored, the 32 bit floating
point format allows to store a virtually unlimited dynamic range. In other
words, 32 bit floating point images can store a virtually unlimited dynamic
range in a relatively compact way with more detail in the shadows than in
the highlights and take up only twice the size of 16 bits per channel
images, saving memory and processing power. A higher accuracy format allows
for smoother dynamic and tonal range compression. This format is important
in the computer graphics industry (gaming and animation) and supported by
Adobe Photoshop CS2, right?
Best regards!
Enio Leite
www.escolafocus.net
___________________________________________________________________________
Date: Tue, 1 Nov 2005 16:15:13 -0800
From: David Cardinal
Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Enio--There is one important missing variable, which
is the gamma of the encoding. Gamma = 1 (linear) means that the lower stops
have many less values than the upper stops (as you've pointed out in your
post).
Higher gammas change this relationship. A high enough
gamma evens things out so each stop has a similar number of possible
values. That is one argument for gammas > 1 which do a better job of
reflecting the point you make--that the eye is sensitive to changes in
value, not as much to absolute values.
For example, by the time a (Raw) image is converted to
Adobe RGB or sRGB the numbers of levels has been evened out quite a bit by
the conversion.
The extra-confusing part is that almost all current
digicams have native linear sensors, but most working spaces &
photo-editing applications wind up in gamma-encoded spaces. So the
"bits" get re-allocated along the way. Raw processing is often
done in the linear gamma space and then photo editing in a working space
with a higher gamma.--David Cardinal
___________________________________________________________________________
Date: Tue, 01 Nov 2005 19:25:55 -0500
From: Denton Taylor
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
It all sounds wonderful in theory. All I'm saying,
like Dan, is let's see the photos where it makes a difference (and Dan has
already admitted that a sky gradient might be one of those instances).
At 06:15 PM 11/1/2005, you wrote:
A higher accuracy format allows for smoother dynamic
and tonal range compression. This format is important
in the computer
graphics industry (gaming and animation) and supported
by Adobe
Photoshop CS2, right?
Regards,
Denton Taylor
photogallery at
www.dentontaylor.com
___________________________________________________________________________
Date: Wed, 2 Nov 2005 01:57:09 +0100
From: Ben Richardson
Subject: Re: 16- and 8-bit: Summing Up
With thanks to Dan for his fine summation, to Andrew
for his swift replies, and to the creator of the example hosted on
visual-vacations (http://www.visual-vacations.com/Photography/16_vs_8.htm),
I have at last been able to confirm my personal opinion on this matter.
I suggest 16 bit colour correction should be treated
in much the same way as setting up levels and colour in scanner software
prior to scanning a new frame - as a means to obtaining a file of
*sufficient quality* for further work which may then be done as happily in
8 bit as in 16.
I would encourage everyone to visit the
visual-vacations example, and to download and try the test themselves, but
TWICE. Once as described, and once with one important change. Rather than
running the complete action first in 16 bit and then in 8 bit as the author
did, do the following:
Split the action into two separate actions, the first
with ONLY the initial, huge levels adjustment, and the second containing
the rest of the adjustments. Now run the levels part of the action on the
original 16 bit file, THEN duplicate the file, convert one copy to 8 bit
and run the rest of the action on both copies.
Now we see it exactly. There are clearly visible
differences between the two versions, but whether one is better or worse,
or would produce a better or worse print, has become a matter of opinion
similar to Dan's examples. The shadowed wood at left is definitely smoother
in the 16 bit, but somewhat more defined in the 8 bit, but doing the
initial levels in 16 bit has clearly given us sufficient quality to work in
either. (I do have to agree with Dan that the example is not exactly
"real-world", but I don't think the multiple zero-tolerance
sharpening is really the issue.)
If the actual 1Ds RAW file was available, you would
never in a million years process it as dark as the Tiff the author supplies
- you'd open up the shadows intelligently in Camera Raw or some other RAW
converter. BUT if that Tiff were all you had (a real-world possibility, at
least), clearly the big levels move only makes sense in 16 bit.
The original shadow area shows values between 0 and 1,
thus with such a huge move to recover detail, Photoshop's math can only
come up with the awful posterization seen in the original 8 bit example.
However, in 16 bit, those same 0-1 values represent a few dozen levels at
least, if my understanding of bit distribution is correct, more than enough
to give us some real shadow detail to work with later. Obviously, there
would be no advantage to simply crunching the numbers in 16 bit if the
original dark Tiff had been an 8 bit file: those tones would be gone for
good already, as we see in the author's version.
It is an extreme example, and somewhat unlikely in
professional work, but it leads me to this:
To Dan's advice about taking 16 bit scanner or camera
files if possible, and going to 8 bits in Photoshop, I would add: at least
get the image in the ballpark while you're still in 16. I believe this was
exactly Jeff Schewe's point when he wrote: "start your creative
retouching in a "perfect 8 bits/channel". That only comes after
doing initial tone/color corrections in 16 bit." This has actually
been my workflow for some time, but it's nice to have it validated.
Summary: 8 bits IS as good as 16, just as long as it's
a good 8 bits!
Many thanks again to all the contributors to this
remarkable resource,
Ben Richardson
___________________________________________________________________________
Date: Tue, 01 Nov 2005 20:22:26 -0500
From: "Iliah Borg"
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
11Mb file:
http://www.pochtar.com/kodak_224.jpg
demosaicing done in floating.
Best regards,
ib
___________________________________________________________________________
Date: Tue, 1 Nov 2005 18:03:39 -0800
From: "Paul D. DeRocco"
Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
What matters is the relationship between the size of
the steps and the magnitude of the noise. The noise out of any camera or
scanner will be many counts in amplitude in 16-bit mode, so having more
in-between counts buys you exactly nothing. Furthermore, the noise is
basically constant on a linear scale, so you get the same number of counts
of noise amplitude at the dark end as you do at the light end.
Linear fixedpoint therefore matches the resolution to
the noise level best. However, a gamma space of two-point-something is a
better match to the eye, and therefore more convenient for editing in. The
application of a gamma curve doesn't create much of a mismatch between the
resolution and the noise level at the two ends of the scale, whereas the
huge amount of low-end resolution you get from floating point is, well,
pointless.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Tue, 1 Nov 2005 18:10:51 -0800
From: Paul D. DeRocco
Subject: RE: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
From: Iliah Borg
11Mb file:
http://www.pochtar.com/kodak_224.jpg
demosaicing done in floating.
The point is what, exactly?
I don't know what camera that was taken with, but I've
seen other hi-res Kodak images that, like this one, are extremely sharp
because they don't use an antialiasing filter (or enough of one). And in
this image, I can see faint moire in the screen, and some slight color
artifacts on the left edge of the yellowish patch, which is about the only
significant color in the whole picture. I doubt that that has anything to
do with the interpolation being done in floating point, though.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Tue, 1 Nov 2005 18:44:07 -0800
From: Peter Figen
Subject: Re: Re: 16- and 8-bit: Summing Up
On Nov 1, 2005, at 4:57 PM, Ben Richardson wrote:
I would encourage everyone to visit the
visual-vacations example, and
to download and try the test themselves, but TWICE.
Once as
described, and once with one important change. Rather
than running
the complete action first in 16 bit and then in 8 bit
as the author
did, do the following:
There are a couple of problems with the example given
here. The first is that I don't know anyone who would process a severely
underexposed image using a linear gamma setting, a grossly overexposed one,
but not under. Second, these images were processed in what is arguably one
of the worst raw converters available. While this certainly shows 16 bpc to
be better when the person processing the original raw file screwed up,
there are enough questions about how the images were arrived at to merit
further testing. For instance, what would a normally processed gamma
corrected image look like, or images processed in alternative raw
converters. CaptureOne from PhaseOne, in my experience always produces
better shadow detail and lower noise than either Canon's own software
or Adobe Camera Raw. I would love to see the original raw file for
comparison.
For the record, virtually anytime I've seen
posterization, it was there on the 16 bit file too. Canon files, the ones
I'm most familiar with, seem to be extraordinarily sensitive to banding in
the bright yellow-green range and processing in 16 bpc does nothing to help
that. It seems to be an inherent limitation of the file structure that
causes it to break much sooner than an equivalent scanned image. This is
not an argument either way, just a not so casual observation that sometimes
things are not as simple as they first appear.
___________________________________________________________________________
Date: Tue, 1 Nov 2005 18:56:37 -0800
From: Lee Varis
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
On Nov 1, 2005, at 10:03 AM, Jeff Schewe wrote:
So, the
argument might be made that when in high bit depth,
not only are you
conserving you image bits but receiving the benefit of
the higher bit depth
of your masks-and even Dan seems to now admit that
higher bit depth of
grayscale documents can provide an advantage...and
yes, to be accurat,
"Selections" in the current Photoshop are
still 8 bit, but masks and
channels in high bit depth images are high bit.
Real high bit masks and alphas have a noticeable
advantage, unfortunately the high bit masks in Photoshop are only
calculated at 8 bit precision which is like having all the weight but none
of the benefit. I have done countless tests to try and validate the
advantage to high bit layer masks in photoshop and I have been unable to
see any visible benefit that wasn't duplicated by adding the .5% noise
generated in the conversion out of 16 bit. I really long for a 16 bit
"extract" mask but this is currently not possible.
Anyone with any experience working with Live Picture
will attest to the significantly smoother blends possible with real high
bit masks (all masks and "stencils" in Live Picture are
calculated at 12 bits) Very obvious on screen and in all kinds of outputs.
However, as we all know Live Picture is Dead Picture and so there is no
viable alternative to Photoshop for image compositing and retouching (many
who continue to use Live Picture will, of course, disagree)
Fortunately a modest amount of noise applied (then
fade using Overlay) to any 8 bit layer mask or alpha channel can solve even
somewhat severe cross fade banding in Layer masks. In all of my tests this
addition of noise is always more effective at reducing banding than doing
the layering/masking in 16 bits, flattening and converting to 8 bits. The
banding introduced by image adjustments over 16 bit masked areas IS
different than what you see in the 8 bit masks - mostly though the
"bands" are still here just in slightly different locations and
this can sometimes be seen as a benefit after a layered image has been
flattened depending on the "colors and tones" under (or through)
the banded mask. I'm not sure if some slight noise is added during the
flattening process but once the file is converted to 8 bits most of the 16
bit mask banding is obscured by the .5% noise added in the conversion.
Frankly... there might be some slight advantage that
isn't directly attributable to the noise introduced in the conversion to 8
bit but as I tend to use masks and alphas with huge multi-layered files I
tend to shy away from working any bigger than absolutely necessary. Believe
me large 16 bit layered files are extremely painful even with a dual G5
with RAID scratch disks.
Of course that is just my opinion - I could be wrong!
regards,
Lee Varis
http://www.varis.com
888-964-0024
___________________________________________________________________________
Date: Tue, 01 Nov 2005 21:59:21 -0500
From: Denton Taylor
Subject: Re: Re: 16- and 8-bit: Summing Up
A perfect example of 'why bother'?
Was that photo so hard that it couldn't be captured
appropriately the first time around?
Frankly, both of the 'corrected' images suck.
At 07:57 PM 11/1/2005, you wrote:
With thanks to Dan for his fine summation, to Andrew
for his swift
replies, and to the creator of the example hosted on
visual-vacations
(http:
//www.visual-vacations.com/Photography/16_vs_8.htm), I have at
last been able to confirm my personal opinion on this
matter.
Regards,
Denton Taylor
photogallery at
www.dentontaylor.com
___________________________________________________________________________
Date: Tue, 01 Nov 2005 21:25:42 -0500
From: "Iliah Borg"
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
The point is what, exactly?
The point is floating, and as such - is not
exact :)
Floating point interpolation is doable, and on all the
files I tried it produces less moire and artifacts then with methods (even
using same interpolation routines).
Apple seems to share this opinion, as I heard Aperture
(at least, partially) is also implemented in floating point.
Camera is SLR/c.
Best regards,
ib
___________________________________________________________________________
Date: Tue, 1 Nov 2005 21:02:32 -0700
From: Ron Kelly
Subject: Re: 16- and 8-bit: Summing Up (Part 1 of 4)
David Cardinal wrote:
the very newest cameras are
doing more analog "pre-conditioning" of the
data before converting to
digital
David:
What do you mean "pre-conditioning"?
Ron Kelly
___________________________________________________________________________
Date: Tue, 01 Nov 2005 22:29:22 -0600
From: Jeff Schewe
Subject: Re: 16- and 8-bit: Summing Up
Ben Richardson wrote:
Summary: 8 bits IS as good as 16, just as long as it's
a good 8 bits!
In a nut shell, yes...that is the essence of what I
have been advocating since I discovered the benefits of doing all major
tone/color corrections in 16, er, high bit depth...including not just
global (think scanner or Camera Raw) but also local through a mask or
selection.
Regards,
Jeff Schewe
___________________________________________________________________________
Date: Tue, 1 Nov 2005 21:29:49 -0700
From: Ron Kelly
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Ric:
What circumstances cause banding in masks? I use masks
as much as the next guy (I assume) but I'm not aware of any banding issues.
I must be missing something here.
For what it's worth I have only had one image that I
can think of that had a banding problem. Yes, that's one image EVER. It was
a scan of a very high contrast image with a very light to medium dark sky,
from a scanner. It had banding in it when I opened the file, before I did
any editing to it. I rescanned it to no avail and finally had to select the
sky and mess with it directly by painting and adding noise.
For the last three years or so I have been shooting
digitally and I've not had ANY banding problems at all. My regular work is
preparing files for off-set and ink-jet.
I feel that I probably do some pretty severe curving
for things like enhancing shadow contrast, for example, where I'm pulling
on the curves till their near vertical at times. While I do have many
challenges in this discipline, banding or unwanted posterization has not
been even a small problem.
The discussion of avoiding banding by editing in 16
bit is puzzling to me because it's a solution to a problem that I don't
have.
Maybe I'm just lucky going around in my bubble of
ignorance. Are others experiencing a lot of banding problems? How common is
this?
I can't recall seeing this topic in too many posts on
this forum but I'm sure there's a way to find out.
Ron Kelly
___________________________________________________________________________
Date: Tue, 1 Nov 2005 21:49:44 -0800
From: David Cardinal
Subject: RE: 16- and 8-bit: Summing Up (Part 1 of 4)
David:
What do you mean "pre-conditioning"?
Ron Kelly
That is what Nikon at least is using to describe the
analog processing they do in their newest models like the D2X before the
D/A conversion. They are not real open about exactly what they are doing
during that phase, but it includes some type of color processing (in
particular per channel amplifiers to help with white balance while not
hurting color). Canon does some pre-processing as well, although I don't
know if they use the term pre-conditioning for it.--David Cardinal
___________________________________________________________________________
Date: Wed, 2 Nov 2005 04:15:46 -0500
From: "Mark Segal"
Subject: Fw: 16- and 8-bit: Summing Up (Part 2 of 4)
If my memory serves me correctly, the argument about 8
vs 16 bit image editing developed before there was an issue about the
merits of working in - say - ProPhoto versus Adobe RGB98. These are
separate issues in time and in principle, eventhough the latter may impact
the former. Hence it is not appropriate to cite this as an example of
shifting ground or changing the rules. Dan is on record that based on his
experience there are substantial risks and little perceptible merits to
working in ProPhoto. He, therefore, is at least being consistent in pairing
his technical preference for 8 bit editing with his technical preference
for RGB98-type colour gamuts. If the argument has now
"progressed" or been focused on the merits of 8 versus 16 bit
editing in wide-gamut colour spaces, perhaps there is still more to say
from a technical and objective perspective - not a matter of religion.
Mark Segal
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:20:42 EST
From: Dan Margulis
Subject: Re: rationale for monitor calibration
Ray Van Dusen writes,
On one of our dedicated printer station LCD monitors,
I visually compared the
"eyeballed" created profile (with its lower
brightness slider
setting) to the Optix/X-Rite created profile (with its
higher
brightness slider setting) and they appeared
surprisingly close at
least by eye (there was a slight color cast to the
eyeballed
profile). They produced "similar"
in-the-ballpark prints.
Before getting all tied up with concepts like
"accuracy", you need to remember what the purpose of calibrating
a monitor is. You are trying to get a good idea of what the final output
will look like. Assuming that the final output isn't defective in some way,
the goal is that when you see it, you shouldn't feel that you would have
done the job differently if you hadn't trusted what you saw on the screen.
If you have that annoying feeling from time to time, then you probably need
to invest some time in calibrating. But if you *never* have that feeling,
then you have already achieved 100% of the goal. "Improving" the
monitor's "accuracy" does you no further good.
Are software/hardware produced profiles merely only
slightly more accurate
(in terms of WYSIWYG) than eyeball produced ones?
It depends on whose eyeball is involved. The Apple
routines are quite powerful. Somebody with a lot of experience should be
able to generate a *more* accurate profile than hardware can. But not that
many people have such experience.
If you're dealing with students, teaching them how to
calibrate a monitor by eye would be a highly useful exercise because it
serves as a surrogate for many other types of color problems that they'll
face in the future. Get yourself a suite of half a dozen images for which
you have reliable output. Don't let anybody touch the monitor's hardware
settings, but have each student sit down for 10-15 minutes and try to make
as nice a profile as he can. When he's done, save it out, reset the monitor
to its original profile, and let the next student have at it. When enough
people have tried it, get them all together, load their profiles one after
another, evaluate the test images, and decide who did the best job, and
why.
Dan Margulis
___________________________________________________________________________
Date: Wed, 02 Nov 2005 06:13:07 -0700
From: Andrew Rodney
Subject: 16- and 8-bit: Summing Up
On 11/2/05 2:15 AM, "Mark Segal" wrote:
If my memory serves me correctly, the argument about 8
vs 16 bit image editing
developed before there was an issue about the merits
of working in - say -
ProPhoto versus Adobe RGB98.
Well both have been around and available for users of
Photoshop the same time. The first incarnation of Adobe RGB (1998) was
SMPTE-240M in Photoshop 5 and later named Adobe RGB (1998). ProPhoto was
introduced around the same time (1998/1999) and perhaps earlier as ROMM
RGB. Wide Gamut RGB was installed the same date and time as Adobe RGB
(1998). It 3suffers2 if you have to use that term (which isn1t technically
correct) the same issues in 8 versus high bit as ProPhoto RGB. Lastly, LAB
has a heck of a lot of colors outside either ProPhoto RGB or Wide gamut RGB
and yet, it doesn1t suffer the criticism although I see the same noise
issues with my digital images uploaded using LAB as I do with ProPhoto RGB.
So no, I don1t agree there has been a shift, only a means to ignore the man
behind the curtain.
These are separate issues in time and in principle,
eventhough the latter may
impact the former.
In principle, maybe but not in time. LAB predates
ProPhoto and Adobe RGB (1998) by a long shot.
Hence it is not appropriate to cite this as an example
of shifting ground or
changing the rules. Dan is on record that based on his
experience there are
substantial risks and little perceptible merits to
working in ProPhoto.
A record not agreed upon by many.
He, therefore, is at least being consistent in pairing
his technical
preference for 8 bit editing with his technical
preference for RGB98-type
colour gamuts.
Nope.
If the argument has now "progressed" or been
focused on the merits of 8
versus 16 bit editing in wide-gamut colour spaces,
perhaps there is still more
to say from a technical and objective perspective -
not a matter of religion.
Well I agree that the obvious benefits of editing in
high bit with the examples I posted have a technical objective. The
religious aspect is how this has been ignored.
Andrew Rodney
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:20:04 EST
From: Dan Margulis
Subject: Re: Re: 16- and 8-bit: Summing Up
Ben Richardson writes,
I suggest 16 bit colour correction should be treated
in much the same way
as setting up levels and colour in scanner software
prior to scanning a new frame - as a means to obtaining a file of
*sufficient quality*
for further work which may then be done as happily in
8 bit as in 16.
Remembering that there is to date no evidence that
16-bit correction is useful even on files of insufficient quality, to some
extent this is the Tim Grey position. Anyone who is working on files that
require such massive editing that they would provoke a visible difference
between 8-bit and 16-bit editing has many, many more serious problems to
worry about than bit depth.
In any event, anybody knowledgeable enough to get a
benefit (if any) from editing in 16-bit is not going to be making a big
levels move to try to correct a grossly bad image. If there was a
major color cast it would be attacked by blending good channels into bad
ones, and if there was an exposure issue it would be treated by assigning a
false profile. Either way, the image would no longer be bad by the time the
curves came out.
(I do have to agree with Dan that the example is
not exactly "real-world",
but I don't think the multiple zero-tolerance
sharpening is really the
issue.) If the actual 1Ds RAW file was available, you
would never in a million
years process it as dark as the Tiff the author
supplies - you'd open up the
shadows intelligently in Camera Raw or some other
RAW converter. BUT if that Tiff
were all you had (a real-world possibility, at
least), clearly the big
levels move only makes sense in 16 bit.
No. The original as processed does look a lot like a
seriously underexposed image, such as one might encounter in real life. But
assuming that how this sabotaged original reacts to editing would predict
how a real-world image would is just like assuming that what happens with a
computer gradient is going to happen with a real image. In both cases
you're dealing with data that's far, far more accurate than what you would
get in real life.
This example is an excellent photograph that was
sabotaged by smashing it into a very small range. What's found in that
limited range is more pristine even than a normally shot, normally exposed
image--let alone a badly exposed original.
If the image were that dark because of incompetent
photography as opposed to sabotage during acquisition, it would be so full
of noise that any difference between 16-bit and 8-bit editing would be like
a drop of water in a river. When digicams are starved for light you get a
higher percentage of garbage even than if the scene were shot on film.
Even accepting for the sake of argument that editing
this particular image in 16-bit gets a better result, which I don't accept,
all it proves is that images that someone has intentionally sabotaged
should perhaps be edited in 16-bit.
In the real world, we need to know how to correct
underexposed images. We need to know how to help out images where somebody
else has made a good faith effort to correct but has done a poor job. But
we do not need to know how to correct images that somebody has deliberately
tried to degrade. That just doesn't happen in the real world.
Dan Margulis
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:20:54 EST
From: Dan Margulis
Subject: Re: Camera bit depths (Was: Re:16- and 8-bit:
Summing Up)
Kevin Connery writes,
I've also done a little bit of retouching on product
photography
(glassware) files from PhaseOne's P25 digital
back, which uses a supposedly
16-bit/channel chip. The handling of real-world
light gradients (photography was done on
a shooting table, with colored [gelled] back- and
under-lighting) was much
easier in 16-bit than 8-bit--it didn't take much tone
or color shifts to create
visible banding in the glow with 8-bit files.
Then it sounds like you might be the guy who can come
up with the elusive demonstration of the real-world file where real-world
corrections work better in 16-bit than in 8-bit. Are these files, with a
record of the steps that were done to them, available? Can they be released
for publication?
Dan Margulis
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:46:02 -0500
(EST)
From: MARK SEGAL
Subject: Re: 16- and 8-bit: Summing Up
Andrew,
Let us not misunderstand precisely what I said: I did
not say the wide-gamut colour spaces post-dated the 8 versus 16 bit
argument. I said the arguments about the colour spaces post-dated the
arguments about bit depth.
OK, Dan's views about the risks of using wide-gamut
colour spaces may not be shared by many, but from my experience they cannot
be dismissed either. I (and it turns out, others) have encountered
situations where ProPhoto was playing havoc with colour and detail
rendition (specifically in what I have referred to elsewhere as
"Chinatown red". By moving these particular images back from
ProPhoto to RGB98 I was able to rescue detail and better simulate the red
tones in the prints. In these cases I was using 16-bit files. Bottom line:
I too prefer to use a wide-gamut editing space because there are colours
the Epson 4000/4800 printers "see" which ARGB98 does not, but I
do have emprical evidence that one needs to be pragmatic about this choice.
Now, if you seem to be successfully demonstrating with
"normal RGB colour images" that "normal kind of edits"
in wide gamut colour spaces systematically produce visibly superior quality
prints in 16 bit mode compared with 8 bit mode, this is evidence I think
Dan should examine and comment on.
Mark Segal
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:45:32 -0800
From: Peter Figen
Subject: Re: banding in masks
On Nov 1, 2005, at 8:29 PM, Ron Kelly wrote:
What circumstances cause banding in masks? I use masks
as much as the
next guy (I assume) but I'm not aware of any banding
issues. I must
be missing something here.
I have often had banding in very subtle layer mask
gradations that were painted in at opacities under 10 percent in near white
areas of the image. It was obvious that there were too few levels spread
across too great a distance. These instances were before layer masks were
available in 16 bpc files, and I haven't had a similar type of masking
recently, so I don't know if working in 16 bpc would make a difference.
___________________________________________________________________________
Date: Wed, 2 Nov 2005 08:49:17 -0800
From: David Cardinal
Subject: RE: Re: 16- and 8-bit: Summing Up
If the image were that dark because of incompetent
photography as opposed to sabotage during acquisition,
it
would be so full of noise that any difference between
16-bit
and 8-bit editing would be like a drop of water in a
river.
When digicams are starved for light you get a higher
percentage of garbage even than if the scene were shot
on film.
Amen to that. Over the years I have had a handful of
"once in a lifetime" images that were badly
under-exposed--normally due to unavoidable issues & lack of prep time
(endangered critter pops up suddenly when you're getting set up to shoot
something completely different, etc.) and in each case noise has been the
limiting factor in correction. The new noise processors are pretty good but
there is a limit to what they can do after the fact. In those cases 8-bit
has been the least of my worries!--David Cardinal
___________________________________________________________________________
Date: Wed, 2 Nov 2005 15:16:22 -0800
(PST)
From: John Opitz
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
In fairness, the demand for images placed the
advocates in a difficult position.
There is no reason to doubt that they actually
believed their original wild claims were true
By the time they learned that there
was serious doubt that there was any 16-bit benefit at
all, let alone a night and day difference, they had
already begun to promote
seminars about the benefits of the 16-bit workflow.
Furthermore, Adobe,
largely at their suggestion, had begun to add 16-bit
capabilities to
Photoshop which were being heavily hyped. As many of
these advocates take
money or other support from Adobe, it would have been
exceedingly
awkward if they had abandoned the
you-are-not-a-professional-if-you-don't-use-16-bit
line.
I’ll tell ya’. You have hoots-fa.
You have spunk. And those that do push products, ideas, most never state
that they are a paid endorser, whether it’s for God and his almighty
dollar (or other currency exchange) or a car, yacht or whatever is brought
to the table, beside the main course. As well as capitalizing on what
you’re mentioning. How is one to know that his/her endorsing is not
being biased based on these benevolent (sorry this is the only word I can
come up because if I use “paid”,”pay” this can be
interrupted as a kick-back) offerings by said company involved? It would be
hard for the endorser to say the product is not what it is hyped to be.
Officially or unofficially. They should have been looking at testing,
instead of looking at… chasing rainbows for that pot of gold. If this
was to happen? Coming forward about it, that is. A thing would happen, what
I call: “Truth or Consequences”. His/her credibility is at
stake and a lot more at that. I would think that people all over the world
would believe this is a common practice, though. But, you know how all that
works. Unlike you, you write, speak with no deceit about things. You say,
do; write about things that others would never dream of doing.
You brought up a very good point… I never lost
the faith…. Just like a father to his own son, you’ve been
there through the worse and best of times. When dark, stormy clouds would
hover over an image-editing program (version 5/5.5, 7) we know so well.
Like a concerned parent, you warned of the downfalls. Even if the advice
fell on deaf ears. You’ve been there to lift one up like a savior out
from the drowning flood that came upon it. While non-believers belittled
some, for not seeing that the clouds would just pass. Sadly, their fate was
not as fortunate. You gave strength and showed how to battle fears of
utilizing other color spaces for editing images that would be better than
editing in a single color space. You showed that conversions were not as
frightening, as a child would have phobias about falling asleep in the
night and having nightmares. To the Father of the False Profile. Your
guidance on how color management can be used for color correcting by
assigning, convert>assign a simple profile. You showed how discipline,
speed, agility like a martial arts master to his students who uses his own
inner physical strength to do things some would think is impossible without
the use of man-made weapons (plug-ins), The Mysticism of Channel Blending.
Your philosophies on working by the numbers approach, eliminating
impossible colors, using common sense. To the way you lit the guided
path for one. I will not thank you. For I would rather go to one knee and
bow, to honor you. For the one that has snatched the pebble from your hand,
telling you it is time for one to leave. May your wisdom and teachings,
writings be the guiding light to a new dimension in color correction. These
things will never be forgotten. Don’t ever sell out. You’re the
last and the few of a rare breed. A toast to you. From my very good
friend, Jack Daniels’ and myself.
John Opitz
___________________________________________________________________________
Date: Wed, 02 Nov 2005 19:09:26 -0500
From: Ric Cohn
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
On Nov 1, 2005, at 11:29 PM, Ron Kelly wrote:
The discussion of avoiding banding by editing in 16
bit is puzzling
to me because it's a solution to a problem that I
don't have.
Ron- If I create a mask from a layer or a gradient and
then apply curves to it, I will frequently see banding if I look at the
alpha channel. This isn't surprising as I've essentially been making edits
to a computer generated 8 bit B&W image. Whether this banding is a
problem is very image/adjustment specific. The banding in the resulting
layer mask has to be severe enough and the layer it's applied to has to be
sensitive enough to show it. I work on a wide variety of images and for
most this does not create a problem.
I also believe that as (non-drum) scanners and digital
captures improve this becomes less of a problem- not because the masks are
any less banded, but because the images have better channels which are less
subject to damage from adjustments. I've been saying for years that what
matters is whether you have good bits to begin with! I wonder if the
benefits the 16 bit advocates "see" isn't really the coincidence
that captures greatly improved at the same time that 16 bit editing become
feasible? It's true that I've had much less trouble with banding, etc. than
I did in the past. I've attributed it to better working methods and better
adjustments, but maybe I'm just as wrong about the reasons for my better
work <g>.
Ric Cohn
___________________________________________________________________________
Date: Wed, 2 Nov 2005 21:24:17 -0800
From: J Walton
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of
4)
John,
Ummm....
I don't think Jack Daniels has been a very good friend
to you. Where are you coming from with this post?
J
___________________________________________________________________________
Date: Wed, 2 Nov 2005 23:11:25 -0700
From: Ron Kelly
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
On 2-Nov-05, at 5:09 PM, Ric Cohn wrote:
If I create a mask from a layer or a gradient and then
apply
curves to it, I will frequently see banding if I look
at the alpha
channel.
Ahh . . . now I'm getting somewhere. Why would I want
to curve the mask? Is the mask on a layer curved along with the image data
on said layer?
If not, do you copy the mask to a grayscale document
and curve is there prior to pasting it back into the original layer?
Ron Kelly
___________________________________________________________________________
Date: Thu, 03 Nov 2005 10:16:04 -0600
From: Jeff Schewe
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
John O wrote:
And those that do push products, ideas, most never
state that they are a paid
endorser, whether it1s for God and his almighty dollar
(or other currency
exchange) or a car, yacht or whatever is brought to
the table, beside the main
course.
Mr. Margulis certainly _SHOULD_ know better than imply
a level of unhealthy impropriety between the relationships of certain
Photoshop testers and Adobe.
I have been an unpaid volunteer alpha tester for
Photoshop since version 4.0. I can't count the hundreds1 or perhaps
thousands of hours I've personally spent trying to work towards improving
Photoshop for the simple motive of getting a better tool for my own work.
For Mr. Margulis or any of the other denizens of this
domain to think that my opinions and philosophies are somehow effected by
the fact I get to work, for free, improving Photoshop is pretty silly. The
net sum I've received is a copy of each Photoshop version I've tested...so
let's examine that. Several hundred hours of testing vs a single version of
Photoshop? I would be lucky to be "making" a fraction of minimum
wage...
I will admit that I have been paid by Adobe to write
articles to be posted on Adobe's web site. But I see nothing about getting
paid to write in the least bit unsavory. I have also occasionally been
sponsored to speak and teach about Photoshop by Adobe. But if you think the
relatively paltry amounts would do anything to alter my opinions, then you
simply have never met me.
Mr. Margulis has met me. I'm pretty sure he knows the
truth, even if his rather slimy attempt to discredit my/our reputations
give insinuations to the contrary...
The statement: "As many of these advocates take
money or other support from Adobe, it would have been exceedingly awkward
if they had abandoned the
you-are-not-a-professional-if-you-don't-use-16-bit line." is pure Dan
Margulis bullshit, and he knows it...don't you Dan?
Perhaps Mr. Margulis should revise and amend his
statements...if nothing else, be _VERY_ clear exactly _WHO_ he is talking
about.
As for getting paid to endorse Photoshop, sorry,
that's never happened.
Regards,
Jeff Schewe
___________________________________________________________________________
Date: Thu, 3 Nov 2005 07:24:59 -0800
(PST)
From: John Opitz
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
Good Morning, Mr. Walton,
<< I don't think Jack Daniels has been a very
good
friend to you.
Yes, true. But that was Saturday, October 28(pool
party). When he turned into the “Blood of Satan”. When the
Jagermeister and Goldschlager dropped in and corrupted him. When these guys
get together you have to make sure you have the Roman Rituals handy.
Preferably, book marked. You know what its like to go through the Roman
Rituals? Unless you’re a priest, you can down a six-pack before you
find what you’re looking for. And don’t forget the holy water.
You don’t want to get into a situation like I did. I had to start
blessing my pool to use water from that. My intention was to have
“The Three Wiseman” just drop in., Jack Daniels, Jameson and
Jose Cuervo.
Where are you coming from with this post?
Gods’ Country, Texas.
On a serious note. Because of the negative waves in
the past from this topic. I felt it was due, positive waves. To appreciate
his time donated to this list. What he has done for the P.S.community.
As well as others on this list that contribute heavily to it. And I
don’t have to list their names. You see them all the time.
Hey…I thought I was on a roll with the poetic way I typed. I was
serious about it. What can I tell you, I won’t give up my day job?
But, you have to cut me some slack. I’m not an author…. Or a
writer either. I got my spelling right! I have to stop now because, I owe!
I owe!, off to work I go!
John Opitz
___________________________________________________________________________
Date: Thu, 3 Nov 2005 08:49:48 -0800
From: David Cardinal
Subject: RE: Re: 16- and 8-bit: Summing Up (Part 2 of
4)
I have been an unpaid volunteer alpha tester for
Photoshop
since version 4.0. I can't count the hundreds1 or
perhaps
thousands of hours I've personally spent trying to
work
towards improving Photoshop for the simple motive of
getting
a better tool for my own work.
FWIW, knowing Jeff, Bruce & Dan, nothing is
capable of stopping any of them from saying what they think, normally about
the same time they think it :-)
In terms of 8-bit vs. 16-bit, the one area I'm
personally most curious about is skies. I don't fully understand all the
interactions between initial bit depth, some of the processing I might do
(like with PixelGenius burn effect), printer profiles, and driver/RIP, but
I do know that for my photography (mostly nature & wildlife) skies can
be much more challenging than I initially expected.
I'd be delighted to hear others results in this area.
In my case I've found skies (when reproduced in large
prints in particular) to be a valuable yardstick for evaluating printer
profiles and profiling solutions. None of the scanner based profile
creation systems did that great a job (this is with an Epson 4000 and
various papers), while both ProfileMaker and the profiles available with
ImagePrint have done much better. I'm getting a copy of PrintFix Pro to
evaluate next, as I'd love to be able to recommend a solution to my readers
that was less expensive than ProfileMaker + Eye-One.
--David Cardinal
Note: The above post provoked a valuable thread on
characteristics of skies. That thread is posted under "Skies" in
the Color Correction section.
___________________________________________________________________________
Date: Thu, 03 Nov 2005 19:09:40 -0000
From: "colorman042000"
Subject: Re: 16- and 8-bit: Summing Up (Part 2 of 4)
--- In colortheory@yahoogroups.com, John O wrote:
On a serious note. Because of the negative waves in
the past from this topic. I felt it was due, positive
waves. To appreciate his time donated to this list.
What he has done for the P.S.community. As well
as
others on this list that contribute heavily to it. And
I don't have to list their names. You see them all the
time. (cut)
Well said Jon! I would like to add that Dan is a man
of convictions, has a clear vision of "what ought to be", he is
not wishy-washy, he has strength and *flavor*, a bit abrasive on the edges,
those are the attributes(like it or not)of a good teacher and leader
in his field.
Andre Dumas
___________________________________________________________________________
Date: Thu, 03 Nov 2005 15:13:56 -0500
From: Ric Cohn
Subject: Re: Re: 16- and 8-bit: Summing Up
On Nov 3, 2005, at 11:16 AM, Jeff Schewe wrote:
As for getting paid to endorse Photoshop, sorry,
that's never happened.
Jeff,
While I'm sure this is true I have always assumed that
the national exposure, paid speaking engagements, endorsements and other
benefits would bring an economic kick to your bottom line. If not, you're
not working it enough!
I know other writers and speakers that because they
are in the "photo" consumer's eye get access to printers,
cameras, lighting gear, etc. in exchange for testing and/or giving
presentations on using these products. Do these people really like these
products: for the most part I assume so- there is a lot of great equipment
out there. Does the fact that they get the newest stuff for free only as
long as they are super positive about it affect how they express their
opinions- yes, I assume it would have to. Certainly, just the fact that you
can judge something without considering it's dollar cost to you personally
has to make a difference.
This is a long winded way of explaining how I
personally read Dan's comments. I can't speak for anyone else.
Regards,
Ric Cohn
___________________________________________________________________________
Date: Fri, 04 Nov 2005 14:47:34 +1300
From: Kevin Crosado
Subject: Re: banding in masks
The banding in the resulting layer
mask has to be severe enough and the layer it's
applied to has to be
sensitive enough to show it. I work on a wide variety
of images and for
most this does not create a problem.
The finished product also comes into it - you can see
all manner of evils on a computer monitor at 100% that disappear in a
print. Sort of like in the days before CTP, when the banding in Quark
gradients used to give me kittens when checking the film, but it never
appeared in the finished jobs, even single colour ones.
--
Regards
Kevin Crosado
De Selby Research
___________________________________________________________________________
Date: Fri, 04 Nov 2005 09:37:13 -0500
From: Ric Cohn
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 1 of
4)
Ron- I frequently use a channel as the beginning of a
mask. I then apply it either as a selection when making an adjustment or as
a mask for an Adjustment or regular Layer. Even applying a blur can
introduce banding if there are too few tones to begin with. If I make
changes that create banding in a mask there is the possibility that the
banding will "show through" to my image layer. Does that clear it
up?
Ric Cohn
___________________________________________________________________________
Date: Fri, 4 Nov 2005 12:26:16 EST
From: Dan Margulis
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of
4)
Jeff Schewe writes,
I have been an unpaid volunteer alpha tester for
Photoshop since version
4.0. I can't count the hundreds1 or perhaps thousands
of hours I've
personally spent trying to work towards improving
Photoshop for the simple
motive of getting a better tool for my own work.
Wow. No wonder you haven't had time to find a single
image that suggests that 16-bit color editing is better than 8-bit. Adobe
must be very grateful to you for spending all this time, and I daresay you
must have made some really close friends in the company.
I will admit that I have been paid by Adobe to write
articles to be posted
on Adobe's web site. But I see nothing about getting
paid to write in the
least bit unsavory. I have also occasionally been
sponsored to speak and
teach about Photoshop by Adobe.
Indeed, and some very posh worldwide destinations they
pick, too. Not to mention the endorsements of your products from Adobe
personnel, the favorable placements of your products on their website, and
their generous support of you as editor-in-chief of their public relations
site.
Mr. Margulis has met me. I'm pretty sure he knows the
truth, even if his
rather slimy attempt to discredit my/our reputations
give insinuations to
the contrary..
There is nothing illegal, unethical, or slimy about
software companies giving money to those they think they can help them, and
there is nothing illegal, unethical, or slimy about people taking it from
them. We have at least two full-time Adobe employees on this list, and
there's nothing slimy about the money they take, either.
Their contributions are valuable. They usually stress
the positive aspects of Adobe products, and correct misconceptions about
them if they can. If Adobe happens to do something that they personally
don't approve of, they'll just keep quiet. If they, like me, strongly
believe that Adobe management is damaging quality by forcing unreasonable
turnaround times on its programming teams, or that Adobe shouldn't permit
you and Chris Cox to bash users in the disgraceful way that you both do,
readers understand that employees sometimes just have to bite their
tongues. And so we respect what they write--because they explicitly
identify themselves as working for Adobe.
The difficulty is not with those who admit their
affiliations, but with shills--"independent experts" who don't
reveal that they're deeply in hock to the company that creates the software
they make their "independent" comments about. The phenomenon is
not limited to Photoshop, and it's not limited to Adobe. It's a logical
response to the growing importance of online commentary. Back in the old
days, the vendors had similar cushy relationships with trade magazines, who
always seemed to have favorable things to say in their
"independent" comments about the products of their largest
advertisers.
At least with the magazines, though, you could see
that they were taking money from the vendors. A lot of today's shills, you
can't. This is not the fault of the vendors, who may have perfectly valid
other reasons for paying the person. Nobody has to be a shill--a person
makes *himself* a shill by a conscious decision to hide the fact that he
can't afford to say bad things about the vendor. All that a person has to
do is disclose the relationship, and then readers can use their own
judgment as to how much weight to give to his comments, and nobody can
accuse him of any impropriety.
This has always been my POV, for all products, not
just Photoshop. This list has always had the following rule:
"CONFLICTS OF INTEREST
Members are entitled to know if posters have
commercial affiliations that might affect their views as to the products
and topics they post about. If you have such an affiliation, you are
expected to disclose it. This doesn't mean in every post, but often enough
so that the readers will be in no doubt as to what your biases might be.
For the purpose of this list, if you're writing about a certain product,
and you've accepted money from that company within the last five years,
that's something that should be disclosed."
The statement: "As many of these advocates take
money or other support from
Adobe, it would have been exceedingly awkward if they
had abandoned the
you-are-not-a-professional-if-you-don't-use-16-bit
line." is pure Dan
Margulis bullshit, and he knows it...don't you Dan?
I know that you have just admitted that you take money
and other support from Adobe. As to the other statements that came in the
two sentences before the one quoted above, one asserted that Adobe was at
that time hyping, as a major reason to buy Photoshop 7, the inclusion of
more 16-bit capability. The other claimed that at the time, certain 16-bit
advocates were marketing seminars where one of the main benefits being
advertised was learning the 16-bit workflow. If you are disputing either of
these assertions, then there's probably room for a little historical
research and discussion. But if we accept that 1) Adobe was hyping 16-bit
workflows; 2) a person was selling seminars hyping 16-bit workflows; and 3)
the same person was also taking money from Adobe--then it seems as a matter
of logic that it might have been awkward for that person to suddenly
discover that there was no benefit to color correction in 16-bit.
As for getting paid to endorse Photoshop, sorry,
that's never happened.
A couple of weeks ago I had a great dinner at
Elizabeth on 37th, a Savannah restaurant that I am happy to recommend. In
addition to a highly commendable presentation of tasso, shrimp, and grits,
they serve a great coffee. When I finished mine, they gave me a second cup
for free, and then a third.
I actually anticipated that they might offer it, and
in fact I secretly thought that I had already paid for the free coffee by
buying that nice dinner. Nevertheless, I thanked the servers for their
kindness.
The problem with taking money from the companies one
writes about is that, like restaurant patrons, it's sometimes hard to know
what they think their money entitles them to get for free.
Dan Margulis
___________________________________________________________________________
Date: Sat, 05 Nov 2005 21:08:37 -0600
From: Jeff Schewe
Subject: Re: Re: 16- and 8-bit: Summing Up (Part 2 of
4)
Dan Margulis writes:
Wow. No wonder you haven't had time to find a single
image that suggests that
16-bit color editing is better than 8-bit. Adobe must
be very grateful to you
for spending all this time, and I daresay you must
have made some really close
friends in the company.
I have plenty of images whose benefits of editing in
16 bit is easy to see. Problem is that most if not all have a variety of
adjustment layers with soft-edged selections or gradients, which fail Mr.
Margulis 's stink test for no "synthetic gradations".
As for my having friends in the company, not so much-I
have a lot of friends on the engineering staff of Photoshop-and yes, they
do appreciate the time & effort I spend trying to make Photoshop
better. Contrast that with certain grumpy old men who seem to go out of
their way to insult, attack and generally approach the engineers in a
mean-spirited way. I've found that my method, over time, works a heck of a
lot better-if you want functions and features added to Photoshop.
Indeed, and some very posh worldwide destinations they
pick, too. Not to
mention the endorsements of your products from Adobe
personnel, the favorable
placements of your products on their website, and
their generous support of
you as editor-in-chief of their public relations site.
Ding, ding, ding...sorry, wrong, thank you for playing
our game :~)
Not sure what posh worldwide destinations Mr. Margulis
is referring to, in fact I have no idea WHAT he's referring to. However,
the rest of this paragraph is typical crap. I have no idea if _ANY_ Adobe
personnel have EVER made any " endorsements ". If they have, I
would love to see/read them. As a rule, Adobe employees are precluded from
making any public endorsements or testimonials. Privately, yes, they have
expressed a degree of "support" to me.
As for "favorable placements of your products on
their website", perhaps Mr. Margulis might want to read the terms of
the membership benefits of the Adobe Solutions Network (ASN). PixelGenius
is a member of the ASN. Part of the membership is a listing as a developer.
As far as I know, that's the _ONLY_ place our products are listed-and no,
the "favorable placements" are something we pay for as a
member of ASN. We don't get anything like that for free.
As for PhotoshopNews.com, if Mr. Margulis took
the time to actually read the "About PhotoshopNews", he would
find the following statement:
"PhotoshopNews is not affiliated with Adobe
Systems Incorporated. Adobe and Photoshop are either registered trademarks
or trademarks of Adobe Systems Incorporated in the United States and/or
other countries."
See: <http:
//photoshopnews.com/about-photoshopnews/>
PixelGenius is the sole owner of PSN. And since we
take neither sponsorship nor advertising, my role as editor-in-chief is
completely without Any compensation. So, I'm unclear just exactly what
"support" he thinks Adobe gives me on "their site"
(which is our site). If he is referring to the fact that I seem to have a
lot of access, yes. I do. See above...I get along with the engineers real
well.
But, as to relations with the rest of Adobe, in point
of fact, we had a rather bloody fight with Adobe legal just to get
permission to use the "Adobe ®Photoshop®" anywhere on the
web site.
As to the other statements that came in the two
sentences before the one
quoted above, one asserted that Adobe was at that time
hyping, as a major
reason to buy Photoshop 7, the inclusion of more
16-bit capability. The other
claimed that at the time, certain 16-bit advocates
were marketing seminars
where one of the main benefits being advertised was
learning the 16-bit
workflow. If you are disputing either of these
assertions, then there's
probably room for a little historical research and
discussion.
Perhaps Mr. Margulis' memory is indeed failing him. If
he is referring to a series of seminars called "Digital Imaging For
Photographers" (DIFP), that Bruce Fraser, Andrew Rodney and I spoke
at, the seminar series was done for the Advertising Photographers of
America (APA) with the proceeds of the events going to APA. So the
characterization that I was "selling" anything is completely
untrue. The thing I was doing for APA was to GIVE them the proceeds (mid-5
figures) and promote high quality digital imaging workflows-including
working in 16 bit.
So, what exactly was I "selling" Mr.
Margulis?
If he was referring to a series of seminars I gave for
Apple called "The Art of High Resolution", those were done for
Apple, and they were free to attendees. Again I wasn't selling
anything...but did advocate 16 bit...at least I'm consistent :~).
Ironically, Mr. Margulis regularly speaks at Photoshop
World. The single largest sponsor of Photoshop World is Adobe...go
figure...
But if we accept that 1) Adobe was hyping 16-bit
workflows; 2) a person was
selling seminars hyping 16-bit workflows; and 3) the
same person was also
taking money from Adobe--then it seems as a matter of
logic that it might have
been awkward for that person to suddenly discover that
there was no benefit to
color correction in 16-bit.
1) Adobe _WAS_ promoting 16-bit workflows...
2) I was _NOT_ selling seminars-I was speaking at
some...
3) The amount of money I've received from Adobe post
dates considerably, any of the time frame Mr. Margulis is referring to.
Photoshop 7 shipped in April of 2002. The only Adobe-paid speaking I've
done was at PhotoPlus Expo in 2003, and again in 2004 relating to Photoshop
CS. The paid writing was done in 2004, again relating to Photoshop CS-which
already had 16 bit. So, his allegation that I would find it
"awkward" to do anything regarding Photoshop 7 because Adobe paid
me money doesn't compute. Either his memory is failing him, he didn't check
his facts or his motives and agenda is showing...
Contrary to Mr. Margulis's assertions, I _STILL_
strongly believe in a 16 bit workflow for all major tone and color
corrections, both globally and locally. And, not only am I a strong
advocate of 16 bit, I'm also pushing hard to get more 32bit HDR into
Photoshop, cause for me, even 16 bit isn't enough.
Mr. Margulis has so alienated the Photoshop engineers
that I doubt he will EVER have any future opportunity to have any input to
the development of Photoshop. Which is really a shame since he certainly
could have a lot of useful contributions. He has considerable knowledge to
share...is an excellent teacher and a personable fellow in person. But for
some reason, when he writes his diatribes, his mean-hearted side takes over
and he looses any sense of decorum, and he also loses the the ability to
actually contribute in any sort of meaning manner.
Personally, I couldn't care less what Mr. Margulis
thinks of me...but he does a serious disservice to the industry when he
distorts the way this industry runs...he knows better, or should.
I'm not going burden the list with any further
discussion regarding my integrity...I don't need to do so and those people
who know me, know where I am coming from... I'll let you, the readers
decide...
Regards,
Jeff Schewe
16-bit is for wimps...give me 32-BIT!!!
___________________________________________________________________________
Date: Sun, 6 Nov 2005 07:24:47 -0400
From: Paco Marquez
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
Gentlemen, I am a photographer who is trying his best,
day in and out, to learn as much as possible from as many experts as
possible. And so I came to subscribe to this list.
I am nothing special and as such you might diss me for
what I am about to say but please understand that I say it with the utmost
respect and gratitude to all you big honchos involved in this back and
forth.
This thread is getting a bit personal for my taste and
I wish you gentlemen would take it "outside" please. Mr Margulis,
I know this is your group and I am just a guest here so I don't say this
lightly.
If you are going to keep this tirade going for much
longer it is just going to get nastier and more personal than it now is. I
am saddened and a bit ashamed by this. The worst part is I can see no end
to it unless you all duel each other and then win your argument by being
the sole survivor.
I enjoy and learn immensely from your disagreements
and historically, disagreements have led the arts and the sciences to great
achievement not to mention something as small in the scheme of the universe
as 8 or 16 bits. But your responses to each other are getting too personal
for myself who comes here to learn from "all" of you. It is
up to me to try out your techniques and theories, and then adopt and adapt
what you have taught.
Please make us see you disagree in a spirit of
goodwill and respect for one another.
To you all my most sincere wishes for Peace, Health,
Love, Gold and Time!
Paco Márquez
661 McKinley St.
MIramar
San Juan, PR 00907
787-721-8554
787-587-7384 Cel.
http://www.pacomarquez.com
___________________________________________________________________________
Date: Sun, 06 Nov 2005 11:43:56 -0800
From: Marco Ugolini
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
For what it's worth, I share Mr. Marquez's very
sensible remarks, and subscribe 100% to the spirit of his message.
Best regards.
--------------
Marco Ugolini
Mill Valley, CA
___________________________________________________________________________
Date: Mon, 07 Nov 2005 11:10:30 -0400
From: Lee Clawson
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
Paco and Marco,
Include me too !
Dan I, unlike you who had to spend an enormous amount
of time thinking, writing, and responding don't find the on-going posts, as
you describe, to have "wasted far more time than it could possibly
merit over the last half-decade". What Andrew (re)started in early
September and continued to date has made me rethink how I work. What you,
Lee Varis and others had to say made me rethink how it is or could be
applied.
My colleagues have written to me saying that reading
through this stuff makes their hair hurt. Sometimes I feel this way too,
sometimes like I'm reading court transcripts. But a waste of time has never
come to mind.
Lee Clawson
___________________________________________________________________________
Date: Mon, 7 Nov 2005 11:44:28 -0500
From: Henry
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
On Nov 5, 2005, at 10:08 PM, Jeff Schewe wrote:
Mr. Margulis has so alienated the Photoshop engineers
that I doubt he will
EVER have any future opportunity to have any input to
the development of
Photoshop. Which is really a shame since he certainly
could have a lot of
useful contributions. He has considerable knowledge to
share...is an
excellent teacher and a personable fellow in person.
This doesn't seem, on the surface, to speak very well
of the Photoshop engineers. Such a statement might also be taken by
some as a validation for the suspicion that has been sensed about the Adobe
attitude by a growing number of product users.
My hope is that they take note when Mr. Margulis makes
recommendations. The same goes for your input, Jeff. It is
troubling when you find a corporation shutting off input from all but the
insiders.
Just an observation.
Henry Davis
___________________________________________________________________________
Date: Mon, 7 Nov 2005 12:51:14 -0800
From: "Mike Russell"
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
From: "Lee Clawson"
...
My colleagues have written to me saying that reading
through this stuff
makes their hair hurt. Sometimes I feel this way too,
sometimes like I'm
reading court transcripts. But a waste of time has
never come to mind.
Hair always hurts when the conventional wisdom is
controverted. This is an indication that careful thought and a return
to basic principles are needed.
While I applaud cordiality, and believe that Dan has
been exemplary here, in human affairs the conflict of important ideas has
always been accompanied by a parallel conflict of personalities.
Mike Russell
www.curvemeister.com
___________________________________________________________________________
Date: Mon, 07 Nov 2005 14:51:46 -0500
From: Steve Hirsch
Subject: Re: Re: Re: 16- and 8-bit: Summing Up (Part 2
of 4)
I wholeheartedly agree with Paco. As someone who
mostly lurks on this board I would add that I might choose to get more
involved in this board1s discussion threads if I didn1t feel that I would
be stepping into a mudslinging firestorm by doing so.
Just my 2c
Steve
--
Steve Hirsch, Systems Manager
Hachette Filipacchi Media, U.S.
1633 Broadway
New York, NY 10019
212-767-6536
___________________________________________________________________________
From: Dan Margulis
Date: FriÊNovÊ11,Ê2005Ê 1:30 pm
Subject: Re: [colortheory] Re: Re: 16- and 8-bit:
Summing Up (Part 2 of 4)
Henry Davis writes,
This doesn't seem, on the surface, to speak very well
of the Photoshop
engineers. Such a statement might also be taken by
some as a validation for the
suspicion that has been sensed about the Adobe
attitude by a growing number of
product users. My hope is that they take note when Mr.
Margulis makes
recommendations.
The underlying point is well taken, but it gives me
too much credit. The historical problem is that, while there are some
people at Adobe who take criticism well, there's at least one member of the
Photoshop team who's so arrogantsthat he can't even consider the
possibility that he's ever wrong, and at least one other who's so shy that
he can't cope with disagreement. The unfortunate result is that the
Photoshop team listens almost exclusively to bootlickers and sycophants who
are guaranteed to greet anything they do with wild applause.
Historically, the stability and reliability of the
Photoshop software has been outstanding in comparison to that of other
Adobe products and those of other vendors, or at least it has been up until
the release of Bridge, which is not sreally a product of the Photoshop
team. OTOH, since 1998 there have been four major corrective upgrades
necessitated not by bugs but by mistakes in concept--Photoshops 5.0.2 and
7.0.1, which corrected badly thought-out color behavior, and Bridge 1.0.1
and 1.0.2, which were necessitated by the irresponsible decision to take
File Browser out of Photoshop before it was clear that the replacement for
it actually was stable enough to ship to customers.
This is an excessive number of "concept"
corrective updates, one that users shouldn't have had to put up with. Every
one of them could have been avoidedhad my advice been taken. In every case,
I gave that advice long before the actual release. In every case, between
the release but before the correctiveupdate, Adobe employees and shills
publicly called me unseemly names forsuggesting that there was something
wrong, but never apologized after the problems were corrected.
The corrective updates, obviously, weren't needed
because *I* found the original releases unsatisfactory, but rather because
thousands of other users did as well. So the question must be not why Adobe
didn't listen to *me*, but whythey couldn't find any of these other users
to listen to.
It is troubling when you find a corporation shutting
off input from all but
theinsiders.
It is, but there's always room for hope--or for Adobe
to do its own internal corrective update.
Dan Margulis