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

[dfort]

...if you like i prepare a video to show what I mean.

That might help. I'm having a hard time following what changed from January 2 to January 5 that would cause those issues. It might be a bad merge on my part.

[RenatoPhoto]

Some color and resolution testing of latest :  magiclantern-raw_video_10bit_12bit.2017Jan05.5D3123

Original image from CR2 (cropped)  taken in manual mode ISO 100   White Balance in manual at 3900K
When open in Adobe Camera Raw WB reads:  Temperature +3900 and Tint +7


Recorded video in Manual Mode ISO100 WB=3900K and extracted DNG for comparison with good exposure and then with low light but bumped exposure by +4EV

TEST1: Properly exposed video Image from DNG.. Note that when I open with Adobe Camera RAW it reads: Temperature +5500 and  Tint +19
On the left are the un-edited images and on the right I have used "Auto WB" in Adobe Camera Raw


TEST2: Low light exposed video image from DNG..  Note that when I open with Adobe Camera RAW it reads: Temperature +5500 and  Tint +19
On the left are the un-edited images and on the right I have used "Auto WB" in Adobe Camera Raw
Exposure has been edited to +4 EV


Question 1: Why is MLV not properly passing White Balance to ACR in the DNG format.
Question 2: Why is there some significant White Balance tweaking required in 10 bit.

NOTE: I cannot find any significant difference in resolution between 10-12-14 bit.  After pixel peeping I see a tiny amount if difference between 10 and 14 bit.. only on low exposure areas.

[Danne]

Thanks for tests. Wonder what darkframe averaging would do for those 10-bit files.
Hard coded wb values in mlv_dump. Until ml-dng code finds the way into unified.
If important you can dig out mlv_dump in cr2hdr.app and use that one. Bouncyball put together missing white balance parts in the ml-dng code dmilligan uses in mlvfs and in his ml-dng code into that version of mlv_dump.

[RenatoPhoto]

@Danne I dont think there is one available for 10bit and windows??

[a1ex]

Question 2: Why is there some significant White Balance tweaking required in 10 bit.

Black level may need some fine-tuning to reduce roundoff errors.

When you simply discard some bits, the resulting signal, when scaled back, will have lower values compared to the original. For 14->10 bit conversion, the difference will be between 0 and 15 DN.

Therefore, when interpreting 10-bit data, it's probably best to adjust the black level by 0.5 LSB. This would require scaling the 10-bit data to a higher bit depth (at least 11).

For latest mlv_dump, which scales the 10-bit data back to 14-bit levels (multiplies by 16), the workaround would be:

Code: [Select]

exiftool *.dng -BlackLevel=2040


Code: [Select]

[14-bit 2047    10to14 2032;
 10to14 2048    10to14 2040]

Test image from here.

For a fix, the raw recording module should probably save the 14-bit black/white levels and let mlv_dump do the scaling. Or, remove the autodetection and just hardcode the reference black level (e.g. 2048 on 5D3); in this case, the roundoff error will be predictable.

[RenatoPhoto]

Thanks A1lex:  Great explanation and solution..

After applying the exif fix here are the results:

[eNnvi]

Sorry guys if i'm taking so long but i'm really in a short of spare time.

I'm still trying to understand what's the big difference between digic 4 and digic 5 for raw_slurp

Io to now i think i just discovered hot water as i'm trying ti figure out how Memory is dinamically allocated in Canon firmware. As a1ex said a few posts ago probably the raw buffer address is a variabile inside a structure. My Guess is that in digic 5 this struct is statically allocated while in digic 4 this is dinamically allocated via a Memory lib (for garbage collection? With debugging symbols and assert management i think)
This should also explain why in digic 5 se get a pointer while in digic 4 we get a pointer to a pointer.

What i don't understand is why the offsets from the struct base address are so different from camera to camera.

Is it possibile to dump a certain part of RAM while running? From address X get N bytes?

[dfort]

@eNnvi -- You can make fresh dumps of ROM0.BIN, ROM1.BIN and RAM4.BIN from the Debug menu.

Looks like the cameras that need to get the CONFIG_EDMAC_RAW_SLURP treatment are all Digic 4:

5D2.212	-	Digic 4
7D.203	-	Dual Digic 4
50D.109	-	Digic 4
500D.111	-	Digic 4
550D.109	-	Digic 4

The 60D, 600D and 1100D are also Digic 4 but I have not found out how these were resolved. I keep getting lost tracing lv_raw_dump.

[dmilligan]

Therefore, when interpreting 10-bit data, it's probably best to adjust the black level by 0.5 LSB.

Or perhaps even just adding back 0-15 units of noise?

[ShootMeAlready]

So why is the 600D experimental?  It seemed to be one of the most full functioned?

[dfort]

So why is the 600D experimental?  It seemed to be one of the most full functioned?

It isn't the 600D that's experimental, it is "10/12-bit RAW video" that is experimental.

This might be the first time that a development branch is being compiled on the Jenkins server so that ML users can have a preview of coming attractions. Note that there is also a section for "Non-CPU lens info" and a "Crop mode recording (crop_rec)" section too. Yeah, I know, users want 10/12-bit and crop_rec but that requires resolving merge conflicts and I already botched it up a few times because I don't have a 5D3 for testing so you can ask someone else to do it for you or learn how to compile ML and try it yourself. It isn't that hard and there are several tutorials in the General Development Discussion section of the forum. (I'm starting to sound like an old man repeating the same thing over and over.)

[nikfreak]

The 60D, 600D and 1100D are also Digic 4 but I have not found out how these were resolved.

Those use EVF_STATE being DIGIC4. All other DIGIC4's using LVSTATE due to the missing EVF_STATE are the ones that are not working. a1ex has the state diagrams published on his bitbucket repo and allocating the buffer is not the problem

[Andy600]

I tried mlv_rec (and mlv_play + raw_twk) with the nightly experimental version for the 50D using non-crop, 5x crop and 10x crop at 10, 12 and 14bit.

10 and 12bit recording exhibit frame tearing with the lower portion of the image always being frame 1 but there were no colored/noisy corrupt frames. 14bit has no corrupt frames.

I don't remember the 50D ever recording in 10x but it does now  (though it might just be that I have never used it before  )

[Levas]

So I've downloaded the 25th december 2016 version of mlv_dump and now I get normal dark dark frames from averaging a mlv file.
And I noticed the differince in file size, this version of MLV dump creates 14 bit files, where the older mlv_dump created 12 or 10 bit files.
Is this for compatibility reasons or are there other advantages that the output files are converted to 14 bit ?

[g3gg0]

So I've downloaded the 25th december 2016 version of mlv_dump and now I get normal dark dark frames from averaging a mlv file.
And I noticed the differince in file size, this version of MLV dump creates 14 bit files, where the older mlv_dump created 12 or 10 bit files.
Is this for compatibility reasons or are there other advantages that the output files are converted to 14 bit ?

can you tell me the exact commandline, the bit depths of the input files and the bit depth the output file had?

[Levas]

I'm using an old script which was once available on magic lantern, made some alterations for averaging.
Input file is 12 bit mlv, output file is a single frame 14 bit mlv

workingDir=`dirname "$0"`
cd "${workingDir}"

sudo mv ./mlv_dump.osx /usr/bin/mlv_dump
sudo chmod +x /usr/bin/mlv_dump

for FILE in `ls -A1 *.MLV *.mlv 2>/dev/null`; do
    BASE=`echo $FILE | cut -d "." -f1`;
    mkdir $BASE;
    mv ./"$BASE".M* ./$BASE
    cd ./$BASE
    /usr/bin/mlv_dump --no-fixcp --no-stripes -o ${BASE}_frame_ $FILE -a
    cd ..
done

[g3gg0]

"--no-fixcp --no-stripes" should not have any effect. they are for dng export only.

Code: [Select]

root@linux-dev:/media/sf_M_DRIVE/raw/10_12_14bpp# mlv_dump M24-2240.MLV -v | grep bits_per_pixel
      bits_per_pixel   12
root@linux-dev:/media/sf_M_DRIVE/raw/10_12_14bpp# mlv_dump --no-fixcp --no-stripes M24-2240.MLV -o M24-2240_avg.mlv -a > /dev/null
root@linux-dev:/media/sf_M_DRIVE/raw/10_12_14bpp# mlv_dump M24-2240_avg.mlv -v | grep bits_per_pixel
      bits_per_pixel   12

which mlv_dump did you use?
when in doubt, always this one: http://www.magiclantern.fm/modules/modules/mlv_dump.zip/mlv_dump.zip

[honza123]

www.youtube.com/watch?v=UWFVnE4-xp0

Test of 10 bit raw video recorded on Canon EOS 600D during daylight.
Resolution: 1728x576, 23,97fps, ISO 100, mlv_rec.mo + mlv_snd.mo

BUILD/dfort/: magiclantern-raw_video_10bit_12bit.2017Jan05.600D102

I recorded 25 mlv video files. Four files were corupted (green cast, frame-skipping).

[g3gg0]

"vibration" could be a stuck frame. then you will see parts of (or the whole) older frame.
it could be the first frame, or even the second-to-last frame you see there.

green cast is no corruption, just a black level error.
fix it (as described here a few times) by correcting the black level in DNG files, or by supplying "--black-fix=<value>" to mlv_dump with value depending on the bit depth.
when calling without any value "--black-fix" it will set black level to 2048

[a1ex]

Or perhaps even just adding back 0-15 units of noise?

Which one looks best? Clicking on each thumbnail will open the full test image.

Render settings:

Code: [Select]

ufraw-batch --out-type=jpg --exposure=5 --temperature=2000 --green=1 --interpolation=ahd --color-smoothing --clip=film


[RenatoPhoto]

@g3goo  When I use --black-fix the dng cannot be read on Adobe Camera Raw and the command prompt shows "Cold pixels : 200000" see below:

 MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: 'M07-1506.mlv'
   - Setting black level to 2048
   - Convert to DNG frames
   - Output into 'M07-1506.raw'
File M07-1506.mlv opened
File M07-1506.m00 not existing.
Processing...


Vertical stripes correction:
  1.00000    1      1      1      1      1      1      1
Cold pixels : 200000
Reached end of chunk 1/1 after 306 blocks
Processed 146 video frames
Done

edit: using the windows version

[honza123]

to g3gg0:
1) "vibration" it could be
2) to fix "green cast" I used command: exiftool "-BlackLevel=2032" "-whitelevel=14992" *.dng
In this case 2/3 of picture is OK, but 1/3 (upper part of frame) is not usable.
Sample is here. I can't upload picture to this forum :-/
http://uschovna.cz/zasilka/LIBLRNMY6XS63UNG-9LL/49WFXLN2CF

[RenatoPhoto]

@a1ex:  Seems like n1 or r2 have less color noise than others.

[Danne]

@A1ex. r2 and r4 looks good. Bottom three not so.

[Danne]

@Renatophoto.
I never used --black-fix option in mlv_dump before but just tried it and it worked over here. Did you also specify the black level number like this --black-fix=2048
Black level setting has nothing to do with cold pixels so not sure why you would be getting that.
Could you specify the full command line output you are using?