CR2 (14bit) + XMP to 4K ProRes (10bit, 444)

[surami]

Somebody knows a way to convert CR2s (14bit) + their XMP datas (adjusments) directly to 4K ProRes (10bit, 444)... of course without colorshifts?

[dmilligan]

Adobe After Effects

[surami]

I'm on Windows and I have got a display, which is 8 bit native + 2 bit dithered.

I tried the Advanced FrameServer, but it's only serves RGB24, RGB32, UYVY and YUY2, so 8bpc:
http://sourceforge.net/projects/advancedfs/
http://wiki.multimedia.cx/index.php?title=RGB
http://wiki.multimedia.cx/index.php?title=YCbCr_4:2:2

I would like to have 10bit 444 at the end.

[surami]

I forgot to mention, that with 8bit 4K JPGs I produce 4K 8bit 444 MP4 video this way:

1. Import the JPG sequence in AE, sRGB + 8bpc, save project file, close AE
2. Put the project file in queue in AME, start frame serving with the Advanced FrameServer, RGB24 preset (video only), this is the "frameserver.avi"
3. In the AviSynth file (frameserver.avs) I have this:

Code Select Expand

AVISource("E:\timelapse_rendering\frameserver.avi", audio=false).AssumeFPS(24,1)
ConvertToYV24(matrix="Rec709")
4. Start the 4k_8bit_444.bat file:

Code Select Expand

ffmpeg -r 24 -i "frameserver.avs" -aspect 16:9 -s 3840x2160 -c:v libx264 -preset slow -crf 13 -profile:v high444 -pix_fmt yuv444p -x264opts keyint=24:min-keyint=1 -g 24 -filter:v unsharp=5:5:0.5:5:5:0.5 -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 -r 24 "4k_8bit_444.mp4"
pause
5. As the rendering is finished stop frame serving, close AME and watch the produced video

Is there a 10bit frameserving solution somehow, because if it exists, then with AviSynth high bit-depth and ffmpeg x264-10bit codec we could produce 4K 10bit 444 MP4 or with ffmpeg prores_ks codec 4K 10bit 444 MOV.

[dmilligan]

On a mac here, sorry. All I do is select ProRes 444 in AME

[Audionut]

Imagesource?

[surami]

On a mac here, sorry. All I do is select ProRes 444 in AME

I thought...

Imagesource?

It makes only 8bit processing.

I'm just reading this and thinking (#22):
http://forum.doom9.org/showthread.php?t=162598&page=2

What would be if the CR2 + its XMP datas (adjusments) could be converted into a virtual 16 bit TIF container (RGB48), but at once only 1 frame. This TIF file would be read out by ffmpeg and converted with prores_ks encoder, so we are at a 10bit frame (YUV 444) and this would be saved in a MOV container. If the 10 bit frame is already in the container, then the cycle should be started again with the next CR2 + XMP data pair. With delayed programing it could work not or is this bullshit? Am I thinking wrong?

Dcraw can read out the CR2 + its XMP data and convert into 16 bit TIF?

[dmilligan]

What would be if the CR2 + its XMP datas (adjusments) could be converted into a virtual 16 bit TIF container (RGB48), but at once only 1 frame. This TIF file would be read out by ffmpeg and converted with prores_ks encoder, so we are at a 10bit frame (YUV 444) and this would be saved in a MOV container. If the 10 bit frame is already in the container, then the cycle should be started again with the next CR2 + XMP data pair. With delayed programing it could work not or is this bullshit? Am I thinking wrong?

Dcraw can read out the CR2 + its XMP data and convert into 16 bit TIF?

Bridge/Photoshop can easily convert to TIFF with the "Image Processor".  You'd probably just want to wait until that finished and then send the TIFFs to ffmpeg encoder.

[surami]

It's too much storing space to convert the CR2s + XMPs to 4K 16 bit TIFFs. Why isn't there any solution for this in 16bit, I mean frameserving? I don't understand. This could automate the whole process to get a final 4K 10bit 444 ProRes (or any other formats) file at the end on Windows, the RAM read/write speed is also faster than HDD or SSD.

[surami]

What is, when only so many 16 bit TIFFs are exported by Adobe Bridge at once what is enough to feed the ffmpeg to get the information be converted. With a delayed exporting and deleting cycle it could work or not? There is the RAM Disk, it's very fast, so this would be the buffer. Could this be solved somehow?

[dmilligan]

Well, you could just do it in batches. Start the converting the TIFFs, as soon as 100 (or 200 or whatever) finish converting, start ffmpeg on those 100, when it's finished you delete them. Then at the end you just join all the chunks together. This could all be accomplished using an Adobe script.

[surami]

Could you turn my head into a right direction, that how to write this kind of Bridge script (never did this)? Do you think, that there is a simple solution to watch the RAM Disk contuniously. I'm thinking about something like this: If the amount of the TIFFs is more then 200, delete the first 150 and after a little time check this again, again and again and delete if the limit is reached. So at the end I could have a continous video, not pieces. This way in theory the ffmpeg could run continously.

[Audionut]

I'm thinking about something like this: If the amount of the TIFFs is more then 200, delete the first 150 and after a little time check this again, again and again and delete if the limit is reached. So at the end I could have a continous video, not pieces. This way in theory the ffmpeg could run continously.

That sounds ugly, and prone to problems.

I would say, just buy some more HDD space, since it is fairly cheap.  Time is money, and I expect you will spend a lot of time, trying to find some hacky way to accomplish this task.

[dmilligan]

Could you turn my head into a right direction, that how to write this kind of Bridge script (never did this)?

The 'ImageProcessor.jsx' script is included in photoshop (check the Presets/Scripts directory). It should have most everything in it you would need. You'd just need to stop it every 100 or so images and call ffmepg (with File.execute, probably from a batch file, Ex: new File("runffmpeg.bat").execute()).

Personally, I would just convert all the TIFFs at once and then send them to ffmpeg and be done with it. Yes you might need a rather large scratch disc (you can use compression in the TIFFS to save a little space), but like audionut says they are cheap.

[surami]

Yepp... sadly more HDD is the solution or to find someone, who can write a 16 bit frameserving plugin for AE/PP/AME. If it is solved, than PIPE -> PIPE -> PIPE

Maybe this things are helpful:
Instructions on how to setup and build the Debugmode Frameserver: https://code.google.com/p/frame-server/wiki/BuildInstructions
Premiere Pro CS6 SDK: http://www.adobe.com/devnet/premiere/sdk/cs6.html
VapourSynth: http://www.vapoursynth.com/about/
Raw format reader for VapourSynth: https://github.com/chikuzen/vsrawsource (see format_list.txt)
VapourSynth -> ffmpeg: http://forum.doom9.org/showthread.php?t=167627