Ad
Ad
Ad
Pages: « 1 2 [3] 4 5 ... 10 »   Bottom of Page
Print
Author Topic: Your Curves  (Read 147396 times)
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1290



WWW
« Reply #40 on: July 27, 2007, 11:08:40 AM »
ReplyReply

Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

But what do they use that bit for? why do I have to work with half the precision, and without being told?!?.

This is what a real 16-bit TIFF histogram (zoom 1:1, maximum detail level) looks like once loaded and saved again using Photoshop. Perhaps the motto "TIFF is a losless format" should be complemented with "...unless PS gets in your way!"

Original


After just Open and Save in PS
« Last Edit: July 27, 2007, 11:10:06 AM by GLuijk » Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6945


WWW
« Reply #41 on: July 27, 2007, 11:17:23 AM »
ReplyReply

Quote
"ACR curves don't preserve Hue, [a href=\"index.php?act=findpost&pid=130140\"][{POST_SNAPBACK}][/a]

Guillermo, where are the measurements that show this? This finding differs from what I usually find, and I believe it also differs from what I understand the math was developed to produce.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1290



WWW
« Reply #42 on: July 27, 2007, 11:26:39 AM »
ReplyReply

Quote
Guillermo, where are the measurements that show this? This finding differs from what I usually find, and I believe it also differs from what I understand the math was developed to produce.
[a href=\"index.php?act=findpost&pid=130145\"][{POST_SNAPBACK}][/a]
OK I will try to pick some samples... please wait.

uffff man, what a pain. did I tell you I hate PS? but I think I managed, and I know why you got the results that ACR preserves tone. Look at these two samples, from top to bottom: ACR curve, PS Luminance blending curve and original image:

[span style=\'font-size:14pt;line-height:100%\']Dress[/span]



where ACR doesn't seem to preserve de Hue but PS-Lum does.


[span style=\'font-size:14pt;line-height:100%\']Lips[/span]



still PS-Lum curves preserve the Hue well and ACR gets very close indeed.


It's funny to see saturation increases in both cases, ACR and PS Lum curves. In this last case the appearance is a saturation loss, but this does not seem true at all as in both tests saturation increased with the PS curve. And more with the ACR one.

This is a very agressive curve, and I think both ACR and PS-Lum curves preserve quite well the Hue, but looking at the histogram discrepancies, it seems that ACR does not perform as well in some tones/areas. And the lip is a good example.

What do you think?
« Last Edit: July 27, 2007, 12:05:15 PM by GLuijk » Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6945


WWW
« Reply #43 on: July 27, 2007, 12:04:07 PM »
ReplyReply

Quote
The 12 bit RAW file is converted to 16 bit into any RAW developer prior to any other process stage. Then true 16-bit white balance is applied, and true 16-bit Bayer demosaicing is done. That is why a developed RAW in linear state is completely full of levels in the lower end of its histogram (no holes at all).
It's in the next step, when the colour profile conversion and gamma compensation are applied, that the lower part if the histogram gets full of holes as an Emmental cheese.

[a href=\"index.php?act=findpost&pid=130142\"][{POST_SNAPBACK}][/a]

Guillermo: When I see an expression like "is converted to" I get uncomfortable. Sure - something is happening, but that doesn't tell me exactly what. And that leads one to wonder what exactly is meant by "true 16-bit White Balance" and "true 16-bit Bayer demosaicing". What is "true" if alot of data is being interpolated or filled with zeros - I don't know exactly what?

What you are saying here also raises questions in my mind about the order in which things happen from the time I acquire the image into the raw converter, process it, and output it to Photoshop (i.e. "render" it). Perhaps you can clarify for me. I was under the impression that the demosaicing happens the moment I acquire the image into Camera Raw - otherwise I wouldn't see a recognizable colour image. Is that right? Now is that happening in 16 bit or in 15 bit mode, and does it really matter much - practically? Now, once the image is in Camera Raw demosaiced, is it in 16-bit or in 15 bit at that moment? -  Because the next thing I'll do is White Balance; again does it matter much whether this happens as 15 or 16 bit mode? What can happen though, as I showed, is that white-balancing can affect the placement of individual channels along the histogram - even leading to clipping.

When the image gets rendered to Photoshop, I believe this is where the conversion to the colour space profile occurs, but I don't see any Emmenthal cheese in the histograms either in ACR or in PS - is this because they don't show the levels in enough detail to recognize it - which your program does? If these holes exist, do they make a visible difference in a print?

The gamma compensation (or correction) happens when? Isn't it already represented in the Camera Raw Interface so I see whatever gamma the converter gives me right there? The brightness and tonal range of the image by the time I finish with it in Camera Raw looks pretty much identical to what I see when I render it in Photoshop, so I am curious again about the sequencing of what is happening under the hood, and what practical effects that sequence may be having.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6945


WWW
« Reply #44 on: July 27, 2007, 12:11:19 PM »
ReplyReply

Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

Andrew,

I'm having real trouble understanding this post. Grateful if you could check the phrasing and clarify it - perhaps also giving some context of what you are replying to. It is a most interesting area to be real clear about. Especially this. I work in "16-bit", but the histogram and the read-out of the curves as U.I. features still behave as if it were 8 bit - i.e. 255 levels are displayed for 16 bit files too, which you see as you read the input-output values in the Curves dialogue and watch the histogram.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
laughfta
Jr. Member
**
Offline Offline

Posts: 89


« Reply #45 on: July 27, 2007, 12:14:43 PM »
ReplyReply

That was fast  

This seems like good science to me. I sure someone will quickly point out any flaws, if they find them.

I think this information (as it presently stands)  should help people obtain strong images from ACR or PS. And will make it much easier to evaluate past and future advice about what the effect is of manipulating the master curve in both.

This is a portion of what Jeff Schewe ( on Dan's ACT forum) quoted Thomas Knoll as saying about the ACR curve:

It maps the min and max of the RGB values (in linear ProPhoto RGB) through
the tone curve, and the middle value is interpolated to exactly preserve
hue. This results in saturation effects that closely match saturation
effects you get from real film tone curves (which many years of looking at
film photos has taught our eyes to like), while preventing the adverse hue
shifts you would otherwise get from the concave and convex parts of the
curve."

I don't see a conflict here—a judgment call is ultimately called for when evaluating adverse hue shifts, which is how it should be.
Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1290



WWW
« Reply #46 on: July 27, 2007, 12:15:04 PM »
ReplyReply

Quote
Guillermo: When I see an expression like "is converted to" I get uncomfortable. Sure - something is happening, but that doesn't tell me exactly what. And that leads one to wonder what exactly is meant by "true 16-bit White Balance" and "true 16-bit Bayer demosaicing". What is "true" if alot of data is being interpolated or filled with zeros - I don't know exactly what?

What you are saying here also raises questions in my mind about the order in which things happen from the time I acquire the image into the raw converter, process it, and output it to Photoshop (i.e. "render" it). Perhaps you can clarify for me. I was under the impression that the demosaicing happens the moment I acquire the image into Camera Raw - otherwise I wouldn't see a recognizable colour image. Is that right? Now is that happening in 16 bit or in 15 bit mode, and does it really matter much - practically? Now, once the image is in Camera Raw demosaiced, is it in 16-bit or in 15 bit at that moment? -  Because the next thing I'll do is White Balance; again does it matter much whether this happens as 15 or 16 bit mode? What can happen though, as I showed, is that white-balancing can affect the placement of individual channels along the histogram - even leading to clipping.

When the image gets rendered to Photoshop, I believe this is where the conversion to the colour space profile occurs, but I don't see any Emmenthal cheese in the histograms either in ACR or in PS - is this because they don't show the levels in enough detail to recognize it - which your program does? If these holes exist, do they make a visible difference in a print?

The gamma compensation (or correction) happens when? Isn't it already represented in the Camera Raw Interface so I see whatever gamma the converter gives me right there? The brightness and tonal range of the image by the time I finish with it in Camera Raw looks pretty much identical to what I see when I render it in Photoshop, so I am curious again about the sequencing of what is happening under the hood, and what practical effects that sequence may be having.
[{POST_SNAPBACK}][/a]

Hey, find above the tests. They are done in PS, ProPhoto 16 bit. No conversions at all.

With true 16-bit, I mean in the complete 0..65535 range, that's all. I don't refer to the genuinity of level values.
ACR shows you a little portion of imaged demosaiced. In fact it develops a little piece of the RAW file in a fast way so user changes can be check in real time.

WB is prior to demosacing. In fact you can do it afterwards (for instance with DCRAW you can appy no WB and apply it later in PS), but it is not recommended and RAW developers always apply it first. Yes, WB can clip. In fact is a linear channel scaling. If your RAW contains a level, let's say: 4000 (12 bit), which in 16 bit becomes 64000, and you apply a WB so a multiplier of let's say 1.5 is applied: 64000*1.5=96000>65535, and hence it gets clipped to 65535.

Yes, I wrote a program to plot 16 bits histograms, find it here: [a href=\"http://www.guillermoluijk.com/software/histogrammar/index.htm]Histogrammar[/url]
It has a tutorial: Tutorial but in Spanish. The holes in the Offtopic (sorry about that) 15-bit PS discussion are from a real PS 16-bit image. Those holes are only 1 level as I used a linear image with no gamma expansion applied.

The gamma compensation is probably applied in real time, as a part of the colour profile conversion (each colour profile has a standard gamma to be applied). So what I think (just guessing) ACR does is a complete RAW development, of only the portion you are currently zooming. Probably with faster and less precise algorithms than those which will be used afterwards once you press "Open".

The stages of RAW development are:
1. Black ofsset substraction
2. Conversion from 12 to 16 bits
3. WB
4. Bayer interpolation
5. Highlight recovery for those needed areas and if activated
6. Colour profile conversion, with gamma.
« Last Edit: July 27, 2007, 12:19:48 PM by GLuijk » Logged

digitaldog
Sr. Member
****
Online Online

Posts: 9170



WWW
« Reply #47 on: July 27, 2007, 12:17:00 PM »
ReplyReply

Quote
Andrew,

I'm having real trouble understanding this post. Grateful if you could check the phrasing and clarify it - perhaps also giving some context of what you are replying to

Is an exact quote referring to the 15-bit versus 16-bit's used in Photoshop.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6945


WWW
« Reply #48 on: July 27, 2007, 12:19:30 PM »
ReplyReply

Quote
That was fast  

It maps the min and max of the RGB values (in linear ProPhoto RGB) through
the tone curve, and the middle value is interpolated to exactly preserve
hue. This results in saturation effects that closely match saturation
effects you get from real film tone curves (which many years of looking at
film photos has taught our eyes to like), while preventing the adverse hue
shifts you would otherwise get from the concave and convex parts of the
curve."

I don't see a conflict here—a judgment call is ultimately called for when evaluating adverse hue shifts, which is how it should be.
[a href=\"index.php?act=findpost&pid=130157\"][{POST_SNAPBACK}][/a]

No - the judgment call is for evaluating saturation shifts, not hue shifts - they don't happen at this stage. That's what the above quote says.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
laughfta
Jr. Member
**
Offline Offline

Posts: 89


« Reply #49 on: July 27, 2007, 12:49:47 PM »
ReplyReply

Quote
No - the judgment call is for evaluating saturation shifts, not hue shifts - they don't happen at this stage. That's what the above quote says.
[a href=\"index.php?act=findpost&pid=130160\"][{POST_SNAPBACK}][/a]

Quote
while preventing the adverse hue shifts...


The way I understood/understand this is that  not all hue shifts are prevented, it is that adverse hue shifts are. And that is a judgment call. And clearly, in light of Guillermo's work, there are some hue shifts, in some areas more than others.

wrong?
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6945


WWW
« Reply #50 on: July 27, 2007, 12:53:55 PM »
ReplyReply

Quote
The way I understood/understand this is that  not all hue shifts are prevented, it is that adverse hue shifts are. And that is a judgment call. And clearly, in light of Guillermo's work, there are some hue shifts, in some areas more than others.

wrong?
[a href=\"index.php?act=findpost&pid=130164\"][{POST_SNAPBACK}][/a]

Wrong - I dunno - different understanding - for sure!  
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
laughfta
Jr. Member
**
Offline Offline

Posts: 89


« Reply #51 on: July 27, 2007, 01:15:31 PM »
ReplyReply

Quote
Wrong - I dunno - different understanding - for sure! 
[a href=\"index.php?act=findpost&pid=130166\"][{POST_SNAPBACK}][/a]

Well, I'm sure it will be clarified at some point—thanks to you for posting your essay.
Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #52 on: July 27, 2007, 01:54:40 PM »
ReplyReply

Quote
With true 16-bit, I mean in the complete 0..65535 range, that's all. I don't refer to the genuinity of level values.
ACR shows you a little portion of imaged demosaiced. In fact it develops a little piece of the RAW file in a fast way so user changes can be check in real time.

...

In fact is a linear channel scaling. If your RAW contains a level, let's say: 4000 (12 bit), which in 16 bit becomes 64000,
...

and you apply a WB so a multiplier of let's say 1.5 is applied: 64000*1.5=96000>65535, and hence it gets clipped to 65535.[a href=\"index.php?act=findpost&pid=130158\"][{POST_SNAPBACK}][/a]

Nope, this is not correct.  4000 in 12-bit is still 4000 in 16-bit. The higher order bits are simply set to zeros. You can confirm this with any calculator that has a "programmer's mode" including the calculator with Mac OS X.  Multiply your 4000 x 1.5 and you get 6000, which uses a whopping 13 bits.  No clipping there.

Adobe Photoshop represents 16-bit image data as a 16-bit unsigned integer, in a form that has the binary point between bits 14 and 15, and therefore can only represent 32,769 unique levels (binary 0000000000000000 through 1000000000000000). This gives a quasi 15-bit range of 0 to 32768. It provides an unambiguous mid-point of 16384 and allows some multiply operations to be performed by bit shifting, which is computationally fast, which in the "old days" was very important for speed. It will decrease the number of levels of *true* 16-bit data by half, but this is of questionable significance.

12-bit data is 12-bit data, even if you drop it into a 15-bit or 16-bit container.

--Rich Wagner
« Last Edit: July 27, 2007, 02:23:35 PM by RichWagner » Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #53 on: July 27, 2007, 03:32:09 PM »
ReplyReply

Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

In the "good ole' days" of CS2, you could actually set the info palette to show the 16-bit data. Now, in CS3, it appears that all high-bit data is shown in 8-bit precision in the info panel, and you can't toggle it as you could previously.

--Rich
Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1290



WWW
« Reply #54 on: July 27, 2007, 03:32:34 PM »
ReplyReply

Quote
Nope, this is not correct.  4000 in 12-bit is still 4000 in 16-bit. The higher order bits are simply set to zeros. You can confirm this with any calculator that has a "programmer's mode" including the calculator with Mac OS X.  Multiply your 4000 x 1.5 and you get 6000, which uses a whopping 13 bits.  No clipping there.

Adobe Photoshop represents 16-bit image data as a 16-bit unsigned integer, in a form that has the binary point between bits 14 and 15, and therefore can only represent 32,769 unique levels (binary 0000000000000000 through 1000000000000000). This gives a quasi 15-bit range of 0 to 32768. It provides an unambiguous mid-point of 16384 and allows some multiply operations to be performed by bit shifting, which is computationally fast, which in the "old days" was very important for speed. It will decrease the number of levels of *true* 16-bit data by half, but this is of questionable significance.

12-bit data is 12-bit data, even if you drop it into a 15-bit or 16-bit container.

--Rich Wagner
[a href=\"index.php?act=findpost&pid=130178\"][{POST_SNAPBACK}][/a]

Rich, when converting n bit data into N bit data with N>n, two things may happen:
1. As you say, high order bits are set to zero
2. High order bits are occupied by the high order bits of the original range.

The second is the case of digital photography, where 12-bit information codified into the RAW file, is transformed first into 16 bit by setting those 12-bit as the higher 12 bits of a 16-bit dword, so the lower 4 bits are the ones set to zero (which equals to multiply by 16).
So 4095 becomes 4095*16=65520, or in binary 111111111111 becomes 1111111111110000
Actually RAW developers as DCRAW or anyone perform calculations in floating point to avoid error propagation, and the result is rounded in the end.


I didn't understand your point about Photoshop 1 bit drop, I have produced with DCRAW 16-bits images that become 15 bits in the meaning that one of every two levels is rounded to the nearest 15-bit equivalent. But I don't know the real reason for this precision lose.


This is a true RAW histogram obtained with DCRAW's -D option. That means no black offset is substracted as can be seen, no scaling and no demosaicing is done:




But once the image is developed, a 16-bit file is obtained with levels filled ranging 0 to 65535 (I constantly read TIFF 16-bit images and calculate their 16-bit histograms):





« Last Edit: July 27, 2007, 03:35:02 PM by GLuijk » Logged

Schewe
Sr. Member
****
Offline Offline

Posts: 5489


WWW
« Reply #55 on: July 27, 2007, 04:09:21 PM »
ReplyReply

Quote
In the "good ole' days" of CS2, you could actually set the info palette to show the 16-bit data. Now, in CS3, it appears that all high-bit data is shown in 8-bit precision in the info panel, and you can't toggle it as you could previously.
[a href=\"index.php?act=findpost&pid=130189\"][{POST_SNAPBACK}][/a]

Uh, in the Info palette, see the little flyout menu by the Sampler icon? Check that flyout where you can set the readout to 8/16/32 bit with lots of other options...it's not wise to jump to conclusions...
Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #56 on: July 27, 2007, 06:43:32 PM »
ReplyReply

Quote
Uh, in the Info palette, see the little flyout menu by the Sampler icon? Check that flyout where you can set the readout to 8/16/32 bit with lots of other options...it's not wise to jump to conclusions...
[a href=\"index.php?act=findpost&pid=130196\"][{POST_SNAPBACK}][/a]

Uh, no?  Not at first, and I spent 15 minutes looking.  It's not in the Info palette options - where one would elpect to find it, and clicking on "8-bit" doesn't do it, and using "shift, option or command" like it says doesn't do it, and...  Oh, now that you told me it's there, I see that there's a 3-pixel triangle next to the eyedropper that indicates a flyout menu!  Got it!

Thanks, Jeff.

--Rich
Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #57 on: July 27, 2007, 09:07:35 PM »
ReplyReply

Quote
Rich, when converting n bit data into N bit data with N>n, two things may happen:
1. As you say, high order bits are set to zero
2. High order bits are occupied by the high order bits of the original range.
[{POST_SNAPBACK}][/a]
I disagree with your Number 2... see below:
Quote
The second is the case of digital photography, where 12-bit information codified into the RAW file, is transformed first into 16 bit by setting those 12-bit as the higher 12 bits of a 16-bit dword, so the lower 4 bits are the ones set to zero (which equals to multiply by 16).
So 4095 becomes 4095*16=65520, or in binary 111111111111 becomes 1111111111110000
This is related to Endianness of the RAW file, not multiplication.  If it were due to multiplication, your raw data would range from zero (0 x 16) to 65520, and any positive offset or multiplication of the raw data would quickly overflow. (See, e.g., [a href=\"http://en.wikipedia.org/wiki/Big_endian)]http://en.wikipedia.org/wiki/Big_endian)[/url] Note that Photoshop cannot display the number you obtained above - it is out of the range that I provided earlier.

From the DNG spec:
BitsPerSample
Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if
SamplesPerPixel is not equal to 1.
If BitsPerSample is not equal to 8 or 16 or 32, then the bits must be packed into bytes using the
TIFF default FillOrder of 1 (big-endian), even if the TIFF file itself uses little-endian byte
order.

OriginalRawFileData
Description
If the DNG file was converted from a non-DNG raw file, then this tag contains the compressed
contents of that original raw file. The contents of this tag always use the big-endian byte order.
Quote
I didn't understand your point about Photoshop 1 bit drop, I have produced with DCRAW 16-bits images that become 15 bits in the meaning that one of every two levels is rounded to the nearest 15-bit equivalent. But I don't know the real reason for this precision lose.
It's because of exactly what's been stated. Photoshop uses an unsigned 16-bit integer with 15-bit precision. See, for example, Bruce Lindbloom's note: http://www.brucelindbloom.com/index.html?R...enceImages.html or Rags Gardner's description: http://www.rags-int-inc.com/PhotoTechStuff.../AdobeMath.html if you don't believe me, or Andrew.
Quote
This is a true RAW histogram obtained with DCRAW's -D option. That means no black offset is substracted as can be seen, no scaling and no demosaicing is done:
Yup. Note that the data range is from zero to about 4095 - it sure doesn't go to 65k as you predicted it would.  The black offset shows that there is baseline noise - you never get zero output from the ADCs. BTW, the DNG BlackLevel and WhiteLevel tags tell you which of this data you can use - and frequently (like with my D2X), the range does not extend to 4095 - it's more like 3880. This is due mostly to sensor non-linearity.
Quote
But once the image is developed, a 16-bit file is obtained with levels filled ranging 0 to 65535 (I constantly read TIFF 16-bit images and calculate their 16-bit histograms):
Sure, DCRAW is giving full 16-bit output. You can stretch it out and scale the 12-bit as far as you want, but that's a different issue. Note that you get jagged histograms if all you do is scale (and if you look closely enough). There are a bunch of zero-valued levels in between the true data points, unlike if the data was 16-bit to begin with, like some scanners and digital backs provide (e.g., Kodak DSC Pro SLR cameras).  Iridient's Raw Developer also gives true 16-bit output.

The "rounding" that you describe occuring in Photoshop will also happen with the 16-bit reference files provided by Bruce Lindbloom if you open/save them with Photoshop. You end up with 15-bit data. That's nothing new.

Note also that Photoshop CS3 still has some math errors, but they're not related to what you describe: see Adobe Forums: http://tinyurl.com/24otay

Cheers,

--Rich
« Last Edit: July 27, 2007, 10:25:03 PM by RichWagner » Logged
Chris_T
Sr. Member
****
Offline Offline

Posts: 541


« Reply #58 on: July 28, 2007, 07:27:46 AM »
ReplyReply

Quote
Now about the images - I infer from your comment that you are thinking of some kind of standard or normative set of test images that the whole industry would adopt as a common platform for testing everything and anything - again not a bad idea in principle (something like the input to an ISO standard I suppose), but I'm glad you realize that would have been "a bit much" for Your's Truly to take-on. You know how these things happen: committees of interested parties or existing associations get appointed to develop the material.  Years of in-committee discussion and debate plus alpha and and beta testing with a host of outside experts would take place - then IF EVER a consensus were to emerge, that organization would produce the set of images for the whole world to use - voluntarily of course.  But not a bad idea in principle. As usual, the devil would be in the details.......................
[a href=\"index.php?act=findpost&pid=130138\"][{POST_SNAPBACK}][/a]

A somewhat relevant analogy is how PCs' performance are measured with benchmarks. There are different benchmarks for measuring integers, FP, graphics, etc. Likewise, different sets of images can be used for evaluating noise reduction, sharpening, stitching tools, etc.

Long before the PC benchmarks were "standardized" by committees, vendors had been using their proprietary ones. Afterall, they need them to evaluate their own designs and make tradeoffs during the development cycle. Some vendors would then demo their products with these. More sophisticated customers would apply them to competative products, leading those vendors to create their own benchmarks. Eventually, they all come to their senses and grudgingly agree to some "standardized" benchmarks. Not perfect, but certainly a huge improvement over free for all. Design or evaluate by benchmarks are not sufficient, but certainly necessary.

Digital imaging tools can and should follow a similar path. It will take one vendor to begin with a set of images to demo his product. (If the vendor has done any testing at all, he would already have this set of images available.) Users and competitors can then challenge and revise the set. Over time, an "accepted" set of images will evolve, with or without the blessing of a committee.

To do this, a vendor does not need to be a genius, but he must have faith in his product, and the courage to demo it properly.
« Last Edit: July 28, 2007, 07:29:07 AM by Chris_T » Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1290



WWW
« Reply #59 on: July 28, 2007, 08:20:23 AM »
ReplyReply

Quote
Yup. Note that the data range is from zero to about 4095 - it sure doesn't go to 65k as you predicted it would.

No Rich, the 0 to 4095 plot is pure RAW data, non processed in any way obtained through DCRAW's special option -D, as I told you. But once developed the 12 bit range is adapted to the expanded 16 bit range, and there all developing stages take place (you can look at how this is performed in DCRAW's source code, look for the scale_colors() function, which BTW deals with floating point numbers not integers).
That is why I also showed you a 16-bit histogram ranging 0..65535, which is the one you get once the development process is done.

Find here some histogram plots from a DCRAW's developed image, in zoom 1:1 detail (i.e. every pixel column corresponds to one level in the 0..65535 range). The numbers up left and up right show you the displayed 16-bit range. These histgrams are almost completely full (no gamma has been applied yet, gamma correction generates holes in the low end of the histogram and in fact is the only true reason why holes appear in the 16-bit histogram):
- The peaks correspond to the original captured levels in the 0..4095 range, and you can see they have been scaled from their original range to take advantage of the expanded 16 bit range. The different scaling for each channel is due to the WB.
- And the remaining levels between peaks (and also in the peaks themselves) are the interpolated values generated in the demosaicing process, as they were already calculated on a 16-bit basis precision.

Last plot is a zoom out version ranging levels 0 to 24575, as you can see far beyond the 4095 limit. Last level with information in this case was 56239 in the blue channel as a result of a light underexposure (I am a really bad street photographer), but normally a few blown pixels reach 65535 in some channel.




You can check by yourself making use of Histogrammar and Histogrammar tutorial on any developed file of your own.

BTW my program provides a little statistic about the analysed image, among other information. For the image above:
Filled levels:
  R: 42327 (64,6% of available)
  G: 44453 (67,8% of available)
  B: 54404 (83% of available)
Linear dynamic range:
  RGB: 56204 (86% of available), range [36..56239]
  R: 44292 (68% of available), range [36..44327]
  G: 48004 (73% of available), range [119..48122]
  B: 56182 (86% of available), range [58..56239]

However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
« Last Edit: July 28, 2007, 09:04:28 AM by GLuijk » Logged

Pages: « 1 2 [3] 4 5 ... 10 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad