Ad
Ad
Ad
Pages: « 1 2 3 [4] 5 6 ... 10 »   Bottom of Page
Print
Author Topic: Your Curves  (Read 146166 times)
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6899


WWW
« Reply #60 on: July 28, 2007, 09:06:21 AM »
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]

Hi Jeff......Heavens forbid one would be foolish enough to jump to conclusions   , BUT something I've been curious about for a while - relevant - to this discussion - and you may know the answer - you're correct that one can set the histogram read-out for the ino palette to 3 different bit depths; however regardless of that setting, when you pull up a Curves adjustment layer, that dialogue box is still configured from 0 to 255, and when you place a point on a curve, each single step using an arrow key shifts the curve 1 level in the Curves Input/Output data, but some 80~120 levels (give or take) as measured with the 16 bit scale in the info palette. (And 32768/256 = 128, but there is obviously not a lock-step translation probably depending on where in the curve.)

So my question is: why don't we have  a more refined adjustment capability such that we could use the cursors to move these curves one level at a time on a 16 bit scale, hence have more control over the extent of the change with each keystroke? This would be particularly useful when correcting colour casts with the individual channel curves.
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: 1283



WWW
« Reply #61 on: July 28, 2007, 09:13:23 AM »
ReplyReply

Quote
So my question is: why don't we have a more refined adjustment capability such that we could use the cursors to move these curves one level at a time on a 16 bit scale, hence have more control over the extent of the change with each keystroke? This would be particularly useful when correcting colour casts with the individual channel curves.
[{POST_SNAPBACK}][/a]

hehe I wonder that many times, and I think the only answer is priorities: how many photographers/graphic designers as you and me are taking care if their curves change Hue? how many are even using curves? how much effort should Adobe put into a good curve editor, specially when there is no commercial product available with such a powerful curve editing capabilities in the market?
Lucky we are that in CS3 they finally decided to plot the image luminance histogram in the curve editor background.

I was this morning looking with great interest to a PS plugin already commented in this thread, calle Curvemeister. It provides a curve editor than can work on any mode (RGB, Lab, CMYK), without changing the real mode in which the image is codified. And that permits to expand (zoom) the curve editor windows as muchs as your screen allows to: [a href=\"http://www.curvemeister.com/]Curvemeister[/url]

BTW regarding the discusion if ACR curves modify or not the Hue of the image, what do you think? I did some more tests this morning on ACR 4.1 and again, its curves show an important Hue shift in some areas of the image.
« Last Edit: July 28, 2007, 09:13:52 AM by GLuijk » Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6899


WWW
« Reply #62 on: July 28, 2007, 09:32:10 AM »
ReplyReply

Quote
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.

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

OK, by one process or another - there is still a process - that's all I was getting at in essence.

I should add one more point - there's no monopoly over the selection of images for running tests. The validity of the case I made in my essay does not depend on that particular set of images. I've run over a thousand through this software during the past several months and on the whole I find the results it yields very satisfactory - and so do many other users on their own images who have far more professional experience than I do. [Check-out for example Mikkel Aaland's book "Photoshop Lightroom Adventure" just published in an up-dated edition.]

In my essay, I've laid out an approach or methodology that anyone with Camera Raw 4.x or Lightroom and Photoshop could undertake with their own images and see whether or not what I've found is confirmed in their own experience. The common sense criteria are to start with raw files, do the edits in the sequence the software recommends, and push the adjustments as far as necessary to achieve the objectives intended for the image.  So have a go at it with your own images and see for yourself whether my observations are validated in your experience.
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: 6899


WWW
« Reply #63 on: July 28, 2007, 09:40:44 AM »
ReplyReply

Quote
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?
[a href=\"index.php?act=findpost&pid=130147\"][{POST_SNAPBACK}][/a]

Yah - it is a pain - now you see - it takes a damn lot of time to do this stuff! One hopes it makes for educational "value-added"! Looking at your illustrations, there is a difference in procedure I think between what you're doing and what I did for making these measurements. For clarity I can explain again what I did: I do not layer the ACR adjusted image on top of a PS image. I have two sets of images for the comparison: One set is the rendered CR image before and after whatever CR adjustments. The other set is the unadjusted (except for white balance) CR image rendered in Photoshop and then adjusted with PS Curves Adjustment Layers. So I am measuring HSB shifts of the rendered images for each of those sets individually.
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
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #64 on: July 28, 2007, 09:46:09 AM »
ReplyReply

Quote
However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
[a href=\"index.php?act=findpost&pid=130244\"][{POST_SNAPBACK}][/a]
And my apologies to Mark, too. This is way off-topic.  Mark wrote a great article, and it deserves further discussion.

--Rich
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6899


WWW
« Reply #65 on: July 28, 2007, 09:46:52 AM »
ReplyReply

Quote
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).

However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
[a href=\"index.php?act=findpost&pid=130244\"][{POST_SNAPBACK}][/a]

Guillermo, nothing to apologize about - this is about the technical under-belly of the observations we are discussing so as far as I'm concerned it's fine and very interesting. But what I'm still struggling with - and I haven't seen a simple answer (perhaps there is no such thing) - if we start with 12 bit data and end-up with 15 or 16 bit data, what are all those intervening levels: zeros or interpolations? Because no matter what the gymnastics, there are *only* 4096 levels of original information. And secondly, what are the implications for drawing Curves or making HSB adjustments that so much of the data is zeros or interpolation?
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: 6899


WWW
« Reply #66 on: July 28, 2007, 10:00:25 AM »
ReplyReply

Quote
hehe I wonder that many times, and I think the only answer is priorities: how many photographers/graphic designers as you and me are taking care if their curves change Hue? how many are even using curves? how much effort should Adobe put into a good curve editor, specially when there is no commercial product available with such a powerful curve editing capabilities in the market?
Lucky we are that in CS3 they finally decided to plot the image luminance histogram in the curve editor background.

I was this morning looking with great interest to a PS plugin already commented in this thread, calle Curvemeister. It provides a curve editor than can work on any mode (RGB, Lab, CMYK), without changing the real mode in which the image is codified. And that permits to expand (zoom) the curve editor windows as muchs as your screen allows to: Curvemeister

BTW regarding the discusion if ACR curves modify or not the Hue of the image, what do you think? I did some more tests this morning on ACR 4.1 and again, its curves show an important Hue shift in some areas of the image.
[a href=\"index.php?act=findpost&pid=130253\"][{POST_SNAPBACK}][/a]

Guillermo,

I just saw your tests on hue shift this morning and commented with a question on the procedure. I'm not getting such discrepancies - yet - but I'm working on more stuff and if I do I'll mention it.

I'm aware of Curvemeister - looks like a neat program and it seems from various web discussions that many people use it. I downloaded a demo once but didn't get into it much. Perhaps it's worth a closer look.

On the Adobe Curves - of course priorities are always an issue for any commercial operation, but you know - Curves is at the heart of this program, probably the single most important tool in the box and I am sure used by millions. It's probably the case that very few people have twigged on the question of how many levels in 16 bit space get shifted with each tweak of the cursor. It's kind of a "fine point", but as you undoubtedly have observed yourself, especially when doing color correction on individual channel curves, there comes a point when you'd like something mid-way between one shift to the left and one to the right!
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: 6899


WWW
« Reply #67 on: July 28, 2007, 10:03:03 AM »
ReplyReply

Quote
And my apologies to Mark, too. This is way off-topic.  Mark wrote a great article, and it deserves further discussion.

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

Rich, thanks - much appreciated, but I think this is a good discussion - you guys are getting "under the hood" which I think is fine if it helps improve our understanding of what we observe when we use these tools.
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: 1283



WWW
« Reply #68 on: July 28, 2007, 10:47:55 AM »
ReplyReply

Quote
But what I'm still struggling with - and I haven't seen a simple answer (perhaps there is no such thing) - if we start with 12 bit data and end-up with 15 or 16 bit data, what are all those intervening levels: zeros or interpolations? Because no matter what the gymnastics, there are *only* 4096 levels of original information.

And secondly, what are the implications for drawing Curves or making HSB adjustments that so much of the data is zeros or interpolation?
[a href=\"index.php?act=findpost&pid=130263\"][{POST_SNAPBACK}][/a]

Luckily the answer is simple: all those thounsands of levels that "should not" be there, as the original range provides a maximimum of 4096 different levels, are just interpolated.
Look at this, it's a real histogram where each X-axis value corresponds to a value in the 0..65535 range (that is why 0..767 values are represented as the plot is 768 pixels wide):

[span style=\'font-size:8pt;line-height:100%\'](NOTE: for simplicity this is the histogram of only the blue channel.
Two blue types were used to distinguish levels according to their origin)[/span]


- In dark blue the captured levels are represented, i.e. those levels captured by your sensor and that were given a value chosen between only 4096 possible values. They appear now equally spaced as to arrange the original 0..4095 range into the 0..65535 range the raw developer had first to spread them along the range, i.e. multiply them by a factor. So between each pair of captured values a lot of zeroes appeared at the first stage but...
- We only know (RGBG Bayer matrix) one of every three values we need to complete the image information, so we need to interpolate the unknown values. And it's after applying this interpolation algorithm to find out the unknown information when all levels until now set to zero in the histogram get filled with interpolated values, presented in cyan blue.


I will show you a numerical example of the process: imagine that you have one pixel with a captured value B=4000. Next to it a pixel of unknown B value according to the Bayer matrix so we will have to interpolate it. And the the third pixel has a value B=4001.

4000,???,4001

If we would represent the histogram at this point, a continuous histogram in the 0..4095 range would appear.

They are 12 bit numbers in the 0..4095 range, ok? now we are going to develop that RAW file. First we scale the RAW data from 12 bit to 16 bit range, i.e. multiply by 2^4=16.
4000*16 -> 64000
4001*16 -> 64016

Our image becomes now

64000,???,64016

If we would represent the histogram at this point, a non continuous histogram in the 0..65535 range would appear, with equally spaced levels separated by 15 zeros in the spaces between.

Now we apply the interpolation algorithm: to calculate the middle pixel blue value we work out the mean: (64000+64016)/2=64008

The final image is:

64000,64008,64016

Repeating the interpolation process for all unknown pixels, statistically all zeroes will be filled with some values so a continuous histogram in the 0..65535 range would appear, but showing peaks (captured) and valleys (interpolated).


Is that clear now?


______________________

regarding the application of curves to the interpolated data, is no problem at all. The editing tools that you may use will not distinguish which is the origin of a given value, they will simply have a bunch of pixels with 3 RGB values each, and operate them without caring about their origin.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
« Last Edit: July 28, 2007, 11:08:10 AM by GLuijk » Logged

laughfta
Jr. Member
**
Offline Offline

Posts: 89


« Reply #69 on: July 28, 2007, 11:13:14 AM »
ReplyReply

(from post # 43)

Quote
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.

What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6899


WWW
« Reply #70 on: July 28, 2007, 11:39:00 AM »
ReplyReply

Quote
(from post # 43)
What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
[a href=\"index.php?act=findpost&pid=130300\"][{POST_SNAPBACK}][/a]

Gloria, from Bruce Fraser, here are some definitions:

<<Hue: The property of a color that is identified by a color name, such as "red," "green," or "blue." Used as a primary in the HSB (Hue, Saturation, Brightness) color model.

<<Saturation: The property of a color that makes it appear strongly colored. Black, white, and gray have no saturation. A red tomato has high saturation. Pastel colors have low saturation. Also known as Chroma. (This attribute of color is used in the HLS (Hue, Lightness, Saturation) and HSB (Hue, Saturation, Brightness) color models. >>

What we've observed (to varying extent between Guillermo and me) is that curves have much more impact on saturation than they do on hue, but this is how the authors of the program intended it to be. More often than not you will find that if you pump the contrast on an image using Curves in Luminosity Blend Mode, the hue may change little or not at all, but the result looks *crappy* because you inherently expect more saturation than you are getting. That's why the curves were designed that way - but you do have the choice, using Blend Modes in Photoshop, or Vibrance and the HSL panel in ACR 4.x or Lightroom.
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: 6899


WWW
« Reply #71 on: July 28, 2007, 11:43:35 AM »
ReplyReply

Quote
Repeating the interpolation process for all unknown pixels, statistically all zeroes will be filled with some values so a continuous histogram in the 0..65535 range would appear, but showing peaks (captured) and valleys (interpolated).
Is that clear now?
______________________

regarding the application of curves to the interpolated data, is no problem at all. The editing tools that you may use will not distinguish which is the origin of a given value, they will simply have a bunch of pixels with 3 RGB values each, and operate them without caring about their origin.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

Thanks very much Guillermo.
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
bjanes
Sr. Member
****
Online Online

Posts: 2784



« Reply #72 on: July 28, 2007, 11:52:17 AM »
ReplyReply

Quote
Luckily the answer is simple: all those thounsands of levels that "should not" be there, as the original range provides a maximimum of 4096 different levels, are just interpolated.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

Bill
Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #73 on: July 28, 2007, 11:59:53 AM »
ReplyReply

Quote
...
They are 12 bit numbers in the 0..4095 range, ok? now we are going to develop that RAW file. First we scale the RAW data from 12 bit to 16 bit range, i.e. multiply by 2^4=16.
4000*16 -> 64000
4001*16 -> 64016
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

I've re-read our posts, and it looks like we've been talking past each other. I agree with what you've stated above. To expand on it, a 12-bit number can be stored in a 16-bit word, and it will be the "same" 12-bit number (unless it's bit-packed).  That number can be scaled to the full 16-bit range, in this case by multiplying by 16 (2^4). A 14-bit number would be scaled by multiplying by 4 (2^2). This will give a 16-bit range, albeit with "holes" of 16 (or Cool between the values.

CR likely does the initial math this way (and subsequently in FP), but it does not save "16-bit files" as simple unsigned integers in the range 0..65,535.  For perhaps historic reasons, 16-bit files are saved in the 15+1 format described earlier. This format (at least at one time) gave significant processing speed advantages, particularly for blends. If an image pixel ranges from [0 ... 32768], and you multiply image pixels (as in a blending mode) you get a maximum value of 32768x32768. This still fits in a 32bit signed integer. A really fast bit-shift operation can be used instead of a very slow division to bring this value back to the image pixel range. At least that's how the story goes.

I'm not sure if CR scales to 16-bit, or to 15-bit, but I would assume 16-bit, since some cameras now produce 16-bit data files. Either way, one significant bit's worth of data is eventually lost when the image is saved (or at least when opened in Photoshop).  I haven't checked the range of data in CR-generated RAW files - is it 15-bit, or 16-bit?

And now back to curves...

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

Posts: 1283



WWW
« Reply #74 on: July 28, 2007, 12:00:02 PM »
ReplyReply

Quote
(from post # 43)
What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
[a href=\"index.php?act=findpost&pid=130300\"][{POST_SNAPBACK}][/a]

Good point.

Mathematically speaking, Hue, Saturation and Brightness are three independent variables (you can set the value of one of them independently of the value set for the other two).
But one thing is mathematics, and another (usually more important) is perception.

I have been doing some tests and reached the following conclusion of what happens to Saturation when applying a curve in PS Luminance mode (I take this as a reference as until now seems to me the only one that really preserves Hue).
The curves used are a contrast S curve, so dark areas of the image get even darker, and lighted areas get brighter, and an opposite inverted S de-contrast curve.

1. What really happens (I have tested some pixels with your loved probes Mark lol):
- Hue is preserved in all pixels
- Saturation is reduced in those pixels where Bright is increased
- Saturation is increased in those pixels where Bright is reduced


2. What you perceive when looking at the picture:
- There seems to have been an overall saturation loss, but I am looking at the images together again now, and I don't think it is too noticeable, what do you think?

Original



PS Luminance


Curve on the right was used:



My 2 hypothesis why they could do this:

1. Keep saturation when increasing bright may lead to clipping, that is why saturation is reduced in the pixels where the curve increases Bright. To compensate the overall effect, saturation is increased in the pixels where our curve is applying Bright reduction.

2. Human eye behaviour: since it is more difficult to recognize colours in dark areas than bright ones, saturation is increased in pixels that get darker, and reduced in the ones getting brighter.
« Last Edit: July 28, 2007, 12:17:31 PM by GLuijk » Logged

Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1283



WWW
« Reply #75 on: July 28, 2007, 12:02:15 PM »
ReplyReply

Quote
Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

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

You are totally right Bill, we don't GAIN INFORMATION, just GAIN TONE VARIETY. It's the same as when you add noise to avoid banding or posterization. You add no information; in fact you destroy it. But your image gains processing robustness.
This is what I wanted to point, perhaps didn't choose the right words.
« Last Edit: July 28, 2007, 12:02:58 PM by GLuijk » Logged

Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1283



WWW
« Reply #76 on: July 28, 2007, 12:07:51 PM »
ReplyReply

Quote
For perhaps historic reasons, 16-bit files are saved in the 15+1 format described earlier. This format (at least at one time) gave significant processing speed advantages, particularly for blends. If an image pixel ranges from [0 ... 32768], and you multiply image pixels (as in a blending mode) you get a maximum value of 32768x32768. This still fits in a 32bit signed integer.

OK so we agree now. Yes, I guessed some speed reasons for using just 15 bits in PS, but the true is that Adobe give little or no documentation about this fact.
DCRAW really outputs 16-bit files in the total range. That is why I posted the following example:

16-bit TIFF file output from DCRAW:




Now we load it in PS, and press Save.




Adobe has stolen half of my levels!!!!!!!!! wasn't TIFF a losless format?
« Last Edit: July 28, 2007, 12:28:18 PM by GLuijk » Logged

RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #77 on: July 28, 2007, 12:09:32 PM »
ReplyReply

Quote
Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

Bill
[{POST_SNAPBACK}][/a]

Without interpolation, you wouldn't have a complete set of R,G,B values for every pixel.

Rather than scaling the data to 16-bit and doing the interpolation with integer math, the interpolation could also be done in floating point, but regardless, the data has to be interpolated.  Either way,  you're "gaining" a complete set of RGB data for your 6 MB file.  

As a last comment on this, the choice of interpolation algorithm heavily influences the quality of the rendered image. For a good intro, see:
[a href=\"http://scien.stanford.edu/class/psych221/projects/99/tingchen/index.htm]http://scien.stanford.edu/class/psych221/p...gchen/index.htm[/url]
http://web.cecs.pdx.edu/~cklin/demosaic/

Many of the algorithms in use are proprietary.

--Rich
« Last Edit: July 28, 2007, 12:45:41 PM by RichWagner » Logged
bjanes
Sr. Member
****
Online Online

Posts: 2784



« Reply #78 on: July 28, 2007, 01:15:51 PM »
ReplyReply

Quote
Without interpolation, you wouldn't have a complete set of R,G,B values for every pixel.

Rather than scaling the data to 16-bit and doing the interpolation with integer math, the interpolation could also be done in floating point, but regardless, the data has to be interpolated.  Either way,  you're "gaining" a complete set of RGB data for your 6 MB file. 

As a last comment on this, the choice of interpolation algorithm heavily influences the quality of the rendered image. For a good intro, see:
http://scien.stanford.edu/class/psych221/p...gchen/index.htm
http://web.cecs.pdx.edu/~cklin/demosaic/

Many of the algorithms in use are proprietary.

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

Obviously, demosaicing is necessary to have a complete color image, but that is not to say that a 6 MB raw file demosaiced to an 18 MB RGB file would be equal in quality to an 18 MB file with true values for all sites, such as from a super Foveon chip. I'm certain that we are losing both spatial and color information.

Bill
Logged
RichWagner
Newbie
*
Offline Offline

Posts: 26


WWW
« Reply #79 on: July 28, 2007, 01:31:08 PM »
ReplyReply

Quote
Obviously, demosaicing is necessary to have a complete color image, but that is not to say that a 6 MB raw file demosaiced to an 18 MB RGB file would be equal in quality to an 18 MB file with true values for all sites, such as from a super Foveon chip. I'm certain that we are losing both spatial and color information.

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

Certainly, Bill, but that's the trade-off of a CFA chip design. Foveon has its own problems, as do scanning backs like the BetterLight. But I think we all agree - you have to interpolate a RAW file whose data is in a CFA pattern. To go back to your question, what we are gaining by interpolation is the complete RGB data set. That's the only reason it is done.

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

Ad
Ad
Ad