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

[Mayo]

If only d posted his post-process workflow, this would be easier

[IliasG]

Right, I found it, had to overwrite raw_info.bits_per_pixel=12; in raw2dng.

Now the image is good, only the colors are messed up.

Looks like this in irfan view (doesn't open in ACR):

http://i.imgur.com/lsMeEFO.jpg

(It's the bottom of a (very dirty) window)

You also have to adapt the Black Level & White Level to 12 bit ..

[chmee]

Open the DNG-File in a Hex-Editor (recommending HxD).
Search for the BitsPerSample-Tag 0102 - think it will be on Position ~1BC
(there will be two entries, because the thumbnail needs this tag as well)

Code: [Select]

0201 0300 0100 0000 0E00 00000102 (or in little-endian 0201) and later on there is 000E (14Bit) -> 0E00. change that.

You find the Whitelevel and blacklevel with the tag-id's C61A and C61D, some bytes after the BitPerSampleTag. Example:

Code: [Select]

1AC6 0400 0100 0000 F807 0000 <-->07F8 = 2040
1DC6 0400 0100 0000 2E2D 0000 <--> 2D2E = 11566
Lower both. For Example Blacklevel to 1000 and Whitelevel to 4000.


mfg chmee

[vicnaum]

Is this sRGB or ADobe RGB?

RAW is beyond these. It becomes sRGB or Adobe RGB when exporting (baking) from bayer raw to RGB in any Raw Converter (ACR, Lightroom, etc).

[Mayo]

Modified reverse_bytes_order() for words instead of half-words in chdk-dng.c ,it's a bit better now.

Code: [Select]

static void FAST reverse_bytes_order(char* buf, int count)
{
long* buf32 = (long*) buf;
    int i;
    for (i = 0; i < count/4; i++)
    {
        long x = buf32[i];
buf[4*i+3] = x;
        buf[4*i+2] = x >> 8;
        buf[4*i+1] = x >> 16;
        buf[4*i] = x >>24;
    }
/*
    short* buf16 = (short*) buf;
    int i;
    for (i = 0; i < count/2; i++)
    {
        short x = buf16[i];
        buf[2*i+1] = x;
        buf[2*i] = x >> 8;
    }
*/
}

Open the DNG-File in a Hex-Editor (recommending HxD).
Search for the BitsPerSample-Tag 0102 - think it will be on Position ~1BC
(there will be two entries, because the thumbnail needs this tag as well)

Code: [Select]

0201 0300 0100 0000 0E00 00000102 (or in little-endian 0201) and later on there is 000E (14Bit) -> 0E00. change that.

You find the Whitelevel and blacklevel with the tag-id's C61A and C61D, some bytes after the BitPerSampleTag. Example:

Code: [Select]

1AC6 0400 0100 0000 F807 0000 <-->07F8 = 2040
1DC6 0400 0100 0000 2E2D 0000 <--> 2D2E = 11566
Lower both. For Example Blacklevel to 1000 and Whitelevel to 4000.


mfg chmee

Will try this now.

[chmee]

ah. Forgot to say. AFAIK the Preview-Jpg is hardcoded on 14Bit-Transcode. Rename the .dng to .tif and look what the viewer is throwing out. 

[1%]

Yep and then post a workable source for the mods so we can try it out in one fell swoop.

If its good will need depth selection for raw2dng/rawrec... I think you could even do silent pics this way too. 8-14 bit.

Real compression I think manipulates the whole image.

[Mayo]

Almost there.



Now to find

1). where the black/white levels are wrongly set in chdk-dng.c
2). why the DNG file won't open in ACR

[JohnBarlow]

Thanks!

RAW is beyond these. It becomes sRGB or Adobe RGB when exporting (baking) from bayer raw to RGB in any Raw Converter (ACR, Lightroom, etc).

[Mayo]

Wow, simply lowered black and white (*0.25f) in raw2dng before it exports

Code: [Select]

raw_info.bits_per_pixel=12;
raw_info.white_level *= 0.25f;
    raw_info.black_level *= 0.25f;
And now the file opens ACR 



I think I'm done here...
1%, I'll send you my modified src files, I trust you can tidy it up and merge with yours?

[AnotherDave]

So what does mean for getting it up and running on the 5D3?  :-)

[bumkicho]

I think I'm done here...
1%, I'll send you my modified src files, I trust you can tidy it up and merge with yours?

Does it mean 12bit or 10bit raw is coming sometime very soon?

[Mayo]

Well, I didn't touch 10-bit, but it should be fairly easy to add.

Here are the modified src files: https://docs.google.com/file/d/0Bw98R-sUdECPZkpjQ2RPWi1yVjQ/edit?usp=sharing

12-bit is currently hardcoded with the variable:

Code: [Select]

static int raw_bitdepth = 12;
...which should be set via a RAW menu option and exported in the RAW footer to be retrieved by raw2dng and processed accordingly.

[scrax]

Well, I didn't touch 10-bit, but it should be fairly easy to add.

Here are the modified src files: https://docs.google.com/file/d/0Bw98R-sUdECPZkpjQ2RPWi1yVjQ/edit?usp=sharing

12-bit is currently hardcoded with the variable:

Code: [Select]

static int raw_bitdepth = 12;
...which should be set via a RAW menu option and exported in the RAW footer to be retrieved by raw2dng and processed accordingly.

why don't you open a fork on bitbucket instead of google drive? It will be easier to follow (and learn from) your changes

[Mayo]

why don't you open a fork on bitbucket instead of google drive? It will be easier to follow (and learn from) your changes

I've been a lone coder for 4-5 years now, and became a bit oblivious to source control
I had a look at the tragic lantern bitbucket (https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/commits/all) but i'm terrified to fuck up things for you guys... If you can quickly teach me how to commit my changes, i will gladly do it.

[Grunf]

As far as i know the Digic 5+ is a modification of this core:
http://www.arm.com/products/processors/classic/arm9/arm946.php?tab=Specifications

Well as long as Arm 946 supports NEON, there is a neat quad-word SIMD shift instruction that is potentially able to do shift to 10 bits for one whole RGB pixel in one instruction:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHEDCEG.html

In that case, there is even more speed to be gained. If not, we need to check into "Enhanced DSP instructions" which seems to be onboard on 946 for sure:
http://infocenter.arm.com/help/topic/com.arm.doc.dvi0022a/DVI0022A.pdf

[bumkicho]

Well, I didn't touch 10-bit, but it should be fairly easy to add.

Here are the modified src files: https://docs.google.com/file/d/0Bw98R-sUdECPZkpjQ2RPWi1yVjQ/edit?usp=sharing

12-bit is currently hardcoded with the variable:

Code: [Select]

static int raw_bitdepth = 12;
...which should be set via a RAW menu option and exported in the RAW footer to be retrieved by raw2dng and processed accordingly.

I would try 12bit to see if it works properly first. Then we can move onto adding 10bit. Well, I say "we" as if I am actually contributing anything to this development. Ha ha. Sorry. I meant I hoped you could.

[jordancolburn]

I've been a lone coder for 4-5 years now, and became a bit oblivious to source control
I had a look at the tragic lantern bitbucket (https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/commits/all) but i'm terrified to fuck up things for you guys... If you can quickly teach me how to commit my changes, i will gladly do it.

Here's a really good Mercurial tutorial http://hginit.com/
I think most of the devs use it and I use it at work and for my own projects like my resume in LaTex and others.  Merging is a little strange at first, but it will make your life SO much easier in the long run.

[tin2tin]

In theory, SD cards can give 22MB/s or 961194 bytes per frame. 1280x600 in 10 bits gives 960000 bytes.

In practice - we need a working build to test it (was the latest one 1% posted - the working one?)

Can't wait to hear if 1280x600 in 10 bits really is possible, so Cameras with SD cards only can benefit from the latest RAW magic.   

[Mayo]

Here's a really good Mercurial tutorial http://hginit.com/
I think most of the devs use it and I use it at work and for my own projects like my resume in LaTex and others.  Merging is a little strange at first, but it will make your life SO much easier in the long run.

Well, that looks nice and easy
Seriously though, the changes are really minor: just do a find 'raw_bitdepth' and all my changes are there (except for reverse_bytes_order() which is terribly hardcoded). If someone who's already setup can look through them it would be much safer than me fucking things up.

[scrax]

Well, that looks nice and easy
Seriously though, the changes are really minor: just do a find 'raw_bitdepth' and all my changes are there (except for reverse_bytes_order() which is terribly hardcoded). If someone who's already setup can look through them it would be much safer than me fucking things up.

I think that quick way to share the code without any risk is, once installed hg, register yourself on bitbucket, go to magic lantern source and fork the repo, you will have your fork on bitbucket pubblic so any change you made will not screw anything in the ML source.
Once done the fork you have to download it on your pc (I use a GUI for managing those forks, SourceTree), make your changes and with "hg pull" update it on bitbucket.
When you are done with all your work you can submit from the fork page on bitbucket a pull request to the ML source, that way it will be reviewed before merging it.

[g3gg0]

If not, we need to check into "Enhanced DSP instructions" which seems to be onboard on 946 for sure:

this is for ARM946E-S vs. ARM946E which we have

but i didnt verify

[trsaunders]

I'm wondering: how is the RAW data (on the camera, before it is copied) aligned? is it 14bits with two zeros packed in 16 bits, or is each pixel packed tightly together?

[Mayo]

I'm wondering: how is the RAW data (on the camera, before it is copied) aligned? is it 14bits with two zeros packed in 16 bits, or is each pixel packed tightly together?

It's tight:

Code: [Select]

/**
* 14-bit encoding:

hi          lo
aaaaaaaaaaaaaabb
bbbbbbbbbbbbcccc
ccccccccccdddddd
ddddddddeeeeeeee
eeeeeeffffffffff
ffffgggggggggggg
gghhhhhhhhhhhhhh
*/

I think that quick way to share the code without any risk is, once installed hg, register yourself on bitbucket, go to magic lantern source and fork the repo, you will have your fork on bitbucket pubblic so any change you made will not screw anything in the ML source.
Once done the fork you have to download it on your pc (I use a GUI for managing those forks, SourceTree), make your changes and with "hg pull" update it on bitbucket.
When you are done with all your work you can submit from the fork page on bitbucket a pull request to the ML source, that way it will be reviewed before merging it.

Thank you. I did all this, let's see how it goes.

[SonicVibe]

Mayo, thanks for your work on this.

I think they meant for you to fork the magic lantern repo and not tragic lantern, which is already a fork of magic lantern.

https://bitbucket.org/hudson/magic-lantern