Brylka – TooDee – PanicPost

FFMpeg/Nuke & OSX

Image sequence to ProRes 422HQ Version 11

In my working environment we use FCPX not so much as a pure editing or finishing tool,
but more as a „work in progress“ tool. Although lately we used FCPX also to finish projects
completely. So I added also Nuke as an alternative “conversion” engine next to FFMpeg.

Normally Nuke is used for doing the compositing work, first steps are usually rendered as 100% JPG image sequences, just before finishing as 10-Bit DPX image sequences. The output from 3D is EXR. These image sequences are loaded into flame/smoke/resolve for further comp,online, grading & finishing.

Before occupying the “expensive” machines, it is very handy to use FCPX to keep the edit up to date.
Sure “Hiero or Nuke Studio” can do this far better in an all Nuke environment, but not as cheap as FCPX is.

FCPX expects quicktime and other movie files but not image sequences directly. Sure Motion or Compressor can be used to convert some image sequences to a quicktime file, but I was looking for an easier way… I looked in the Apple AppStore and googled around but I couldn‘t find a ready to use tool.

After a while I saw that FFMpeg can help here, but I didn’t want to use the Terminal.

So thanks to Google, I was able to write my first AppleScript, I googled around and found different snippets of code that I could use and slowly understood how to write this little App.

Here is „TD_ImgSeq-to-ProRes_FF_v11“.

Changes in version 11.0:

  • Tested with FFMpeg 3.0.1 on OS X 10.11.4

Changes in version 9.0:

  • Tested with FFMpeg 2.7.2 on OS X 10.10.5
  • You have Nuke installed on the machine orfor testing purposes use the Non-Commercial version? You can change the variable “RenderWithFFMpeg” and use Nuke over Python to render a ProRes444 instead of a ProRes422HQ with FFMpeg! Now for sure there are no color shifts whatsoever! The ProRes444 is set to sRGB colorspace, the read node is also set to sRGB to avoid Nuke reading out header information about the color space.
  • Note, for project delivery or final playout I prefer Nuke over FFMpeg! (read here: https://support.apple.com/en-us/HT200321)
  • The script expects Nuke V9.07 installed on the machine – the version can be changed in the script.
  • Another new feature that I added: After the files are converted to ProRes422HQ/ProRes444: An Automator script is called and adds/tags the “HD 1-1-1” profile to the file.
  • During the conversion a window is displayed that the script is working. I would like to have a real progress bar, but as FFMpeg or Nuke is handling the conversion there is no feedback from the tools while the conversion is in progress.
  • The first time you start the script a folder called “TD_ImgSeq” is created on your Desktop. All converted files are there. When you re-compress an images sequence that already has a ProRes created before, the old ProRes gets deleted.
  • Hint: Change file program file name to TD_ImgSeq-to-ProRes_NK_v08 or TD_ImgSeq-to-ProRes_NKNC_v08 when using Nuke to do the conversion and you need both or all three apps.

Changes in version 4.0: (still important)

  • Change of “color pix_fmt” to yuv422p10.
  • Set the colorspace conversion to “fcc:bt709” – I don’t know why, but now there is NO visible colorshift anymore!
  • EXR files getting a 3D-Lut applied to sRGB, they still have a color shift to the original files.

It does:

  • Let you choose a folder that contains one image sequence that you want to convert to a ProRes 422HQ quicktime file. This resulting file is written to the desktop of the current user and gets the name of the image sequence.
    The idea is, that these quicktime are copied into the FCP-Project-Library anyway so why put them fist in your job folder structure.
  • If this file is already existing on the Desktop and you run the script again, the existing file will be deleted first.
  • I tested it with EXR, JPG, TIF and DPX file sequences – it should work with all Image-Formats that FFMpeg supports.
  • Note that EXR image sequences get a 3D-LUT applied but there is a color shift happening, I don’t know why.
  • DPX files are expected to be in sRGB otherwise there might be a change in color values.

It expects:

  • A folder name and file name structure like this: „JOBname_ShotName_v001/JOBname_Shotname_v001.0001.exr
  • or also more simple like:
  • „ShotName/ShotName.0100.exr“
  • An example from a recent job:
  • Job_Sh010B_Render_Beauty_Pack_v005/Job_Sh010B_Render_Beauty_Pack_v005.0557.exr (… to …v005.0670.exr)
  • The number of digits in the frame numbers don’t have to be four like in the examples.
    The first frame number is also not important.

Limitations:

  • Only the first file in the folder gets analyzed. Therefore there can by only one image sequence in the folder. The tool is meant to be simple and with few user clicks at the moment.
  • In the script there is a variable called “multi” – there you can decide if the first file in a folder is used (Default) to convert or you get a file selector to choose a file if more than one sequence of images files are in one folder. Note, it fails when there are two sequences with the same extension in one folder. I am not a programmer, this get complicated for me 🙂

The “bigger” picture – on color consistency in OS/X 10.10.x and QuicktimeX/AV Foundation:

  • I created my own test color chart (Color_Bars_v04) and the Digital Color Meter from OS X to measure color shifts when converting image sequences to ProRes files and viewing them in Quicktime Player X, FCPX, Motion, Compressor, Nuke, VLC, Autodesk Flame and DaVinci Resolve.
  • If you use Motion to convert image sequences to a ProRes 4444, the file will be ColorSync managed by Apple/OS X. Means it works fine with FCPX and Compressor.
  • The are visual differences displaying a file in Quicktime Player X and FCPX. It has to do a lot with Tags/Metadata which often is missing in the ProRes files.
  • FFMpeg is not officially supported by Apple. I managed to get good results with ProRes 422HQ but not with ProRes444. After a lot of google/forum readings it seems that the FFMpeg engine does a colorspace conversion that trips Quicktime/AV Foundation.
  • VLC is sometimes showing more accurate color results than QuicktimeX/AV Foundation. My guess it simply ignores a lot of Tags/Metadata.
  • The Quicktime Player X requires tagged files and the right metadata to show you a perceptual right result on your screen. (https://developer.apple.com/library/mac/technotes/tn2227)

What´s next:

  • I would like to have a progress bar or a usable output from ffmpeg to show what happens while the App “renders”.
  • It could read all image sequences that are in one folder and converts them all. Or you just select one folder and all sub folder will get scanned and converted.
  • The output path could be set by the user – this is of course the easiest to do.
  • Or also the destination quicktime codec could be made accessible to the user.
  • And timecode (from DPX files) burn-in and many things more…

The App:

TD_ImgSeq_to_MOV

  • Download the TD_ImgSeq_to_MOV_v11.zip
  • This Zip file contains the compiled “App” to use is with FFMpeg, the source code Applescript, the Automator script, the Nuke Python script and the 3D-Lut file.
  • Put the “TD_ImgSeq_to_MOV” directly in your applications folder, please not in a subfolder. (Or adjust the paths in script for yourself.)
  • The subfolder “FFMpeg” is empty – download the “latest” FFMpeg version and place the three files “ffmpeg, ffprobe and server” there. (I use 3.0.1 from http://ffmpegmac.net/)
  • The expected path to FFMpeg is /Applications/TD_ImgSeq_to_MOV/FFMpeg/ffmpeg
  • The 3D-Lut .cube file is expected to be here: /Applications/TD_ImgSeq_to_MOV/FFMpeg/3d-lut/Linear_to_sRGB.cube