M8 Review at B&H

[Concorde-SST]

Advertisement (gone after registration)

sorry, forgot to add - can this be because of the

xx-bit "limitation" or specialisation of Leica´s handling

of the DNG´s ?

 

thanks,

 

concorde-SST

[mikelc]

..all i know is that the m8 files are to my liking better in every way than what i was getting with my idsii...a camera which i loved...by better i mean richer in detail and color...or maybe better isn't the right word...but it caused me to sell all my canon gear to go full time with supporting the m8 with quality glass...and even with the cv lenses i have it stll looks better to me than the 1dsii...i'm sure the numbers don't add up (for one there's a 6mp difference)...but great photo files are not about numbers

 

http://www.mikecetta.com

[jaapv]

Jaap, thanks. I will give you a call. I am at Burgh-Haamstede. Very nice location.

 

That is about 60 kms from my practice. Best combine it with a visit to Rotterdam.

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!

[ho_co]

Bill--

Again and again, one finds people voicing opinions without shooting the camera.

 

There was a lot of disbelief when the 8-bit business first became known, and I think this forum's discovery of the file structure contributed to Leica's publication of the reasons for the choice.

 

According to the article on this topic in LFI 2/2007 (which you should definitely read, just to reassure yourself):

 

1) The camera does discard a fair amount of data loss in highlight areas, but these values amount to distinctions without a difference and are not perceptible to the eye on screen or in a print.

 

2) Throwing out the highlights has enabled the M8 to expand its shadow definition. That is, you have only so many bits to work with. Throwing away half of them allows the others to expand over more space, increasing definition. (Same with Photoshop: If you want to make a major adjustment to an image, you will get better results by converting an 8-bit file to 16 bits, making the change, then converting back to 8 bits.)

 

3) The compromise was chosen to enable smaller files that are quicker to write.

 

4) Leica's algorithm recovers most but not all of the data.

 

 

Now, not in the LFI article, but from practice:

 

Don't draw conclusions from the fact that the data are packed into 8 bits. Data packing has been done since the days of mainframes.

 

Read the reports of reviewers here on the forum when they started working with the M8. They have all commented that the camera seems to show increased dynamic range. See particularly David Adamson's thread on making 30 x 40 prints from the M8's files. He says the M8 works better than any other 35mm-format camera he has ever seen. (Google his name to see if his opinion should mean anything to you.)

 

So in fact the B&H reviewer is more or less correct in his description of the mechanism involved, but wrong in his conclusion.

 

If he were to shoot the M8, his reaction would change to: "Man, if they get this kind of quality out of packed 8-bit data, maybe they should go to a 4-bit algorithm!"

 

--HC

[Bill W]

Howard,

I had read the article in LFI. I guess I am not a technical guy and my point should have been that the reviewer simply discarded the M8 based on a borrowed camera and the assumption on the specs. I know what the M8 can do but I cannot explain how it does it. The glass is superior to anything out there and the M8 captures images like no other digital camera I have owned. I actually bought one of the early Leica digitals in 1998 made by Panasonic I believe. It took OK images but nothing like M8 can. I have shot Leica R and M equipment for over 20 years. Its just my hobby and has been for over 40 years.

[ho_co]

Bill--

Understood. I just yesterday received the relevant issue of LFI, so it's all fresh on my mind. Michael Hußmann does a pretty good job of explaining it, though some parts are still foggy in my brain.

 

John Camp's explanation above is also good. In fact, one-half of the number of steps available to the sensor are all used in the final (14th) bit. Half of the remaining dark/light steps are allotted to the penultimate (13th) bit. Clearing at least part of those makes room to spread out all the remaining tones over a larger number of steps, spreading out the shadows to give a much better detail.

 

As pointed out above, the 14 bits are compressed by means of a look-up table and then reconstructed by means of the same look-up table, so most of the data are restored, but with the added dynamic range allowed by tossing the top value or two.

 

One other thing: As LFI remarks, Nikon also offers a "virtually lossless" compressed RAW, but I have never seen an explanation of how it works. (I'm sure it has been published, but I haven't seen it; I would be grateful if you could point me to it.) I think we are very lucky to be dealing with a company that comes out and describes the procedure so that we can diagram it and try it ourselves.

 

An analogy: The US is, I believe, the only country every bill of whose currency is the same size. A 100-dollar bill is exactly the same size as a 1-dollar bill. They both cost the government the same thing to produce, but one--by convention--stores one hundred times the purchasing power of the other. That's how data-packing schemes work as well. (The M8 doesn't use a true data-packing algorithm, because that requires a lot of processing power; but the principle is the same: Pack the data from 14 bits into 8 bits.)

 

Personally, I would prefer that Leica give us the choice of 8- or 16-bit RAW files. But according to LFI, the 16-bit (12-bit in their example) version would underperform the 'compromised' 8-bit files. And all we good Leica users would be running around using the 16-bit RAW mode thinking we are so smart, while avoiding the technological advantage Leica is now forcing us to accept.

 

--HC

[sandymc]

Advertisement (gone after registration)

Nikon compresses to 567 levels, effectively about 9 1/4 bits of data, somewhat over twice the number of levels that Leica does. Most of the difference between the Nikon scheme and the Leica scheme is actually in the dark areas, where Nikon preserve all the data coming off the sensor.

 

And just for reference, number of levels does not correspond to dynamic range if non-linear compression used. That's exactly the point of compression schemes of this type. They allow high dynamic range without requiring very large number of levels.

 

Sandy

[J_Brittenson]

Nikon compresses to 567 levels, effectively about 9 1/4 bits of data, somewhat over twice the number of levels that Leica does. Most of the difference between the Nikon scheme and the Leica scheme is actually in the dark areas, where Nikon preserve all the data coming off the sensor.

This is similar to Canon CRW. The high-order bits are preserved, while the low-order bits are huffman coded using a constant dictionary with a predetermined bias and error distribution. Small sample values are all high-order bits.

[j. borger]

sorry, forgot to add - can this be because of the

xx-bit "limitation" or specialisation of Leica´s handling

of the DNG´s ?

 

thanks,

 

concorde-SST

No i do not think so .... you are just playing with some very dangerous lightroom sliders here..... Ligtroom has several sliders to be carefull with .. very easy to process a file to death and completely ruin it!

Pull the red slider to the right for instance and see how it messes up your B&W file if you zoom in and look .......

[ho_co]

Sandy & Jan--

Thanks for the info on Nikon and Canon encoding. You understand this better than I, so let me ask this:

 

The LFI article implies that there is a single, fixed look-up table for Nikon, and it is stored in the RAW processor. Now you point out that the LUT has over 512 values.

 

As I understand it, the M8 stores only 256 values per image in its LUT (less than half of Nikon), but has the advantage of generating them ad hoc with each image.

 

Any thoughts on the two different systems? Is it safe to say that Leica's logic might have run this way: a) We're sticking with 8 bits, therefore only 256 values; We'll compensate for that by making the LUT specific to each image?

 

I'm also curious about how you would compare the Leica and Canon encoding. You've probably already defined it completely, but I lost you with 'huffman coding.'

 

--HC

[carstenw]

As I understand it, the LUT in the Leica is simply a square root, possibly combined with a trick to use the last two bits, and the table is always the same. Where did you get the impression that it was a per-photo table?

 

Leica's motivation was surely writing speed, space, and the power of the built-in processor.

 

Canon compresses the image with a real compression algorithm, to my knowledge. Huffman coding simply uses a system of representation where the commonly occurring values are stored using the shortest codes, and the less common values with longer codes. An alphabetic example would be to store E with 1 or 2 bits, and X with many more. By redistributing the bits in this manner, you can save space. RLE (run-length encoding) is another simple way to save space. If you have 15 identical values in a row, say E again, you store 15E rather than EEEEEEEEEEEEEEE. I am not sure what compression algorithms are used in RAW formats, however. Given that Huffman coding requires knowledge of the entire domain (input set of values), I am pretty sure that it is not used. RLE is probably used, possibly combined with other schemes, such as Lempel-Ziv encoding.

[J_Brittenson]

As I understand it, the LUT in the Leica is simply a square root, possibly combined with a trick to use the last two bits, and the table is always the same.

sqrt(2^14 * 2^2) = 2^8

so:

E = sqrt(S * 4)

for E = encoded value, S = sample

In real life, with a stochastic rounding dither:

E = (sqrt(S * 4) * 2 + random_bit) / 2

Not that much of a trick...

 

This is super fast given that just about every modern embedded processor with signal processing functionality has a fast vectored square root function, and many have a single-bit noise source.

 

Canon compresses the image with a real compression algorithm, to my knowledge. Huffman coding simply uses a system of representation where the commonly occurring values are stored using the shortest codes, and the less common values with longer codes.

Huffman coding uses a tree. The shortest possible bit string is output for each value or input bit string (either fixed or variable length), based on its frequency of occurence. To decode this, the tree is needed; in compression terms, it's usually called the dictionary. Canon doesn't quite do it this way (although they have a few different methods). They take the low-order bits and look them up in a fixed table, and output a fixed corresponding bit string (of variable length). The decoder then has a built-in dictionary (since it's not supplied in the encoded file), to turn this bit string back into the original value. Optionally, the dictionary can be included in the file for a "real" huffman coding. Or the huffman part can be omitted entirely, to save space (some of the G series P&S's did this IIRC); all that's lost in that case are the low-order bits of each sample.

[ho_co]

Carsten--

You are correct, I completely misunderstood the remarks in the LFI article that Leica stores a LUT in each file. I interpreted that to mean that it might differ from file to file.

 

Carsten & Jan--

Thanks for the pointers on Huffman coding and on the Leica 16 > 8 bit algorithm.

 

After piddling with some of the math, this is how it appears to me:

1) The look-up table stored in all M8 DNG files is identical

2) For that reason, there is no reason for the LUT other than observing the DNG specification

3) Since the M8 is the only camera that writes this type of DNG, at the moment its DNG is still problematic for some raw processors

4) Therefore, Leica could have reduced the file size even more by removing the LUT and specifying in its raw description that the file contains 256 values, to be decoded by squaring and dividing by four.

 

Is that accurate? (I recognize that the 'universality' of DNG is an advantage that might spur the decision to choose Leica's approach.)

 

I think Michael J Hußmann did a superb job of describing the advantages of the M8's encoding in his LFI article, and also a good job of pointing out its disadvantages, but with the requisite 'company spin' to make them seem possibly less important than they are. He is an excellent technical writer. But I'm beginning to think that more than just a technical explanation is necessary.

 

That is, I'm beginning to think not just that I would *like* the choice of writing uncompressed DNGs, but that we must make that request of Leica in the strongest terms.

 

--HC

[sdai]

That is, I'm beginning to think not just that I would *like* the choice of writing uncompressed DNGs, but that we must make that request of Leica in the strongest terms.

Exactly, no matter what a great job Michael has done to explain what has been done ... Leica failed to convince some of its customers why they just can't provide the other option - if they do believe that 8 bit encoding really can hold its own, show us the proof and I'll no longer have any doubt.

 

BTW, LUT isn't really part of DNG ... and Canon's current CR2 format is based on the LJPEG standard which combines simple linear prediction and huffman encoding, and enables bit to bit reproduction of data. If you go with the simple approach using a LUT, when the data is gone, then it's pretty much gone.

[ho_co]

BTW, LUT isn't really part of DNG ...

Michael's article says (p 57) it is an option allowed for in the DNG specification (though of course, Leica has handled it a bit differently ).

 

Certainly interesting to see how others have approached the question; seems as if each version gains a certain number of nay-sayers.

 

I'm still learning about what has gone before.

 

--HC

[sandymc]

Well, its not really true to say that LUT is not a part of DNG - its correct that a DNG file is based on a linear representation of the image, but that is true for every raw format that I'm aware of. The ability to code the file in a non-linear way via the LUT has a been a part of DNG since day one.

 

Sandy

[GMB]

Let me ask a hopefully not to stupid question. When I develop DNG files in C1 into TIF files, I have the choice beteen 8 and 16 bit. Given that the DNG file has (only) 8 bit, does the 16 bit option still make sense? (I know that when I make adjustments under 16 bit I loose less data than if I make them under 8 bit.)

 

Georg

[AlanG]

..all i know is that the m8 files are to my liking better in every way than what i was getting with my idsii...a camera which i loved...

 

Mike Cetta | Fine Art Photographer

 

It may be great for others to hear these opinions, but...

 

What I'd like to see is someone who has the M8 and 1DSII post raw files of the same image shot as "identically" as possible with the two cameras. Then we could each examine and process the images and see for ourselves what is going on.

 

Preferably this would be an image that has a wide dynamic range and a good range of colors. Include a color target in part of the scene where there is "good" lighting. An ideal test to show maximum quality from each camera would be for the Canon to be set at ISO 100 and the M8 to be set at ISO 160. (The speed for the best quality of each respective camera.) Then shoot images that are bracketed in exposure to establish each camera's "actual' sensitivity so we can come reasonably close to getting matching tone curves. Post a few of these and we'll have something valuable to work with.

 

This would give those interested a solid foundation to use for comparison.

[sandymc]

Let me ask a hopefully not to stupid question. When I develop DNG files in C1 into TIF files, I have the choice beteen 8 and 16 bit. Given that the DNG file has (only) 8 bit, does the 16 bit option still make sense? (I know that when I make adjustments under 16 bit I loose less data than if I make them under 8 bit.)

 

Georg

 

Georg,

 

16-bit TIFFs do make sense, because TIFFs are linear - put simply, because we see light in power terms (each stop is half the light of the previous stop), an 8-bit non-linear compressed file (M8 DNG) is a lot better than an 8-bit linear file (TIFF 8-bit), although worse than a 16-bit linear file.

 

Sandy

[Advertisement]

Hallo,

Look here: Leica M

[johnll]

So far as I know, humans can't tell the difference between 8-bit and n-bit images (n>8) on screen or in prints. In fact, virtually all printers only use 8-bit data. However, and this is a big however, if you want to post-process an image using (e.g.) curves, color balancing, saturation changes etc. and if you only have 8-bits to work with you are at risk to end up with posterization in tonality and/or hue etc. Even JPGs (which are only 8-bit) work fine so long as (1) you can fit the subject contrast into the dynamic range available (which is a function of the camera, not the file format) and (2) you don't care to make any significant changes to the image in post. At least, this is what I've been told, and it fits my own experience (not including M8 DNGs) and makes sense to me. The conclusion from this is that 8-bit DNGs are fine so long as you don't mess about with them too much. I wouldn't doubt the statements that Leica has encoded these 8-bits in such a way as to get more mileage out of them than some others do, but even 12-bits (which I believe are the norm for most DSLR RAW files, not counting MF backs) provide a great deal more info than 8-bits ... 16 times as much.