Official Response from Leica on Laundry List

[farnz]

Advertisement (gone after registration)

... but a 10-bit non-linearly encoded file doesn't implies a double sized file...

I agree, Alexander, but it does require a minimum of 2 bytes of data, which I think is George's point. Anything between 9 and 16 bits will require a minimum of 2 bytes so the up-scaling to accommodate 10 bits is likely to be the same as to acommodate 16 bits. If the M8 uses an 8-bit processor and 8-bit data buses, which seems very likely, then each 10-bit file would require 2 write cycles instead of one. This would negatively affect processing speed, which would show up as lag.

 

Pete.

[george +]

If you write an unencoded 16-bit file you get a doble sized file, but a 10-bit non-linearly encoded file doesn't implies a double sized file. It would be a file marginally bigger than the actual 10MB file. That is the point.

 

Ruben, these days programmers operate in bytes, not bits. A byte is eight bits. It would be too much trouble to manipulate ten bit groups across byte boundaries.

 

The stream that you propose would look like this:

 

111111111122222222223333333333 pixel bits(10/)

11111111222222223333333344444444 bytes(8/)

 

The top line are the pixel information - ten bits per pixel, the bottom line shows the bytes that carry it. So the first pixel is the entire first byte and two bits of the next. The second pixel starts at the third bit of the second byte and goes to the fourth bit of the third byte, etc.,etc.,etc.,

 

Yes, it could be done - but messy. So Leica decided to go with eight. Because their choice was eight or sixteen. (Not ten - that was not a realistic option - I guess) .

 

I am not disputing that sixteen bits per pixel may have been better. It might have been. But it would have made a double sized file, that means half the number of images on the same SD card. OK?

 

So; what do I not understand?

[guywalder]

Guy, thanks a lot for compiling this list and thanks to Leica for taking the time to crawl through it with us.

 

And the next time we present a forum concern summary, it would be great to develop priorities, as I am sure they also are doing. Maybe they will be less afraid of forum craziness if we show some engineering savvy.

scott

 

Guy, Scott,

 

I second the thanks to Guy for making the effort!

 

Regarding priorities

1) Get the M8 to work as it has already been designed to!

i.e. fix the bugs and irritations in what has already been engineered. There is no point in dreaming about great new features until the M8 is a stable, reliable product.

2) Improve the usability of what is already there. There are various comments here already, for me this includes the unresponsive review system/buttons and the too small histogram, oh yes, and 1/3rd stop compensation in manual mode....

3) when 1 and 2 are done, then get with the new features.

 

Finally from me, yet again, lens coding. The Leica response is way too weak. This is from the company that only just got round to offering auto exposure, and they still give me no option to set focus, aperture and ISO manually (nothing wrong with any of that!), so to say that I can't be trusted to set the lens code is pathetic. If Leica were smart the lens coding would not only be user settable in camera, but also a look up table in C1, so if I got it wrong in camera i could re-set it in post. If I get the focus wrong I'm never going to recover that in post.....

Guy

[rami G]

nor for my one!

 

I agree that 27 has not been fixed. and it is very anoying.

 

I second those who are willing get higher than the 8bit spectrum as an option, or even, if it would be less than the full 16bit 20mb files, I am willing to sacrifice some speed and some space for a bigger files as default.

[carstenw]

Have any of the people who want more bit-depth actually seen pictures where there were problems? Note that the only possible ill effect here is posterisation within the tonal range, not problems beyond the tonal range.

[stunsworth]

Note that the only possible ill effect here is posterisation within the tonal range, not problems beyond the tonal range.

 

That was the point I was trying to make in the bald shiny head thread.

[rosuna]

Advertisement (gone after registration)

Yes, it could be done - but messy. So Leica decided to go with eight.

 

Many A/D converters work in 12-bit and 14-bit spaces, not only 8 and 16-bit (In fact, I think all operate in 16-bits and then 2 or more stops of tonal range in the shadows are deteled). When you open one of such files, typical in Canon or Nikon cameras, you place the tonal information in a 16-bits space, but they weren't true 16-bits files. They contain a lot less information. The encoding formula employed by Leica is quite simple. Messy or not it can be done better.

 

Note that the only possible ill effect here is posterisation within the tonal range, not problems beyond the tonal range.

 

That is the point. I fear posterisation effects and loss of tonal range. It is nonsense to have a sophisticated CCD FFT sensor and A/D converter and then compress the tonal range. Usually, you pay a price for a wider dynamic range and tonal range (more noise at high ISOs), so I would like to have that tonal range preserved.

[george +]

Many A/D converters work in 12-bit and 14-bit spaces, not only 8 and 16-bit (In fact, I think all operate in 16-bits and then 2 or more stops of tonal range in the shadows are deteled). When you open one of such files, typical in Canon or Nikon cameras, you place the tonal information in a 16-bits space, but they weren't true 16-bits files. They contain a lot less information. The encoding formula employed by Leica is quite simple. Messy or not it can be done better.

 

 

 

 

 

That is the point. I fear posterisation effects and loss of tonal range. It is nonsense to have a sophisticated CCD FFT sensor and A/D converter and then compress the tonal range. Usually, you pay a price for a wider dynamic range and tonal range (more noise at high ISOs), so I would like to have that tonal range preserved.

 

Yes Ruben, they all - or most I would think - use sixteen bit files. That is all that I was attempting to point out. That tenbit files could be messy. OK?

[scott kirkpatrick]

Guy, Scott,

 

Regarding priorities

1) Get the M8 to work as it has already been designed to!

i.e. fix the bugs and irritations in what has already been engineered. There is no point in dreaming about great new features until the M8 is a stable, reliable product.

2) Improve the usability of what is already there. There are various comments here already, for me this includes the unresponsive review system/buttons and the too small histogram,

3) when 1 and 2 are done, then get with the new features.

 

Finally from me, yet again, lens coding. The Leica response is way too weak.

 

I agree, and they don't really need us for (1). Just good clear bug reports when there are failures in the field, something the dealer network should do, but probably isn't as skilled or as detailed as we'd like to see. So we can improve on (1) feedback by staying cool and doing quick problem analyses to get the right questions answered by the owners of the problem units.

 

(2) is where making our priorities emerge is important. And I don't expect that we all agree. maybe it is worth posting another poll for a week? Force some choices on ourselves, rather than asking for everything.

 

For example, which do you want to see first --

Change ISO and exposure using the up/down and left/right arrows in non-Play mode

or

Specify the lens selected (overriding lens detection) from a menu.

 

(I didn't ask which to do, only which to do first...) With a longer list of suggested improvements, we could sort out the ones to do first and have some leaders in hardware (on/off switch or shutter button?) as well as in firmware and function.

 

 

 

scott

[scott kirkpatrick]

Ruben, these days programmers operate in bytes, not bits. A byte is eight bits. It would be too much trouble to manipulate ten bit groups across byte boundaries.

 

The stream that you propose would look like this:

 

111111111122222222223333333333 pixel bits(10/)

11111111222222223333333344444444 bytes(8/)

 

The top line are the pixel information - ten bits per pixel, the bottom line shows the bytes that carry it. So the first pixel is the entire first byte and two bits of the next. The second pixel starts at the third bit of the second byte and goes to the fourth bit of the third byte, etc.,etc.,etc.,

 

Yes, it could be done - but messy. So Leica decided to go with eight. Because their choice was eight or sixteen. (Not ten - that was not a realistic option - I guess) .

 

 

Messy isn't a matter of aesthetics. Modern signal processors have instructions like

READ BYTE, READ Double-BYTE, and various shifts. The code for reading or writing a file of 8bit values goes like this:

 

add 1 to byte address of last pixel value

add 1 to byte address of where you will put it

get that value and put it there

 

3 machine cycles and two bus transfers of one byte, probably grouped to add up to 4 bytes at a time.

 

For 16 bit data, the 1's become 2's and the result looks the same.

 

For ten bit data, the code looks sorta like this:

 

add 5 to 5* the address of last pixel value

save the result

divide that by 4 and keep the remainder (modular division)

get the byte at this address

add 1 to this address

get that byte

put both of them into a shift register

shift left by the remainder of the first operation padding on the right with zeros

(or shift right by 2*(4-shift)

Figure out where the result should be stored. We start all arrays on the same boundaries, don't we? Or is there a change in dimensions, in which case we do the same thing over again. Then store both bytes.

 

Loosely speaking, fetching a byte in order to do some level-setting, compression or whatever, even before writing out the RAW file, costs one instruction and one read. 16 bit data costs one instruction and a wider read. Oddwidth data costs 3-5 instructions, and at least twice the read/write time. If you thought the DMR was a little slow but the quality was worth it, this is 3x slower, and may not achieve the same quality.

 

That's why the instant engineering judgement is that 8bit and 16bit data storage are always the leading contenders.

 

scott

[guywalder]

I agree, and they don't really need us for (1).

scott

 

Scott,

my comment was based on the response to 12, 15, 17, 20 and (for me) 20. My reading of Leica's answer is 'not working on these'.

A priority list is a great idea, as long as it doesnt dilute the 'stable, reliable camera is No 1'!!

Maybe worth splitting out the laundry list into 'functional problems' and 'feature wants'? and then set the feature wants priorities

Guy

[scott kirkpatrick]

Scott,

my comment was based on the response to 12, 15, 17, 20 and (for me) 20. My reading of Leica's answer is 'not working on these'.

 

I think you are right, Leica can't do much about 12, 15, 17, and 20 without solid evidence in their hands. 12 doesn't happen to me. 15 and 17 are freeze-up issues involving a particular card and perhaps a particular load of data on that card. But without those card, they are not going to make progress. And 20 was a really scary picture. It was posted by Phil Evans, Dec 22, 2006. Phil, did you ever send Leica the file?

 

In each case, we could have done more as well. I would hope the whole issue of supporting more cards, including SDHC, and protecting the camera against strange things that users can do by making the firmware more bulletproof will proceed regardless.

 

scott

[rosuna]

Loosely speaking, fetching a byte in order to do some level-setting, compression or whatever, even before writing out the RAW file, costs one instruction and one read. 16 bit data costs one instruction and a wider read. Oddwidth data costs 3-5 instructions, and at least twice the read/write time. If you thought the DMR was a little slow but the quality was worth it, this is 3x slower, and may not achieve the same quality.

 

That's why the instant engineering judgement is that 8bit and 16bit data storage are always the leading contenders.

 

scott

 

The speed in processing and archiving the final DNG file depends on many other variables. Even if this particular operation becomes slower, the impact in the total processing time can be small. Moreover, writting a 12MP file (for instance) is faster than writting a 20MB file.

 

Think about the JPG file. You must to get the data, apply the corrections (vignetting, cyan corners, etc.), color interpolation, sharpening and other algorithms, JPG compression and writting. It is a long a complex process. The DNG processing is a much simpler process. However, the JPGs are processed at a similar or even faster speed. The size of the final file seems to be the determinant factor in the total time required for storing the final file.

[george +]

The DMR writes a 16-bit file, uncompressed.

The non-linear compression made by the M8 is a good idea, but I cannot understand why they choose 256 variants.

 

Oh Ruben, this is quite an admission. They chose 256 because that is what one 8 bit byte will hold. And a byte of 8 bits is a standard of todays information processing.

[rosuna]

Oh Ruben, this is quite an admission. They chose 256 because that is what one 8 bit byte will hold. And a byte of 8 bits is a standard of todays information processing.

 

It is an interesting contribution, and quite technical.

 

Obviously, I used "256 variants" (=2^8) as a synonymous of 8-bits.

 

Even you can understand this.

[carstenw]

You two should get a room. This is getting indecent

 

I repeat my request: I also find that 8-bit storage sounds... risky, but I have yet to see ill effects. I think we should not bother Leica with a feature request before we have shown that their 8-bit trick isn't good enough. Can anyone show that it isn't good enough?

 

This is my challenge to you who want 16 (or 10) bits.

[rosuna]

Carstenw, I consider indecent to have to bear trolls here.

 

You are right in your point. The question is if there are practical differences between 8-bits DNG files from the M8 and hypothetical 16-bits files. Can we see these differences? Whether we can see them the costs can be worth, or not. What are those costs? File size and writting/processing time. The only way of putting some light on this is to compare the M8 and DMR files, looking at the highlights and tonal range. There are other factors in a complete evaluation, but we haven't enough information. We only can argue.

 

The last issue of the LFI Magazine contains an article that explains the 8-bit encoding clearly, and the reasons of Leica for it. However, at the end, the author asks if a wider storing space wouldn't have been a better option...

[sdai]

Perhaps we shall drop all the technical issues and ask Leica for some black dots instead ... LOL

[Guest guy_mancuso]

I was thinking Stainless steel myself

[Advertisement]

Hallo,

Look here: Leica M

[george +]

It is an interesting contribution, and quite technical.

 

Obviously, I used "256 variants" (=2^8) as a synonymous of 8-bits.

 

Even you can understand this.

 

Hey Ruben, wake up!!! This is not a personal p*ssing contest. We are trying to help Leica; where help is needed. And now that you acknowledge the LFI article, you too can see the benefit of that scheme. Good.

 

Now that we cleared that, we need proof - if some can be found - that the eight bit scheme needs improvement. And if such proof exists in some cases, then (and only then) an 8bit/16bit option may be interesting.

 

And I guess you too agree that we can forget about that impractical tenbit thing. Which, apart from the question whether improvement over the eightbitthing was needed at all, was what all I was discussing.

 

Pace?