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

Started by d, May 22, 2013, 10:58:34 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Mayo

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

IliasG

Quote from: Mayo on May 23, 2013, 07:23:20 PM
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)
0201 0300 0100 0000 0E00 0000
0102 (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:

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
[size=2]phreekz * blog * twitter[/size]

vicnaum

Quote from: JohnBarlow on May 23, 2013, 07:14:06 PM
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.

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;
    }
*/
}


Quote from: chmee on May 23, 2013, 07:36:30 PM
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)
0201 0300 0100 0000 0E00 0000
0102 (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:

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. 
[size=2]phreekz * blog * twitter[/size]

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!

Quote from: vicnaum on May 23, 2013, 07:38:29 PM
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

raw_info.bits_per_pixel=12;
raw_info.white_level *= 0.25f;
    raw_info.black_level *= 0.25f;


And now the file opens ACR  ;D



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

Quote from: Mayo on May 23, 2013, 08:25:29 PM
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:

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

Quote from: Mayo on May 23, 2013, 09:03:15 PM
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:

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
I'm using ML2.3 for photography with:
EOS 600DML | EOS 400Dplus | EOS 5D MLbeta5- EF 100mm f/2.8 USM Macro  - EF-S 17-85mm f4-5.6 IS USM - EF 70-200mm f/4 L USM - 580EXII - OsX, PS, LR, RawTherapee, LightZone -no video experience-

Mayo

Quote from: scrax on May 23, 2013, 09:15:51 PM
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 :P
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

Quote from: Kunibert on May 23, 2013, 01:05:01 AM
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

Quote from: Mayo on May 23, 2013, 09:03:15 PM
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:

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

Quote from: Mayo on May 23, 2013, 09:22:55 PM
I've been a lone coder for 4-5 years now, and became a bit oblivious to source control :P
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

Quote from: vicnaum on May 23, 2013, 11:30:48 AM
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.  :P 

Mayo

Quote from: jordancolburn on May 23, 2013, 09:57:26 PM
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 :P
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

Quote from: Mayo on May 23, 2013, 10:18:23 PM
Well, that looks nice and easy :P
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.
I'm using ML2.3 for photography with:
EOS 600DML | EOS 400Dplus | EOS 5D MLbeta5- EF 100mm f/2.8 USM Macro  - EF-S 17-85mm f4-5.6 IS USM - EF 70-200mm f/4 L USM - 580EXII - OsX, PS, LR, RawTherapee, LightZone -no video experience-

g3gg0

Quote from: Grunf on May 23, 2013, 09:38:40 PMIf 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
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

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?
50D, 5D3

Mayo

Quote from: trsaunders on May 23, 2013, 11:59:58 PM
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:

/**
* 14-bit encoding:

hi          lo
aaaaaaaaaaaaaabb
bbbbbbbbbbbbcccc
ccccccccccdddddd
ddddddddeeeeeeee
eeeeeeffffffffff
ffffgggggggggggg
gghhhhhhhhhhhhhh
*/



Quote from: scrax on May 23, 2013, 10:25:37 PM
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