What's the difference between RedLog and PDLOG

[Stu Maschwitz]

...But then film holds far more DR than a normal 4k/2k scan will capture...

Not true.

-Stu

 

[Mathew Mackereth]

but CWS, i don't actually want all the values mapped linearly - i want them to match a film response. so i'd prefer them to compress, because this is what film does - and so i'm used to it and facilities are geared for it, and well that's how film works. -

... i guess the issue for me is exactly as you say, calibration for an entire film. if i'm adjusting in redcine to map all the values from 1-1024 then i'll need to at some point convert this into a colourspace that can be put to film. if each clip has been adjusted or stopped down differently to squeeze maximum range into the Redlog - then this will be difficult.

using redlog and mapping the highest white point on the neg to 1024, and then mapping this to maximum white in 8-bit space will skew all the colour values lower(depending of course on the exact log curve), or require a different curve to compress the blacks and whites back to something we'd expect to work with. it also doesn't behave like film when planning for a film out.

which is why i'm a sad panda. I just can't see why redcine has to clip it.

macka

 

[Chris Swinbanks]

Not true.
-Stu

OK, will have to do some further checking on technical data of latest film stocks. I haven't had a scanner for a couple of years now, but I was under the impression that the newer stocks were recording above the 2.046 density range that a scanner (in 10bit log) will handle... I could well be incorrect on that!

but CWS, i don't actually want all the values mapped linearly - i want them to match a film response. so i'd prefer them to compress, because this is what film does - and so i'm used to it and facilities are geared for it, and well that's how film works. -

I think many of us are used to working with log files from film (15 years for me now), but not from Redcode. My point is that when pulling down the ISO/EV to save highlights & get the data to a DI suite for the creative grade, it appears that the way Redcine works now there is still room at the lower end of the 10bit log scale to avoid compressing the black information while allowing you to get highlights in, which is the point of working in a log space in the first place. Log not only compresses the data into a smaller file, it gives more bandwith to the blacks/shadows to avoid banding issues. Thats no different to setting a film scan to set unexposed black at 0cv rather than 95 cv to give you more headroom for highlights (I've had to do this in the past to recover processing faults)

... i guess the issue for me is exactly as you say, calibration for an entire film. if i'm adjusting in redcine to map all the values from 1-1024 then i'll need to at some point convert this into a colourspace that can be put to film. if each clip has been adjusted or stopped down differently to squeeze maximum range into the Redlog - then this will be difficult.

I see that as likely to be a necessary part of part of the interactive grade, and the log dpx files (0-1023) ARE the colourspace that will go to film. With Redcine/Redlog (and I presume Redline for batch processing) in its present configuration if you are willing to setup a 1-light style transfer for all footage then you'll accept that there is likely to be be some compromise for some shots, ie, highlight clipping and/or compressed blacks.

using redlog and mapping the highest white point on the neg to 1024, and then mapping this to maximum white in 8-bit space will skew all the colour values lower(depending of course on the exact log curve), or require a different curve to compress the blacks and whites back to something we'd expect to work with. it also doesn't behave like film when planning for a film out.

which is why i'm a sad panda. I just can't see why redcine has to clip it.

macka

ummm, why would you want to map it to 8-bit? Unless you're using an app that doesn't handle 4:4:4 10 bit for colour work? Is that why you want to work with pdlog685?

 

[Dj Joofa]

OK, will have to do some further checking on technical data of latest film stocks. I haven't had a scanner for a couple of years now, but I was under the impression that the newer stocks were recording above the 2.046 density range that a scanner (in 10bit log) will handle... I could well be incorrect on that!

One way a film scanner is able to read density over 2.046, while still keeping at 10 bits, is by increasing the density step size from 1/500 to, say 1/465 -- in which case it will be able to read till density 2.2.

 

[Mathew Mackereth]

sorry CWS- the 8-bit was just an example to look at how the log values would map to any linear display system - picking up on your video conversion point from earlier in the thread - please interpret those comments to relate to converting from log space to linear data for compositing or display - regardless of display bit depth. Making the point more to illustrate that a properly implemented pdlog would work on a variety of systems in the way that current filmscans do, with recognised workflows to switch between formats - making the transition easier for everybody... I'm specifically thinking about compositors working across multiple facilities who all have had experience with cineon/dpx scans for film.

so i guess i'd still like to use PDlog it if it worked to give us a broad dynamic range... and sincerely hope they modify redcines interface/export.

...until then i must agree it seems that dropping the values to fit within the clamped range and using redlog is a far better option than losing the highlight detail... and i'm sure i can set up a system that doesn't make me a completely sad panda...

..don't know how pandas got involved...

macka

 

[Chris Swinbanks]

Sad pandas might have to go to open-exr, then dpx for filmout.
Of course, we are promised that very soon this all becomes irrelevant when all our DI platforms can handle .r3d natively....... we are waiting for our camera, we are waiting for our Birger mount, we can wait for native .r3d handling.... but only for so long....
In the meantime I have a RED feature to worry about....

 

[Chris Swinbanks]

One way a film scanner is able to read density over 2.046, while still keeping at 10 bits, is by increasing the density step size from 1/500 to, say 1/465 -- in which case it will be able to read till density 2.2.

Do you know if any of them have adjustable step sizes, and if so how do you then relate that back to 10 bit log? That would require it to recognise a (film) gamma shift, would it not?
Do SMPTE specs define a DR for DPX? AFAIK, Cineon as a system is locked to the formula of 1 cv = 0.002 density, that way you can send any file to any facility and get an expected outcome on film or via calibrated viewing system. Add a variation that can't otherwise be accounted for, and it will screw what is basically a well functioning system.

 

[Dj Joofa]

Do you know if any of them have adjustable step sizes, and if so how do you then relate that back to 10 bit log? That would require it to recognise a (film) gamma shift, would it not?
Do SMPTE specs define a DR for DPX? AFAIK, Cineon as a system is locked to the formula of 1 cv = 0.002 density, that way you can send any file to any facility and get an expected outcome on film or via calibrated viewing system. Add a variation that can't otherwise be accounted for, and it will screw what is basically a well functioning system.

According to Arri digital intermediate manual it is possible to vary density steps, so at least Arri must make a scanner that lets that happen. I have to check on the header/etc. of a DPX file format if corresponding information is stored somewhere. Meanwhile, here is a quote from the Arri's manual.

"Cineon and DPX files have been used for more than 10 years in VFX and in DI productions. Nevertheless, there is ongoing discussion whether the dynamic range and quantization of the 10 bit format is sufficient.

Since the average base density is mapped to the code value 95, there remains a range of 928 code values for the density above base, which equals 1.86 log D. The characteristic curve of camera negatives has a roll-off, or “shoulder”, the density does not increase linearly beyond an exposure of 9 stops (1.6 log D). A scene with very bright highlights, however, can result in a negative having densities above 1.86. Those highlights will be lost in a standard DPX scan; the effect is called clipping and is demonstrated in Figure A.1.

Film scanners like the ARRISCAN can capture density information above 2.046 log D but the standard 10 bit encoding will not include this data. One could extend the dynamic range by reducing the quantization steps."

 

[Jamie Metzger]

Thank you Graeme,

Good explanation.

REDLog is a RED designed log cruve that puts the data in a form of maximum precision and dynamic range for 10bit.

PDLog is a log curve desined to take RED Data to print density for grading or output to film. It does, however, have less precision than REDlog, as PD was designed for film, not digital.

Some places can handle REDLog just fine. For those that can't PDlog might be more to their needs / wants.

Graeme

 

[Rocco Schult]

Does anybody have a clue if RED acted in response to this -very important- thread ?
E.g. through a revision in the programming for the conversion ?

Happy New Year.

 

[Deanan]

Does anybody have a clue if RED acted in response to this -very important- thread ?
E.g. through a revision in the programming for the conversion ?

Happy New Year.

REDlog is a full range log tuned for optimal distribution of values.
PDlog 685 uses the cineon linear to log function with white point at 685
PDlog 985 is the same with a white point at 985.

 

[Rocco Schult]

Hi Deanan,

Happy New Year btw!

Thanks for your reply, but that doesn't really answer my question. PDLog has clipped calues above 685 which is not exactly necessary and implied by the format.
As the most used format (for filmstyle workflow), it would be welcome to have it optimized. Following the thread one could assume RED might modified that specific feature to preserve the detail while exporting - as the format allows it.
The correction values must now be altered all time and handled manually to have 'everything' in the file.

 

[Nick Shaw]

Have a look at the Autodesk white paper (http://images.autodesk.com/adsk/files/red_autodesk_whitepaper.pdf) for their suggestion of how to use PDLog985 output to create what is effectively PDLog685 including super-whites.

 

[Rocco Schult]

Thanks Nick, I was looking into it. But having used and tested both formats after export on Lustre my impression is it doesn't make any noticeable difference. But time was short to verify against possible reserves in the raw original.
What I just want is a format that preserves everything. And PDlog 685 seemed so welcome as the facility was used to it as standard and has aligned its setup (and user behaviour) to it. Unfortunately the facility is not beta tester for Autodesk and so we have to wait for further impressions of how the import node might work in the future.

P.S: Having looked at it again, it seems the exposure correction of -2 is a general assumption to preserve high whites. That should be included in the conversion table from RED to avoid clipping. That btw is the table to be officially available instead to rip it out of some Scratch installation and having it outdated once RED might do something about it.

 

[Chris Swinbanks]

Hi guys, interesting to see this thread lift its head again, because I think we've all learned a lot in the ensuing period.

I originally expected that the pdlog685 "clipped" highlights, where it doesn't.
It just re-maps all the exposure values to a lower level than the other luts, via its 16bit transfer mapping. ie, peak white (1.0) maps to 685 cv in 10 bit log land. Those with a digital-film b/g will know this represents only a standard 90% white on a film scan.
Whereas in pdlog985 and Redlog, peak white (1.0) maps to a much higher value, around 1000 - 1020 cv. (don't have the charts in front of me, still on hols).
I've got all the currently available transfer LUTS on an XL sheet, PM me if you want a copy, as I think its fair game that this info is out in the realm for those of us that need to use this in post.

Before Xmas I started testing the Autodesk method (pdlog985 -2.0 exp) on some test charts I'd had shot on a couple of film stocks and the Red One.
I think it is a very valid method for preparing footage for film grading and output, as its a pretty reasonable match as a starting point.
I don't think its the best method for all options (ie, vfx work), but for most general footage it will be a valid (starting point) for a film pipeline.

cheers
Chris

 

[Deanan]

Thanks for your reply, but that doesn't really answer my question. PDLog has clipped calues above 685 which is not exactly necessary and implied by the format.

PDLog 685 does not clip values above 685. The cineon lin2log spec has a very shallow slope above 685 which does not lend itself well to converting linear footage to print density. It works well film but not for linear images. We included it as an option becuase a number of people requested it but we discourage people from using it. PDlog 985 is a bit better but it's not an ideal curve for our sensor like REDlog is.

If you are seeing clipping with PDlog 685 it's not the output lut itself that's clipping but because a prior stage in the processing is being pushed into clipping. Since some parts of the processing are done in float and some in 16bit (not everything can be done in float without serious disadvantages), you can push things to clip with some settings before hitting the output lut.

 

[OneLung]

TVC Colorspace - Redlog, PDlog685, PDlog985, other?

TVC Colorspace - Redlog, PDlog685, PDlog985, other?

There's been a lot of discussion in this forum about film pipeline, but I'm curious about what everyone suggests for TVC workflow. I'll give you our brief workflow so far and then maybe someone can fill us in on our missing colorspace knowledge. And let me just say that I've been researching this for days and still haven't found a bona fide answer. Currently we edit with proxies rendered out of Red Rushes (nice to have small timecode burn-ins as a backup), in either Final Cut or Avid, generate an edl to send to Monkey Extract, and render DPX sequences out of Monkey Extract for DI.

The big question mark becomes what color space should we render out the DPX sequences in to go to DI and have the best possible range, with the best video delivery. Our DI facility requests Log color space. From what I've gathered Redlog is the optimized log space for Red footage but if the color correction system doesn't support Redlog what should we do? Is there a LUT that they can load for Redlog or should we go with PDlog685, or PDlog985?

Equally what should we render out from Monkey Extract if we are going to skip DI and go straight to a Avid Nitris or Flame? I feel like there is a lot of other people equally confused out there and until .R3D is native in all applications there will continue to be missing pieces in the Red workflow. Autodesk has putting together a pretty informative documentation together, I wish Red would do the same with specifics to their LUTs and colorspaces. I'm just getting tired of reading "color in Apple Color or Scratch" because for color we are following the talent, not the most compatible Red software package, and that often means Red isn't native on their platforms.

The Autodesk White Paper suggests:

Video Deliverable
If your primary deliverable is video, then set Gamma to Rec709 and Color Space to REDspace™. Setting the Color Space to REDspace™ rather than Rec709 seems counter-intuitive; however in our tests, setting it to Rec709 gave results that were far too saturated. If the scenes were lit for ISO 320, you would find that converted images look dark. This does not necessarily mean that the images were underexposed. It does mean that you have to begin your grading session with an overall gamma boost. Use the Brightness parameter to brighten everything during the conversion process. A value of about 2.5 in Crimson is a good starting point. (The Brightness control in REDCINE™ is 10x more sensitive, so use a value of about 25.)

Another important point about the Rec709 Gamma setting is that the converted images contain all the highlight information that was captured by the camera. One might assume that using one of the log Gamma settings would export images with more highlight information, but this does not seem to be the case.

Film Deliverable
If your primary deliverable is film, we assume you will be using a print film simulation 3D-look up table (LUT) (such as from Autodesk® Lustre® Color Management) for grading. The goal is to convert your images into something resembling a Cineon®-style scan from color negative film. Because the characteristics of the RED ONE™ are so different from film negative, and because of the limited color processing flexibility of Crimson, this is not entirely possible.

To get the tone scale approximately correct, set Gamma to PDLog985. This results in images that have the correct contrast but look about two stops over exposed. Unless a shot is very underexposed, set the Exposure parameter to 2.0. This puts a normally exposed gray at a 10-bit value of about 470 (as per convention).

Set the Color Space parameter to either CameraRGB or REDspace™. Colors will seem washed out compared to film capture. To correct this, try using the Saturation parameter to boost saturation. A fair amount is needed, but going above 0.2 can start to cause clipping artifacts in saturated colors. Crimson can display the individual RGB channels. This is a good way of detecting if too much saturation boost has clamped detail in certain colors. (The Saturation control in REDline™, REDALERT!, and Crimson is zero-based rather than one-based. For REDCINE™, use 1.2.)