infos about cineform pre workflow vs HdLink + firstlight input output workflow

[Carlo Macchiavello]

Hi guys,
today i see an interesting tutorial from Henry Olonga about workflow with dslr video.

Henry Olonga - Firstlight tutorial - Using the program on Vimeo

he use an interesting workflow where use vegas to remove grain (neat video) + flatten process (contrast -0,40, move contrast center), and output this in cineform 4:4:4.
then it load this flatted avi in firstlight and correct with slider and lut.
He show in tutorial that this flatted video is more CC able then original cineform files.

i use PPro and after, and i would avoid to render more times
My question is about quality and speed.
i can replicate this workflow, i can build a 16bit composition in after, load .mts apply CC to have flat video, and output cineform 4:4:4. then all other CC i do with firstlight.

but... one additional render and more render time instead of my usual workflow.

i see that in firstlight i have an input curve to encode my stuff...
Can i have a custom curve to encode all info from video in flat mode like this?

from my understand. dslr video (avchd from GH2) have 8 bit encoding, then have a limited infos.
When i convert it in cineform, it is relaxed in a 10/12 bit space, but original infos are original infos, we have a better red infos (4:2:0 to 4:2:2 conversion), thanks to cineform interpolation.

if i convert with HDlink and load in firstlight i think i can flat it in encoding curve better then in some tools, be cause it just have a 10/12 bit color space, and at same times i can avoid an additional render.

could you tell me if is wrong, or i miss something?

[Charles W. Hull]

It looks like the trick is to apply all the filters before encoding, so just encoding with HDlink and flattening with FirstLight would not achieve the same effect.

[Carlo Macchiavello]

if i understood correctly the work of input curve i think is possibile to do directly in firstlight.

we have 8 bit info, we spread and manipulate in vegas in some way, with a simple contrast filter, then it output file

input curve should grab and manipulate input information for firstlight color manipulation, if i have a custom curve to flat my movie, i do the same thing of contrast filter of vegas. i need only a right kind of input curve to manage correctly the 8 bit information.

is not similar (but not the same) about cineon managment? cineon file must be encoded correctly or you see a dark, bad satured picture.
cineon have more info, but if i understood correctly input output curve of firstlight, we can do a similar work with dsrl files.

[Carlo Macchiavello]

Please correct me if i do a mistake.
after experimentation i found my personal holy grail of cineform setup to work better in color correction.

In firstlight workspace i setup input (encode) Rspace, and Output (decode) LogC
this kind of setup give me a flat video, that enable me to apply better the LUT or color correction, and i can recover overexposed area.

below you can see first the result of with my workspace color setup,

http://img809.imageshack.us/img809/7752/withencode.jpg

and here the result of general video gamma setup

http://img526.imageshack.us/img526/9...houtencode.jpg

[David Newman]

Interesting, although I'm not sure how this greatly differs from a reduction of exposure and contrast to reveal highlight and shadow details. However, what you propose works fine (I think I prefer SLog to LogC,) particularly if you don't need to push saturation or white balance a huge amount. The Input curve defines what linear light is, so saturation, white balance and exposure are a tad effected by this change, while they are no longer mathematcially correct, they could be a creative advantage.

[Carlo Macchiavello]

to be honest, i'm start to learn about color space input output, then actually i played with an high contrast shooting, and i tried to find most of color infos from it.
I worked on some si-2K and red shooting in past, and now that i play with a simple dslr (gh2) i tried to have the best from its shooting.

could point to me a good documentation about different color space la Rspace etc and their description?

i tested also with Slog, but i prefer Clog, it give me a bit more info on highlights of shooting, and is a bit softer than Slog, it allow me to do a pre color with firstlight and final CC with Colorista II.

i don't know if is mathematically correct, but is not important for me, my target is a smooth shooting to have more space for creative CC ;-P

[David Newman]

The is no information to read on this, RSpace is something we developed as a contrast curve that approximates RedSpace, for those that wanted that look without crushing their dynamic range in camera. We applied as input curve, you are applied an invert contrast to source that has a gamma curve, so I'm not sure want you get.

[Carlo Macchiavello]

i tested more and more. Slog is interesting where i have very high contrast, i expose for highlights, and i'm be able to find more in shadows.
i know that my test are not scientific, but visual test, but... work for me.

[Carlo Macchiavello]

Additional info about my test
today i tested my workflow idea with higher bitrate... better better...
i actually use a Panasonic GH2 hacked, i up the bitrate from 24 to 132 mbits and you can see a lots of difference in highlights.
A standard avchd (24mbits) seems that crush more the highlights than avchd codec can do at 132 mbits with hack.

At 132 or (i need to buy a faster sd card to do) at 220 mbits, Panasonic gh2 codec can record more info at top and bottom of gamma in avchd, and with this unsual workflow i can use cineform to extract this additional info.

In my internal meter info, i read overexposed zone, but when i convert shooting in cineform, and i interpretate with in out curve, i can recover dectails in burned highlights. it's away to have more with simple sd card... until hacker be able to change also the color curve of camera.