Jump to content

M8 Feature Options


Guest guy_mancuso

Recommended Posts

  • Replies 138
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Charles,

Go into the menu. Select Histogram. Select standard w/ clipping.

It is in the current firmware.

This shows you the clipping which is occuring in the preview.

Ray

 

Ray,

With this set I dont get a clipping warning when viewing the full screen image, only when i press 'info' then I get the TINY histogram/clipping previews. My camera came from the shop with 1.092 installed a couple of weeks ago. :confused:

Guy

Link to post
Share on other sites

Guest guy_mancuso
Ray,

With this set I dont get a clipping warning when viewing the full screen image, only when i press 'info' then I get the TINY histogram/clipping previews. My camera came from the shop with 1.092 installed a couple of weeks ago. :confused:

Guy

 

 

Exactly what Ray said is what i got on 1.092

Link to post
Share on other sites

Advertisement (gone after registration)

Hello Guy!

2. Optional 16 Bit setting. Knowing this will slow down camera buffer and less storge space OR adopt 10-bit non-linear encoding by default. Non-linear encoding for storing purposes a great idea

I have 'investigated' this issue since the first M8 DNGs have been available. My first assumptions was, that this 8 bit to 14 bit linearisation is not the right way, but the more and more images I have compared (also some 16 bit DNGs from DMR converted to 8/14 bit) the less I have found significant differences. In LFI, 'mjh' has done a very impressiv description in comparing the M8 way and 'usual' 12 bit DNGs (named CR2 :-)

We have exactly 4 possibilyties to save M8 raw data in a DNG:

 

a) plain 16 bit like DMR

 

B) linearised 8/14 bit like M8

 

c) lossless JPEG with 14 or 16 bit (difference in storage size is marginal: 13 - 16MB, depending on content)

 

d) lossless JPEG with linearised 8/14 bit

 

Is is not senseful option to use plain 14 bit, because this needs the same space like 16 bit do. In DNG (exactly TIFF EP) there is no bitstream storage mode defined to save 2 bits per word.

 

Pros and cons:

 

a) needs twice the starage space (20MB) than the actual system. Obviously, it is also slower. Benefit is, that there is absolutly no lost of resolution AND dynamic.

 

B) We have the full dynamic range, we have decreased 'color resolution', but we have the smallest storage size.

 

c) This gives all the advantages from (a) plus lesser storage space. Disadvantage is, that it may be much more (cpu) time consuming (at storage time and at review time)

 

d) this would be only a compromis for smaller (than actual) DNG file (6 - 8MB) size. Not so time consuming than 14/16 bit lossless jpeg.

 

My personal opinion is, to have (a) as an alternativ method, where storage space (and time) does not matter.

 

The 10 bit linearised method is - pardon - more than senseless, because the 'genious' methode of 'square function' is not useable. 8 bit squared yields 16 bit (which will fit into the LinearisationTable) but 10 bit squared needs 20 bits, which is not in accordance which the DNG (TIFF EP) specification of a 16 bit (SHORT) table.

Link to post
Share on other sites

wierd, maybe I have 1.092.0 and you and Ray got 1.092.1 :rolleyes:

 

I already tried overexposing (by lots), but no clipping in full screen mode. I'll try it again

 

Guy, there are two settings which need to be enabled:

 

- Menu/Histogram/Std. with clipping or RGB with clipping

- Menu/Auto Review/Histogram/On

Link to post
Share on other sites

You have "explained" nothing (Another joke?). I seriously doubt you even can read properly, or maybe you are insulting by fun.

 

Come on Ruben, no need to descend to this level of personal attack no matter what you may think.

 

As I understoof it the point that George was making was that if you want to store 10 bit values they have to be stored inside 16 bits (i.e. 2 bytes).

 

I have to admit that unlike George I have only been working in IT since 1976, but I can see the point he's making.

Link to post
Share on other sites

It is certainly easier to store data in even bytes, as George points out, but it is not necessary. One can store information in partial bytes. One might store 4 pixels in 40 bytes instead of 5 pixels, yielding a 10-bit scheme with only an 4-pixel dependence, which is certainly doable. To retain the current writing speed, however, it might be necessary to modify the hardware. I don't know to what extent these processors are programmable, but if the firmware updates could modify the way data is written to include some bit-level shifts and ORs, then such a change is possible.

 

Ruben and George, I really wish you wouldn't get quite so angry. It doesn't help you or anyone else, and it is normally so great and peaceful around here, quite a contrast to many forums.

Link to post
Share on other sites

With some hesitation, I dip a toe in these torrential waters:

 

First, is there anyone who has experienced real (as distinct from hypothetical) problems with the 14/8 bit root colour compression? Raise a hand, please. I think the explanation given in LFI was pretty convincing. The proof of the pudding is in the eating, not in the recipe.

 

Second, I think new lenses are a different matter. It deserves a more than marginal discussion. Please see the recent thread 'New lenses for the M'.

 

Third, the dynamic characteristics of the M8 are quite close to slide film, especially Kodachrome. This means that there is ever a latent danger of overexposed highlights. When I used KC professionally, we routinely bracketed our exposures. We can still do that without too much menu-fiddling if we use manual exposure. Now of course, with a motorised camera, we might be able to do that on auto exposure too. While the extent of bracketing should be menu-adjustable, the activation is however a different matter. Maybe the most rational way would be either a thumb-friendly bracket button, or a bracketing drive mode on the switch under the release. I simply offer this as food for thought. I am quite happy with manual exposure!

 

The old man from the Age of the Ave Maria

Link to post
Share on other sites

Hello Lars!

First, is there anyone who has experienced real (as distinct from hypothetical) problems with the 14/8 bit root colour compression? Raise a hand, please. I think the explanation given in LFI was pretty convincing.

It is not possible, due to lack of real 14/16 bit M8 DNG, to observe real problems!

So, only hypothetical assumptions can be taken.

No doubts, 14 bit dynamic is available and matches the highest contrast, our lenses for the M8 will produce. This is better than low contrast lenses and 12 bit dynamic or what ever the competition will support.

The issue is not the dynamic range, it is the fine (micro) contrast of all the lenses, which MIGHT be influenced by the limited resolution of only 8 bit. I think M8 lenses are uncompareable to all other lenses for all other digital cameras (even DMR+R8/9).

But these are all pure assumptions, as long as we (or I) do not have real 14/16 bit DNGs to compare.

So, if there is an optional storage format with 14/16 bit DNG, nobody can longer complain or create theories or hypothesis about the 8/14 bit 'compressed' DNGs.

It is absolutly senseless, to compare images of the M8 with images (regardless which dynamic or resolution they have) from other brand. I have done this and failed in all cases, because the lenses are (politly said) not compareable.

Link to post
Share on other sites

It is not possible, due to lack of real 14/16 bit M8 DNG, to observe real problems!

So, only hypothetical assumptions can be taken.

 

It is certainly easier to store data in even bytes, as George points out, but it is not necessary. One can store information in partial bytes. One might store 4 pixels in 40 bytes instead of 5 pixels, yielding a 10-bit scheme with only an 4-pixel dependence, which is certainly doable. To retain the current writing speed, however, it might be necessary to modify the hardware. I don't know to what extent these processors are programmable, but if the firmware updates could modify the way data is written to include some bit-level shifts and ORs, then such a change is possible.

 

That is my point.

 

The encoding can take more time, but "encoding" isn't the only task during internal processing/writting, and many other variables are involved (for instance, the type of SD card used). A 10-bit encoded file requires, 1) more processing time and 2) more writting time (because the resulting files is bigger than a 8-bit DNG), The question is if this implies a sustantial increase or not.

 

The 8-bit encoding and storing is compressing the tonal range. The A/D converter separates 16-bits, 14 are preserved and then "encoded". You go from 16,384 variants (=2^14) to 256 variants (=2^8). That reduction keeps more variants for the shadows. There weren't too many variants left for the shadows even in the 14 bits space! However, the tonal variants of the highlights are brutally reduced. The argument is that the human eye cannot discern much variability there anyway. The LFI article says Leica compared the original 14-bit output and the 8-bit alternative and no discernible differences can be appreciated, even in scenes with a lot of highlight gradations. The only way of testing this is by comparing DMR and M8 files. Maybe Guy Mancuso or others can do some research.

Link to post
Share on other sites

Guy,

If you are looking for more than just firmware fixes, I would say get rid of the "protect" button and replace it with a user defined button. Actually this could be done now if we had the software, who cares what the button is named. Most users do not use the protect button.

Inept photographers like me use the protect button :( I mark all the shots I want to keep as protected on the card and then I hit the "delete all"button. Much faster than deleting the images one by one.

Link to post
Share on other sites

However, the tonal variants of the highlights are brutally reduced.

 

Do you have an example showing these brutally reduced highlight tones? Surely if they are so bad we should be able to identify them in their own right without reference to any other image?

Link to post
Share on other sites

Hello!

The LFI article says Leica compared the original 14-bit output and the 8-bit alternative and no discernible differences can be appreciated, even in scenes with a lot of highlight gradations.

I am convinced, this is absolutly valid, for 'normal' images, which are correctly exposed and exactly in the dynamic range of 14 bit. But if, due to not fully balanced light situations, highlights are overexposed or shadows are underexposed, there might be a lost a tonal values when trying to correct the brightnes and/or contrast.

The only way of testing this is by comparing DMR and M8 files. Maybe Guy Mancuso or others can do some research.

This comparison can surely be approximated, by using equivalent lenses on M8 und DMR. But do those lenses exist in reality?

Link to post
Share on other sites

Hello!

 

I am convinced, this is absolutly valid, for 'normal' images, which are correctly exposed and exactly in the dynamic range of 14 bit. But if, due to not fully balanced light situations, highlights are overexposed or shadows are underexposed, there might be a lost a tonal values when trying to correct the brightnes and/or contrast.

 

Which is exactly the reason one should expose correctly for the highlights and use the remarkable shadow recovery possibilties of the M8 to balance the exposure of the image in postprocessing. The shadows behave like they are 16/14-bit as far as I can tell.

Link to post
Share on other sites

Guy, there are two settings which need to be enabled:

- Menu/Histogram/Std. with clipping or RGB with clipping

- Menu/Auto Review/Histogram/On

 

Carsten,

Thanks, I got there in the end :p

But guess what? now I am going to moan about only getting clipping on a full view when using auto preview (cos' I dont like auto preview) :(

Guy

Link to post
Share on other sites

@guy:

I think you mean "SDHC" in number 8....

According to this website Acronyms and abbreviations by the Free Online Dictionary., SNDC means "Status, Data Not Consistent".

Although I don´t perfectly understand what it means, I am sure I wouldn´t want that in my camera... :rolleyes:

Great list you made! Thanks!

 

Stefan

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.

×
×
  • Create New...