Jump to content
Sign in to follow this  
the warrior

The reality of the 8-bit Leica

Recommended Posts

Advertisement (gone after registration)

I'm surprised that we are still speculating about the transformation from 14bit Kodak raw data into the 8bit DNG file. You won't find the formula

 

dng pixel value = sqrt( 4*raw pixel value) (1)

 

anywhere in a DNG file, but back in Fall 2006, a forum contributor plotted up the lookup table values, and compared them with a line expressing formula (1). No visible difference.

 

Since then a host of vignetting corrections have been created for in-camera use plus continuous AWB replacing table-driven, and they work in the processing pipeline that contains this transformation. I can't imagine Leica changing formula (1) at this point.

 

scott

 

edit: one post a page or so back missed the point of this transformation by saying that someone (an elf inside the camera?) multiplied the raw data by 4, took a square root of the result, and then looked at a table. NO! the raw data is simply used as an index into a table, where the camera's program finds the DNG pixel value. There's a surprising amount of room in the camera's memory (and the executable firmware is fairly big as a result). The scarce resource is DSP and microcontroller cpu cycles, and using a lookup table saves many of these.

Share this post


Link to post
Share on other sites
I'm surprised that we are still speculating about the transformation from 14bit Kodak raw data into the 8bit DNG file. You won't find the formula

 

dng pixel value = sqrt( 4*raw pixel value) (1)

 

anywhere in a DNG file, but back in Fall 2006, a forum contributor plotted up the lookup table values, and compared them with a line expressing formula (1). No visible difference.

 

Since then a host of vignetting corrections have been created for in-camera use plus continuous AWB replacing table-driven, and they work in the processing pipeline that contains this transformation. I can't imagine Leica changing formula (1) at this point.

 

scott

 

edit: one post a page or so back missed the point of this transformation by saying that someone (an elf inside the camera?) multiplied the raw data by 4, took a square root of the result, and then looked at a table. NO! the raw data is simply used as an index into a table, where the camera's program finds the DNG pixel value. There's a surprising amount of room in the camera's memory (and the executable firmware is fairly big as a result). The scarce resource is DSP and microcontroller cpu cycles, and using a lookup table saves many of these.

 

Hi Scott,

Could you possibly give me the link to the posting of the forum member you refer to from 2006.

If the square root is used, multiplying by four is of course never done before the look up table. It would make the look up table four times as long.

The look up table should only have 16383 entries, and the stored algorithm inside can be anything, like: ouput=sqrt(4*input) .

 

I must say that I still have a problem with this SQRT. Human sensors have pure logarithmic sensitivities, which gives us our enormous dynamic range.

If compression has to be done to some source, the best fitting compression is a logarithmic compression, just for that reason.

 

Jaap has promised to send me a full 14 bit file. Once received, I will try to compress/decompress this file acoording to sqrt and according to Log.

This may reveal some important differences.

 

Hans

Share this post


Link to post
Share on other sites

Hans, Maurizio, files sent you will get a Yousendit notification.

Share this post


Link to post
Share on other sites

Hallo Hans!

I must say that I still have a problem with this SQRT. Human sensors have pure logarithmic sensitivities, which gives us our enormous dynamic range.

If compression has to be done to some source, the best fitting compression is a logarithmic compression, just for that reason.

Well, than let's learn some mathematics :-)

 

SQRT(2) = exp(log(2)*0.5) = 1.414

Share this post


Link to post
Share on other sites
Hallo Hans!

 

Well, than let's learn some mathematics :-)

 

SQRT(2) = exp(log(2)*0.5) = 1.414

Nice attempt, but exp(log x) = x, so are you trying to tell that a sqrt is in fact a logarithm?

No it is not.

Share this post


Link to post
Share on other sites

Advertisement (gone after registration)

Hans, Maurizio, files sent you will get a Yousendit notification.

 

Jaap,

I received your 4 pictures, thanks for that. The second picture with the DMR is unsharp everywhere, and the comparing picture with the M8 is not. Is this with any specific reason ?

What I will do is to compress/expand the DMR pictures according to SQRT and LOG.

That gives me three pictures to compare:

1) Uncompressed original, 2) Processed with a sqrt, and 3) processed with a log.

So I won't need any M8 pictures to compare.

Give me a week to come to results.

 

Hans

Share this post


Link to post
Share on other sites
Nice attempt, but exp(log x) = x, so are you trying to tell that a sqrt is in fact a logarithm?

No it is not.

 

Lol!

Indeed it was a nice attempt!!!

 

Waiting anxiously your tests... (even if I am convinced of Leica's decision with the whole thing, it would be cool to see them)

Share this post


Link to post
Share on other sites
exp(log x) = x

 

Not to get in the way of anyone else's fun, but while that is true,

 

exp(log(x)*0.5) certainly is not = x

 

BTW, Hi Harald

 

Sandy

Share this post


Link to post
Share on other sites
Jaap,

I received your 4 pictures, thanks for that. The second picture with the DMR is unsharp everywhere, and the comparing picture with the M8 is not. Is this with any specific reason ?

What I will do is to compress/expand the DMR pictures according to SQRT and LOG.

That gives me three pictures to compare:

1) Uncompressed original, 2) Processed with a sqrt, and 3) processed with a log.

So I won't need any M8 pictures to compare.

Give me a week to come to results.

 

Hans

 

Misfocussed? I'll have a look Was it the house or the street ? I can reshoot.

Share this post


Link to post
Share on other sites
Hi Scott,

Could you possibly give me the link to the posting of the forum member you refer to from 2006.

 

....

 

I must say that I still have a problem with this SQRT. Human sensors have pure logarithmic sensitivities, which gives us our enormous dynamic range.

If compression has to be done to some source, the best fitting compression is a logarithmic compression, just for that reason.

 

 

The first dng decoding that I recall was by a Russian programmer, who hasn't been active in the forum since then. I'll look for him when i get some time, as I have email correspondance that might turn him up.

 

I agree, humans are logarithmic, but that is an expensive computation to do on the fly, so the traditional rendering of am image for human consumption is "gamma correction," in which the linear data is compressed by taking its gamma-th root (i.e. raising it to the 1/gamma power) before sending the pixels to the screen. Current practice uses gamma values from 1.8 (Mac tradition) to 2.2 (PC). And the square root ( raw data)^(1/2) is right in the middle. I have always suspected that Leica uses the subsampled dng data for a quick review on the LCD, followed a second later by the jpeg version. But there's no way to prove this, and they haven't chosen to say anything about it in LFI or other public venues.

 

scott

Share this post


Link to post
Share on other sites
Hallo Hans!

 

Well, than let's learn some mathematics :-)

 

SQRT(2) = exp(log(2)*0.5) = 1.414

 

 

... about learning some math... I red above this formula ....

 

dng pixel value = sqrt( 4*raw pixel value)

 

well... there is something strange ... sqrt(x*y)=sqrt(x)*sqrt(y)... shall we conclude that dng pixel value = 2*sqrt(raw pixel value) ???

Share this post


Link to post
Share on other sites
... about learning some math... I red above this formula ....

 

dng pixel value = sqrt( 4*raw pixel value)

 

well... there is something strange ... sqrt(x*y)=sqrt(x)*sqrt(y)... shall we conclude that dng pixel value = 2*sqrt(raw pixel value) ???

 

of course. The business of shifting the bits around is just to make sure that all eight easy-to-store bits are filled with meaningful information.

 

scott

Share this post


Link to post
Share on other sites
Not to get in the way of anyone else's fun, but while that is true,

 

exp(log(x)*0.5) certainly is not = x

 

BTW, Hi Harald

 

Sandy

No the answer is of course Sqrt x and not x

A = exp(log A), so if A=sqrt x, then

sqrt x=exp(log(sqrt x))=exp(log( x exp 0.5))=exp((log x )*0.5)

 

We are drifting away from the Leica M8.

Share this post


Link to post
Share on other sites
Misfocussed? I'll have a look Was it the house or the street ? I can reshoot.

Jaap, It was the house.

 

Hans

Share this post


Link to post
Share on other sites
The first dng decoding that I recall was by a Russian programmer, who hasn't been active in the forum since then. I'll look for him when i get some time, as I have email correspondance that might turn him up.

 

I agree, humans are logarithmic, but that is an expensive computation to do on the fly, so the traditional rendering of am image for human consumption is "gamma correction," in which the linear data is compressed by taking its gamma-th root (i.e. raising it to the 1/gamma power) before sending the pixels to the screen. Current practice uses gamma values from 1.8 (Mac tradition) to 2.2 (PC). And the square root ( raw data)^(1/2) is right in the middle. I have always suspected that Leica uses the subsampled dng data for a quick review on the LCD, followed a second later by the jpeg version. But there's no way to prove this, and they haven't chosen to say anything about it in LFI or other public venues.

 

scott

Scott,

I must admit that you have mentioned the first valid point in favour of the sqrt, whis is in having a much faster result on the LCD,

It could explain why a picture is almost directly there on the camera's display, and after one or two seconds it is slightly corrected (with the correct gamma?) .

In displaying a logarithmically compressed picture, the processor should have first made the antilog conversion plus the gamma conversion all in one go through a look up table, but that takes probably one or two seconds before the picture shows up.

The downside of this sqrt algorithm is a file that is not optimally compressed, meaning that usefull information has been lost forever.

 

Hans

Share this post


Link to post
Share on other sites
Jaap, It was the house.

 

Hans

 

 

Hans, the weatherforecast promises the same light Saturday, I'll send you ma correct file

Share this post


Link to post
Share on other sites
The lookup table isn't dynamic - it remains the same for all images. Although there is no reason why Leica couln't change that if they wanted. It is easily extractable from the DNG.

 

In fact, If you set CornerFix to "verbose" mode, you will see the first part of the table displayed.

 

Sandy

 

Ok, I confirm that indeed.

At first I tried your tool in Mac OS, but it didn't provided a log even in verbose, unless it wasin console? I dont know. Anyway, then I jumped in the win version and yes, the tables are constant. Nice tool btw...

 

Now, correect me if I am wrong, but only Leica can mke them dynamic right? That is, this needs to be done before on the fly, just before the compression is taken, if we want to preserve fidelity of the shot. Is that correct?

Share this post


Link to post
Share on other sites

Hallo Hans!

It could explain why a picture is almost directly there on the camera's display, and after one or two seconds it is slightly corrected (with the correct gamma?) .

The picture you see on the LCD at first is simply the 320x240 pixel thumbnail, which is also included in each DNG file. After some seconds (depending on how fast the SD card is) the DNG is converted and show instead on the LCD. This picture is scaleable.

Share this post


Link to post
Share on other sites
Hans, the weatherforecast promises the same light Saturday, I'll send you ma correct file

 

Jaap,

may I bother you one more time, and ask you to send me a complete black picture ( lens cap on, 1/8000 sec) and a complete white (bright sky, 4 sec, lens full open), picture from your DMR.

 

Hans

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue., Read more about our Privacy Policy