The reality of the 8-bit Leica

[Peter Branch]

Advertisement (gone after registration)

One can, I suggest, speculate forever if a particular bit level conversion algorithm – calculated, look-up table, whatever – produces the “best” compromise. What is “best” for some subjects is inevitably not going to be the “best” for all subjects and all lighting conditions.

 

Since we are not considering lossless compression methods some data is inevitably lost in the conversion. Precisely which data has been lost has been decided in advance by the camera manufacturer. This is true whether the conversion is fixed or dynamic. Leica justifies the choice it made in terms of the mismatch between the linear coding of light intensity, inherent in the original 14/16 bit data from the sensor, and the logarithmic response of the eye to brightness in a scene. This approach makes a lot of sense as half the bits are effectively used to characterise the brightest stop leaving the other half of the bits to characterise the remaining 8 to 10 stops of the dynamic range.

 

For most pictures Leica’s choice works very well and Leica M8 files have exceptionally good shadow detail. Therein lays the problem. The highlight detail is not exceptionally good. It is better than average and in most situations more than adequate but rather too often in my experience it fails to deliver what one would really like. I spend too much time working on highlights in CS3 and very little time working on shadows.

 

What I don’t know is whether this problem could be solved using a different conversion algorithm or whether the only answer is to have a 14 / 16 bit DNG file. The problem with the latter is that one would still have to select appropriate curves depending on the subject lighting etc. and this could result in just as much work. I wish I knew the answer and I bet Leica do as well.

[marknorton]

In theory, the table could be made dynamic by analysing the image and, according to a set of rules, change the mapping on the fly.

 

As a first step, the camera could find the brightest and darkest part of the image and constrain the table to work within that DR; it could also apply other rules - no point using a table to preserve shadow detail if there isn't any - but it sounds like a lot of work when the goal is just to reduce the data volume.

 

The M8 configuration - integrated motor, single power source, no SDHC support, 500 MHz DSP constrained what they were able to do. To obtain acceptable battery life, image capacity and processing speed, the 8 bit mapping (much less computationally intensive than any compression algorithm) was possibly the only option.

 

A differently configured camera - manual wind with a winder, alternative power sources, SDHC support - might have changed things but the slow DSP is always going to limit what they can do, especially with JPEG refinement. If they put in a faster DSP, that would have an impact on battery life.

[Advertisement]

The Leica Q3 is available for pre-order at B&H Photo Video and Adorama

[marknorton]

Peter, I suppose I dislike the "Mother Knows Best" attitude from Leica. That may be true with their optical designs but they are still finding their way with electronics and, especially, image processing. Their statement that image quality is not compromised may be more an expression of hope than reality.

 

I would instead much prefer them to make it an option so that we can decide whether the hit on battery life, storage capacity and performance justifes any improvement in image quality.

 

I'd also like an M8 with all the JPEG stuff stripped out, a DNG only camera, a digital MP if you will.

[marknorton]

Mark... just as an idea... do you think that, to try to understand the lookup table that probably is "written" in M8 firmware, could be useful to shot a grayscale target (many are easily available) and then analizying the DNG values through a tool like PhotoME ? I ask this for I appreciate PhotoME, and am guessing how to make some "scientific" use of it...

 

Luigi, that's not necessary; any DNG contains the lookup table which is available to anyone who goes looking. As Sandy says, Leica can change the table in firmware if they want to but endlessly messing with it doesn't necessarily improve things.

[jaapv]

Peter, I suppose I dislike the "Mother Knows Best" attitude from Leica. That may be true with their optical designs but they are still finding their way with electronics and, especially, image processing. Their statement that image quality is not compromised may be more an expression of hope than reality.

 

I would instead much prefer them to make it an option so that we can decide whether the hit on battery life, storage capacity and performance justifes any improvement in image quality.

 

I'd also like an M8 with all the JPEG stuff stripped out, a DNG only camera, a digital MP if you will.

Mark, Leica was the first optics company that implemented CAD in their design process in the nineteenfities and their first digital camera dates back to 1992. The digital ignorance excuse won't wash

 

I would go for that camera too, btw.

[diogenis]

One can, I suggest, speculate forever if a particular bit level conversion algorithm – calculated, look-up table, whatever – produces the “best” compromise. What is “best” for some subjects is inevitably not going to be the “best” for all subjects and all lighting conditions.

 

Since we are not considering lossless compression methods some data is inevitably lost in the conversion. Precisely which data has been lost has been decided in advance by the camera manufacturer. This is true whether the conversion is fixed or dynamic. Leica justifies the choice it made in terms of the mismatch between the linear coding of light intensity, inherent in the original 14/16 bit data from the sensor, and the logarithmic response of the eye to brightness in a scene. This approach makes a lot of sense as half the bits are effectively used to characterise the brightest stop leaving the other half of the bits to characterise the remaining 8 to 10 stops of the dynamic range.

 

For most pictures Leica’s choice works very well and Leica M8 files have exceptionally good shadow detail. Therein lays the problem. The highlight detail is not exceptionally good. It is better than average and in most situations more than adequate but rather too often in my experience it fails to deliver what one would really like. I spend too much time working on highlights in CS3 and very little time working on shadows.

 

What I don’t know is whether this problem could be solved using a different conversion algorithm or whether the only answer is to have a 14 / 16 bit DNG file. The problem with the latter is that one would still have to select appropriate curves depending on the subject lighting etc. and this could result in just as much work. I wish I knew the answer and I bet Leica do as well.

So far this is what I am experiencing as well, and if the lookup tables are indeed not dynamic, then this explains why in very contrasty photos which use the whole spectrum available, highlights need a lot more processing.

There is of course no substitute for lossless recording, but then again, it must be easy to create dynamic tables for some difficult situations.

[Peter Branch]

Advertisement (gone after registration)

Mark, if it comes down to a trade off between JPEG capability in a camera and more helpful highlight information in the DNG files then I would always vote for the highlight information. That is why I use Leica lenses despite their cost. They have outstanding highlight graduation on film, due in large measure to their low flare, and I would like to get the same capability in a digital M camera.

[pgk]

I spend too much time working on highlights in CS3 and very little time working on shadows.

 

I'd agree that the highlight detail can require more work BUT I'd say that on 'average' I have to work less on the Leica DNG files than raw files from my other cameras. This does of course vary depending on subject matter and output requirements. Its a tricky one. Personally I find that for many of my images the M8 delivers effective files. In some situations other cameras produce easier/quicker to adjust files.

 

The 'reality of the 8-bit Leica' is IMHO that it delivers remakably effective files, not perfect, but very, very usable. I'd rather spend my time 'learning' the adjustments that I utilise to best effect for myself, than worrying about whether its 8, 12, 14 or 16 bit and I'll look forward to future developments as long as they do not dramatically increase the time that I have to spend in front of my computer (an oft ignored but increasing problem).

[t024484]

We don't know whether the A/D converter on the M8 is 12 or 14 bit but whichever it is, they will simply translate the value output to values in the range 0 - 255 using a lookup table which they can tweak endlessly to provide the characteristic they are looking for. It may be the table has changed over time with successive firmware releases. The table is specified in the DNG of course which is how the DNG processor gets the values back to 12/14/16 bit.

 

One simple approach is to multiply values in the range 0 - 4095 by 16 to give values in the range 0 - 65520, then take the square root to give values in the range 0 - 255.

 

I assume you have obtained your formula using some sort of curve fitting tool; the m8 doesn't have the horsepower to do much on the fly, so a lookup table is the most likely scenario.

 

Hi Mark,

My algorithm was just a first attempt with two important conditions to be met,1) the slope at zero has to be one just like the uncompressed file, and 2) the outcome at 2exp14 should be 255 (and not 256 as I first did).

A square root does not have a slope of 1 at x=0, and compression at low values is much stronger than with a logarithm, so you will loose much more detail in the darker areas.

 

No matter if a square root or a logarithmic calculation is used, in both cases a look up table has to be used to prevent the processor to do any calculation in this respect.

So it is not important how complex the algorithm is, once calculated and stored into the lookup table, it always places the same load on the M8 processor.

 

But once the algorithm has been chosen, I do not think that Leica can make any changes with new firmware releases to the look up table, since raw processors like Lightroom will have to translate the compressed Leica values back into non compressed values.

This has to be done with the inverse of Leica´s compression algorithm.

If Leica were to change their look up table, how could Lightroom know. I do not think that a complete decompression look up table is stored in each and every DNG picture, so compression/decompression will have to be a straightforward algorithm. More likely is that the DNG file holds one byte, telling that the DNG file is uncompressed, compressed according to a square root, according to a logarithm, or according to whatever known algorithm.

 

I have made a new table going from 0-255 with a logarithmic (8bits Ln) and a square root algorithm (8bits SR), still assuming a 14 bit A/D converter.

 

Welcome, dear visitor! As registered member you'd see an image here…

Simply register for free here – We are always happy to welcome new members!

 

As you can see, the square root algorithm is not very impressive at low values, much too much compression over there, and it does not start with a slope of 1.

My belief is that it will be a logarithmic conversion.

But once I have Jaaps files, I will try to process them with both algorithms.

 

Hans

 

P.S. The header in my table saying sqrt(x) should be read as sqrt(4x)

[marknorton]

The linearisation table is stored in the DNG and the DNG reader uses it to convert 8 bit values to, say, 12 or 14 bit values for further processing. The table has 256 entries for each 8 bit value in the DNG - the reader simply indexes into the table and loads the uncompressed value...

[diogenis]

Hans,

They take the (2^14) signal from the sensor, multiply by 4, then square root, then look at the table. The raw processors (C1) then x^2 x 4 to uncompress and get the value.

It is possible for a specific table to be embedded with each photo taken, so as to have a better aproximation to the original uncompressed signal, Or make just one profile with a particular table which will follow some principles.

The first add some complexity, the second loses some detail which Leica claims cannot be seen. If we claim that tables again are stable and originated by leica and always the same.

Are they? or not?

[t024484]

The linearisation table is stored in the DNG and the DNG reader uses it to convert 8 bit values to, say, 12 or 14 bit values for further processing. The table has 256 entries for each 8 bit value in the DNG - the reader simply indexes into the table and loads the uncompressed value...

Mark,

I am surprised, but in that case it is like you say, Leica can do whatever they want with each software update.

Do you have happen to have any knowledge where I can find a detailed description of the DNG file format.

 

Hans

[t024484]

Hans,

They take the (2^14) signal from the sensor, multiply by 4, then square root, then look at the table. The raw processors (C1) then x^2 x 4 to uncompress and get the value.

It is possible for a specific table to be embedded with each photo taken, so as to have a better aproximation to the original uncompressed signal, Or make just one profile with a particular table which will follow some principles.

The first add some complexity, the second loses some detail which Leica claims cannot be seen. If we claim that tables again are stable and originated by leica and always the same.

Are they? or not?

 

Your question is already answerred by Mark, in the posting before yours.

[diogenis]

Google adobe dng and you will find the spec.

If you can peek in the dng file and be able to locate where that table is located, then if you compare one photo to another, we will know if its only one table or many tables.

 

If I was Leica, I would have gone dynamic tables, focusing where detail is needed.

[sandymc]

If we claim that tables again are stable and originated by leica and always the same.

Are they? or not?

 

Let me put it this way - of all the images provided by various people using all sorts of combinations of lenses and firmware versions over the course of developing CornerFix, I've never seen any variation in the lookup table.

 

Sandy

[sandymc]

Do you have happen to have any knowledge where I can find a detailed description of the DNG file format.

 

Adobe - Digital Negative (DNG)

 

Sandy

[diogenis]

Let me put it this way - of all the images provided by various people using all sorts of combinations of lenses and firmware versions over the course of developing CornerFix, I've never seen any variation in the lookup table.

 

Sandy

 

But corner fix fixes vignetting, how does it allow you to peek at lookup tables?

I'm not questioning your observations, I just want to understand that we are both talking about the same thing. And we dont need all the photos, just 2 are enough. If these 2 shows the same values in lookup tables, then the tables are all the same.

nm, I will check the tool myself..

[sandymc]

But corner fix fixes vignetting, how does it allow you to peek at lookup tables?

I'm not questioning your observations, I just want to understand that we are both talking about the same thing. And we dont need all the photos, just 2 are enough. If these 2 shows the same values in lookup tables, then the tables are all the same.

nm, I will check the tool myself..

 

The first step in the devinetting process is to get to a real (aka linear) 14-bit image. That's done via the look-up table.

 

Sandy

[t024484]

I had a look at Adobe's DNG description which leaves still several questions open to me,

but I can remember that some 6 months ago, a forum member went deeper into the specific Leica DNG file, and posted his findings in a pdf file.

Does someone still has a copy of this pdf file or a link to the original posting.

When I use the search function for "M8 DNG" , almost every posting shows up.

 

Hans

[Advertisement]

Hallo,

Look here: Leica M

[sandymc]

I had a look at Adobe's DNG description which leaves still several questions open to me,

but I can remember that some 6 months ago, a forum member went deeper into the specific Leica DNG file, and posted his findings in a pdf file.

Does someone still has a copy of this pdf file or a link to the original posting.

When I use the search function for "M8 DNG" , almost every posting shows up.

 

Hans

 

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