dpx->mp4 OR dpx->mov->mp4

[Peter Taps]

Folks,

 

I have to set up a process of converting dpx static images to H.264 movie file. During the process, I also need to apply a LUT for proper color conversion.

 

DPX images are in RGB format and H.264 is in YUV format. I am being told by some people working at a digital processing lab that, in their experience, converting dpx to H.264 never gives them good color output. Instead, they convert dpx images to .mov file first. In the next step, they convert .mov file to .mp4 file. This seems to give a better color output.

 

What I didn't get is a good technical explanation on why this works better.

 

I am wondering if there is any merit to this approach.

 

We don't mind going though this additional step, if required. However, I am hoping I can find a better solution that helps reduce our overall processing time.

 

Regards,

Peter

[Jeremy Ables]

Peter,

 

From what I have looked up and my understanding your H.264-is an RGB format, my only experience however, is my DSLR that uses H.264 compression and outputs .mov files in an Adobe RGB color space. What may work better for this lab may be that they need to go into a .mov file first in order to get to a color grading/correcting software where they can take your image into suitable file format for color correction. Also H.264 is horrible typically for this type of work it is highly compressed and the correction/grade either does not stay with the image well or at all. Even if you have RGB files and they put them into a .mov file format, which is still RGB, when they go into the color correcting software (apple color) you do go to (my understanding-please someone correct me if I am wrong) a larger color gamut for them to work with and although they may have to fix things when they bring it back to the .mov file it usually a send a clip back to the software make tweaks and re-render. Once they are done They can send it out as an .mp4 which is still an H.264 compression if I have read my latest export windows correctly and it will change the colors some with the compression but not nearly as much if you tried to color correct with H.264. I hope I have explained it in a way that makes since if not helpful but I think that the lab was looking out for your best interest, and trying to get you the best result possible. If someone else can either give a better explanation or a better solution I look forward to finding out what it is.

 

Jeremy A.

[Phil Rhodes]

Hi,

 

We should be clearer on terminology here.

 

A ".mov file" is a container. A quicktime movie can hold many codecs, including various types of MPEG-4.

 

MPEG-4, by which they almost certainly mean h.264, a subset of MPEG-4, actually is a codec. MP4 files are very similar in format to Quicktime .mov files in any case.

 

It should not in theory be necessary to do any intermediate processing steps between a DPX sequence and an MP4 file. In practice, a lot of software does not handle luminance range conversion very well and the lab people you were talking to may have found an obscure workaround for this that relies on various quirks in whatever software they're using; however, what they're describing is a nonsensical from a theoretical point of view and I would want to know more about why they think it helps.

 

No matter what, doing an RGB to YUV conversion (or vice versa) will cause some slight modification of colour because RGB and YUV do not describe the same colour space; there are some colours which can be represented in one but not the other. This will cause some excessively saturated colours to be clipped, although from a casual viewing perspective this is not usually terribly objectionable (and is unavoidable in your situation).

 

You could convert DPX sequences directly to h.264 with the free software tool ffmpeg, using a commandline something like this (off the top of my head, and untested:)

 

ffmpeg -f image2 -r 24 -i "Movie_Frame_%04d.dpx" -crf 24 -vcodec libx264 Movie.mp4

There may be other things you'd want to specify; particularly, this assumes that the input frames are also 1920x1080 (or they will be scaled, not cropped, to fit). You could make it crop the input if you needed to. You can make it multiplex in a soundtrack at the same time. Note you have to give it framerate as it won't read the rate headers from the DPX; for fractional rates, this should be expressed as a numerator and denominator (24000/1001 etc). The %04d works like a printf statement; modify to suit the number of frame count digits in your DPX files. Confusingly, the "constant rate factor" (crf) option tends to increase bitrate as the number decreases; you can also simply specify "-b 5000k" or similar, instead, but CRF gives it more options to create constant quality rather than constant bitrate, if you can stand the variability. There is apparently a way to use -crf with a defined maximum bitrate, but I'd have to look that up.

If your input frames are not at the desired output resolution, use -s 1920x1080 to scale and various options around filters and use "-vf crop=width:height:x:y" if you need to do that (some experimentation may be required). Don't encode black bars for scope material, for instance.

You could also have it mux in a soundtrack by using an extra -i (input file) and possibly the -map option to define what goes where.

Like most free software, ffmpeg changes almost daily and things may change, but this should get you going.

P

[Jeremy Ables]

Phil,

 

I appreciate you clearing up the terminology you use so much and read so many different articles everything becomes jumbled together. I am glad you were able to come up with another solution for Peter hopefully he is armed with some technical info the next time he talks to the processing lab!

[Oliver Hadlow Martin]

If command lines scare you, you can always download Davinci Resolve lite from blackmagic (it's free) and use their render tool from there to create your h.264 from your DPX sequence. Or use adobe after effects if you have it, or any other program that lets you encode for that matter.

[Peter Taps]

Thank you all for your help.

 

Regards,

Peter

[Peter Taps]

Phil,

 

I appreciate your help.

 

I like ffmpeg/avconv as it runs on Linux. One problem I found was that ffmpeg does not take a 3D LUT file as a parameter. I am wondering if you know any workaround for this.

 

I also looked at another tool called AviSynth. It has the capability to take a 3D LUT file via a plugin. However, the plugin works only on Windows.

 

Regards,

Peter

[Chris Burke]

for mac and a quick gui interface, I use Graphics Converter. It will convert dpx to any quicktime wrapped file format. It can to an auto level or gamma correction perhaps even a LUT can be applied. It is a basic straight forward program that does the job.