Page 1 of 1

-hald-clut and batch processing on Windows problem

Posted: 2013-04-24T21:32:33-07:00
by bgruen
I'm trying to create a process on a Windows workstation that takes ProRes 4x4 / log-C footage from an Arri Alexa camera and converts it to various ProRes formats / REC709. To do this I am using ffmbc to create a tif sequence from the clip(s), then using IM's convert program to apply a lookup table to alter Log C to Rec709, then lastly back to ffmbc to create the new ProRes file from the corrected sequence. It is all working but there is a problem... the performance of convert.

The problem stems from how the command line is built. For some reason unknown to me the convert -hald-clut function places the two files together on the command line then the -hald-clut flag follows, which is a bit backwards as the program can not deliniate the input file(s) from the LUT image. This prevents one copy of convert processing multiple files (which is how it should be done for performance sake). In fact, on the "command line" webpage the two LUT functions are listed as image sequence operators, which in actuality they are not. A lookup table is not an image in an image sequence, rather is is a setting that is applied to an image or image sequence that just happens to be stored in an image file.

This is what I want to work:
convert *.tif D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png -hald-clut newfile.%00d.tif
or
convert *.tif +adjoin D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png -hald-clut newfile.%00d.tif
or
convert *.tif D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png -hald-clut +adjoin newfile.%00d.tif


It doesn't work because the png file is just lumped in with all of the tif files, -hald-clut and +adjoin collide, and one bad frame results.

A parse-able version of the command line should be something like:
convert *.tif -hald-clut:"D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png" newfile.%00d.tif


What I have that is working is:
for /f %i in ('dir /b A001*.tif') do convert %i D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png -hald-clut REC709.%i

Because this has to start and stop a convert process for each frame it take about a second to do each frame. My goal is to be able to process tens of thousands of frames in a single day. I am convinced that if I could get one copy of convert to process each sequence then I would be able to accomplish this goal.

Am I missing something? Is there a way to get a single convert process to apply a -hald-clut to an image sequence?

Bob

Re: -hald-clut and batch processing on Windows problem

Posted: 2013-04-24T22:11:09-07:00
by fmw42
Am I missing something? Is there a way to get a single convert process to apply a -hald-clut to an image sequence?
Not that I know about in IM 6, though it would make a nice addition. Right now you would have to write a script to loop over your input images.

A similar question was asked about -clut not too long ago. See viewtopic.php?f=1&t=23071&hilit=clut

Re: -hald-clut and batch processing on Windows problem

Posted: 2013-04-24T23:08:01-07:00
by snibgo
It would be good if clut and hald-clut took the last image of the sequence and applied it to all the other images (the actual frames), leaving a sequence of the modified frames. Sadly, they don't.

With a more complex script, you could ensure convert is called just once, and the hald-clut is read just once. Something like:

Code: Select all

convert ^
D:\LUTs\Arri\Hald_CLog_to_Rec709.ISO800.png ^
  ( frame0001.tif -clone 0 -hald-clut -write new_frame0001.tif +delete ) ^
  ( frame0002.tif -clone 0 -hald-clut -write new_frame0002.tif +delete ) ^
  ( frame9999.tif -clone 0 -hald-clut -write new_frame9999.tif +delete ) ^
  null:
You are limited to the maximum command length, which is about 8900 characters for Windows 7.

Note that this is possible only because the syntax treates the hald image just like any other image.

If this isn't fast enough, well, that's what overnight processing is for.

Re: -hald-clut and batch processing on Windows problem

Posted: 2013-04-25T02:47:43-07:00
by anthony
The limitaion on windows 7 should be solvable using IMv7 "magick" script. However IMv7 is still in alpha.