Reading mode: Light Dark

How does RAW black point subtraction work?

Go to last post
N

NateW

Well-known member
Messages
100
Reaction score
39
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?

So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?

And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?

Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
 
The black point bias is added after ADC encoding, so you still get 14 EVs, just with black_level fewer values in the final EV. In other words, the highest represented ADC value is 2^14 - black_level instead of 2^14
 
Last edited:
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?

So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
Linear means that for a given increase in signal, the encoded output always changes by the same amount. It does not mean that zero output corresponds to zero signal.

Ignoring the low order bits would mean counting 0, 512, 1024, 1536, 2048, 2560 etc.

Assume that the signal captured is 1 digital count (DN) above black level, within a possible range of [0 ... 16383].

If your black level is 512, this gives an output of 513, or binary 00 0001 0000 0001

At 5 counts above black level, the output is 517, or binary 00 0001 0000 0101.

So we do use the low order bits, but instead of 16383 levels above zero, we only have (16383-512) = 15871 possible values, a dynamic range of 13.95 log2 DNs. This is close enough to 14 bits for most purposes.

The reason we do this is that read noise can take us below the black level, and we need to capture these negative values for accurate handling of shadow noise, for instance when stacking multiple images. If we used conventional signed integers, we would need an extra bit to denote sign, which be largely wasted. A black level of 512 is easily subtracted in post processing and means we only waste 0.05 bits of potential information.
NateW said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
According to Bill Claff's PhotonsToPhotos site, Sony A7iv (inverse) gain is 4.707e- / DN, so saturation is 77115 e-. Assuming Poisson statistics, noise standard deviation is the square root of this, so 278 e- at max output.

At 4.707 e- / DN this gives 59 DN, which is 5.9 log2 DN.

66ccccb02afb4c00bfdf869dab49c980.jpg.png


I believe the curve above shows signal in electrons, not DN. From Bill's article:
NateW said:
NateW said:
The standard Photon Transfer Curve is a log10-log10 curve of noise in electrons versus signal in electrons.

Because we are interested in photography rather than engineering, we will use log2 rather than log10 throughout this article.
Click to expand...
Click to expand...
It is the noise in the Poisson-distributed noise in the signal (and other contributions) which the photon transfer curve measures.
NateW said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from.
Click to expand...
Hope this helps.

--
Alan Robinson
 
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?

So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?

And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?

Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
Simply, it's just a number subtracted from each image value, for the reasons described above. Basically, if a black level tag is found in the metadata, subtract it, if none is found, don't. My Nikon D7000 provides pre-subtracted raw data, my Z 6 does not.

Some camera's provided black levels aren't right or optional, so the software has to step in with an alternate. See RawTherapee's. camconst.json file for examples.
 
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?
Click to expand...
If such a value is given, then that is where black is supposed to be in that raw image. They wouldn't tell you that value of 512 if it wasn't still biasing all the values. Some cameras subtract it before writing the raw data, but they will report zero as the black point.
NateW said:
So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
You have a misunderstanding of bits. They are logarithmic; you can't just add and subtract them for addition and subtraction; such actions are actually multiplication and division. 14 bits of values minus 5 bits of values actually leaves :

16384 - 512 = 15872. You calculate the bits needed for 15872 values by dividing the log of 15872 by the log of 2:

log(15872)/log(2) = 13.954 bits. Think about it; the 14th bit gave you 8192 more values than the 8192 values of 13 bits. You only lose 512 of those values to the black point bias.
NateW said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
Bill is already subtracting the blackpoint.
NateW said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.

--
Beware of correct answers to wrong questions.
John
http://www.pbase.com/image/55384958.jpg
 
Last edited:
Horshack said:
The black point bias is added after ADC encoding,
Click to expand...
I don’t think so. I think the ADCs zero count point is below the sensor black point. Otherwise, how do we get encoded values below the black point?
Horshack said:
so you still get 14 EVs, just with black_level fewer values in the final EV. In other words, the highest represented ADC value is 2^14 - black_level instead of 2^14
Click to expand...
 
JimKasson said:
Horshack said:
The black point bias is added after ADC encoding,
Click to expand...
I don’t think so. I think the ADCs zero count point is below the sensor black point. Otherwise, how do we get encoded values below the black point?
Click to expand...
Yup. It's an offset before the ADC (or inherent to its internal operation), not after it. As others have pointed out, read noise can create negative values and if you want to average it out over multiple exposures, having what is effectively either an abs() function or clamp at zero will make that fail.

Everything else about Horshack's post was OK though.
 
Horshack said:
JimKasson said:
Horshack said:
The black point bias is added after ADC encoding,
Click to expand...
I don’t think so. I think the ADCs zero count point is below the sensor black point. Otherwise, how do we get encoded values below the black point?
Click to expand...
By having the ADC's output biased, which is then scaled to the black level bias recorded in the ADU value.
Click to expand...
Well, we agree on the bias part, if by bias you mean that the ADC is unipolar with respect to an arbitrary voltage, but bipolar (with an odd encoding) with respect to the black point. But what’s the purpose of adding some number to the ADC count? That seems to be to be an unnecessary complication with overflow side effects.

Oh, one possible reason just occurred to me: calibration. But if that’s necessary, why not handle it in the metadata?

--
https://blog.kasson.com
 
Last edited:
John Sheehy said:
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?
Click to expand...
If such a value is given, then that is where black is supposed to be in that raw image. They wouldn't tell you that value of 512 if it wasn't still biasing all the values. Some cameras subtract it before writing the raw data, but they will report zero as the black point.
John Sheehy said:
So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
You have a misunderstanding of bits. They are logarithmic; you can't just add and subtract them for addition and subtraction; such actions are actually multiplication and division. 14 bits of values minus 5 bits of values actually leaves :

16384 - 512 = 15872. You calculate the bits needed for 15872 values by dividing the log of 15872 by the log of 2:

log(15872)/log(2) = 13.954 bits. Think about it; the 14th bit gave you 8192 more values than the 8192 values of 13 bits. You only lose 512 of those values to the black point bias.
John Sheehy said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
Bill is already subtracting the blackpoint.
John Sheehy said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
John, makes perfect sense, but I'm struggling with order of operations. I just did a "scrabble" of operations in my hack software, putting black subtract after the interpolation operations but I couldn't resolve its place after all the other things, demosaic, white balance, tone curve. It simply didn't produce a decent result unless it was first in the order.
 
JimKasson said:
Horshack said:
JimKasson said:
Horshack said:
The black point bias is added after ADC encoding,
Click to expand...
I don’t think so. I think the ADCs zero count point is below the sensor black point. Otherwise, how do we get encoded values below the black point?
Click to expand...
By having the ADC's output biased, which is then scaled to the black level bias recorded in the ADU value.
Click to expand...
Well, we agree on the bias part, if by bias you mean that the ADC is unipolar with respect to an arbitrary voltage, but bipolar (with an odd encoding) with respect to the black point. But what’s the purpose of adding some number to the ADC count? That seems to be to be an unnecessary complication with overflow side effects.

Oh, one possible reason just occurred to me: calibration. But if that’s necessary, why not handle it in the metadata?
Click to expand...
 
Horshack said:
JimKasson said:
Horshack said:
JimKasson said:
Horshack said:
The black point bias is added after ADC encoding,
Click to expand...
I don’t think so. I think the ADCs zero count point is below the sensor black point. Otherwise, how do we get encoded values below the black point?
Click to expand...
By having the ADC's output biased, which is then scaled to the black level bias recorded in the ADU value.
Click to expand...
Well, we agree on the bias part, if by bias you mean that the ADC is unipolar with respect to an arbitrary voltage, but bipolar (with an odd encoding) with respect to the black point. But what’s the purpose of adding some number to the ADC count? That seems to be to be an unnecessary complication with overflow side effects.

Oh, one possible reason just occurred to me: calibration. But if that’s necessary, why not handle it in the metadata?
Click to expand...
When I wrote my OP I was thinking in terms of the internal ADC operation and how it might convert the internal sampled voltage into a signless output ADU. To me that would be by applying a large positive bias against the internal representation. I didn't mean to suggest the bias was applied externally to the ADC, although on re-reading my OP that's not very clear.
Click to expand...
I believe most cameras now use single ramp ADCs, not SA ones, so the ADC is just a counter and a comparator. The ramp comes from a shared DAC.



I am ignoring CDS.
 
ggbutcher said:
John Sheehy said:
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?
Click to expand...
If such a value is given, then that is where black is supposed to be in that raw image. They wouldn't tell you that value of 512 if it wasn't still biasing all the values. Some cameras subtract it before writing the raw data, but they will report zero as the black point.
ggbutcher said:
So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
You have a misunderstanding of bits. They are logarithmic; you can't just add and subtract them for addition and subtraction; such actions are actually multiplication and division. 14 bits of values minus 5 bits of values actually leaves :

16384 - 512 = 15872. You calculate the bits needed for 15872 values by dividing the log of 15872 by the log of 2:

log(15872)/log(2) = 13.954 bits. Think about it; the 14th bit gave you 8192 more values than the 8192 values of 13 bits. You only lose 512 of those values to the black point bias.
ggbutcher said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
Bill is already subtracting the blackpoint.
ggbutcher said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
John, makes perfect sense, but I'm struggling with order of operations. I just did a "scrabble" of operations in my hack software, putting black subtract after the interpolation operations but I couldn't resolve its place after all the other things, demosaic, white balance, tone curve. It simply didn't produce a decent result unless it was first in the order.
Click to expand...
Black point subtraction needs to be done before application of the compromise matrix. It is conceivable that it could be incorporated into the LUTs.
 
JimKasson said:
ggbutcher said:
John Sheehy said:
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?
Click to expand...
If such a value is given, then that is where black is supposed to be in that raw image. They wouldn't tell you that value of 512 if it wasn't still biasing all the values. Some cameras subtract it before writing the raw data, but they will report zero as the black point.
JimKasson said:
So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
You have a misunderstanding of bits. They are logarithmic; you can't just add and subtract them for addition and subtraction; such actions are actually multiplication and division. 14 bits of values minus 5 bits of values actually leaves :

16384 - 512 = 15872. You calculate the bits needed for 15872 values by dividing the log of 15872 by the log of 2:

log(15872)/log(2) = 13.954 bits. Think about it; the 14th bit gave you 8192 more values than the 8192 values of 13 bits. You only lose 512 of those values to the black point bias.
JimKasson said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
Bill is already subtracting the blackpoint.
JimKasson said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
John, makes perfect sense, but I'm struggling with order of operations. I just did a "scrabble" of operations in my hack software, putting black subtract after the interpolation operations but I couldn't resolve its place after all the other things, demosaic, white balance, tone curve. It simply didn't produce a decent result unless it was first in the order.
Click to expand...
Black point subtraction needs to be done before application of the compromise matrix. It is conceivable that it could be incorporated into the LUTs.
Click to expand...
 
ggbutcher said:
JimKasson said:
ggbutcher said:
John Sheehy said:
NateW said:
I’ve been trying to improve my understanding of how raw photo processing works, but I think I’m getting hung up on black point subtraction. RawDigger tells me that the black point for my A7IV is 512. I’m assuming that this is 512 out of 16383 (.03125), and not after scaling to fill the full 16bit range (.0078125), correct?
Click to expand...
If such a value is given, then that is where black is supposed to be in that raw image. They wouldn't tell you that value of 512 if it wasn't still biasing all the values. Some cameras subtract it before writing the raw data, but they will report zero as the black point.
ggbutcher said:
So, if 512 is 9 bits of data, how is the camera encoding 14stops of linear dynamic range in only the upper 5 bits of data? Is the data encoding only linear after black point subtraction is performed?
Click to expand...
You have a misunderstanding of bits. They are logarithmic; you can't just add and subtract them for addition and subtraction; such actions are actually multiplication and division. 14 bits of values minus 5 bits of values actually leaves :

16384 - 512 = 15872. You calculate the bits needed for 15872 values by dividing the log of 15872 by the log of 2:

log(15872)/log(2) = 13.954 bits. Think about it; the 14th bit gave you 8192 more values than the 8192 values of 13 bits. You only lose 512 of those values to the black point bias.
ggbutcher said:
And if the camera black point is 9 log2 DNS (512/16383) why does the photon transfer curve show that noise maxes out around 6 log2 DNs (64/16383)?
Click to expand...
Bill is already subtracting the blackpoint.
ggbutcher said:
Sorry in advance, I know these are elementary questions. Just trying to locate the misunderstanding them might stem from. Thanks!
Click to expand...
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
John, makes perfect sense, but I'm struggling with order of operations. I just did a "scrabble" of operations in my hack software, putting black subtract after the interpolation operations but I couldn't resolve its place after all the other things, demosaic, white balance, tone curve. It simply didn't produce a decent result unless it was first in the order.
Click to expand...
Black point subtraction needs to be done before application of the compromise matrix. It is conceivable that it could be incorporated into the LUTs.
Click to expand...
I don't use a working profile, no color matrix until export.
Click to expand...
Are you not editing in a colormetric space?
ggbutcher said:
It really didn't like being anywhere but at the front, right after import.
Click to expand...
 
John Sheehy said:
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
I'm working on trying to reverse-engineer's Adobe's blackpoint handling. So far I already established it's not doing simple subtraction (link). By comparison, a cursory check of RawTherapee indicates it does do simple subtraction - the same experiment performed in that link yields identical output for RawTherapee (ie, modifying a blackframe raw so that the ADU values below black level are clamped to the black level yields the same output as the original blackframe raw with the ADU values unomdified).
 
Horshack said:
John Sheehy said:
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
I'm working on trying to reverse-engineer's Adobe's blackpoint handling. So far I already established it's not doing simple subtraction (link). By comparison, a cursory check of RawTherapee indicates it does do simple subtraction - the same experiment performed in that link yields identical output for RawTherapee (ie, modifying a blackframe raw so that the ADU values below black level are clamped to the black level yields the same output as the original blackframe raw with the ADU values unomdified).
Click to expand...
When I do black point subtraction, I do it in a signed representation, so there’s no clamping at that point. I use double precision floating point, which is immense overkill.
 
JimKasson said:
Horshack said:
John Sheehy said:
No self-respecting conversion is going to ignore the blackpoint when it is higher than zero. You can't get correct color when you leave the bias in. However, it is more accurate to maintain original readout values of less than 512 as negative numbers, rather than clipping to 0 (everything 512 or less becomes zero) if you want minimal artifacts for very weak signals, and only clip the data at the last stage to create a display image. All interpolation and resizing is best done when negative values are maintained. This clips less signal and maintains linearity.
Click to expand...
I'm working on trying to reverse-engineer's Adobe's blackpoint handling. So far I already established it's not doing simple subtraction (link). By comparison, a cursory check of RawTherapee indicates it does do simple subtraction - the same experiment performed in that link yields identical output for RawTherapee (ie, modifying a blackframe raw so that the ADU values below black level are clamped to the black level yields the same output as the original blackframe raw with the ADU values unomdified).
Click to expand...
When I do black point subtraction, I do it in a signed representation, so there’s no clamping at that point. I use double precision floating point, which is immense overkill.
Click to expand...
That's how I do it in Octave as well. I think RT uses 32-bit floating point, but it still seems to be clamping to the black level nonetheless.
 
Last edited:
JimKasson said:
I believe most cameras now use single ramp ADCs, not SA ones, so the ADC is just a counter and a comparator. The ramp comes from a shared DAC.
Click to expand...
Eric Fossum wrote (on December 16, 2015):

There is no universal "best" approach that has been developed over the past 20+ years. Single slope and its derivatives/improvements are used, SA is used, and Kawahito's group has pushed the cyclic ADC pretty far. Then there are a lot of hybrid approaches - one for the MSBs and one for closing in on the LSBs. Sigma delta has not really been employed too much since single slope is easier for the lowest order, and higher order sigma delta requires too much digital filter circuitry per column. Gain before the ADC is pretty common these days - something we avoided in the early days because power and area efficient PGAs were not well established.
 
Last edited:
Detail Man said:
JimKasson said:
I believe most cameras now use single ramp ADCs, not SA ones, so the ADC is just a counter and a comparator. The ramp comes from a shared DAC.
Click to expand...
Eric Fossum wrote (on December 16, 2015):

There is no universal "best" approach that has been developed over the past 20+ years. Single slope and its derivatives/improvements are used, SA is used, and Kawahito's group has pushed the cyclic ADC pretty far. Then there are a lot of hybrid approaches - one for the MSBs and one for closing in on the LSBs. Sigma delta has not really been employed too much since single slope is easier for the lowest order, and higher order sigma delta requires too much digital filter circuitry per column. Gain before the ADC is pretty common these days - something we avoided in the early days because power and area efficient PGAs were not well established.
Click to expand...
I would not like to try to put ten or twenty thousand monotonic 16 bit SA ADCs on a CMOS sensor chip.
 
You must log in or register to reply here.

Similar threads

JimKasson
Correcting Raw Black Point Errors with Lightroom's Calibration Panel
Replies
16
Views
210
JimKasson
JimKasson
S
How reliable are “Photons to Photo” data? G9 vs Canon 6DMII
4 5 6
Replies
108
Views
2K
Jens_ac
J
M
  • Question Question
Confusion about Floating Point in Color Space Transforms
Replies
17
Views
83
ggbutcher
ggbutcher
N
Digital Sensor “Characteristic Curves”?
Replies
19
Views
276
Jack Hogan
J
T
Myths about RAW and JPEG -- A thorough (read: long) list.
6 7 8
Replies
150
Views
3K
Bob A L
B

Keyboard shortcuts

f
Forum
m
My threads
Mobile site
About
Editorial content
Cameras & Lenses
Community
All content, design, and layout are Copyright © 1998–2025 Digital Photography Review All Rights Reserved.
Reproduction in whole or part in any form or medium without specific written permission is prohibited.
When you use DPReview links to buy products, the site may earn a commission.
©GPS Media - Guides, Products, Services.
Back
Top