12-bit (and 10-bit) RAW video development discussion

[Levas]

I'm amazed by the quality difference between 14 and 10 bit

But explainable, downloaded the original dng's and checked them.
In the 14bit file you can see the wall(or shadows) are exposed at the left border/lower limit of the histogram, BUT within limits off the histogram, no cutoff in histogram.
When you do an exposure correction of 3 stops on the 14 bit file, the left side of the histogram starts low and raises, no cut off in detail.
Bottom line, you nailed the exposure for lifting the shadows.

The 10 bit file has the same exposure, but the lower 4 bits of data are cut off.
If you raise it with an exposure of 3 stops, you can see the histogram starts high, so the data in the shadows is cut off.
You nailed the exposure time for 14 bit, but for 10 bit this means detail loss in the shadows.

Makes all sense, but didn't think about it too much before, the quality difference is a lot. 
I'm using the raw histogram data to expose correctly, but does the raw histogram take in account if you're recording 14/12 or 10 bit ?
Cause it seems if you're planning on lifting the shadows, and if your shadows are at the all left end of the histogram, you're better of with 14 bit.

[dfort]

Of course you should also compare 10bit raw against 8bit H.264.

The sweet spot seems to be 12bit. However, the big improvements come with lossless compression. I think that's what made the Black Magic Pocket Cinema Camera such a big hit, it was the 12bit lossless raw recording feature. Well, that and the log 10bit ProRes but we probably can't do that.

...does the raw histogram take in account if you're recording 14/12 or 10 bit ?

Good question.

[a1ex]

The histogram is always computed from 14-bit data, but only the top 12 stops are displayed (count them). Maybe something to consider in the next histogram iteration.

Long answer (computing the histogram from 12-bit or 10-bit data, i.e. while recording at a lower bit depth, is not trivial, although not very difficult either).

[CITY-U1001]

wait new test build for 50D  i see for 5D2 something change ?

[dfort]

@CITY-U1001 - The 5D2 test doesn't apply to the 50D. See Reply #1524

[dariSSight]

Thanks and Happy Holidays to Magic Lantern and a special THANKS and HAPPY HOLIDAYS to dfort for helping me out on setting up for builds, I have a build on my desktop now and I guess I'm read to pitch in.

[6D_ML]

Of course you should also compare 10bit raw against 8bit H.264.

I did. In case of 6D, while detail and dynamic range are noticeably higher in 10 bit RAW, 8bit H.264 file has an edge with a relatively "consistent and accurate" color, whereas 12/10bit file gets polluted with a green & yellow cast in blacks/shadows. This temperature/tint difference is also noticeable between 14 bit (best IQ results) and 12/10 bit files. Has anyone noticed similar temp/tint shifts with other models?

[a1ex]

Is the color shift visible with mlv_dump?

If using other converter, is it following this recommendation? (if not, you know where you have to report the issue)

[kyrobb]

dforts 550D build works flawlessly for me, in both 10 and 12 bit. The 50D build however goes a bit wonky for me. About every 30ish frames I'll get one frame where the bottom 3rd of the frame offsets to the left slightly. This happens in both 10 bit and 12 bit.

[6D_ML]

Is the color shift visible with mlv_dump?

With mlv_dump (option 15), 10bit DNGs are identical to those produced by MLV App (color shift visible)

If using other converter, is it following this recommendation? (if not, you know where you have to report the issue)

I couldn't check black level with mlv_dump since "-v" is not listed as an option, and it doesn't do any operation. What did the trick to remedy the color shift in 10 bit files is the option 4 (converting image data to 14 bit depth per channel).


Download 10bit DNG interpreted as 14bit



Download 10bit DNG

[Sganzerla]

I did. In case of 6D, while detail and dynamic range are noticeably higher in 10 bit RAW, 8bit H.264 file has an edge with a relatively "consistent and accurate" color, whereas 12/10bit file gets polluted with a green & yellow cast in blacks/shadows. This temperature/tint difference is also noticeable between 14 bit (best IQ results) and 12/10 bit files. Has anyone noticed similar temp/tint shifts with other models?

With 5D MKIII there is a magenta color shift in the blacks (with mlv_dump), the only reason I quit using 12/10bit lossless.
Edit: Didn't know about this 14bit conversion solution for the color shift. Will try soon my own tests...

[a1ex]

Not sure what "option 15" is, and the EXIF info in the DNG says Adobe Photoshop Lightroom, so I couldn't tell whether you were using the right version - try the command-line mlv_dump from the Experiments page.

[dfort]

dforts 550D build works flawlessly for me, in both 10 and 12 bit. The 50D build however goes a bit wonky for me.

Glad to hear the 550D is working but those issues on the 50D is news to me.

[Danne]

What build is working with the 550D? Last I tested I had timing?(wacky recordings) issues.

[Andy600]

The 50D build however goes a bit wonky for me. About every 30ish frames I'll get one frame where the bottom 3rd of the frame offsets to the left slightly. This happens in both 10 bit and 12 bit.

What build are you using and which app for MLV>DNG?

Can't reproduce it here.

[6D_ML]

Not sure what "option 15" is, and the EXIF info in the DNG says Adobe Photoshop Lightroom, so I couldn't tell whether you were using the right version - try the command-line mlv_dump from the Experiments page.

I used batch_mlv_in-out to output 10bit DNG above. I need to read a manual for command-line mlv_dump before I make it output DNGs

[a1ex]

Okay, so the linked mlv_dump is following my advice when used with -b 14, but not by default (it has the defaults slightly changed - our version upconverts to 14-bit by default).

To avoid color shift in shadows, the DNG bit depth needs to be at least 1 bit above the recorded bit depth (otherwise, the 0.5 LSB adjustment won't be applied).

[dfort]

I need to read a manual for command-line mlv_dump before I make it output DNGs

Just run mlv_dump without any input/output or options. The crop_rec_4k version it will print out this:

Code: [Select]

MLV Dumper
-----------------

[ERROR] Error: Missing input filename
Usage: mlv_dump [options] <inputfile>
Parameters:
  -o output_file      write video data into a MLV file
  -v                  verbose output
  --version           print version information
  --batch             format output message suitable for batch processing
  --relaxed           do not exit on every error, skip blocks that are erroneous

-- DNG output --
  --dng               output frames into separate .dng files. set prefix with -o
  --no-cs             no chroma smoothing (default)
  --cs2x2             2x2 chroma smoothing
  --cs3x3             3x3 chroma smoothing
  --cs5x5             5x5 chroma smoothing
  --no-fixcp          do not fix cold pixels
  --fixcp2            fix non-static (moving) cold pixels (slow)
  --no-stripes        do not fix vertical stripes in highlights

-- RAW output --
  -r                  output into a legacy raw file for e.g. raw2dng

-- MLV output --
  -b bits             convert image data to given bit depth per channel (1-16)
  -z bits             zero the lowest bits, so we have only specified number of bits containing data (1-16) (improves compression rate)
  -f frames           frames to save. e.g. '12' saves frames 0 to 12, '12-40' saves frames 12 to 40.
  -A fpsx1000         Alter the video file's FPS metadata
  -x                  build xref file (indexing)

-- MLV autopsy --
  --skip-block <block#>        skip given block number, as if it wasn't present
  --skip-type <type>           skip given block type (e.g. VIDF, AUDF, etc), as if they weren't present
  --extract <block#>           extract the block at given position into autopsy file
  --extract-type <type>        extract the block type (e.g. VERS, LENS, etc) into autopsy file
  --replace <block#>           replace block with data from given autopsy file; requires --autopsy-file
  --payload-only               extract/replace affect not the whole block, but only payload
  --header-only                extract/replace affect not the whole block, but only header
  --autopsy-file <file>        extract/replace from this file
  --hex                        extract prints the selected data as hexdump on screen
  --ascii                      extract prints the selected data as ASCII on screen (only suitable for VERS and DEBG)
  --visualize                  visualize block types, most likely you want to use --skip-xref along with it

-- MLV manipulation --
  --skip-xref                  skip loading .IDX (XREF) file, read block in the MLV file's order instead of presorted
  -m                           write only metadata, no audio or video frames
  -n                           write no metadata, only audio and video frames
  -I <mlv_file>                inject data from given MLV file right after MLVI header
  -X type                      extract only block type int output file

-- Image manipulation --
  -a                  average all frames in <inputfile> and output a single-frame MLV from it
  --avg-vertical      [DARKFRAME ONLY] average the resulting frame in vertical direction, so we will extract vertical banding
   --avg-horizontal   [DARKFRAME ONLY] average the resulting frame in horizontal direction, so we will extract horizontal banding
  -s mlv_file         subtract the reference frame in given file from every single frame during processing
  -t mlv_file         use the reference frame in given file as flat field (gain correction)

-- Processing --
  -e                  delta-encode frames to improve compression, but lose random access capabilities
  -c                  compress video and audio frames using LJ92. if already compressed, then decompress and recompress again.
                      specify twice to pass through unmodified compressed (lossless) data to DNG which speeds up writing, but skips preprocessing
  -d                  decompress compressed video and audio frames using LZMA or LJ92

-- bugfixes --
  --black-fix=value   set black level to <value> (fix green/magenta cast). if no value given, it will be set to 2048.
  --white-fix=value   set white level to <value>. if no value given, it will be set to 15000.
  --fix-bug=id        fix some special bugs. *only* to be used if given instruction by developers.
So if I'm understanding what is going on--the version of mlv_dump you are using needs this:

Code: [Select]

mlv_dump --dng -b 14 <inputfile>
If you use the "official" crop_rec_4k mlv_dump you can skip the "-b 14" option because it will save to 14 bit by default:

Code: [Select]

mlv_dump --dng <inputfile>
To understand why the 0.5 LSB adjustment won't be applied, read Reply #1004.

[kyrobb]

I see. I'm using MLV app and converting to ProRes. The issue is present both in the app and after export. Maybe an MLV app issue? I'll have to check with mlv_dump.

[6D_ML]

Is the color shift visible with mlv_dump?

Managed to extract a DNG (download link) with mlv_dump default conversion (mlv_dump --dng myfile.mlv). The color shift is there, and I'd rate its severity between results produced by “batch_mlv_in-out” (best) and “MVL App” (worst). There is also the highest level of blue hue present in clipped blacks with mlv_dump. Hopefully, devs can tackle the color shift issue with 10bit files. I can help so far with feedback only.

If you use the "official" crop_rec_4k mlv_dump you can skip the "-b 14" option because it will save to 14 bit by default:

Code: [Select]

mlv_dump --dng <inputfile>

dfort, thanks for the tip. In my case I had to use the following cmd syntax to extract DNGs:

Code: [Select]

root_path_to\mlv_dump --dng root_path_to\MLVfile.mlv

[a1ex]

This DNG renders identically to the first one from #1536 (the only difference between the two being some hot pixels and vertical stripes, only noticeable if you subtract the raw data in the two images). Overall, the median difference between the two is 0.

Code: [Select]

dcraw -a -W -b 16 M21-2259_*.dng

Results: new vs old.

No idea what further improvements you are expecting - I am unable to see any difference between the two files after rendering.

[6D_ML]

Thanks for your reply A1ex. Lightroom renders files the way I described above. RawTherapee produces results very similar to yours with no difference.

[IDA_ML]

Dfort,

Many people who want to experiment with their 7Ds keep asking me where they can download the latest stable 7D build with 10/12-bit RAW recording.  I direct them to your download area but all they find there is the Dec. 12-th build which does not work well with the 7D, (earthquake motion with normal uncropped RAW video).  The Dec. 11-th build was much better and more stable.  I was wondering if you might be able to upload your Dec. 11-th build with a RAW-tweak module for the 7D again.

Thank you.

[dfort]

The code for the 7D wasn't touched between the Dec-11 and Dec-12 builds.

Check it out:

https://bitbucket.org/daniel_fort/magic-lantern/branch/raw_video_10bit_12bit_LVState-wip

[IDA_ML]

Well, there must be some difference, otherwise, why would you post two absolutely identical builds on two subsequent days?  I tested both builds extensively and provided detailed feedback (see posts 1390 and 1454 for the Dec. 5 and  Dec. 11 builds, respectively and compare them with post 1465 describing the behavior of the Dec. 12-th build).   If you do not trust the feedback information that I provided, you could test these builds by yourself with your own 7D.  There must be some explanation why the two builds behave so differently.