Logging Software for Canon 5D

Andreas,

Thanks for the additional info.

In Preview, the Inspector window shows a ColorSync profile of "Dell 2408WFP," though it doesn't matter (all parts of the image would be changed similarly). So, yeah it is pretty clear that the differences are actual, or possibly due to conversion settings and proper/improper metadata, or lack thereof, in the resulting files, as well as how those files were interpreted in FCP.

Some comments:

• I wouldn't be surprised that the camera itself is creating invalid video files (i.e., the metadata is wrong/missing, the color mapping/space is improper, etc.). Some of these things may be affected by camera settings (as strypes/Gerard mentioned).
• If camera sensor data is inherently RGB but being flagged/stored as Y'CbCr data, something may be funky with how that happens.
• I wonder how the automatic gamma setting in Compressor is affecting things during conversion (though, the first two "slices" look to differ only by a slight gamma difference)?
• The 5DtoRGB application claims to process the camera files in 10-bit, but QT/FCP/Compressor may internally do the same, especially when transcoding to ProRes. I find its claims a bit misleading (suggesting that it is "superior" in all cases to other methods). One reason it may seem to do a better job (as seen in their comparison image on the product page) is that they apply chroma smoothing (and other image manipulation?) by default. I wonder if you applied those filters after Compressor transcoding or L&T if you couldn't do similar changes?
• Is the resulting video created by the various methods in Y'CbCr or RGB. If RGB, FCP may be adjusting the image during import, depending on its settings for handling RGB files.
• To me, the more I hear about all of the issues involved with using DSLRs, it just doesn't make much sense to me to ever want to use them (or choose to use them, except in rare situations). If I need that much DOF control, I'd just use a "real, high quality" video camera. The weird issues with the resulting video files just reinforces the idea that these cameras are intended for still photographers to do a "little bit of video" (as it is mentioned in the product literature). To me, the costs savings are a wash, or a big loss, when you consider the added gyrations required for a good post workflow, along with poor camera ergonomics, etc. Argh.
• I'd be wary using the 5DtoRGB tool, not knowing if what is done in processing is actually correct. I'd feel more confident if the developers actually described everything they are doing to the image during conversion (after all, some/a lot/most/all of their underlying code is based on the ffmpeg open source libraries).

Oh well...


Thanks for everyone's input to this discussion. I would appreciate any other input, as well...


-Dave

Pff, a lot of info already here...
Did not know there was a 'hidden' UMID in the THM files. But it will be fun to reverse engeneer it...
(although i have a zillion other things to do, and i'm in the camp of 'do not go back to the source, and if you must, keep your folder structure logical, where the rootfolder is a 'tapename')

My approach is to convert while shooting. Thus, offloading your cards during the shoot using a laptop, and have that laptop do the conversion so you arrive home with 'ready to edit' material.

For that i made this: (Shameless plug!)
[www.videotoolshed.com]

It can transcode to Prores, and gamma can be set in the QT dialogue box.
Nothing fancy, it is just like you export from QT pro, and have up to 9 process run at the same time.
(I ran a small test, outperformed Mpeg Streamclip that only does 4 processes at the same time. Image quality was exactly the same...)
What is fancy, once you've set it up, it runs worry free without you need to pay attention to it.
(eg, If you insert the same card again, you'll be warned.)
And another hip addition (As per request of the BBC), it can transcode to optical XDcam (1920x1080 @ 50 Mb)

Of course this isn't the best of the best in term of image quality, but it is handy and hugely universal, and the disks are cheap and rugged, so if you are a DP, it is a very good way to give the content to your client.
(And since the TC is retained, you can also deliver Prores and originals while you're at it, so it is up to the finishing editor what to use)

Bouke
www.videotoolshed.com

D-Mac Wrote:
-------------------------------------------------------
> [*] I'd be wary using the 5DtoRGB tool, not
> knowing if what is done in processing is actually
> correct. I'd feel more confident if the developers
> actually described everything they are doing to
> the image during conversion (after all, some/a
> lot/most/all of their underlying code is based on
> the ffmpeg open source libraries).

Well, just trust your eyes...
(And to be transparant, my Offloader uses FFmpeg as well to get from H264 to XDcam, and uses your installed QT to do the conversion to Prores (or any other QT format).)

Bouke
www.videotoolshed.com

Quote
Bouke
But it will be fun to reverse engeneer it...
(although i have a zillion other things to do, ...

Same for me Let me know.

Andreas

P.S.
The German Telekom meanwhile succeeded to 'fix?' the line so I got half ISDN connection speed. I can't recall how it was possible to work with the internet those days where that was normal.
Load this page takes way more than a minute. Grrr...

>Have you tried to change the 'Gamma Interpretation' in Compressor?

Okay, I switched gamma interpretation to "none" as a test on one of the clips, and I got pretty much the same result as having it on auto. For now, Color is my miracle worker with H.264. I'm sure the issue is down to either a setting in the camera or firmware.



www.strypesinpost.com

Sorry to bring up this thread. I am now working with some SxS cards. If I make a disk image from folder using the hybrid method, the iso comes out as Mac OS extended. If I make a disk image from disk 1s1, I get a Dmg file that is fat32. The card is going straight in via the expresscard slot.



www.strypesinpost.com