Messages

For sources that have north of 13 stops of dynamic range, should we just use the 13-stop curve?

That works, as do the other Protune curves, the 13-stop curve place a little more emphasis on the shadows.

Does CF only accept 16-bit or 8-bit ?

For RAW only 16-bit should be used.   For YUV v210 is a 10-bit format, and there are several 10-bit RGB pixel formats.

The codec uses 16-bit SSE2,  so the unpacking has to occur somewhere.  This might be 5-10‰ of the compute load.

zcream,

Use the CineForm codec SDK.  http://twitter.com/CineFormSDK
What are you referring to here? "lack of documentation related to various fields in the CF header."

Use BYR4 (16-bit linear format -- easy) re: "the lack of knowledge of packed vs unpacked RAW inputs."

David

The Cineon curve is a byproduct of film scanning and it relates to the nature of negative film.  The large lifted black is mostly a waste codewords (in my opinion) but it can help in film style workflows for those that still think that way.  The data that represents black is always lifted slightly as you do want to encode the noise (just not too gained up) not clip it.  The sensor data is often significantly lifted, so that DC offset is removed before applying the log curve.

Excel spread sheet with the formulas https://dl.dropboxusercontent.com/u/5056120/protuneVgamma.xls

I thought something like that at first, wouldn't you use a curve that divided the stops equally amongst the available codewords: 10bit - 1024 codes, 12-bit - 4096 codes etc.?  So for a 12-stop camera, using 12-bit log storage you would think you need 341-ish codes per stop (4096 / 12 = 341.33.)  The source is in linear space is digitized, so say 14-bit (with noise in the lower bits), which has a highlight stop of 8192 values, which will be stored as 341 values in log space (efficient) -- this is fine -- whereas the bottom usable stop (for a 12-stop camera) is the lowest 3 bits, 8 values of mostly noise expanded out to 341 codewords.   That is not going to work.  It also plays havoc on compression efficiency as the last stop is mostly noise, and noise is uncompress-able.

Why do want to reduce the number codewords used for the highlight, but not give equal weight to the shadows, as the shadows are not all signal.  We want to store the signal without too much overhead of the noise. For wider dynamic range systems there is a lower noise floor, so we need to use fewer bits in the highlights saving more codes for the lower stops. That is why there are different log curves.

Q1:  It will be CineForm compressed into an MOV or AVI.  You can choose to compress native RAW (CineForm  RAW) or developed (debayered) to RGB or YUV and compress that as CineForm.

Q2: There is no significant advantage to color correction upon RAW vs debayered to RGB, both have the same dynamic range.  However, texture and detail are controlled by the demoasic, so if you can choose that later, I would think that is a bonus.  Also RAW compressed is about 40% size or RGB compressed, with the same quality.

Q3: All compressed sources must have a log or gamma encoding, all compressor assume there is at least gamma correction (e.g. H.264, ProRES, etc.)  There a quality/efficient gains using log encoding.   Uncompressed RAW is linear, so you have to select a curve to compress it.  This is not metadata, as is does manipulate the data before it is stored.  The CineForm codec has some clever tricks to use metadata to describe decoding behavior, independently from the encoding curve applied.  Most log curves are 1D LUTs. GoPro Protune is log 113, SI-Log is Log 90, I like log curves that are mathematically described, rather than loading a table   
  output = log10(input * (base - 1.0) + 1.0)/log10(base)     // input and output ranges are normallized 0 to 1, base is the log base (e.g. 113)

Q4: I don't have that.

Any thoughts on MLV support??

First I've heard of it, I've been busy.  It is what should be supported next?  If so, please point be to the specifications. 

I'm not familiar with Adobe Digital Camera Profile, is that a standard?

Hopefully they implement the demosaic algorithms I showed them a while back. The licensing was compatible, so fingers crossed...

I still have tabs open to those links (thank you again), so it will hopeful happen, just need to find the engineering cycles.

 iaremrsir is correct.  You are not trying for the best look straight out of the conversion, but a good curve that preserves all your source image, that is easy-ish to color correct on top of.

Hi David,

When I use the new version of the raw2gpcf (v114) with the -c -f25 -422 command set, the pictures turn out darker than they do in the previous version of raw2gpcf. Is there anything I can do about this. Another thing, how does one get a hang of all the features and command instructions that come up on the command prompt page. Some of these will require some more explanation for folks like me - absolute beginners.

Is it a lot darker?  What options are you using?  I few versions go I started using the black level offsets from the .RAW bitstream, that would have made a change, but hopeful for the good.

As a beginner I'm surprised you are using the -c (Cineon) switch, which even I don't use. I prefer the default (GoPro Protune), or a log curve like -l400 (which requires GoPro Studio version 2.0.)

I've been away for a while.  What is the latest in ML that I need to add support within RAW2GPCF?

I have updated RAW2GPCF to support larger Log curves for a flatter look.  Previous only -l255 was the largest, now up to -l65535 works, although -l900 is the highest recommended.

http://miscdata.com/ML/RAW2GPCFv114.zip

I haven't looked at the details of Slog2, but you can control how flat the image is using the -lX switch that controls the Log curve, using -l900 will give at 13-stop log curve which is pretty flat in appearance.  You can also pre-shape the developed image using the metadata switches.  If you want to under exposure the output by a stop add +EXPS=0.5 as non-destructive metadata.

Neither CineForm RAW or Cinema DNG add or subtract noise, so the differences here are selected black level and what post processing the Cinema DNG viewer is doing.  Black calibration can help, but it mainly helps for fixed pattern noise and/or dead pixels.

To try RAW2GPCF, you need to launch in from a cmd prompt, for directly like I think you are trying'.

'Windows+R' type 'cmd' <press enter>

This will get you a shell where you can try out RAW2GPCF with it disappearing after it executes.

Yes the Surface Pro is awesome little ultrabook with the correct drivers

Sounds like a bug to be filed with blackmagic.

contact [email protected] about license extensions.

I like the Surface Pro, but do all my editing at half res as it is no desktop replacement.  Yet I do a lot of edit with it.

Is it commonly being used (MLV)? Where is the specification?

Revisiting debayer soon.

GoPro Studio 2.0 is out.  Time I get back into ML RAW.

What is this "new raw file format" you speak of?

I have confirmed there was a bug in the despeckle code within the 1.3.2 version of CineForm Studio.  2.0 will be here in a few weeks, and it should addresses this failure.

I also get "Failed to encode. Do you have GoPro Cineform Studio Installed". This is in rawanizer after I updated it to the latest so perhaps it's their fault.

There is bug that shows that error if you get any if the paths wrong.

I've not seen an image that can't be corrected with primaries and saturation clip point.

RAW as the camera shot it.
https://www.dropbox.com/s/jg5rkyxmwa6gzyd/RAWcolor.jpg

Turning on White balance and the color matrix from camera metadata, with Sat. Clip point off (1)
https://www.dropbox.com/s/7t7aacdqpoxcqqg/CameraMatrix%2BCameraWB.jpg

Primaries to remove clipping and fix shadows and mid-tones
https://www.dropbox.com/s/yvxf6hg2ipzz6z4/CameraMatrix%2BCameraWB%2Bprimaries.jpg

Setting Saturation Clip point
https://www.dropbox.com/s/uzwxaduent435qz/CameraMatrix%2BCameraWB%2Bprimaries%2BSatClipPoint.jpg

If the sun or clipped object was in the scene, it would be correctly clipped to white.

It is not really a matrix problem nor is it a raw2gpcf problem, it to be expected when the green channel clips in camera. It is easy to address in post, plus it teaches us to underexposure a little more.