Dan Margulis Applied Color Theory
Problem with Camera-Generated 8-bit Files
Date: Mon, 14 Feb 2005 08:53:02 EST
From: Dan Margulis
Subject: Another 16-bit test
Folks,
In late December, list member Geoff Shearer sent me a
package of two sets of two images that he had tested by extensive
correcting 16-bit and 8-bit versions of each, requesting that I confirm his
finding that his 16-bit correction was better than his 8-bit. I have said
that I would post results of any such testing here, so here goes.
Geoff did all of the following, which I require before
doing such testing:
1) He had actually done his own 8- vs. 16-bit
tests on the two sets of files and believed they showed an advantage for
the 16-bit method.
2) In addition to the 8- and 16-bit files used
for each test, he enclosed copies of everything he had done, curves, etc.
3) The images were clearly real-world, not some
block of unknown color of an unknown object. One was a picture of a man
wearing a fez; the other featured presents arranged around a Christmas
tree.
4) The corrections that were applied were wildly
extreme, due to some workflow issues. Several of the procedures followed
are definitely not to be recommended, including certain corrections that
counteracted others. However, they were all legitimate, if ill-advised,
attempts to improve the images, not moves specifically designed to degrade
the image in order to defeat the test.
5) In advance of the testing, he gave me
permission to publish the results, which I will probably do in Professional
Photoshop Fifth Edition next year.
The results were the same as the last time someone
submitted similar materials. That is, Geoff was correct that given his
8-bit file and his moves, the results were much worse than when doing the
same thing in 16-bit. However, it turned out that this was due to a problem
in his camera's acquisition module, which had generated the 8-bit file.
When the 8-bit file was created in Photoshop starting with Geoff's original
16-bit file and then the moves were repeated, there was no significant
quality difference between it and the version done entirely in 16-bit.
The two images were captured in a linear (1.0 gamma)
space. However, they were worked on exclusively in Adobe RGB, which is 2.2
gamma. Translation: when the files were first opened they were grossly and
hideously dark. Nevertheless, a series of corrections were applied to try
to save the images. Some of the corrections worked against one another,
e.g. RGB master curve applied simultaneously with a contrary curve in one
of the channels.
Anybody who is correcting images this way (sorry,
Geoff!) has many more pressing things to worry about than the number of
bits in the file. Nevertheless, the final results were acceptable for
lightness and for color.
Geoff states that the 8-bit and 16-bit versions of his
two files were produced from raw captures from a Canon EOS 10D, using Canon
Digital Photo Professional 1.5 to convert. I reran all of his steps on all
four original files, and, when finished, converted the 16-bit files to
8-bit so that there could be a fair comparison between the results.
As Geoff had said, the version done in 8-bit was
considerably worse. The pictures featured large areas of dark, rich colors:
a burgundy in one, a dark green in the other. These areas took on some
nasty dark noise in the 8-bit version that was missing in the version
prepared in 16-bit. There's no doubt in my mind that most people would
consider this the kind of night-and-day difference that has been used to
justify working in 16-bit when doing massive corrections.
However, I then did a third set. I converted the
original 16-bit files into 8-bit in Photoshop rather than use the camera
8-bit. I reran Geoff's corrections on these files and compared them to the
versions corrected entirely in 16-bit. There was no qualitative difference.
Although the two sets were not identical there was no reason to prefer one
to another.
Geoff agreed with this conclusion. He wrote me,
"Thanks for taking the time to look at my samples
and explain the cause of the differences - I think I understand most of
what you are saying, and my own tests verify that a 16-bit file
taken to 8 bit in Photoshop and "worked over" gives results that
are not significantly different from doing the entire edit in 16-bit.
I don't have your book in front of me right now but I think that you
wrote there (or maybe in the newsgroup) that if you can bring in a file
from another software program as a 16-bit image, do it, but then you
can take it to 8-bit right away and see no significant difference in
your final image. This example just seems to be further illustration
of that."
Closer examination of the Canon 8-bit file demonstrated
that it was the cause of the problem, as opposed to some magic that
Photoshop might have been performing. The Canon 8-bit file looked like the
16-bit version on casual inspection, but in fact was always slightly
darker, never lighter. In some cases the pixels were seven levels darker
than they should have been. In lighten mode the mean variation was .06
levels, which is accounted for by the noise that Photoshop intentionally
puts in when it converts from 16 to 8 bits. In darken mode, the mean
variation was 2.51 levels with a standard deviation of 2.03; both numbers
being totally unacceptable. That´s why noise was appearing in the
dark colors.
Since this is the second time that I've tested and seen
an issue with 8-bit files that are produced by camera software, I reiterate
the recommendation that when possible, camera owners should capture in
16-bit and only convert to 8-bit in Photoshop. As for when to convert,
AFAIK there's no damage in keeping it in 16-bit if you don't mind having a
doubled file size. OTOH, it's hard to torture an image much more than these
were. If these don't show an advantage for 16-bit correcting, it kind of
confirms everyone else's results, and suggests that there are really no
conceivable circumstances under which correcting a color photograph in
16-bit could provide any real advantage over doing it in 8-bit.
My thanks to Geoff for putting together the test so
carefully.
Dan Margulis
___________________________________________________________________________
Date: Mon, 14 Feb 2005 08:25:55 -0700
From: Andrew Rodney
Subject: Re: Another 16-bit test
On 2/14/05 6:53 AM, "Dan Margulis"
wrote:
The two images were captured in a linear (1.0 gamma)
space.
That1s the ONLY way a digital camera can encode the
data!
However, they
were worked on exclusively in Adobe RGB, which is 2.2
gamma. Translation: when
the files were first opened they were grossly and
hideously dark.
What do you mean? What RAW converter was used? If the
data came in as Adobe
RGB (1998) and tagged as such, no big deal. IF the data
came in as Linear
data (which isn1t Adobe RGB (1998) or for that matter
is an undefined RGB
file), he assigned Adobe RGB (1998)?
Nevertheless,
a series of corrections were applied to try to save the
images. Some of the co
rrections worked against one another, e.g. RGB master
curve applied
simultaneously with a contrary curve in one of the
channels.
All he had to do was assign the proper input profile.
Was the image scene referred or output referred?
Geoff states that the 8-bit and 16-bit versions of his
two files were
produced from raw captures from a Canon EOS 10D, using
Canon Digital Photo
Professional 1.5 to convert.
Check with Geoff but I don1t think that software allows
linear data to be
produced from the RAW data. So the files probably were
in Adobe RGB (1998).
But your 3findings2 need some clarifications from
Geoff.
"Thanks for taking the time to look at my samples
and explain the cause of
the differences - I think I understand most of what you
are saying, and
my own tests verify that a 16-bit file taken to 8 bit
in Photoshop and
"worked over" gives results that are not
significantly different from
doing the entire edit in 16-bit.
And the evaluation of what was and wasn1t significantly
different was output
on what device?
Since this is the second time that I've tested and seen
an issue with 8-bit
files that are produced by camera software, I reiterate
the recommendation that
when possible, camera owners should capture in 16-bit
and only convert to
8-bit in Photoshop.
Virtually every RAW data file is in high bit (it1s not
necessarily in 16-bit
and in fact it1s technically incorrect to say they are
when in most cases
they are 10-bit, 12-bit etc). As far as I know, there1s
only a handful if
that of true 16-bit capture devices. Photoshop lumps
all this into a term it
calls 316-bit2 which I guess is fine since it1s working
on all such data in
15 bits anyway and having a bunch of sub menus (10-bit,
12-bit, 14-bit)
would clog up the sub menus. Point is, RAW data always
linear high bit data.
You1re always producing RAW data but you can tell the
camera to render that
data and encode it into something like sRGB or Adobe
RGB and unless the
camera has a RAW+JPEG option, the RAW data (and the
high bit data) is gone
forever.
There are advantages of doing high bit, linear gamma
corrections on scene
referred data in a RAW converter that simply can1t be
done on a gamma
corrected, output referred 8-bit file. That1s why we
need not only better
and more robust RAW converters, more importantly we
need a standard RAW
format like Adobe1s .DNG so we can actually handle
these files today and in
the future.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Mon, 14 Feb 2005 11:59:37 -0700
From: Chris Murphy
Subject: Re: Another 16-bit test
Dan,
At first glance is there an obvious difference between
the 16bpc file converted to 8bpc files produced by Photoshop and the camera
vendor's software PRIOR to edits? Is there a technique that could be
developed to quickly reveal the propensity of an 8bpc file to posterize in
an unacceptable manner?
Based on what you've written, it seems clear that there
is a significant difference between the methods of 16bpc>8bpc
conversion. The Photoshop method is significantly superior to the camera
vendor's method, given the context of this discussion. Is this due to the
dithering Photoshop uses in the conversion? Or is there some other
explanation?
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________
Date: Mon, 14 Feb 2005 12:15:56 -0800
From: Mike Russell
Subject: Re: Another 16-bit test
I've seen this effect also in at least one camera
model, the Canon EOS D30, in a comparison image I received some time ago
from Chris Brown. The camera's 8 bit capture was noisier in the
shadows than the corresponding 16 bit capture, although the ISO setting was
the same for both. My conclusion was that the manufacturer cut some
very Procrustrean corners for the 8 bit file, using a lower quality,
possibly faster, pathway for 8 bit capture than for 16 bit.
Mike Russell
www.curvemeister.com
www.geigy.2y.net
___________________________________________________________________________
Date: Mon, 14 Feb 2005 21:15:22 -0800
From: Paul D. DeRocco
Subject: RE: Another 16-bit test
I don't know much about the D30, but the D60 and
10D, which I have, give you the choice of raw or 8-bit JPEG. This means
that all you can really compare and contrast are the quality of the Bayer
interpolation and JPEG compression, not anything specific about the
truncation from 16-bit to 8-bit.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Tue, 15 Feb 2005 00:42:09 EST
From: Dan Margulis
Subject: Re: Another 16-bit test
Chris Murphy writes,
At first glance is there an obvious difference between
the 16bpc file
converted to 8bpc files produced by Photoshop and the
camera vendor's software
PRIOR to edits?
On gross inspection, no.
Is there a technique that could be developed to quickly
reveal the
propensity of an 8bpc file to posterize in an
unacceptable manner?
The question needs to be rephrased. There can be
unacceptable posterization in a 16-bit file too. The question has to be, is
there a way to find out whether an 8-bit file would posterize in a way that
16-bit would not.
The testing of a lot of people so far indicates that
there are no circumstances in normal image handling of a color photograph
where that would occur, provided there is nothing wrong with the original
8-bit file. As for why this *particular* 8-bit file had a defect that
caused posterization, yes, that can be tested and proven, but I don't know
that there would be a test that could find every conceivable defect in a
file.
Based on what you've written, it seems clear that there
is a
significant difference between the methods of
16bpc>8bpc conversion.
The Photoshop method is significantly superior to the
camera vendor's
method, given the context of this discussion. Is this
due to the
dithering Photoshop uses in the conversion?
No, it seems that this is not a question of Photoshop
being good as much as Canon being bad. You would think that, to extract
their 8-bit file, they would make the 16-bit first internally and work from
there. Evidently they aren't doing that, the 8-bit seems to be made by an
entirely different algorithm.
If the 8-bit file were converted back to 16-bit, or the
16-bit to 8-bit, then the files obviously would not match. However, granted
that an individual pixel of the 8-bit wouldn't match exactly the value of
the 16-bit, it should be equally likely that it is lighter or darker than
the 16-bit pixel.
That wasn't the case with this 8-bit file. *Every*
pixel was darker than the 16-bit, to the extent that they varied at all.
When I applied the 8-bit to the 16-bit in LIGHTEN mode, the mean difference
in pixel value was an inconsequential .06 levels, which is accounted for by
the Photoshop dither. But when I applied it in DARKEN mode, the mean
difference was a totally unacceptable 2.51 levels. Furthermore, there was a
standard deviation of 2.03, meaning that there were some six- and
seven-level variations floating around.
Given that this was an extremely dark file to begin
with, that kind of extra darkening is a recipe for trouble, particularly in
the deepest shadows. And the defect in this picture was definitely black
noise in the deep shadows, noise that wasn't present when the same moves
were applied to the 16-bit file.
So, whatever the software is doing to create this 8-bit
file out of the raw capture is fairly messed up.
Dan Margulis
___________________________________________________________________________
Date: Tue, 15 Feb 2005 07:17:58 -0700
From: Andrew Rodney
Subject: Re: Another 16-bit test
On 2/14/05 1:15 PM, "Mike Russell"
wrote:
I've seen this effect also in at least one camera
model, the Canon EOS D30,
in a comparison image I received some time ago from
Chris Brown. The
camera's 8 bit capture was noisier in teh shadows than
the corresponding 16
bit capture, although the ISO setting was the same for
both.
Was any sharpening on when the camera produced the
8-bit data?
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Tue, 15 Feb 2005 09:44:58 EST
From: Dan Margulis
Subject: Re: Another 16-bit test
Andrew Rodney writes,
What do you mean? What RAW converter was used? If the
data came in as Adobe
RGB (1998) and tagged as such, no big deal. IF the data
came in as Linear
data (which isn1t Adobe RGB (1998) or for that matter
is an undefined RGB
file), he assigned Adobe RGB (1998)?
Correct. That's why the images were so ridiculously
dark when he began.
All he had to do was assign the proper input profile.
That's right. That's all he had to do, but he didn't do
it; he made it much, much harder for himself than he needed to. However,
the way he did it created the need for a series of huge corrections to a
high-quality original. That is the scenario that, your business partner
assures us, creates a "night and day", "totally obvious to
anyone who looks" advantage for working in 16-bit.
In response to your query to Mike about sharpening, in
the case of Geoff's files there does not appear to have been any sharpening
to either the 16-bit or 8-bit versions, but it was a good thought, since
that would certainly explain some of the problem.
Dan Margulis
___________________________________________________________________________
Date: Tue, 15 Feb 2005 09:30:03 -0700
From: Andrew Rodney
Subject: Re: Another 16-bit test
On 2/15/05 7:44 AM, "Dan Margulis"
wrote:
Correct. That's why the images were so ridiculously
dark when he began.
Actually they were not dark in that the data was just
fine and no editing was necessary. The problem was the display was showing
a totally incorrect preview of the numbers. Think of it this way. If I gave
you a file that would 3normally1 preview correctly but turned down the
luminance of your display to the degree that you saw a very dark preview,
would then going into levels or curves (in high bit or not) be the way to
3fix2 the issue? I think not.
That's right. That's all he had to do, but he didn't do
it; he made it much,
much harder for himself than he needed to. However, the
way he did it created
the need for a series of huge corrections to a
high-quality original. That is
the scenario that, your business partner assures us,
creates a
"night and day", "totally obvious to
anyone who looks" advantage for working
in 16-bit.
Given that this is a silly way to fix the issue, I1d
still prefer to have the high bit data to do such severe corrections upon.
Also note that you1re editing a file with a 1.0 encodded gamma. So the
edits are not being applied in a very smooth (perceptually uniform)
fashion. A benefit of a 2.2 gamma working space is that you1re much closer
to this uniform editing. So not only is the file really dark appearing
(when again, it1s not really dark), but the edits are real difficult to
apply uniformly over the tone range of the image. Yet another reason why
high bit would be the way I1d tackle this (if I knew indeed the image was
too dark which it wasn1t).
BTW, what you could have done was 3edit2 the Adobe RGB
(1998) working space and set it for a 1.0 gamma which would at least make
the ugly file preview lighter although it1s quite unlikely that the
primaries of this modified Adobe RGB (1998) space is anything like that of
the actual image data which is scene referred.
In response to your query to Mike about sharpening, in
the case of Geoff's
files there does not appear to have been any sharpening
to either the 16-bit
or 8-bit versions, but it was a good thought, since
that would certainly explain
some of the problem.
A huge problem with many RAW converters is they have
off settings for sharpening which don1t turn off all the sharpening. I1ve
seen this with scanner drivers as well. The manufacturers feel that if they
really did provide a totally unsharpened file, the user would complain or
think the image was soft (which it is although it could be in focus).
At least with Adobe Camera RAW, no sharpening really is no sharpening. I
can1t say that1s the case for the Canon software. Since we are dealing with
(initially) linear encoded data, the one area you1d see the most noise is
shadows since this represents the least amount of data (in a file that
contains 4096 steps of data, only 64 bits would make up the last 1 stop of
shadows). It1s REAL easy to produce noise and other nasty stuff there (even
being a bit underexposed will do this with no sharpening applied).
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Tue, 15 Feb 2005 17:40:11 -0000
From: "Geoff Shearer"
Subject: Re: Another 16-bit test
To clarify a bit, the original reason for bringing
these conversions into Photoshop in linear form was for testing that I was
doing to create my own custom input profile. This workflow is not my
usual, and as Dan said earlier, it is not recomended. However, it is
the only time that I have noticed a substantial quality difference between
editing in 8-bit vs. 16-bit. I concur with Dan's explination - that
the Canon software is not doing a good 8-bit conversion.
Some "camera profile" experts advise working
on the uncorrected linear images; others say that a gamma correction curve
should be applied first. I was simply testing different ways of
creating input profiles. My questions relating to 8 vs 16-bit came
from this testing.
At the risk of opening another can of worms, I have yet
to create or purchase a custom camera input profile that works well all of
the time with all different types of images. Input profiles for the
digital cameras that I use are hit or miss. I actually have several
different camera profiles that I use, depending on the image. Some I have
created myself, some are "canned" from the software manufacturer.
or a third party.
It is worth noting that Canon's Digital Photo
Professional does NOT allow you to use custom input profiles; however,
Capture One, my usual converter, does allow this. Capture One also
automatically applies a gamme curve to all images it converts - you can't
get a linear file even if you want one. The reason I was testing
using DPP is that you can get a linear file out of it.
Geoff Shearer
___________________________________________________________________________
Date: Tue, 15 Feb 2005 11:32:52 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
On 2/15/05 10:40 AM, "Geoff Shearer"
wrote:
To clarify a bit, the original reason for bringing
these conversions
into Photoshop in linear form was for testing that I
was doing to
create my own custom input profile.
Sounds reasonable.
This workflow is not my usual,
and as Dan said earlier, it is not recomended.
However, it is the
only time that I have noticed a substantial quality
difference
between editing in 8-bit vs. 16-bit. I concur
with Dan's
explination - that the Canon software is not doing a
good 8-bit
conversion.
Very odd that the Canon software would treat the two
differently but then, that1s Canon for you. What happened when you only
bring in the high bit file in Photoshop and have it do the high bit to
8-bit conversion?
Some "camera profile" experts advise working
on the uncorrected
linear images; others say that a gamma correction curve
should be
applied first. I was simply testing different
ways of creating input
profiles. My questions relating to 8 vs 16-bit
came from this
testing.
The profile software shouldn1t care but there will be a
significant difference in building the profile with linear data versus
gamma corrected data.
At the risk of opening another can of worms, I have yet
to create or
purchase a custom camera input profile that works well
all of the
time with all different types of images.
Me either! That1s why I just use Adobe Camera RAW and
totally forget about input profiles. I can alter the data from a form
that1s nearly scene referred (colorimetrically) or apply all the tone and
color tweaks I want to render the data into a working space for encoding
(output referred).
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Tue, 15 Feb 2005 11:55:43 -0700
From: Chris Murphy
Subject: Re: Another 16-bit test
On Feb 14, 2005, at 10:42 PM, Dan Margulis wrote:
The question needs to be rephrased. There can be
unacceptable posterization
in a 16-bit file too. The question has to be, is there
a way to find out
whether an 8-bit file would posterize in a way that
16-bit would not.
Perhaps before extrapolating beyond the current
anecdote at all, I'd like to be clear on the exactly sequence of arriving
at the two 8bpc files: the one that did not have appreciable less
posterization than the edits applied while in 16bpc mode (Photoshop's); and
the one that did (Canon's).
What's the origin of the 16bpc file handed off to
Photoshop for conversion to 8bpc? Was it a high-bit RAW file? Was it
processed with Canon software into a 16bpc TIFF, or was it processed with
Camera RAW to a 16bpc document in Photoshop where it was subsequently
converted to 8bpc, or was it process with Camera RAW directly to an 8bpc
document?
What's the origin of the 8bpc file that came from
Canon? JPEG? TIFF?
If the two originals from this camera aren't both TIFFs
(one capture 8bpc the other 16bpc), I don't see how this is really an
apples to apples comparison. It could be the difference between the
demosiacing built into the camera versus that in either the Canon software
or Camera RAW. It could be a bad JPEG algorithm in the camera, if the 8bpc
capture was JPEG.
No, it seems that this is not a question of Photoshop
being good as much as
Canon being bad. You would think that, to extract their
8-bit file, they would
make the 16-bit first internally and work from there.
Evidently they aren't
doing that, the 8-bit seems to be made by an entirely
different algorithm.
Depending on the camera, it could actually make sense
to have record 8bpc straight way, demosaic that limited amount of data, and
JPEG it because that would be considerably faster than recording high bit
(even 10bpc), demosaicing 10bpc data, then dumbing down to 8bpc, then JPEG.
So indeed they may be doing a number of essentially destructive things in
arriving at an 8bpc file.
That wasn't the case with this 8-bit file. *Every*
pixel was darker than the
16-bit, to the extent that they varied at all. When I
applied the 8-bit to the
16-bit in LIGHTEN mode, the mean difference in pixel
value was an
inconsequential .06 levels, which is accounted for by
the Photoshop dither. But when I
applied it in DARKEN mode, the mean difference was a
totally unacceptable 2.51
levels. Furthermore, there was a standard deviation of
2.03, meaning that there
were some six- and seven-level variations floating
around.
What about highlights? Canon notoriously applies a
fairly aggressive S-curve to boost contrast when capturing as JPEG.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________
Date: Tue, 15 Feb 2005 19:14:58 -0000
From: "Geoff Shearer"
Subject: Re: Another 16-bit test
Andrew Rodney wrote:
Very odd that the Canon software would treat the two
differently but then,
that1s Canon for you. What happened when you only bring
in the high bit file
in Photoshop and have it do the high bit to 8-bit
conversion?
When I bring in 16-bit file from Canon software
and then convert immediately to 8-bit and then run my corrections, there is
little to no significant difference in the files from those that are edited
entirely in 16-bit. Honestly, I can convince myself that the all
16-bit file is a little better in some places, but the difference is so
small that it would never show up in a print. And who knows, I might
just be seeing what I want to see.
The profile software shouldn1t care but there will be a
significant
difference in building the profile with linear data
versus gamma corrected
data.
This is very true - In my experience the profiles
built from linear data are visually much worse than those made after a
gamma correction curve is applied.
Me either! That1s why I just use Adobe Camera RAW and
totally forget about
input profiles.
ACR is really getting there, and I can get a
great-looking conversion from it with very little effort on most images.
It is remarkable that one converter can handle so many different RAW
files. For my workflow, Capture One (and now Bibble, which I am
testing) has a few "bells and whistles" that I like, but this is
only a workflow thing, not a quality thing.
By the way - I am checking into your earlier suggestion
that sharpening may account for some of the differences in the Canon
software. I checked, and I DID have sharpening enabled on my original
test. As soon as I get some time I'll re-run the test and see if
turning it off makes a difference.
Geoff Shearer
___________________________________________________________________________
Date: Tue, 15 Feb 2005 19:22:30 -0000
From: "Geoff Shearer"
Subject: Re: Another 16-bit test
Chris Murphy wrote:
What's the origin of the 16bpc file handed off to
Photoshop for
conversion to 8bpc? Was it a high-bit RAW file? Was it
processed with
Canon software into a 16bpc TIFF,
Yes - the 16bpc file I sent to Dan was processed in
Canon Digital Photo Professional into a 16bpc TIFF. I specified that
the conversion was to use a Linear Tone Curve - an option in the Canon
Software, and that the output was to be a 16-bpc tiff.
What's the origin of the 8bpc file that came from
Canon? JPEG? TIFF?
It is the same RAW file, processed with the same
settings as the 16 bpc file in Canon Digital Photo Professional, but this
time I specified an 8-bit tiff as the output file. That is the only
change made in the Canon Software - everything else stayed the same
If the two originals from this camera aren't both TIFFs
(one capture
8bpc the other 16bpc), I don't see how this is really
an apples to
apples comparison.
The two "originals" are not originals at all.
They are both conversions from the same RAW file. The only
difference is that one was converted as a 16-bit tiff and the other as an
8-bit tiff.
No JPEG files were created (or injured) in this test.
Geoff Shearer
___________________________________________________________________________
Date: Tue, 15 Feb 2005 13:28:53 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
On 2/15/05 12:14 PM, "Geoff Shearer" wrote:
Honestly, I can convince myself that the all 16-
bit file is a little better in some places, but the
difference is so
small that it would never show up in a print.
Printed how? There1s a world of difference between
output to a halftone dot and my contone printer (a Fuji Pictrography). I1m
not saying you will see a difference but the output should be defined. And
how many other edits or adjustments (even color space conversions) have to
take place on the data?
This is very true - In my experience the profiles
built from linear
data are visually much worse than those made after a
gamma
correction curve is applied.
That has a lot to do with the profiling software and
the assumption it1s making about the data.
By the way - I am checking into your earlier suggestion
that
sharpening may account for some of the differences in
the Canon
software.
If you can, try converting using that and ACR with no
sharpening. Yes, the contrast can fool your eyes but if you can get both
close, you1ll probably be able to see if indeed off is off with the Canon
software. I know for a fact that off is off in ACR. If you see what appears
to be a sharper appearing image with the Canon converter, even with a
setting that appears to be 3off2, it1s possible it1s still applying some
sharpening. Then the question is, does this happen while the data is linear
or after a tone correction. That alone could play a huge role in the
quality.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Tue, 15 Feb 2005 16:07:57 -0500
From: "Iliah Borg"
Subject: Re: Re: Another 16-bit test
If anybody is interested...
I'm one of the authors of a RAW converter; if we
normalize the data to 8 bits before demosaicing, things are substantially
worse then if we do demosaicing in 16 bit, and then convert to 8 bit. In
quite a lot of converters 8 bit mode is "pure" 8-bit, that is
demosaicing is done in 8 bit. One of the things that can go wrong in 8 bit
space are white balance operations, that can involve muliplications on up
to 4. If precautions are not taken, highlights are blown out quite easily.
Best regards,
ib
___________________________________________________________________________
Date: Tue, 15 Feb 2005 13:49:22 -0800
From: David Cardinal
Subject: RE: Re: Another 16-bit test
From: Geoff Shearer
It is the same RAW file, processed with the same
settings as
the 16 bpc file in Canon Digital Photo Professional,
but this
time I specified an 8-bit tiff as the output file.
That is
the only change made in the Canon Software - everything
else
stayed the same
Geoff--If the 8-bit output from this process is linear
that would explain a lot. Conversion of the 12bpp camera data (4096 values)
into 8bpp linear essentially must map each 16 input values into a single
output value in order to retain the linearity.
This means that (for example) the range of 16-32 from
your sensor is mapped into a single output value. That is an entire factor
of 2 (e.g. a stop of light) represented with one and only one value in the
resulting file. Enough to produce all sorts of ugly effects. (I've left out
what happens between 0-15 since depending on other noise in the image the
really low values may not enough signal information to really analyze this
way. For example on a "typical" D1X image (ISO 200, studio
lighting) values from 0-4 are mostly just noise. If that same file is
converted to 8-bit using a typical D-SLR tone curve, the input values 16-32
wind up getting 8-12 output values (depending on your tone setting).
If I was Canon I'm not sure I'd even allow 8bpp linear
output as an option. Seems like they're just asking for issues like this.
For 8bpp they'd be better off doing a tone mapping before outputting.
--David Cardinal
Pro Shooters LLC
http://www.proshooters.com
___________________________________________________________________________
Date: Tue, 15 Feb 2005 16:32:22 -0500
From: "Iliah Borg"
Subject: Re: Re: Another 16-bit test
Geoff,
Have a look at this quick shot, opening it in Photoshop:
http://www.pochtar.com/GMBCCDC_NC4_1_ISO200_1.jpg
This image is linear; it is normalized to Photoshop
from 0..4095 range; and linear colour profile is assigned to it. You can
try similar trick for preparing target for profiling, just add conversion
to colour space with gamma = 2.2 or 1.8 TRC. Normally I would avoid
assign/convert operations, but use some utility to normalize and
"gamma-correct" the target before profiling.
Best regards,
ib
___________________________________________________________________________
Date: Tue, 15 Feb 2005 13:39:03 -0800
From: David Cardinal
Subject: RE: Re: Another 16-bit test
From: Iliah Borg
I'm one of the authors of a RAW converter; if we
normalize
the data to 8 bits before demosaicing, things are
substantially worse then if we do demosaicing in 16
bit, and
then convert to 8 bit. In quite a lot of converters 8
bit
mode is "pure" 8-bit, that is demosaicing is
done in 8 bit.
That is pretty horrifying. Doing the conversion to
8-bit before any type of gamma/tone correction is really asking for trouble
in the shadows since you wind up having very few discrete values to
represent quite a few stops of light in the shadow areas. It would
certainly explain ugly results, though. I don't know if Dan's test
specifies the gamma of the 8-bit and 16-bit "test" images, but in
linear images 8-bits sure doesn't provide very much to work with at the low
end. Entire stops of light wind up being represented by only a few values.
--David Cardinal
Pro Shooters LLC
http://www.proshooters.com
___________________________________________________________________________
Date: Tue, 15 Feb 2005 16:27:00 -0800
From: Dennis Dunbar
Subject: Re: Another 16-bit test
Dan,
One of the complicating factors in any 8 bit vs 16 bit
test is the basic limitation imposed on us by the video system. That is in
almost all cases we are only given an 8 bit view of the image because the
OS and the video cards only support 8 bit LUTs, (there are one or two cards
that will support 10 bits but I understand the Mac OS still limits the
screen draw to 8 bits).
So unfortunately we are left in a sort of limbo,
Theoretically 16 bits should be better, but we can't see it anywhere
because there is no output device that will let us see this difference.
Dennis Dunbar
___________________________________________________________________________
Date: Tue, 15 Feb 2005 17:04:00 -0800
From: Mike Russell
Subject: Re: Re: Another 16-bit test
Dennis Dunbar wrote:
So unfortunately we are left in a sort of limbo,
Theoretically 16 bits
should be better, but we can't see it anywhere because
there is no
output device that will let us see this difference.
Likewise, the small number of people who favor 32 bit
per channel images are in a limbo, not being able to see the difference
that they presume would be visible, if only there were monitors capable of
displaying 96 bit RGB images.
Mike Russell
www.curvemeister.com
www.geigy.2y.net
___________________________________________________________________________
Date: Tue, 15 Feb 2005 17:45:55 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
On 2/15/05 5:27 PM, "Dennis Dunbar"
wrote:
So unfortunately we are left in a sort of limbo,
Theoretically 16 bits
should be better, but we can't see it anywhere because
there is no
output device that will let us see this difference.
Not so, I have a 16-bit capable printer sitting right
here (an Epson 2200) which with the right driver (in my case ImagePrint)
can handle and send high bit data to this device.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Tue, 15 Feb 2005 20:28:30 -0500
From: "Iliah Borg"
Subject: Re: Re: Another 16-bit test
Mike Russell wrote,
Likewise, the small number of people who favor 32 bit
per
channel images are in a limbo, not being able to see
the difference that
they presume would be visible, if only there were
monitors capable of
displaying 96 bit RGB images.
I guess I know what you think of us using floating
point...
Best regards,
ib
___________________________________________________________________________
Date: Tue, 15 Feb 2005 17:44:51 -0800
From: Paul D. DeRocco
Subject: RE: Re: Another 16-bit test
From: Dennis Dunbar
One of the complicating factors in any 8 bit vs 16 bit
test is the
basic limitation imposed on us by the video system.
That is in almost
all cases we are only given an 8 bit view of the image
because the OS
and the video cards only support 8 bit LUTs, (there are
one or two
cards that will support 10 bits but I understand the
Mac OS still
limits the screen draw to 8 bits).
Where you risk seeing a slight difference is if your
8-bit edits degrade things down to six or seven bits of resolution. It's
rare, but you can get slight posterization.
Ciao,
Paul D. DeRocco
___________________________________________________________________________
Date: Tue, 15 Feb 2005 21:22:51 -0500
From: Raphael Bustin
Subject: Re: Re: Another 16-bit test
At 05:45 PM 2/15/2005 -0700, Andrew Rodney wrote:
Not so, I have a 16-bit capable printer sitting right
here (an Epson 2200)
which with the right driver (in my case ImagePrint) can
handle and send high
bit data to this device.
Meaning what, exactly?
"Can handle" might just mean ignoring any low
order bits it finds inconvenient.
You can't logically claim that the printer can
reproduce anything like 16 bits/chan of color, at any reasonable spatial
resolution, using six inks.
You might, just might, on a really good day, find a 16
bpc contone printer... maybe LightJet or some such. But an inkjet?
That's just not realistic.
rafe b.
http://www.terrapinphoto.com
___________________________________________________________________________
Date: Tue, 15 Feb 2005 19:57:14 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
On 2/15/05 7:22 PM, "Raphael Bustin"
wrote:
Meaning what, exactly?
Meaning that the product will use the additional data
when producing the proprietary screening for output.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Wed, 16 Feb 2005 00:09:21 -0500
From: Raphael Bustin
Subject: Re: Re: Another 16-bit test
Can you devise (or have you actually conducted) a test
that can demonstrate an observable, visual benefit of 48 bit (vs 24 bit)
RGB files, printed through the ImagePrint RIP, onto paper in the Epson
2200?
rafe b.
http://www.terrapinphoto.com
___________________________________________________________________________
Date: Wed, 16 Feb 2005 09:01:51 EST
From: Dan Margulis
Subject: Re: Re: Another 16-bit test
David Cardinal writes,
I don't know if Dan's test specifies the gamma of the
8-bit and 16-bit
"test" images, but in linear images 8-bits
sure doesn't provide very much to
work with at the low end. Entire stops of light wind up
being represented by
only a few values.
I don't specify a particular gamma, just any real-world
color photograph with any series of attempts, however far-fetched or
misguided, to improve it.
However, I agree that technically low-gamma images
would be the most likely to show damage from working in 8-bit, if damage
there is. So, when Geoff first described his images, I was very interested,
because he's combining all the disadvantages of a linear file with those of
a fairly wide-gamut RGB, he's making huge moves, and he's got good original
data to work from. I was therefore prepared for them to show an advantage
if they were corrected in 16-bit as opposed to 8-bit.
Granted, the workflow was absurd--anybody who's doing
things this way, and we know Geoff doesn't do this ordinarily, has no
business even thinking about bit depth until they straighten out their work
habits. Still, if *this* torture test doesn't show an advantage for
correcting in 16-bit, it becomes very difficult to even imagine any
conceivable circumstances under which it would be worthwhile to retain the
extra data.
A number of people have stated as a given that if you
work in linear gamma, or in LAB, or in an ultra-wide gamut RGB, you need to
work in 16-bit. AFAIK, not one of them has ever produced even one image
that backs the claim up. It wouldn't surprise me if one exists, but
I'll wait and see.
Dan Margulis
___________________________________________________________________________
Date: Wed, 16 Feb 2005 07:57:37 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
On 2/15/05 10:09 PM, "Raphael Bustin" wrote:
Can you devise (or have you actually
conducted) a test that can demonstrate
an observable, visual benefit of
48 bit (vs 24 bit) RGB files, printed
through the ImagePrint RIP, onto paper
in the Epson 2200?
Yes, you can see it on output depending on image
content, processing etc (naturally).
The amount of unique levels of screening that exist
will determine how many bits of information can uniquely be resolved on
print. It is safe to say that if the driver contains 256 levels of
screens that it could adequately resolve a full 8 bits of data.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Date: Wed, 16 Feb 2005 15:49:50 -0000
From: "Geoff Shearer"
Subject: Re: Another 16-bit test
Andrew,
By this, do you mean that ImagePrint (or some other
software that can use higher-bit depth) will print a "better"
8-bit file because of the ability to resolve the full 8 bits? Or am I
misunderstanding?
Geoff Shearer
___________________________________________________________________________
Date: Wed, 16 Feb 2005 09:48:23 -0700
From: Andrew Rodney
Subject: Re: Re: Another 16-bit test
Not 8-bit, high bit. It can use the higher bit
depth data for the very high number of screens it can use for dither.
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________
Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.