What's the difference between RedLog and PDLOG

[Russ Lasson]

What's the difference between RedLog and PDLOG?

Thanks,

-Russ

[Graeme Nattress]

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

[Russ Lasson]

Thanks Graeme!

-Russ

[Russ Lasson]

What are the values for the white and black points for REDLog?

Thanks,

-Russ

[Graeme Nattress]

REDLog is full range, so it uses all available code values, 0-1023. Black is probably going to be around 140 ish on a 10bit DPX, white at 1023. Standardly, in DI mode in RedAlert you're also keeping what was happening below black to allow it to encode the full noise floor as-is.

Obviously, as soon as you start changing exposure and things that alter blacks, like contrast, brightness and so on, curves etc, you're altering those points.

Graeme

[Eran Gindin]

Is there a RedLog LUT available for use in your compositing app?


Eran

[Tom Tomlinson]

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


So can I only make 10 bit tiffs/10 bit dpx's from Red Alert? Or is it 16/10?

No 8 or 16 selectable?

I see redCine has 10 bit only dpx and 8/16 as options for tiff.

Thanks,
TomT

[Mike McCarthy]

I believe all DPXs are 10bit, it is the nature of the format. I think TIFFs are inherently 8bit or 16bit, where 10 bit source is padded with 6 zeros in a 16bit file, but I am not sure on that.

[John Tissavary]

I believe all DPXs are 10bit, it is the nature of the format. I think TIFFs are inherently 8bit or 16bit, where 10 bit source is padded with 6 zeros in a 16bit file, but I am not sure on that.

There's a 16bit spec for dpx, but it seems to be rarely used.

cheers,

jt

[Deanan]

In RedAlert, DPXs are 10bit and Tiffs are 16bit.

[Lucas Wilson]

There's a 16bit spec for dpx, but it seems to be rarely used.

Hey John... 16-bit DPX is mainly used for full-range linear scans from a SpiritII 4K. Pretty sure it's the Spirit. Might be a Northlight2.

Lucas (in Hong Kong)

[Marcus Struzina]

I'm planning on trying a low budget DI filmout test of my Red footage and have a question about how you communicate to the filmout house exactly what the black and white points are on REDLOG dpx files and if these are enough . I understand there are standards for PDLOG dpx files, is there some table of linear values to the REDLOG values available ?. Any help appreciated.

[Terry Wester]

Ok, I have wanted to ask for some clarification for a while, and this seems like a good thread to do it.:unsure:

If you want to output the full dynamic range of a clip out of RedAlert or RedCine as rec709 it has to be a 16bit tiff, or openEXR? Is this correct?

The way I understand it, if you want to to keep all the dynamic range in a 10bit DPX file sequence it will have to be output as log. Is this correct?

[Zach Hilton]

Ok, I have wanted to ask for some clarification for a while, and this seems like a good thread to do it.:unsure:

If you want to output the full dynamic range of a clip out of RedAlert or RedCine as rec709 it has to be a 16bit tiff, or openEXR? Is this correct?

The way I understand it, if you want to to keep all the dynamic range in a 10bit DPX file sequence it will have to be output as log. Is this correct?

:ohmy: bump

[Graeme Nattress]

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

Graeme

[Chris Swinbanks]

I'm planning on trying a low budget DI filmout test of my Red footage and have a question about how you communicate to the filmout house exactly what the black and white points are on REDLOG dpx files and if these are enough . I understand there are standards for PDLOG dpx files, is there some table of linear values to the REDLOG values available ?. Any help appreciated.Are you transferring the .r3d files to dpx yourself, or relying on the post house to do that?
Are you grading (color timing) the footage yourself, or relying on the post house?
Look at it this way... give a filmout house a 10bit log DPX file, and by rights they just shoot that to film as is, based on their existing setup with a film processing lab (if it isn't the same place).
You can read 10 bit log colour values in your preview window by setting the RGB tab to read 10bit RGB_LOG.
If you do this, then you are starting to work like a film scan, where 95 cv (in 0-1023) equates to "unexposed" black on film, and 90% white sits at 685 cv. Above that gets into peak whites.
18% grey sits at around 445cv.
A well balanced clip sitting at these values should give a good 1-light basic light print from a digital neg and allow the natural film curves to do their job of softening the transition out of the shadows and also into highlights. Try to keep the main part of the image between 95-685 cv.

edit: ... and if you're relying solely on Redcine to colourtime/grade your shots, you'll need to load at least something resembling a log viewing lut on your monitor to give you a chance of grading it correctly... ideally you'll take it to another app where you have a 3D lut to preview the shot on a fully calibrated system...

Chris

[Marcus Struzina]

You can read 10 bit log colour values in your preview window by setting the RGB tab to read 10bit RGB_LOG.
If you do this, then you are starting to working like a film scan, where 95 cv (in 0-1023) equates to "unexposed" black on film, and 90% white sits at 685 cv. Above that gets into peak whites.
18% grey sits at around 445cv.
Chris

Thanks Chris for the useful info, I'm wondering if the REDLOG or PDlog DPX outputs can also be sent for filmouts , or does the lab have to convert them to PDlog 685. If they do what is the process or settings for the conversion of PDlog985 or REDLOG dpx files back to PDlog 685? Do they need to know additional gamma settings? My plan is to do a preliminary rough grade in REDCINE, and then reassemble and Grade the DPX's in Apples Color . The motivation for my question is that by using REDLOG instead of PDlog685 I will hopefully preserve more tonal and colour precision allowing more extreme grading.

Marcus

[Deanan]

RedLog would need to be converted into PDlog for filmout. Some facilities have been converting to linear from redlog and then to their own pdlog formula tuned for their recorders.

PDlog685 is pretty much the cineon spec for log to linear conversion in reverse (linear to log).
It's not exactly what you'd get in a film scan (regarding peak whites going well above 985) but it lets one reverse the log conversion using standard log2lin tools that are in programs like shake.

[Chris Swinbanks]

Deanan, any conversion graphs or specs you can publish for the different "logs"?
Please correct me if I'm off the ball here... its getting late...
The way I've been reading them, Redlog takes full dynamic range and puts it into 10bit log.. so thats somewhere between 9-11 stops (depending on whose posts you read) packed into 0-1023cv, therefore there's likely some highlight & bottom end compression? (guessing).
In Cineon spec 10 bit log from a scan is really only 2.046 density, so about 7 stops.
PDlog685 packs xxx info into what???... if I'm reading this correctly (and from some limited testing... must do more) its really only packing useful information into 95-685cv range, which is clipping highlights and hard clipping black at 95cv. Not what I'd choose for a filmout.
PDlog985 (? dont have Redcine in front of me) is likely to be similar, clipping 95-985(or whatever the number is..), however are you saying this has a PD matrix applied as part of the conversion?

Would love to see a table of numbers that explains it more precisely... maybe I've missed it somewhere if its already been discussed.

.... now I think about it, maybe I did see some conversion tables somewhere amongst the redcine files... will look again tomorrow.

regards
Chris

[Patrick Tresch]

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

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

Graeme

Who can handle REDLOG? What do you need to handle that?

Those with Scratch systems will surely use the original R3D, so who would be able to use this format? Is there a Lut that can be imported to any grading suite (wich supports lut)?

Thanks.

Pat

[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]

---
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]

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.

[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.
-StuOK, 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.

mackaummm, 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]

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