Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Mysterium-X dynamic range...

Pardon me if my I am misunderstanding, but I can see how people are getting confused by this. Jeff you agree that the sensor captures light linearly

Yes.

and that light is measured exponentially.

It's being measured, quantized, or abstracted linearly as well. Light measurements only become non-linear when you reference them using a non-linear scale, such as stops.

The number of stops in a range does not NEED any specific number of bits. First of all, forget bits. They are a binary abstraction. Just ask yourself how many levels of gradation you would like, on a linear scale, from the darkest point to the lightest point that the sensor can interpret. Currently that scale is linear from 0 to 4095. That happens to be a 12bit value.

You can represent that exact same range with a 10bit or 8bit value if you wanted. 8 bit would give you 256 gradations from darkest to lightest. 10 bits would give you 1024 gradations. 12 gives you 4096, 14 would be 16,384, 16 would be 65,536, etc..

Stops are ONLY ONE OF MANY ways to measure light transmission. Bits are how a digital system compounds data sizes. Everyone suddenly thinks that bits are somehow interrelated with stops, and they are not. No one is even questioning what the actual range is. 12 stops can mean completely different amounts of light depending on our starting and ending EV's. As it is, "12 stops" is a completely arbitrary relation. What if the range was expressed in Lux or footcandles?

For example, what if the range is 0.12fc to 475.14fc? That's a "12 stop" range and on a linear 12 bit scale, it's 0.116fc per integer value 0 thru 4095.

On the other hand, what if the range is 0.47fc thru 1925.12fc? That is FOUR TIMES the luma range, but is still a "12 stop" difference. Expressed on a linear 12 bit scale, it would be 0.47fc per integer value 0 thru 4095.

I'm fairly sure you do need over 13 bits of A/D to capture over 13 stops. If 12 bits allows us from 0-4096 raindrops, and rainstops are a square exponential measurement of raindrops (raindrops = 2^rainstops), and only 11 rainstops worth of rain fall in any cup, the highest value measured will be 2048, right? what happens if 13 rainstops aka 8192raindrops fall in a cup?

You're associating bits = stops or that the numbers on the sides of the cups are specifically linked to their capacity, that is not the case. Bit's is simply the number of steps or gradations you divide the whole into. Let's say you re-marked all those cups with 14 bit values. So now the scale is 0 thru 16385. The cups are still the exact same size and lets say the exact same amounts of rain fell, you just have more numbers to divide up. So more precision. Increasing the number of bits is analogous to the difference between measuring the same liter of water in centiliters vs. milliliters. The finer unite of measure allows for more precision.

If you wanted to capture more rain drops, or more range, let's say your cups are deeper. You can still use the same scale, it just stretches to match the deeper cup, therefore you account for the range, but at a loss of accuracy. Same thing as now, we could capture the equivalent of 12 stops of rainfall, but change the scale on the cups to a 10bit gradient of 0 to 1023. Same range, less precision.

I am under the impression you need at least as many bits of precision as you want stops of dynamic range

They are not related, so why? More bits equals more precision, so more is typically better. But there is no specific rule that says the number of bits needs to be equal or greater than the number of stops. A/D conversion is often not directly relational anyway, depending on the processes being used. It's not uncommon to have A/D converters that are 12, 8 or even fewer bits creating 16 and 24 bit audio in the audio world. Processing light values is really not a whole lot different than processing sound. It's just that with light and images, we process millions of times more information for any instant in time due to all the pixels. In most A/D processes, the bit depth typically represents the amount of data processed in a given cycle as opposed to the accuracy of the conversion. I don't believe RED has ever stated specifics or bit levels of their A/D process.

Anyway, we have gone back to beating numbers to death and I think I'm done. I really don't know how to explain any more without going the opposite direction and getting overly technical and into lots of math that most people won't want to see. It just is what it is...

The camera gives us 12bits of recorded values for each RAW R, G or B pixel on the sensor. If you don't think that's good enough or you don't think that makes sense, then fine... But the proof is in the pudding, or images. It looks pretty good.
 
@Jeff
I'm still not clear on why you feel A/D bits should have nothing to do with stops of dynamic range, despite information I have seen and experienced. Perhaps you could explain why this concept doesnt apply:
http://www.luminous-landscape.com/tutorials/expose-right.shtml
even though when viewing a raw histogram on RED ONE stopping down one stop does move the value of a peak from what appears to be 100% down to 50% and why some CMOS/CCD technical literature recommends using at least 10bit A/D for signals with 60db dynamic range (10 stops), 13bits for 73db+ (12+ stops) etc?

You talk about footcandles, so by your same math, if a scene consisted of a range from 1-4096 footcandles (12 stops) and the sensor and A/D are linear then those are mapped at 1fc per gradation, so clearly in a linear system (as most CMOS/CCDs are, from what I understand) one would theoretically require 12 bits to contain all those values and also 14bits would be required for a scene containing a 1-16384fc range (14 stops).

I'm just trying to figure out why we arent at a consensus on this seemingly simple concept. Maybe its still a matter of misunderstanding about the function of an A/D converter in a photosensitive imaging system?

I dont mean to say that RED isnt giving enough bits, clearly they have it figured out, whether it be due to 14 or 15bit A/D with gamma encoded recording or something else. I am just trying to clear it up for the sake of my own understanding and for those that might be confused reading through responses in this thread. Also it is interesting to know these things for reference in comparison to other similar cameras, even though camera systems are rarely designed with A/D bit depth as their primary limitation in terms of latitude.
 
So it is important to have both more bits and the ability to capture more stops of light (or more dynamic range) on the sensor? Because if you captured 15 f-stops in an 8 bit image it would give a lot less post freedom/re-exposing room?
 
Think of it this way: Take a picture of a black piece of paper on a white piece of paper. That represents a dynamic range of say, 8 stops. But you only need 1-bit color to represent that accurately. Every pixel is either black or white (the papers are perfectly straight, so you don't need any anti-aliasing, smarty-pants). But say you put your hand on the papers. No color on your hand is darker than the black paper, or whiter than the white paper, so the dynamic range is the same, but you're now gonna need a lot more bits to make that picture look good. At least 16, if you don't want it to look like King's Quest.
 
I would love to hear Graeme's thoughts on this discussion!
 
@Jeff
I'm still not clear on why you feel A/D bits should have nothing to do with stops of dynamic range, despite information I have seen and experienced. Perhaps you could explain why this concept doesnt apply:
http://www.luminous-landscape.com/tutorials/expose-right.shtml

The Luminous Landscapes article does apply somewhat, with the RED One and most digital systems, a practice of Exposing To The Right (ETTR) can be beneficial. However, with a linear system like the RED One, ETTR can often sacrifice dynamic range. The histograms on the link you provided are actually good illustrations of this. Contrary to what the page says, neither of those histograms demonstrate maximum S/N ratio.

Best practice with the RED One, is to shoot for a "thick negative" or "thick" or "full" histogram. The purpose behind ETTR is to push, or even compress, most of your desired exposure toward the upper end of your luma range. Let's just completely forget about stops here for a minute, because it really does not matter. All you need to concern yourself with is the luma range available in a linear relationship from dark to light. The reason behind ETTR and compressing the histogram to the right is to push your usable range as high as you can go without clipping in order to keep your blacks above the lowest acceptable noise floor.

In those examples linked, both histograms are sacrificing DR. The first histogram is sacrificing a good 20% or more on the high end of the range and a good 10% or more on the low end. Assuming the image being shot has a full dark to light, full contrast spread, that the camera operator would want.

With the Mysterium sensor, ETTR was an OK practice, but not to the extreme that one would employ with these older DSLRs. This article is dated - it's about 5 years old, maybe 6. So while it's desirable with the RED One to get your highlights right up to the right end of your histogram, without clipping, you don't need to compress your blacks as much as they show.

With the Mysterium-X sensor, the extra stops are gained on the low end, by reducing the noise floor, so we now have freedom to relax our histogram even more. This can also be said about some of the the newer DSLR's.

even though when viewing a raw histogram on RED ONE stopping down one stop does move the value of a peak from what appears to be 100% down to 50%

Of course it does, you're cutting your light in half if you move down a full stop.

and why some CMOS/CCD technical literature recommends using at least 10bit A/D for signals with 60db dynamic range (10 stops), 13bits for 73db+ (12+ stops) etc?

I would defer to Graeme on the finer points of A/D conversion. But the real point here is that Mysterium-X is not increasing range over what we already have. It is increasing USABLE RANGE by lowering the noise floor.

You talk about footcandles, so by your same math, if a scene consisted of a range from 1-4096 footcandles (12 stops) and the sensor and A/D are linear then those are mapped at 1fc per gradation, so clearly in a linear system (as most CMOS/CCDs are, from what I understand) one would theoretically require 12 bits to contain all those values and also 14bits would be required for a scene containing a 1-16384fc range (14 stops).

In your example, 14 stops would only be required for the larger range *IF* you wished to maintain the 1fc per gradation precision. If you still wished to maintain a 12-bit level of precision, with a 14 stop range, you could. To use your same numbers, it would equate to 4fc per gradation. So there comes the question of whether or not that level of precision is acceptable for your application.

I'm not saying that 12 bits is always enough or that we don't need greater bit depth to represent greater DR. I'm just saying that DR and bit depth are not specifically linked, nor do they have to be. It's a balance between what DR is afforded by the sensor / A/D process, and the bit depth at which the information is encoded which is the level of detail or precision your application requires. For now, 12~13 stops of DR into a 12bit system seems to be working quite well. After all, DPX, which is a 10bit system has been acceptable as a DI standard for years from 16bit film scans.

And like I also said above, we're being told 12 or 13 stops of latitude. That's fine and great, but where that range starts will effect just how much range is there. And as I pointed out before, the difference between about 1/3 of a footcandle as a toe EV, can shift the total DR by a factor of 4, even though both DR ranges would still be "12 stops". Or another way to put it, is RED would only have to lower their base EV by a couple points to gain two full stops that would essentially fit within the same luma range as before. The real difference between M and M-X sensor is the drastically improved (read, lowered) noise floor.
 
Well put, Jeff. Though I feel like this has been explained a couple times over.

Don't get latitude confused with dynamic range, though. Latitude is the amount by which you can under- or overexpose a shot and still have it look good. Dynamic range is -- well, you know what dynamic range is ;)

http://en.wikipedia.org/wiki/Exposure_latitude
 
Think of it this way: Take a picture of a black piece of paper on a white piece of paper. That represents a dynamic range of say, 8 stops. But you only need 1-bit color to represent that accurately. Every pixel is either black or white (the papers are perfectly straight, so you don't need any anti-aliasing, smarty-pants). But say you put your hand on the papers. No color on your hand is darker than the black paper, or whiter than the white paper, so the dynamic range is the same, but you're now gonna need a lot more bits to make that picture look good. At least 16, if you don't want it to look like King's Quest.

There is a 99.99% chance your compu monitor is an 8 bit LCD. probably less than 8 bit - that is not even capable of all colors in the 256 RGB gamut. yet... You can look at pictures on this LCD, even maybe do pro work on it when a good CRT is not available. They do not look like Kings Quest. You can look at pictures that have 20 stops of dynamic range on your LCD screen and they look fine.

Why? Because 256 shades of grey in RGB is about the same as the cabability of your eyes. These 20 stops were MAPPED to the available colors of your screen. Problems only occur when you try to REMAP (that is grade) these values. Then you are stretching small changes in values to represent large changes.

Say you had a darkish background corner. In this corner, there is a shadow with values RGB 2, 2, 2, and a slightly lighter spot with values 3, 3, 3. if you do not regrade, this will appear totally smooth - your eye can barely tell the difference between 2, 2, 2, and 3, 3, 3 within a 256 range. More bits, so that 2, 2, 2, could be correctly recorded as say 2.08, 1.98, 2.04 would make most likely no perceptible difference at all.

BUT... If you try to re-grade this dark corner, so that its values are stretched to the entire range between light and dark of 8 bit so 2, 2, 2, becomes 1, 1, 1, and 3, 3, 3, becomes 255, 255, 255 then you will have massive banding.

8 bit is fine, but its the limit - of you don't stretch it much, you're covered.

Remember, the end user, most likely, is watching your product on an 8 bit or less display.
 
Well put, Jeff. Though I feel like this has been explained a couple times over.

Don't get latitude confused with dynamic range, though. Latitude is the amount by which you can under- or overexpose a shot and still have it look good. Dynamic range is -- well, you know what dynamic range is ;)

http://en.wikipedia.org/wiki/Exposure_latitude

The 2 are directly correlated. Dark parts of your pic are like underexposed whole images, and light parts are like overexposed whole pics.
 
In your example, 14 stops would only be required for the larger range *IF* you wished to maintain the 1fc per gradation precision. If you still wished to maintain a 12-bit level of precision, with a 14 stop range, you could. To use your same numbers, it would equate to 4fc per gradation.

Perhaps I'm not being clear, I wasnt talking about exposing to the right but rather the implications of linear response as it is described in that article and is relevant to our discussion. You could use 4fc per gradation to store 1-16384fc (14stops) of contrast in 4096 gradations (12bit), but you wouldn't want to since the first gradation (0-1) would then be storing your 1-4fc information, which is lowest two full stops of contrast and if two stops of detail are averaged out into one gradation, they can no longer be represented. the third darkest stop captured, 4-8fc would then be stored in one gradation (1-2) so it too would have no detail. Your first three stops would have to somehow be differentiated by being either a 0,1, or 2. If those values were visible due to an absence of noise in the A/D, I imagine if you gamma corrected those shadows, posterization might be quite bad.

It may be that there is no change in the in the A/D precision and recording capabilities for M-X, but I would tend to imagine that would mean they were already using 14bit A/D. Or perhaps the A/D isnt as linear as i have been led to believe it is.
 
I meant total, not per channel. You're right, 8 bits/channel is what we're all used to. (24-bit color.) King's Quest (IIRC) was 8 bits total, like this:

http://upload.wikimedia.org/wikipedia/commons/6/6d/Dithering_example_dithered_web_palette.png

As far as latitude, yes, they are related, but not the same. Not trying to be pedantic here, but latitude is informed by both the DR of the sensor/film and the DR of the scene. If you're taking a picture of a foggy day and your histogram looks like the washington monument, then you've got a few stops of latitude.
 
There is a 99.99% chance your compu monitor is an 8 bit LCD. probably less than 8 bit - that is not even capable of all colors in the 256 RGB gamut. yet... You can look at pictures on this LCD, even maybe do pro work on it when a good CRT is not available. They do not look like Kings Quest. You can look at pictures that have 20 stops of dynamic range on your LCD screen and they look fine.

Post deleted because I made an incorrect assumption about Rob's post speaking towards total bits, not bits per channel.

Screen%20shot%202010-01-26%20at%2010.13.07%20AM.png
 
Those 32bits though are 8 each for red, green and blue, and 8 for an alpha channel on the GPU. LCD panels on cheaper laptops are 6bits per component, and 8bits per component on better LCD panels. Some very high end panels do 10bits per component.

Graeme
 
Wow Todd, that was pretty harsh, and incorrect on your part. And depending on which Macbook Pro you are looking at, you have either a 6bits/channel or 8bits/channel display. If it's the LED backlit model, it's 8bit.

Graeme pretty much sums it up. We're finally starting to see affordable 10bit LCD panels trickle onto the market now. The HP Dreamcolor is somewhat 10bit, there are a handful of more expensive grading and coloring panels out there. A few of the new high-dollar LED LCD HDTV panels are shifting to 10bit. LG's 47LH90 HDTV is reportedly 10bit if I've read their spec-sheet correctly and it sure looks nice, rivaling a nice plasma in most respects. But it's expensive for a < 50" HDTV, although a real bargain for 10bit, if it truly is (I haven't confirmed).
 
I stand corrected. My apologies to you Rob. I need a :footinmouth: smiley.
 
No worries - we are all here to learn and help others learn.

Graeme
 
Jeff, I've understood all you're points, but you can't bend information theory to suit.

13 stops requires 8192 values if stored in a linear form, 13.3 stops requires an extra bit. We don't have to talk in terms of stops, but yes, its all about the level of granularity in the grade, thats were Red footage stops looking homogeneous..

I wasn't complaining about what redcine-x build 90 shows me, 12 bits raw-> floating point RGB is better than I expect, more than I deserve.. but once the pixels are split into wavelet coefficients, information still gets thrown away just like in every other compression system (albeit without the macroblocks), so 13.3 stops from a 12bit bayer, after getting lossy compression applied, is still a remarkable claim, even from a 15bit sensor, even after post processing and debayering.

We could after all capture 15stop of luma using a 2bit sensor, but grading does become awkward.

So I guess redcode must be exploiting the lack of information in the high end somehow to make better use of the bits.

Frankly, I never believed 11.3stop from a 12bit sensor, so lets all agree the mx has more usable range than the mysterium :)
 
Rob it is really difficult to believe anything you say when you get the most basic points of your argument wrong. The industry started moving from 8-bit to 10-bit LCD's all the way back in 2007 and I'm sitting here on a year-old MacBook Pro with a 32-bit LCD. 99.99% chance huh? Your arguments would be much stronger if you took 2 minutes to research some of your posts before you made them (google is built into every browser nowadays, unless you are still using some early 2000's version like your monitor.) Exaggerations for emphasis only work in comedy, when you are not meant to be taken seriously. I guess it's possible that I just didn't get the post and you were trying to be funny.

Huh? I think you are confusing the bit depth of your display interface with the bit depth of your LCD electronics. I believe it is still true that the majority of LCDs out there are still 6bpc devices that utilize dithering to display 8bpc (24bit RGB) input from their standard display interfaces...

What would a real 32bit LCD panel be? One with a red, green, blue, and alpha transparency dot for each pixel in its array? That doesnt exist. The 32bit number you are seeing in your system information is clearly related to the 32bit display mode of your GPU. Todd, you're not helping your case by insulting Rob's researching skills.

My understanding is that even Macbook and Macbook Pro laptops as well as any laptop you are likely to see in a store, except for newest ones with the new RGBLED displays, use 6bit LCDs that use TN or TN+ technology and use dithering to achieve "support for 16million colors" (8bpc color). Apple had a lawsuit about this a year or two ago.

If anyone has any real information otherwise I would be very interested to see it. Maybe some high end pro or military laptops have another kind of panel?

In desktop LCDs you can often tell what kind of panel (6bpc or 8bpc) is used by whether it quotes 16.7 or 16.2million colors displayed. Not sure how the math works out on this or where this comes from, anyone know?
 
Back
Top