What's the difference between RedLog and PDLOG

[Marcus Struzina]

Deanan or Graeme, Is there any clipping necessary in the transfer of the R3d files into PDlog685, or is the full 12bit linear dynamic range of the raw file compressed into the 95cv-685cv range ? Also if it is the case that the 685 point in the PDlog685 represents 90% white, so what level represents 90% white in REDLOG if 100% is 1023?

 

[Terry Wester]

You can get full dynamic range on 10bit as long as you don't export linear light.

Graeme

Graeme,
Are you saying that a rec709 10bit DPX has the same dynamic range as a redLog 10bit DPX?

 

[Graeme Nattress]

YES.

There will be a subtle precision difference as the code values are distributed differently, but that should not be easily visible at all.

Linear light, however, will instantly loose you 2 stops in the shadows.

Graeme

 

[Patrick Tresch]

YES.

There will be a subtle precision difference as the code values are distributed differently, but that should not be easily visible at all.

Linear light, however, will instantly loose you 2 stops in the shadows.

Graeme

Sorry don't understand...:clown2:

is REC709 Linear or log? So will REC709 loose 2 stops in the shadows or not?

Thanks

Pat

 

[Graeme Nattress]

REC709 is a video gamma curve. It's not log and it's not linear light.

Graeme

 

[Terry Wester]

YES.

There will be a subtle precision difference as the code values are distributed differently, but that should not be easily visible at all.

Linear light, however, will instantly loose you 2 stops in the shadows.

Graeme

Graema,

Thanks for the info, This is enlightening. :innocent:

Just a couple of more questions, and I promise I will shut up.

I understand DPX 10 bit carries the full dynamic range of the image in rec709 and Red Log, what about PD Log 685 and PD Log 985?

Also, is there ever an advantage to output 16bit tiffs, or openEXR, as Red Log or Rec709, besides the convenience of a different file format? Is it just like putting 1 gallon of water in a 5 gallon bucket, nothing is lost just putting it in a larger container?

 

[Graeme Nattress]

What differs with these curves is not dynamic range, per se, but the precision of the data, and how it distributes available code values for highlights and shadows.

In order from most to least on the log ones, is:
RedLog
PD985
PD685

Not sure where REC709 fits in there, probably just below RedLog, but not certain.

Graeme

 

[Martin Ludwig]

What differs with these curves is not dynamic range, per se, but the precision of the data, and how it distributes available code values for highlights and shadows.

In order from most to least on the log ones, is:
RedLog
PD985
PD685

Not sure where REC709 fits in there, probably just below RedLog, but not certain.

Graeme

these are some informations which should be in a RED book. Any chance to get this knowledge collected?

 

[radi]

give us some LUTs

give us some LUTs

---
PDlog685 is pretty much the cineon spec for log to linear conversion in reverse (linear to log). ---

Why don't you put the Log Courves or the corresponding De-Log Courves as an XLS or other file (LUT) here on the forum to avoid more "guessing"?
Everyone would now be able to establish a perfect workflow for his specific filmprinter...

Or: if you have two versions to be made from one content (let's say 10bit DPX Sequence in LOG) you can make a cross-conversion to another format (let's say to 709) without rendering the whole thing again!

Cheers

 

[Chris Swinbanks]

PDlog tables

PDlog tables

Why don't you put the Log Courves or the corresponding De-Log Courves as an XLS or other file (LUT) here on the forum to avoid more "guessing"?
Everyone would now be able to establish a perfect workflow for his specific filmprinter...

heh, heh... knew I'd seen 'em somewhere.... Scratch has the tables in XML format. Don't know if it would be kocher to post them here though... expect Lucas would have to open up on that one and say if its OK or not. :matrix:

 

[Marcus Struzina]

I second Radi's suggestion to make available a REDLOG lut or the data to make one, is this feasible?


www.belladonnathemovie.com

 

[Stu Maschwitz]

It is done:

http://prolost.blogspot.com/2008/03/red-log.html

I'm sure Graeme will correct me if I bungled anything!

-Stu

 

[Stu Maschwitz]

Deanan or Graeme, Is there any clipping necessary in the transfer of the R3d files into PDlog685... ?

Not necessary, but it is there unless you drop the EV.

In other words, using PDlog685, your "headroom" values are not included, they must be "revealed" by reducing EV.

I think this is a mistake that should be corrected—it's too easy to accidentally clip values. I've never heard of a log system that clips at the white point—it's not really meant to be "white," as film prints show ample values above 685.

Until this is fixed you must drop EV down about 0.4 stops to reveal all the highlight detail, at which point you are packing all the sensor data below 685.

But this is hardly a recipe for a film-like image, nor is it a very good use of a the precision afforded by a 10-bit file format.

-Stu

 

[Mathew Mackereth]

Not necessary, but it is there unless you drop the EV.

In other words, using PDlog685, your "headroom" values are not included, they must be "revealed" by reducing EV.

I think this is a mistake that should be corrected—it's too easy to accidentally clip values. I've never heard of a log system that clips at the white point—it's not really meant to be "white," as film prints show ample values above 685.

Until this is fixed you must drop EV down about 0.4 stops to reveal all the highlight detail, at which point you are packing all the sensor data below 685.

But this is hardly a recipe for a film-like image, nor is it a very good use of a the precision afforded by a 10-bit file format.

-Stu

darn! is the above correct? I just set up a lengthy transfer from raw to PDlog685 assuming (that's where i went wrong...) that there would be headroom above the white point...and that it would integrate with the already established 35mm workflow...

haven't had a chance to test for myself, but will do so tomorrow...

surely this is a bug? - are the guys at red working to rectify this headroom issue in redcine and correctly map these higher than white values correctly to the cineon spec, or must i use redlog in future and figure out a way to squeeze that into the pipeline...? - or does redlog clip too?

macka

 

[Mike Seymour]

darn! is the above correct? I just set up a lengthy transfer from raw to PDlog685 assuming (that's where i went wrong...) that there would be headroom above the white point...and that it would integrate with the already established 35mm workflow...

haven't had a chance to test for myself, but will do so tomorrow...

surely this is a bug? - are the guys at red working to rectify this headroom issue in redcine and correctly map these higher than white values correctly to the cineon spec, or must i use redlog in future and figure out a way to squeeze that into the pipeline...? - or does redlog clip too?

macka

Yes it is true which is why we drop the ISO do bring back the headroom
NEVER fail to display the histogram and you'll see it for yourself.

Now it is being address and I believe it will be shortly addressed.

Mike @ fxphd.com

 

[Chris Swinbanks]

OK, I'll bite... (and the following is about thinking along the lines of a DI process to filmout)
Why does anyone think pdlog685 has a bug? Not the first time I've heard this today.
It clips Redcode values to 95-685, which if you go back to 1993 was Kodak's Cineon handywork for converting log images from 10bit to 8bit (for video). You accept that above 90% white will be lost, but that will become 255 in an 8bit range. Nothing exists under 95, its unexposed black.... lose it!
Why limit your DI process to 58% of the available bit range?
I can't seem to tell how it gets to Printing Density (as in pdlog), is there a matrix that gets applied somewhere? It doesn't appear to be in the LUT conversion.
Graeme, care to spread some more wisdom on this?

What makes less sense to me is pdlog985, which lifts the black enormously and stretches them out to show all the noise, and also loses the last few bits of the available range at the top end, although you'll never see this on a print.

The only log transform that makes sense for film work (that I can see) is Redlog.

With any of the transforms it appears that you need to reduce the Exposure value (or ISO as Mike suggested, Exp Val gives you more subtle control I feel) to bring extreme highlights into play so that they are available for use at a later stage (also true for Rec709). But isn't that what its all about, retaining all that highlight information for later decisions in post?

 

[Mathew Mackereth]

Thanks mike - will do!

I guess i just assumed that PDlog treated the RAW data as a neg, and that the above white values would get kept as they do with cineon/dpx. I thought that 90% grey would map to 685 , and higher values would be held in the 685 to 1024 range - just like they do with a film transfer.... I'll be more careful in future...

I do hope red "fix" this.

It clips Redcode values to 95-685, which if you go back to 1993 was Kodak's Cineon handywork for converting log images from 10bit to 8bit (for video). You accept that above 90% white will be lost, but that will become 255 in an 8bit range.

this clipping is great if going to video- but i'm looking at a film pathway - plenty of above 90% white can be printed back to film, although as you say, it may not be able to be easily discerned... but having this information allows lattitude to grade and comp, hence the headroom built into the cineon spec.

So I would definitely say it is a bug, as a film transfer to dpx with the 90% grey at 685, would have a ton of info in the whites above this point useful for compositing and grading - if Redcine clips this info off at 685, than is it really following spec? Nothing is lost by including this information - those users intending on going to video can still clamp it and transfer down.

I know i would have been in strife if i'd delivered finished comps to a post house with all the detail in the whites missing...

though if in redcine, white really means "maximum value transferred into any other format" then i agree with you that dropping the iso to bring back headroom and using redlog, which uses all the available bits, does seem the best workaround...

a lot of testing to do on the pathway...

 

[Stu Maschwitz]

It clips Redcode values to 95-685, which if you go back to 1993 was Kodak's Cineon handywork for converting log images from 10bit to 8bit (for video). You accept that above 90% white will be lost, but that will become 255 in an 8bit range. Nothing exists under 95, its unexposed black.... lose it!

Not quite. Yes, the Kodak 1D log-to-vid conversion would map 685 to 255, but only if you used zero highlight rolloff. This was a very poor emulation of a film print indeed.

The current film print emulations use a nice soft shoulder that show a substantial amount of detail above 685. Compare this image:

http://rebelsguide.com/dl/logVideo_03_Rec709toLog2383.jpg

...to this image:

http://rebelsguide.com/dl/logVideo_03_Cineon2383.jpg

...to see an example of what I'm talking about.

It may be true that PDlog685 is not the best setting to use with RED One footage destined for film, but that's a separate issue from the clipping imposed when using the PDlog modes.

Even following Mike's wise advice to always view your histogram, you can still get bit like macka did. There's no obvious way to discern between values clipped by the chip and values clipped by the processing.

I would think that RED would bend over backwards to make sure people weren't artificially truncating their precious dynamic range, even by 0.4 stops. Its a fundamental misunderstanding of the Cineon log spec that the white point represents any sort of "cap."

Glad to hear (for the first time) that a fix is in the works Mike—I hope you're right, as the last reply I've seen from Graeme on this issue was not hopeful.

-Stu

 

[Miguel "Macgregor" De Olaso]

Not necessary, but it is there unless you drop the EV.

In other words, using PDlog685, your "headroom" values are not included, they must be "revealed" by reducing EV.
-Stu

I have to manually lower the ISO to recover that half stop for each shot in the timeline. This is stupid since it is a waste of time.
Why is this still happening in REDCINE? I don´t know.

 

[Chris Swinbanks]

late at night is not my best time for posting... :blink:

If there is a "bug" I think its that Redlog does not pull all the highlights into the useable range automagically, causing you to have to manipulate ISO/exposure to bring it down. I think we are all in agreeance there, but it doesn't take too much effort to work out the adjustment. Where that will be a PITA is trying to batch process shots for a standard transfer, rather than looking at each shot individually. Just how far do you re-rate your ISO/EV to ensure you get all highlight detail under varying lighting conditions?
But then film holds far more DR than a normal 4k/2k scan will capture, or a telecine transfer unless you alter the contrast range to capture max highlight detail as well as blacks... so I see this as no different than a telecine manipulation of film in that sense.

As for the pdlog curves, get a hold of the tables (from Scratch) and have a look under the hood.... if you're used to working with film and log files (Cineon/DPX) I believe you will stay away from them. There are no nice highlight rolloffs in the transition values from 16bit to 10bit.
PM me if you want them.

I've been playing with some dark night shots that have blown out shop windows in the background, a straight Redlog transfer will get most of the detail, with room to spare at the bottom end of the 10bit range, however to get the maximum amount of highlight detail I have to bring EV down to -1.52 (from -0.14 camera setting).
Black detail does not shift down the scale, but compresses. Ideally I'd like to see the whole range shift down the 10 bit scale to bring in highlights before any kind of compression (is this a gamma shift?) gets applied at the bottom end.
It seems that appropriate curves will have to be used to bring back the correct tonal scale at DI time.