How to export to DPX (or Cineon)

[memo]

Hi all, I am doing a short 2K sequence which is going to be printed to film, and the post house needs my output in a sequence of DPX.

My source graphics are all standard 8-bit linear RGB, so my workflow in shake is all 8-bit linear till the end. At the end of my tree I have a fileOut which I’ve setup to export as DPX, but do I have to add a LogLin node before the fileout node?

I have read the manual regarding the LogLin node (As well as various articles about cineon, log colorspaces etc.), and understand how it is needed when mixing Cineon files with linear RGB files, or when sending a Cineon file to a node which only supports 8-bit images etc – but I am not 100% sure if I need it before my fileOut/DPX, or does the fileOut/DPX take care of that?

When I apply the LogLin just before my fileOut all of the blacks become quite lighter, do I need to adjust this with the sliders there (I found that by decreasing the rBlack I can bring it back to black) – but maybe its normal that it appears like that (less contrast), but it will look OK on film?

Also what about converting the 8-bit final image to 10-bit? Is that taken care of in the fileOut/DPX node? or do I have to add a bitconversion node as well? (I couldnt find one)

In short, what should I Do!?

cheers

[bnw]

The FileOut will not do any LogLin conversion, nor will it Bytes up to 10 bit. You’re safe doing the Bytes part, and you should since people are likely expecting 10bit rather than 8bit DPXs (Shake writes 16bit images to DPXs as 10bit, but 8bit images as 8bit).

The log part is harder. I would give the film out facility a call and ask them, or go round and have a chat if you can. Even if you convert your stuff to log, it will print on film different to how you see it on your monitor… they might be set up to handle this if you ask them to, or you might have to get it graded through a film LUT before you print, or you might have to print, view, grade it yourself, print, view again… welcome to the wonderful world of film 🙂

You can get some idea of what it might look like using Truelight in Shake – there’s a whole seperate manual, for that…

[Gregory Hill]

Hi, thanks for that.

So I will do a Bytes (to upsize to 16bit) and then LogLin, and then FileOut (does the order of the Bytes->LogLin, LogLin->Bytes make any difference to quality?).

I am not expected to do a final grade, so I guess I can skip the whole ‘using specific film LUT and adjusting’ etc, but I was just concerned that when I apply the LogLin to convert Linear->Log, my blacks were quite pulled up to greys, and my contrast was really decreased. So I was wondering whether I should fix this using the rBlack slider. Like I said I dont want to do a final grade, but I just want them to see something roughly correct and not totally wacked out. But now I think I understand this whole thing a bit more… from what I gather, after the lin->log conversion its normal that my blacks are quite grey and everything is low contrast; I should NOT fix that with the rBlack slider (unless I have a LUT – but that enters the realm of grading which I am not doing). Once they receive the log files and apply a log->lin conversion it will be back to how I originally did it!

[Gregory Hill]

Actually, another question I have is, is there such a thing as ‘film safe’ colors as there is NTSC or PAL safe? e.g. If I want something to be pure white should (or can) I use 100% RGB? or around 92% like TV Safe? and same goes for black, should I use 0% RGB or 6% like TV safe?

[bnw]

Good questions!

Bytes before LogLin, always – LogLin is quite a drastic colour correction, essentially, and really you want to be in a high bit depth to do it.

Do not adjust the LogLin at all, ever, unless you really know what you’re doing – the default settings are a standard that the post house will be expecting. It’s completely normal for the image to look really low contrast in log.

Film can hold such a range of colours that whites/blacks being clipped will not be a problem if you’re coming from video – but you may find that when you see it on film it’s higher contrast than you’re expecting, because print film crushes the blacks and whites a bit. In a much nicer way than video legalizers, though – that’s a grading thing really, not a delivery spec thing. Colours are more of a problem… there aren’t really illegal colours that will explode a projector or anything, but things may look different. Truelight in Shake has a gamut warning for this but we’re leaving the realm of things I have experience with here 🙂

Good luck!

[Gregory Hill]

OK thats brilliant, many thanks…

[Barbara Mills]

It’s probably too late but let me notice that LinLog conversion is not required nor recommended during export_to_film process. You actually should give them linear images. Film printing is performed in linear space. Both lin2log and log2lin conversions introduces data loss and should be avoided whenever possible.

cheers,
sy.

[mark spevick]

HUH? uh that is why you always convert in FLOAT and use a round trip set up. Please let me know what company recommends delivering linear files for filmout. Only when the source was originally linear has anyone recommend one deliver linear material because they will convert it to log using there conversions. Which are custom made by them for there lasers. I will double check with my contacts at Pactitle and eFilm but no one has ever said, “Hey you know what would be really great? Deliver use Linear files.”

R.

@SYmek 23934 wrote:

It’s probably too late but let me notice that LinLog conversion is not required nor recommended during export_to_film process. You actually should give them linear images. Film printing is performed in linear space. Both lin2log and log2lin conversions introduces data loss and should be avoided whenever possible.

cheers,
sy.

[Barbara Mills]

I’ll love to know yours/theirs complete opinion on this subject. As to my knowledge there are two issues here: one is LUT used by facility (both scaners and printers) which allows to pack more color space in 16 bit images by exaggerating the importance of some areas (what is performed by LUT color correction). The second issue here is a log color space introduced by DPX which is simply pseudo data compression process and as we know implies data loss (even in FLOAT!). LUT used by facilities should be provided to post-production house as it makes possible to touch any file. Lin2log conversion will allow you save 12bit files – nothing more. Log has nothing to do with printers – why printers would have to be aware of logarithmic images? They expect that input colors are non-linear mapped to increase color spaced saved in files. This non-linear mapping (as defined in proper LUT) is not the same thing as logarithmic color space in cineon or DPX files.

cheers,
sy.

[mark spevick]

uh why doesn’t compression imply loss? Data compression doesn’t require loss of data. If there was no good reason for log. Other then thats how film works. Kodak sure wasted a lot of money when they could have just made linear files. The log response of film is better met buy feeding the laser a log file. You CAN control your shadow much better when you know what you are doing with a log file. I am pretty sure I understand this. I help implement icc at Apple and Macromedia. If you want to have any control over the toe and shoulder of the film THAT ISN”T EVERY going to happen in linear space, or gamma encode video space. Film has reciporcity it doesnt maintain a 1:1 response over the whole exposure range. Shadows build slow and have compressed tonal ranges. The highlights strech out as the silver just can’t hold anymore photons and literly start dumping electrons to neighboring silver halide partilces. I can memic this response in log space. I CAN NOT in linear or gamma encoded video.

[mark spevick]

uh why does compression imply loss? Data compression doesn’t require loss of data. If there was no good reason for log. Other then thats how film works. Kodak sure wasted a lot of money when they could have just made linear files. The log response of film is better met buy feeding the laser a log file. You CAN control your shadow much better when you know what you are doing with a log file. I am pretty sure I understand this. I help implement icc at Apple and Macromedia. If you want to have any control over the toe and shoulder of the film THAT ISN”T EVER going to happen in linear space, or gamma encode video space. Film has reciprocity it doesn’t maintain a 1:1 response over the whole exposure range. Shadows build slow and have compressed tonal ranges. The highlights stretch out as the silver just can’t hold anymore photons and literly start dumping electrons to neighboring silver halide partilces. I can memic this response in log space. I CAN NOT in linear or gamma encoded video.

[mark spevick]

Just so it a little more clear to everyone
http://www.deathfall.com/article.php?sid=5158
That is a simplified explination that I think everyone can understand.

[mark spevick]

Just so it a little more clear to everyone
http://www.deathfall.com/article.php?sid=5158
That is a simplified explination that I think everyone can understand.

[bnw]

I’m really not sure about some things in that article… at the risk of starting yet another interminable discussion… 🙂

Quote:

But don’t assume that the 16.7 million colors are a sampling of the entire spectrum of color; you could choose to have 16 million shades of red, and the remainder in shades of blue. This wouldn’t buy you a very nice photorealistic image, but if you were really keen on red and blue, you would have some gorgeous tones.

Nothing technically incorrect there, but I’m not sure what the point is… you could have a colour space using primaries all around the blue and red areas but what would be the point? Maybe you could avoid some banding in really subtle gradients, but using more bits all round is the normal solution to that, not using a crazy colourspace. Something red, something blue and something green really are the obvious primaries for an additive tristimulus system.

Quote:

In a logarithmic color space, the same bits can be used to emphasize details in the white and black areas of an image.

Not really. Log curves emphasise the lower values at the expense of the higher ones. That graph is very strange, what’s the vertical axis showing? Why isn’t the line for linear straight? Is that gamma-encoding linear or photometrically linear?

Quote:

which is highly responsive in areas of extreme dark and light.

The reason film has smoother highlights is that it’s not very responsive up at the top end. You need a lot of light to saturate the emulsion to completely opaque. Progressively more and more as you go higher… the old darts bursting balloons as opposed to landing in buckets analogy 🙂

[Barbara Mills]

Still disagree here, sorry. I still see misunderstanding here. Kodak designed cineon for compression reason not because of film curve response. If you can represent 16bit pallete of information in 10bit this a serious reason to spend money for development specially 15 years ago. In my opinion you mix up two issues here: 10bit log compression and color mapping curves. Yes, of course, colors in different media shouldn’t be linearly converted and they are not (just take gamma for an example). That’s why responsiveness of different media is taken into account. This has nothing to do with a logarithmic cineon representation which is static! It’s equal whatever film stock you use! Some facilities change it to accumulate in one color correction both LUT (your correction in respect to media) and standard LOG (cineon data compression). But still these are two issues. And printers work in linear (although still mapped accordingly to scanner that sourced these images) . They convert 10bits to 16bits and finish with a pure data without cineon remapping. That why you don’t have to convert to log for printing. They will have to convert it to lin (unroll cineon compression) although still leaving color remapping which is your concern.

[Author]

Posts