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 :)

Review - Panavision "Log" vs. Red "linear"?

Joe G.

Well-known member
Joined
May 24, 2008
Messages
831
Reaction score
0
Points
0
Website
politicalfilm.wordpress.com
Stu Maschwitz at Prolost blog has done some tests.

Digital Cinema Dynamic Range

He seems to suggest that the Panasonic cameras use a logarithmic color space that is superior to the Red. I don't understand the technical side of this (and he trumps all at the end showing 35mm film quite superior to both).

Any comments?

PS-

He was probably using B-15 or lower. Has B-16 increased the range so that his results are no longer valid?
 
Well Panavision sensor is still photosensor that is linear and blows highlights exactly at the same intensity as any other CMOS or CCD sensor (more or less)

If you choose to send data out in the linear or log format has nothing to do how it handles the DR. It has a lot of to do with amount of data and compression accuracy.

Untill someone will introduce the photosensor that has logarithmic characteristic we are stuck with linear sensors for now.

I will disagree about superiority of log data as oppose to linear. Linear data gives you more accuracy at given processing power.
 
Are we talking Panasonic or Panavision? Not the same...
 
The blog was referring to Panavision, the Genesis.
This article appears slightly out-of-date. I also feel the test that was performed was skewed.
REC709 is fine and all, but why? I get better results when using Redlog. No, I'm not doing filmouts yet. So what.
 
Log and "Linear" are just different ways of storing the dynamic range of the sensor output, whatever it is for those cameras. I don't think 10-bit Log is necessarily superior or worse than 12-bit linear for dynamic range in any general sense, it really depends on the individual camera. Whatever the recording method, the Genesis and the RED are designed to record the maximum useful dynamic range of their respective sensors. The main difference is that a RAW recording of a Bayer output is less "processed" into any other format, whereas some other cameras convert the linear output of their sensor to 10-bit Log. But even though the RED outputs RAW files, they are compressed files, so you can't say that it's completely "unprocessed" either.
 
I never considered compressing the raw data processing or limiting the DR or color space, but maybe it does? I think this is a question for the code geeks on here to address. All of my DSLR's compress the raw data and I believe it to be totally lossless. But the raw compression is to a much less degree than on RED.
 
I don't think 10-bit Log is necessarily superior or worse than 12-bit linear for dynamic range in any general sense

Actually there are some advantages of non-linearity (say log) vs. linear in some situations, especially where it is desired to cram a higher DR into a capacity of lower DR.

Compressing a signal (say using a log function) and then expanding it later using the reverse mapping has historically been used to good effect in analog communication in devices called "companders" to offer better noise immunity. Even in digital compression, many schemes make use of this fact -- for e.g., A-law and u-law in audio compression, especially at low bit rates.

The process of film negative scanning may also been seen as similar to this. The input light is already stored as compressed log signal and then linear scanning into 10 bit numbers (10 stops) lets one store more than 10 stops, even if highlight compression is not applied towards the end of the curve. This process have the satisfying result of distributing the 10 bits in a way that more resolution is given to darker stops and less resolution to brighter stops that works well with human perception of brightness.

Similarly in compression of video signal out of camera, some sort of non-linearity before compression (say Wavelet) and then reverse-mapping back to linear may help to reduce noise in darker areas (noise here being resulting from compression modeled as additive). I.e., the end-end signal from sensor to post-processing is still linear, however, darker areas in the image may have better detail free of noise.
 
Linear is just not very efficient for storage. Using 50% of your code values for the last stop is a waste especially if you know you're going to compress the highlight anyway when going to a perceptually mapped output.

However, if you know you're overexposing a low contrast scene and will be expanding the up upper stops back out, then it would help to use an encoding closer to linear or linear depending...
 
Not talking about the RED, but just because a camera records RAW files doesn't guarantee that it records more dynamic range than a camera that records conversions to LOG -- for example, you could design a RAW camera with really poor dynamic range.

The "natural" output of any sensor is nearly linear, LOG is just another form of compressing that range into a form that can be recorded within the bit depth, plus it mimics the look of a scan of color negative film. In the future, maybe all digital cameras will just record 12-bit, 14-bit, 16-bit, etc. linear RAW files and leave any conversion to LOG for post, but for now, there is a tradition of working with 10-bit LOG images for D.I. and efx work, so it makes sense for some cameras to create that format.
 
Linear is just not very efficient for storage. Using 50% of your code values for the last stop is a waste especially if you know you're going to compress the highlight anyway when going to a perceptually mapped output.

However, if you know you're overexposing a low contrast scene and will be expanding the up upper stops back out, then it would help to use an encoding closer to linear or linear depending...

Deanan, wasn't there a Log recording mode in the original Red
One spec? I seem to remember something like that form NAB 2007.
 
Touche.

I was just wondering if that had been abandoned or if we might ever see a pre-compression Log curve applied?

Linear is just not very efficient for storage. Using 50% of your code values for the last stop is a waste especially if you know you're going to compress the highlight anyway when going to a perceptually mapped output.

Can you tell me anything more about RedFlex?
 
Touche.

I was just wondering if that had been abandoned or if we might ever see a pre-compression Log curve applied? Can you tell me anything more about RedFlex?

Evin, I think REDRAW is already taking care of it:-)

RedFlex as I understand it is more careful treatment of highlights cliping.
 
Not talking about the ...

David, have you ever considered a career as a technical writer. I think you are one of those very few "non-technical" (by degree) people I have seen who are able to put technical concepts so succinctly expressed that everybody can understand, and still be technically accurate almost invariably.

I think Red must hire you for writing technical documents. And, I am not joking. I don't think that, in general, Red does a good job of explaining technical stuff to people on this forum. I can tell you from my experience that are so many wonderful research publications out there with wonderful ideas, but nobody bothers reading them because they are poorly written, and that knowledge gets wasted, and several years / decades somebody re-invents those ideas and seemingly "new ideas" are born.
 
Evin, I think REDRAW is already taking care of it:-)

Huh? RedRaw? Do you mean Redcode Raw? That is a 12bit linear RAW recording space. Hence the question.

RedFlex as I understand it is more careful treatment of highlights cliping.

That is what Jim alluded to in his response to my Build 16 test.
 
Huh? RedRaw? Do you mean Redcode Raw? That is a 12bit linear RAW recording space. Hence the question.

Yes, it is 12 bit linear on output from REDCODE RAW but to compress 12:1 fast you will be tempted to cut on this last or maybe two last most significant bits in logarithmic fashion.
I don't know what Graeme is doing there, he hates operating on log since it is equations nightmare, and on top of it it is wavelet based codec as well, but to leave these few most significant bits without bringing it down to the same granularity level as the first few less significant bits, it is waste of data space.
.
 
Compression is an art as well as a science.

Graeme
 
Back
Top