scott kirkpatrick Posted July 24, 2008 Share #61 Posted July 24, 2008 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. Link to post Share on other sites More sharing options...
Advertisement Posted July 24, 2008 Posted July 24, 2008 Hi scott kirkpatrick, Take a look here The reality of the 8-bit Leica. I'm sure you'll find what you were looking for!
t024484 Posted July 25, 2008 Share #62 Posted July 25, 2008 You're probably thinking of Carl Bretteville's work. See here: http://www.l-camera-forum.com/leica-forum/leica-m8-forum/39117-secrets-blue-dot-revealed-other-m8.html and here: the m8 metadata project Sandy Exactly what I meant, thanks a lot. Hans Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #63 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
jaapv Posted July 25, 2008 Share #64 Posted July 25, 2008 Hans, Maurizio, files sent you will get a Yousendit notification. Link to post Share on other sites More sharing options...
isaac Posted July 25, 2008 Share #65 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #66 Posted July 25, 2008 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. Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #67 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
diogenis Posted July 25, 2008 Share #68 Posted July 25, 2008 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!!! and no, log=/sqrt function Waiting anxiously your tests... (even if I am convinced of Leica's decision with the whole thing, it would be cool to see them) Link to post Share on other sites More sharing options...
sandymc Posted July 25, 2008 Share #69 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
jaapv Posted July 25, 2008 Share #70 Posted July 25, 2008 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. Link to post Share on other sites More sharing options...
scott kirkpatrick Posted July 25, 2008 Share #71 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
luigi bertolotti Posted July 25, 2008 Share #72 Posted July 25, 2008 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) ??? Link to post Share on other sites More sharing options...
scott kirkpatrick Posted July 25, 2008 Share #73 Posted July 25, 2008 ... 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 Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #74 Posted July 25, 2008 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. Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #75 Posted July 25, 2008 Misfocussed? I'll have a look Was it the house or the street ? I can reshoot. Jaap, It was the house. Hans Link to post Share on other sites More sharing options...
t024484 Posted July 25, 2008 Share #76 Posted July 25, 2008 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 Link to post Share on other sites More sharing options...
jaapv Posted July 25, 2008 Share #77 Posted July 25, 2008 Jaap, It was the house. Hans Hans, the weatherforecast promises the same light Saturday, I'll send you ma correct file Link to post Share on other sites More sharing options...
diogenis Posted July 26, 2008 Share #78 Posted July 26, 2008 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? Link to post Share on other sites More sharing options...
isaac Posted July 26, 2008 Share #79 Posted July 26, 2008 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. Link to post Share on other sites More sharing options...
t024484 Posted July 26, 2008 Share #80 Posted July 26, 2008 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 Link to post Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.