 # What is the dynamic range of a JPEG image?

Started Jan 9, 2016 | Discussions
 Forum

Andy C Knight wrote:

D Cox wrote:

xpatUSA wrote:

D Cox wrote:

Are you looking for a graph of "Number-of-Photons-Hitting-a-Pixel" against numbers in the file from zero to 255 ? I think this will vary according to the particular sensor and the ISO setting.

No, Don. I am looking for the reason why some people say a JPEG's dynamic range is 8 stops (by virtue of JPEG being 8-bit) and others say it is more, e.g. 11 stops.

I think because they are confused between two completely different uses of binary numbers.

The difference between a JPG file and a 16-bit TIF file is not the range but the number of steps (integers) within that range. A 16-bit file can potentially give you better gradation, but not better dynamic range.

Not trying to hijack the thread, but may I ask some more direct questions which may (or may not :-D) give some clarity to this thread...

1. What is "Dynamic range"

2. Does an 8 bit RAW file (which contains one pixel with a single integer between 0 and 255) have infinite DR, if the noise is zero? (since 255/0 is infinity??) Am I even on the right track??

I previously thought that a lossless 8 bit JPG had a max DR of 8 bits per pixel... Or am I confused with SNR or something else??

See here .

Jack

Complain
Re: What is the dynamic range of a JPEG image?

Jack Hogan wrote:

xpatUSA wrote:

Jack Hogan wrote:

xpatUSA wrote: What would be your calculation for a ProPhoto JPEG image where the max RGB is 240,240,240 and the min RGB is 4,4,4?

I am going to pull a quick attribute substitution while you are not looking and say that what that's going to give you is the contrast ratio of the image, as opposed to the DR of any item in the chain. Following DM's approach, where color data is reverted to linear relative luminance according to ProPhoto's gamma curve

Trying to keep up, is the linear relative luminance in units of Y as given by aR+bG+cB where a,b,c are the coefficients found in Rec. 709 etc? In which case, can I instead use Bruce's CIE calculator, converting RGB numbers (for a color space, it's illuminant and exponent) to XYZ or xyY and use those values of Y to derive what has now become 'Contrast Ratio'?

Hi Ted,

I am simplifying, but the end results are not going to be much different. If the three RGB values are the same, the coefficients used to determine the luminosity component are immaterial because they add up to 1:

0.2*100 +0.7*100 + 0.1*100 = 100.

A light bulb glows

for an 8-bit file resulting from encoding 14-bit raw data:

Contrast Ratio = 228.58 / 0.25682 = 890.

Trying to match that first number (to see if I'm following) using said BT.709 coefficients for the higher JPEG level R=G=B=240:

Y = 0.2126 R + 0.7152 G + 0.0722 B where RGB are linear and normalized to 1

Y = (0.2126x(240/255)^1.8+0.7152x(240/255)^1.8+0.0722x(240/255)^1.8)x255 = 229.74 so I'm wrong as usual. Wrong coefficients? Looks like you might have use D50 adapted . . .

Looks to me like rounding error in the numerator: (240/255)^1.8*255 = 228.6. And the denominator is in the linear region of ProPhoto (second line below) . . . in which case could I use Bruce's calculator but select D50 going from RGB to XYZ.

The same exercise with sRGb results in a CR of 713. The question is whether these contrast ratios can be related back to some form of a DR.

Had forgotten about the linear bit (as similarly found in sRGB), duh.

Think I'll take a break for today, I'm getting there though.

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
Re: What is the dynamic range of a JPEG image?

xpatUSA wrote:

Jack Hogan wrote:

I am simplifying, but the end results are not going to be much different. If the three RGB values are the same, the coefficients used to determine the luminosity component are immaterial because they add up to 1:

0.2*100 +0.7*100 + 0.1*100 = 100.

A light bulb glows

Exactly! I was reading all this color conversions with some surprise. I thought it was unnecessary and you could use the nonlinear part only. And Jack showed why! Thanx. I started to be a bit concerned I missed something.

-- hide signature --

/Roland
Kalpanika X3F tools:
https://github.com/kalpanika/x3f

Roland Karlsson's gear list:Roland Karlsson's gear list
Sigma DP3 Merrill Sigma dp2 Quattro Sony RX100 III Pentax K-3 Pentax K-1 +14 more
Complain

Roland Karlsson wrote:

Andy C Knight wrote:

I previously thought that a lossless 8 bit JPG had a max DR of 8 bits per pixel... Or am I confused with SNR or something else??

Ah ... this is the kernel of the poodle!

My claim is that if you use compressed coding (as sRGB JPEG does) then the dynamic range is not the actual digital values, but what they represent decoded.

I have heard that you then get 11 [stops].

Indeed I am becoming more persuaded that is the case, Roland.

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
Success - could use the Lindbloom calculator . .

xpatUSA wrote:

Jack Hogan wrote:

xpatUSA wrote:

Jack Hogan wrote:

xpatUSA wrote: What would be your calculation for a ProPhoto JPEG image where the max RGB is 240,240,240 and the min RGB is 4,4,4?

I am going to pull a quick attribute substitution while you are not looking and say that what that's going to give you is the contrast ratio of the image, as opposed to the DR of any item in the chain. Following DM's approach, where color data is reverted to linear relative luminance according to ProPhoto's gamma curve

Trying to keep up, is the linear relative luminance in units of Y as given by aR+bG+cB where a,b,c are the coefficients found in Rec. 709 etc? In which case, can I instead use Bruce's CIE calculator, converting RGB numbers (for a color space, it's illuminant and exponent) to XYZ or xyY and use those values of Y to derive what has now become 'Contrast Ratio'?

Hi Ted,

I am simplifying, but the end results are not going to be much different. If the three RGB values are the same, the coefficients used to determine the luminosity component are immaterial because they add up to 1:

0.2*100 +0.7*100 + 0.1*100 = 100.

A light bulb glows

for an 8-bit file resulting from encoding 14-bit raw data:

Contrast Ratio = 228.58 / 0.25682 = 890.

Trying to match that first number (to see if I'm following) using said BT.709 coefficients for the higher JPEG level R=G=B=240:

Y = 0.2126 R + 0.7152 G + 0.0722 B where RGB are linear and normalized to 1

Y = (0.2126x(240/255)^1.8+0.7152x(240/255)^1.8+0.0722x(240/255)^1.8)x255 = 229.74 so I'm wrong as usual. Wrong coefficients? Looks like you might have use D50 adapted . . .

Looks to me like rounding error in the numerator: (240/255)^1.8*255 = 228.6. And the denominator is in the linear region of ProPhoto (second line below) . . . in which case could I use Bruce's calculator but select D50 going from RGB to XYZ.

The same exercise with sRGb results in a CR of 713. The question is whether these contrast ratios can be related back to some form of a DR.

I put the formula for linear sRGB into a spreadsheet and a) got close to your value of 713 and b) observed the same numbers as in my spreadsheet using Bruce's calculator: Whether that ratio of 718 or your 713, either one, is "the DR of my JPEG" could now be a matter for discussion, now that I've caught up with the arithmetic.

Maybe it's the "linear dynamic range" . . .

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
Re: What is the dynamic range of a JPEG (encoded) image ?

Jack Hogan wrote:

xpatUSA wrote: Prompted by DM's response or at least the part that I understood, it seems that the question above is all wrong and that I should at least be talking about linear Y.

So I've changed tack and used Bruce's calculator to avoid tedious arithmetic. First, I entered sRGB numbers 1,1,1 and then 255,255,255 to get the Y part of xyY (linear luminance) and calculated the DR as log(2)(Y1/Y255) EV. Gamma "sRGB" and Bradford D65.

Then I repeated the exercise for ProPhoto, gamma 1.8, Bradford D50.

I got 11.64 EV for sRGB and 14.377 EV for ProPhoto.

Hi Ted, imho those numbers are too big. Recall that

DR = Maximum recordable signal / minimum acceptable signal.

The numerator is easy to determine, the denominator harder because subjective. If we assume 8-bit sRGB, Jpeg Numbers (JN) near zero are linearly related to the input (in e- or approximately also to 14-bit raw data). Ignoring perceptual effects, if we assume a clean capture at base ISO the minimum acceptable signal is probably going to be limited by quantization error as the familiar SNR=x criterion for acceptability (x=1 for engineers) goes out the window at these tiny gains* in JN/e-. So the minimum acceptable signal is even more subjective and probably going to be determined by how much quantization error you are willing to stomach: 1%, 10%, 30%... How low will you go?

I think by looking at the graph above most people would feel that the signal stops being acceptable somewhere below 2DN possibly as low as 0.5 or even 0.25 (JN in this post, the graph comes from this article ). So that's the denominator from which this Jpeg's DR can be very subjectively estimated at somewhere around 7-10 stops. What would you choose?

This is with a very clean capture. As more electronic noise is added it starts becoming the dominant factor in the denominator. But then you are measuring the DR of the image data, not the Jpeg container.

* The gain in the graph is 0.125DN/e-. As a reference, assume a camera with FWC of about 26400e-. Then for 8-bit sRGB signals near zero in the linear region gain = 12.92*255/26400 = 0.125JN/e-.

.

Good thoughts expressed, Jack. A few nagging things that are haunting the cobwebs of my mind:

 All of the sRGB ICC Color Profiles that I have inspected (using ICC Profile Inspector 2.4) indicate that various implementations of (the irritatingly non-unitary "sRGB color-space") use a (seemingly unfortunately) low number of "look-up-table points" (1024 total - the only exception being the "RT_sRGB.icm" color-profile in RAW Therapee, which uses 4096 points). It seems that this may result in an (either modified, or) additional source of (non-linear, level-dependent, complicated) "quantization" effects existing within the JPEG encoding end of things ?

 Remember that what will ultimately substantively matter to the "perceptual faculties of our minds' eyes" as viewers of such images is (further) affected by the JPEG decoding utilized in any given application (as well as printer/display characteristics, viewing parameters, viewing ambient light conditions, etc.). This "chilling factoid" about JPEG-decoded accuracy set me back:

The decompressed subimage can be compared to the original subimage ... by taking the difference (original - uncompressed) results ... with an average absolute error of about 5 values per pixels (i.e.): I (think) that they are describing an average error of 5 out of 255 (decoded, linear) "tone-levels". If so, that is a (Max Signal) / (Average Error) Ratio of 5.6724253411 EV (Holy Baloney, Batman ! ).

Arithmetic rounding errors exist (within JPEG decoding, as well as JPG encoding, internal processes).

I know little about "look-up-tables" ("LUT"s). (If/when used), what may be their "arithmetic errors" ?

In my previously posted calculations (yielding a reported total value of 14.6454141597 [bits]), what was a (likely) simplistic assumption was made that the non-linearly sized "gradation differences", the limited number of points of the gamma-correction look-up-tables, and the fact that "black-point compensation" is utilized (in certain particular sRGB Color Profiles), would not act to degrade my lofty "calculational heights".

.

DM

Complain
Re: What is the dynamic range of a JPEG (encoded) image ?

Detail Man wrote:

Good thoughts expressed, Jack. A few nagging things that are haunting the cobwebs of my mind:

 All of the sRGB ICC Color Profiles that I have inspected (using ICC Profile Inspector 2.4) indicate that various implementations of (the irritatingly non-unitary "sRGB color-space") use a (seemingly unfortunately) low number of "look-up-table points" (1024 total - the only exception being the "RT_sRGB.icm" color-profile in RAW Therapee, which uses 4096 points). It seems that this may result in an (either modified, or) additional source of (non-linear, level-dependent, complicated) "quantization" effects existing within the JPEG encoding end of things ?

 Remember that what will ultimately substantively matter to the "perceptual faculties of our minds' eyes" as viewers of such images is (further) affected by the JPEG decoding utilized in any given application (as well as printer/display characteristics, viewing parameters, viewing ambient light conditions, etc.). This "chilling factoid" about JPEG-decoded accuracy set me back:

The decompressed subimage can be compared to the original subimage ... by taking the difference (original - uncompressed) results ... with an average absolute error of about 5 values per pixels (i.e.):

I (think) that they are describing an average error of 5 out of 255 (decoded, linear) "tone-levels". If so, that is a (Max Signal) / (Average Error) Ratio of 5.6724253411 EV (Holy Baloney, Batman ! ).

Arithmetic rounding errors exist (within JPEG decoding, as well as JPG encoding, internal processes).

I know little about "look-up-tables" ("LUT"s). (If/when used), what may be their "arithmetic errors" ?

In my previously posted calculations (yielding a reported total value of 14.6454141597 [bits]), what was a (likely) simplistic assumption was made that the non-linearly sized "gradation differences", the limited number of points of the gamma-correction look-up-tables, and the fact that "black-point compensation" is utilized (in certain particular sRGB Color Profiles), would not act to degrade my lofty "calculational heights".

All good observations. Yes, the real world is not as perfect s the theoretical world.

I assume a 1024 look up table is not as bad as it sounds though. The conversion function is quite smooth and to interpolate the intermediate values is quite easy. I assume linear interpolation is good enough, but, as the function is known, it is possible to do even better. Linear interpolation tends to give a systematic error for convex and concave functions.

-- hide signature --

/Roland
Kalpanika X3F tools:
https://github.com/kalpanika/x3f

Roland Karlsson's gear list:Roland Karlsson's gear list
Sigma DP3 Merrill Sigma dp2 Quattro Sony RX100 III Pentax K-3 Pentax K-1 +14 more
Complain
Re: Success - could use the Lindbloom calculator . .

xpatUSA wrote:I put the formula for linear sRGB into a spreadsheet and a) got close to your value of 713 and b) observed the same numbers as in my spreadsheet using Bruce's calculator:

Whether that ratio of 718 or your 713, either one, is "the DR of my JPEG" could now be a matter for discussion, now that I've caught up with the arithmetic.

I was working off 14-bit discrete data. If you do it in floating point, you indeed get 717.7 in sRGB

CR = [(240/255+0.055)/1.055]^2.4 / [(4/255)/12.92] = 717.70

Jack

PS On the other hand it looks like Bruce's gamma curve for ProPhoto does not include the linear portion?  If I do the ProPhoto calculation in floating point I get 914.55

Complain
Re: What is the dynamic range of a JPEG (encoded) image ?

Detail Man wrote:

 All of the sRGB ICC Color Profiles that I have inspected (using ICC Profile Inspector 2.4) indicate that various implementations of (the irritatingly non-unitary "sRGB color-space") use a (seemingly unfortunately) low number of "look-up-table points" (1024 total - the only exception being the "RT_sRGB.icm" color-profile in RAW Therapee, which uses 4096 points). It seems that this may result in an (either modified, or) additional source of (non-linear, level-dependent, complicated) "quantization" effects existing within the JPEG encoding end of things ?

 Remember that what will ultimately substantively matter to the "perceptual faculties of our minds' eyes" as viewers of such images is (further) affected by the JPEG decoding utilized in any given application (as well as printer/display characteristics, viewing parameters, viewing ambient light conditions, etc.). This "chilling factoid" about JPEG-decoded accuracy set me back:

The decompressed subimage can be compared to the original subimage ... by taking the difference (original - uncompressed) results ... with an average absolute error of about 5 values per pixels (i.e.): I (think) that they are describing an average error of 5 out of 255 (decoded, linear) "tone-levels". If so, that is a (Max Signal) / (Average Error) Ratio of 5.6724253411 EV (Holy Baloney, Batman ! ).

Arithmetic rounding errors exist (within JPEG decoding, as well as JPG encoding, internal processes).

I know little about "look-up-tables" ("LUT"s). (If/when used), what may be their "arithmetic errors" ?

In my previously posted calculations (yielding a reported total value of 14.6454141597 [bits]), what was a (likely) simplistic assumption was made that the non-linearly sized "gradation differences", the limited number of points of the gamma-correction look-up-tables, and the fact that "black-point compensation" is utilized (in certain particular sRGB Color Profiles), would not act to degrade my lofty "calculational heights".

Right, DM.  I think one thing to keep in mind is that the chosen gamma is typically very close to a 'square rooter', which is a fairly efficient way to encode data that behaves according to Poisson statistics.  So an error of 5 levels may mean very little in terms of the available quality of the recorded information, depending on the size of the underlying signal.

Quantization error is on the other hand a big deal at 8 bits in the shadows.

Jack

Complain

xpatUSA wrote:

Roland Karlsson wrote:

Andy C Knight wrote:

I previously thought that a lossless 8 bit JPG had a max DR of 8 bits per pixel... Or am I confused with SNR or something else??

Ah ... this is the kernel of the poodle!

My claim is that if you use compressed coding (as sRGB JPEG does) then the dynamic range is not the actual digital values, but what they represent decoded.

I have heard that you then get 11 [stops].

Indeed I am becoming more persuaded that is the case, Roland.

And with a different coding, you could use a JPG to represent a range of as many stops as you want (within reason).

Adjustments made from a raw file with a Curve tool can allow the range of integers used in a file to represent various ranges of numbers of photons hitting pixels.

However, there is not much point in allocating numbers in a file to numbers of photons greater than will fill a well. Even with 16 bits, integers are a scarce resource. So one avoids "clipping".

D Cox's gear list:D Cox's gear list
Sigma fp
Complain
Re: Success - could use the Lindbloom calculator . .

Jack Hogan wrote:

xpatUSA wrote:I put the formula for linear sRGB into a spreadsheet and a) got close to your value of 713 and b) observed the same numbers as in my spreadsheet using Bruce's calculator:

Whether that ratio of 718 or your 713, either one, is "the DR of my JPEG" could now be a matter for discussion, now that I've caught up with the arithmetic.

I was working off 14-bit discrete data. If you do it in floating point, you indeed get 717.7 in sRGB

CR = [(240/255+0.055)/1.055]^2.4 / [(4/255)/12.92] = 717.70

Jack

PS On the other hand it looks like Bruce's gamma curve for ProPhoto does not include the linear portion? If I do the ProPhoto calculation in floating point I get 914.55

Gets better and better. As to ProPhoto: I don't publish such JPEGs that often, so it can remain a minor niggle for now.

Thanks again.

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
Re: What is the dynamic range of a JPEG image?
2

So the minimum acceptable signal is even more subjective and probably going to be determined by how much quantization error you are willing to stomach: 1%, 10%, 30%...

Jack raises an important consideration. A DR calculation involves not only the ratio of the maximum to minimum signal, but also how much quantization error you are willing to tolerate. Norman Koren has a chart showing the number of levels in various exposure zones for linear and gamma 2.2 (this does not take into account the linear segment in sRGB at low luminances) and opines that lower limit of DR is reached when the darkest f/stop contains 8 levels.

http://www.normankoren.com/digital_tonality.html

Greg Ward uses a 5% quantization step as the limit and his Table 1 lists the DR of sRGB as 1.6 in log base 10 units. This corresponds to 5.3 f/stops (to convert from log 10 to log 2, multiply by log 2 base 10)

http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

-- hide signature --

Bill Janes

Complain

Jack Hogan wrote:

See here .

Jack

But I'm still digesting the rest of the info there and in the following posts.

Regards

Andy.

Complain
Re: What is the dynamic range of a JPEG image?

Jack Hogan wrote:

xpatUSA wrote: What would be your calculation for a ProPhoto JPEG image where the max RGB is 240,240,240 and the min RGB is 4,4,4?

I am going to pull a quick attribute substitution while you are not looking and say that what that's going to give you is the contrast ratio of the image, as opposed to the DR of any item in the chain.

just for the record, Jack, the penny just dropped on why you said that, duh

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
Re: What is the dynamic range of a JPEG image?

Bill Janes wrote:

Norman Koren has a chart showing the number of levels in various exposure zones for linear and gamma 2.2 (this does not take into account the linear segment in sRGB at low luminances) and opines that lower limit of DR is reached when the darkest f/stop contains 8 levels.

http://www.normankoren.com/digital_tonality.html

Greg Ward uses a 5% quantization step as the limit and his Table 1 lists the DR of sRGB as 1.6 in log base 10 units. This corresponds to 5.3 f/stops (to convert from log 10 to log 2, multiply by log 2 base 10)

http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

Good references, Bill.

Complain
Re: What is the dynamic range of a JPEG image?

Bill Janes wrote:

http://www.normankoren.com/digital_tonality.html

Good reference.

Here is a summary of 8 bit linear vs 8 bit gamma 2.2. It shows number of levels in each zone, where zone 1 is brightest and zone 11 darkest. Of course, the zones are not Zone System zones

Zone. linear / 2.2

1. 128 / 69
2. 64   / 50
3. 32   / 37
4. 16   / 27
5. 8     / 20
6. 4     / 14
7. 2     / 10
8. 1     / 8
9. 0     / 6
10. 0     / 4
11. 0     / 3

As you can see, the linear very soon loses number of levels, which might result in posterization/banding. I would say that 5 or maybe 6 zones are kind of safe for linear. For gamma 2.2 you have maybe 8, 9 or 10 zones that are kind of safe.

This show quite clearly why 8 bit linear is not a good idea.

-- hide signature --

/Roland
Kalpanika X3F tools:
https://github.com/kalpanika/x3f

Roland Karlsson's gear list:Roland Karlsson's gear list
Sigma DP3 Merrill Sigma dp2 Quattro Sony RX100 III Pentax K-3 Pentax K-1 +14 more
Complain
Re: Hmm... I get some odd values

Bill Janes wrote:

http://www.normankoren.com/digital_tonality.html

That's a very interesting link provided. If I am reading it correctly is suggests...

gamma encoded value = raw pixel ^ (1/gamma)
decoded value = encoded ^ gamma

So performing some quick calculations...

With simple rounding down for the 8 bit Quantiser the minimum detectable transformed signal threshold would be 1 LSB or 1/255 ~ 0.003922...

Expanding this (with gamma 2.2) we get...

0.003933^2.2 =  5.077e-6 --> 1/196,964 --> ~17.6 bits !!

Or with normal rounding (i.e. 1/2 LSB is rounded up to 1) the limit decreases to ~ 0.001961

So expanding --> 0.001961^2.2 = 1.1052e-6 --> 1/904,793 --> ~19.8 bits !!!!

This would obviously only apply to a lossless compressed JPG. (i.e. all the values in the LUT are set to 8 bits)

Now these figures are way above any suggestions here - so what am I doing wrong??

Regards

Andy.

Complain
Re: Hmm... I get some odd values

Andy C Knight wrote:

Now these figures are way above any suggestions here - so what am I doing wrong??

A gamma function is not invertible at the origin because it amplifies signal near zero to smithereens. What's in the deepest shadows? Noise.  So since gamma would amplify it to smithereens sRGB, for instance, does not use gamma in the deepest shadows: it uses a linear curve there. That's why your numbers are incorrect.

Complain
Re: Hmm... I get some odd values

Jack Hogan wrote:

Andy C Knight wrote:

Now these figures are way above any suggestions here - so what am I doing wrong??

A gamma function is not invertible at the origin because it amplifies signal near zero to smithereens. What's in the deepest shadows? Noise.  So since gamma would amplify it to smithereens sRGB, for instance, does not use gamma in the deepest shadows: it uses a linear curve there. That's why your numbers are incorrect.

Ah ha... I was unaware of that!

Do you know at what point it becomes linear? (i.e. perhaps 'Zone 12' and below??)

(I was thinking perhaps it's not a sudden change to 'linear' bur rather a gradual decrease in gamma. Otherwise an abrupt change would mean all data to the DCT below (say) 'Zone 11' would be zero - or is that the whole point )

Regards

Andy.

Complain
Re: Hmm... I get some odd values

Andy C Knight wrote:

Jack Hogan wrote:

Andy C Knight wrote:

Now these figures are way above any suggestions here - so what am I doing wrong??

A gamma function is not invertible at the origin because it amplifies signal near zero to smithereens. What's in the deepest shadows? Noise. So since gamma would amplify it to smithereens sRGB, for instance, does not use gamma in the deepest shadows: it uses a linear curve there. That's why your numbers are incorrect.

Ah ha... I was unaware of that!

Do you know at what point it becomes linear? (i.e. perhaps 'Zone 12' and below??)

0.04045 out of 1 on the way down the curve. So for 8-bit that would be 0.04045*255 = 10.31475. Slope is 12.92.

I've also seen 0.039something elsewhere, too.

-- hide signature --

Ted

xpatUSA's gear list:xpatUSA's gear list
Panasonic Lumix DMC-LX1 Sigma SD9 Panasonic Lumix DC-G9 Panasonic Leica DG Macro-Elmarit 45mm F2.8 ASPH OIS Sigma 17-50mm F2.8 EX DC OS HSM +13 more
Complain
 Forum