Magic Lantern Forum

Using Magic Lantern => Post-processing Workflow => Topic started by: dirtcastle on June 01, 2013, 09:55:11 AM

Title: Alternatives to converting in QuickTime Pro?
Post by: dirtcastle on June 01, 2013, 09:55:11 AM
I've been getting a color shift in QuickTime Pro 7 (Mac) when I convert .tiff files to Prores 422.

The color shift seems to affect all of QuickTime, not just exports/conversions.

It is similar to the following problem.

http://www.eoshd.com/comments/topic/1233-h264-playback-and-quicktime-a-bug/

What are the alternatives to converting batches of .tiff files in QuickTime?

I'm on a Mac.
Title: Re: Alternatives to converting in QuickTime Pro?
Post by: dirtcastle on June 02, 2013, 09:32:52 AM
The framework ffmpeg can convert multiple .tiff files to .mov format.

http://ffmpeg.gusari.org/viewtopic.php?f=11&t=808
Title: Re: Alternatives to converting in QuickTime Pro?
Post by: togg on June 02, 2013, 03:50:43 PM
Compressor should do the job. There's the "add image sequences" button.
Title: Re: Alternatives to converting in QuickTime Pro?
Post by: Hazer on June 04, 2013, 01:11:16 AM
I've been looking into this.  I noticed the color shift with ffmpeg, and have reproduced it in just about every other quicktime based process, including Compressor, and even Photoshop when it exports with Quicktime.  Needless to say, if you spend quality time tweaking your raw color in Adobe Camera Raw, this is the last thing you want.  It's totally noticeable and totally unacceptable.

I don't use After Effects, so I haven't tested that.  But its Apple counterpart, Motion, works, as does FCP X.  X is a little clunky for this sort of thing, but Motion is just about as fast as Quicktime player.  No need to even save the project when you're done.

If you export via Motion, the source .tif file and the resulting .mov file look identical.  Interestingly, although Compressor causes a color shift when you process image sequences with it directly, you can batch Motion projects through Compressor and the colors are still good.  I believe Motion and FCP X use a separate codebase from the older Quicktime apps.

If you're handy with the command line, here's the script to invoke Compressor on a Motion project.  Just fill in the blanks for your setup:

/Applications/Compressor.app/Contents/MacOS/Compressor \
-clustername "This Computer" \
-batchname "dngbatch" \
-jobpath "/Path/to/motionproject.motn" \
-settingpath "/Users/yourusername/Library/Application Support/Compressor/Settings/yoursettings.setting" \
-destinationpath "/path/to/some/moviename.mov"

So:  Apple Motion.  Either on its own, or through Compressor.
Title: Re: Alternatives to converting in QuickTime Pro?
Post by: Murphy on June 04, 2013, 04:46:33 AM
You might want to check whether it's actually shifting the colour, or whether QuickTime is just using a different icc colour profile to the software you view your tiffs in. My guess is that it's just the fact that QuickTime uses a 2.2 gama profile to display movies, compared to the standard 1.8 gama the system uses, rather than the shift actually being baked into the file on export/conversion.

Try copying one of the mov frames from the QuickTime edit menu, and paste it into photoshop, and compare it to the original tiff frame in photoshop. The actual rgb information in both files should be the same, and I'd put money on them looking the same, when viewed in the same colour space such as the photoshop environment.

A lot of program's have different colour profiles, and it sometimes does make it a nightmare to match things up when switching between QuickTime, FCP, AE etc. The print and web designers here know what I'm talking about :) But i doubt your mov files are actually loosing rgb data integrity (lossy compression not withstanding)

@Hazer would you be able to copy and compare some frames in photoshop of your motion>compressor method? My guess is that it's just adding the system's 1.8 gama profile to the mov file's metadata header, but if the raw rgb frame you copy from the motion exported mov into photoshop doesn't look the same as the original frame when viewed under the same colour space, the method you're using could potentially be changing (and destroying) rgb colour information in your file, and is probably not what you want happening, even though it superficially looks right in QuickTime compared to photoshop or the osx system picture viewer etc.