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

[Levas]

@Geggo
I did use the same mlv_dump as in your link.
The build from 25th december for osx

When I use that build on 12 bit mlv's, I'll get 14 bit dng's 
Which is nice, as in you can view them normal in finder, but the downside is that file size is also increased 

[RenatoPhoto]

@Danne
mlv_dump --dng --black-fix=204 -o %Input%.raw %Input%.mlv
I suspect is something to do with ACR.  If I use exiftool then it works..  I was hoping to eliminate the exiftool step.

[Danne]

Tried putting --black fix command before the --dng?
Are you on mac? Could you upload a dng?

[RenatoPhoto]

Yea, no change.. here is a dng
https://drive.google.com/file/d/0B9z8Y0rg-pu8SjFaMUtyeTRzT0E/view?usp=sharing

[Danne]

I don,t think you are doing it right. Try something like this. It absolutely works over here.

Code: [Select]

mlv_dump --black-fix=2048 --dng My.MLV

[dfort]

I don't remember the 50D ever recording in 10x but it does now 

So it joins the 5D2 and 7D as cameras that shouldn't be working but are, sometimes, at certain settings? Does the 50D have zoom mode? Zoom in the LiveView to 5x or 10x and record video? I believe that's the setting that's working on the 5D2 but I'm not sure.

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

So the 60D, 600D, 1100D use EVF_STATE while the 5D2, 7D, 50D, 500D, 550D use LVSTATE and are missing the EVF_STATE? Learning how the 600D was resolved #define DEFAULT_RAW_BUFFER MEM(MEM(0x51FC)) isn't going to help with the 550D even though lv_raw_dump starts out very similar on both cameras? I keep getting lost and not knowing how the 600D address was discovered I'm clueless when it comes to trying to figure out these platforms. After @dmilligan explained how he traced lv_raw_dump on the EOSM figuring it out on the 700D and 650D was relatively easy. (Thanks to @eNnvi for explaining dmilligan's explaination  )

https://bitbucket.org/hudson/magic-lantern/pull-requests/781/650d-and-700d-enable/diff

[RenatoPhoto]

@Danne  No Go!
As I said it seems to be something wrong with ACR..  If I use the exiftool then it works.

[g3gg0]

When I use that build on 12 bit mlv's, I'll get 14 bit dng's 

vs.

Input file is 12 bit mlv, output file is a single frame 14 bit mlv

do we talk about the MLV -> MLV(averaged) script that produces 14 bit files
or about DNG conversion which is 14 bit only yet?

[g3gg0]

@Danne  No Go!
As I said it seems to be something wrong with ACR..  If I use the exiftool then it works.

is it better with '--no-fixcp --no-stripes' ?

[Danne]

@Renatophoto.
This command can,t work which you put up.

Code: [Select]

mlv_dump --dng --black-fix=204 -o %Input%.raw %Input%.mlvYou can,t even create a new MLV with another black level. In case it would have worked it would look like this.

Code: [Select]

mlv_dump --black-fix=2048 -o Output.MLV Input.MLV
It only works when spitting out dng files. Try exactly what I put out here.

Code: [Select]

mlv_dump --dng --black-fix=2048 INPUT.MLV
If still not working upload part of you mlv file

@Levas

Input file is 12 bit mlv, output file is a single frame 14 bit mlv

I thought this was to be expected, especially since g3gg0 updated code so all bits(10/12/14) would work with the 14bit code in mlv_dump?

[RenatoPhoto]

Danne: I tried your suggestion and it does not work.
g3gg0: I tried but no luck either.

I think it something related to my system and ACR.  I will use exiftool to do the black level correction until it is fixed directly on the mlv_rec.mo

[Levas]

@Geggo

MLV conversion to dng's gives 14bit dng's even with 12 bit mlv's.
So 12 bit MLV gives 14 bit dng frames
Doesn't matter if average is used or not, always end up with 14 bit dng's

The MLV_dump build I used before, 20 November 2016 build, gave 12 bit dng's or 10 bit or 14 bit, depending whatever bit depth the mlv file was recorded.

[g3gg0]

so MLV averaging produces the correct format, right?
i am asking because you reported the generated MLV has 14 bits although it should have 12 bits.

DNGs are *always* 14 bit in the branches i know. maybe you used mlv_dump builds from other sources.
do not know about the pending PR if it would produce 12bpp DNGs

[DeafEyeJedi]

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

Agreed!

[RenatoPhoto]

3X resolution testing  of latest dfort:  magiclantern-raw_video_10bit_12bit.2017Jan05.5D3123

In liveview (zoom 3x) the ML Grey Scale preview flickers when selecting aspect ratios beyond 16:9 i.e 1.85:1, 2:1, etc

Using cinnema ratios like 2.35:1 In liveview (zoom 3x) in ML Grey Scale preview the areas above and below the video, which should be black, have images (lines here) on the right half of the screen.  see below:



With big resolutions I get some bad frames:

3008x1320:


3520x1320:


Best Regards,
Renato

[RenatoPhoto]

3X resolution testing  of latest dfort:  magiclantern-raw_video_10bit_12bit.2017Jan05.5D3123

Also ML Grey Scale turns to Canon preview while recording..

[Levas]

@Geggo

so MLV averaging produces the correct format, right?

Yes, the resulting average MLV has the right format, the average MLV is 12 bit, when input MLV is 12 bit.

Only thing new to me was that when extracting dng's, it gives 14 bit dng's no matter what the input is, 10/12 or 14 bit.
I was used to a MLV_dump which gave dng's in the same bit depth as the recording was.

[budafilms]

I made a test with a card Tone 14/12/10 bits
5d Mark III 1.1.3
Build January 5

I hope this can be usefull for the comunity.

Full info into the video.

[MitchLally]

I made a test with a card Tone 14/12/10 bits
5d Mark III 1.1.3
Build January 5

I hope this can be usefull for the comunity.

Full info into the video.

Is this before or after the black level fix posted by A1ex above for 10 bit files. It is supposed to remove the purple colour cast in 10 bit.

[budafilms]

I didn't apply any correction, no black level 2048 in 5d Mark III.
But if @a1ex need a new test I can make it again!

[Danne]

Here is the latest version of mlv_dump with g3gg0 latest commits. It,s vital to specify black level.
https://bitbucket.org/Dannephoto/magic-lantern/downloads/mlv_dump

Source: https://bitbucket.org/hudson/magic-lantern/commits/75f61f30b6e2a6fb1a136d538b8fe190919024a9?at=unified

Specify like this if working with a 5D mark III
mlv_dump --black-fix=2048 --dng your.MLV
Correction:
mlv_dump --black-fix=2040 --dng your.MLV

[a1ex]

... 2040

[Danne]

Thanks, corrected.
WHat is the black level number for 12bit? The same as for 10bit?

[Tracerman]

Hi,

I've tested 10bit and 12bit mlv_rec on the 550D : magiclantern-raw_video_10bit_12bit.2017Jan05.550D109

10 bit recording is indeed eagerly awaited on this platform, because 1280x544(2.35) at 23.98 fps makes about 20MBps
which is the maximum rate I can get from it (SandDisk 64Gb ExtremePro) so its pretty cool
big thanks to the ml devs, it gives a new life to this (ok rather old) camera but with (it seems) a lot of users still ...

I tested it in this configuration, recording goes OK (green light!) but when I try to read back it's not quite OK yet
(I've tried with mlv_play on the camera (with raw_twk loaded), with mlvfs on Linux and mlvproducer on Win7 with the same result) :

In 10 bit mode : it seems that 1 frame out of 2 is in fact the 1st recorded frame, and the other has problems on the top third of the frame.

In 12 bit mode : every frame is split vertically in 2 and offset in time and/or vertically (I can post another video if you need).

14 bit mode is all OK but recording stops after a few seconds (buffer full).

If I can be of some help in testing just let me know, having at least 10bit mlv_rec working would be awesome !

Thanks !

[budafilms]

@a1ex @danne

Yes it works! 5d3.
No color pink/magenta and blue. Tested 10/12/14 bits

./mlv_dump --black-fix=2040 --dng M10-0135.MLV








image upload no limit