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

[1%]

Nope.. feel free to try, I'm not the best coder... guy should have really provided source... may 14th is hella old and slow.

[Greg]

I guess I'll find out?

http://pastebin.com/PviXPWNZ

It is saving files... I don't see any increase in speed but maybe a few extra frames... I think the change is still incomplete.

Pink garbage when I open them

Second shot had image cut up into squares like lv_rec used to do when it was out of sync.

On the 500D:
tcc : error: undefined symbol 'raw14_to_raw12'   

[1%]

Did oyu add the struct to raw.h? also link the .o in the makefile.

[Mayo]

Nope.. feel free to try, I'm not the best coder... guy should have really provided source... may 14th is hella old and slow.

I don't have all the required libs installed for this (And i really should be in bed right now), but in raw2dng.c

Code: [Select]


struct raw12_pixblock
{
        unsigned int c_hi: 8;
        unsigned int b: 12;
        unsigned int a: 12;
        unsigned int f_hi: 4;
        unsigned int e: 12;
        unsigned int d: 12;
        unsigned int c_lo: 4;
        unsigned int h: 12;
        unsigned int g: 12;
        unsigned int f_lo: 8;
} __attribute__((packed));

int raw_get_pixel(int x, int y) {
    struct raw12_pixblock * p = (void*)raw_info.buffer + y * raw_info.pitch + (x/8)*12;
    switch (x%8) {
        case 0: return p->a;
        case 1: return p->b;
        case 2: return p->c_lo | (p->c_hi << 8);
        case 3: return p->d;
        case 4: return p->e;
        case 5: return p->f_lo | (p->f_hi << 8);
        case 6: return p->g;
        case 7: return p->h;
    }
    return p->a;
}
If anyone wants to try 

[1%]

Gonna try it on the file I made already

[Greg]

Did oyu add the struct to raw.h?

Yes 

also link the .o in the makefile.

No 

[1%]

First one came out as pink shit with modified raw2dng.

Some of the frame pieces do come out... so it is kinda working.

[d]

It looks like I accidentally uploaded an old, broken version of rawc.o. The correct, working version is now at the same URL. If you downloaded it before this reply went up you will need to re-download and and re-link it. Sorry about that.

Also, I noticed a mistake in the example raw_get_pixel posted earlier. The correct shifts for pixels C and F are:

Code: [Select]

raw->c_lo | (raw->c_hi << 4);
raw->f_lo | (raw->f_hi << 8);

[tin2tin]

This is just... wow! The perspective of this is just incredible. Thank you for investing your time in this.

[a1ex]

Impressive.

[tin2tin]

What is the 12/10 bit speed of 720p? Would this be usable for SD cards?

[Andy600]

It looks about 25% reduced cool

@a1ex - have you shot anything with compression? How's it looking?

[vicnaum]

What is the 12/10 bit speed of 720p? Would this be usable for SD cards?

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?)

[squig]

Settle, settle, this development is only like 13 hours old, the little swimmers are still trying to find their way to the egg. 

[a1ex]

I didn't shoot anything with it, only ran the benchmark. Right now I have no idea whether the algorithm is correct. You need an additional task to prepare the buffers, so the raw processing should become a pipeline, like this:
- source raw to cropped raw: via EDMAC, triggered from LiveView (EVF) task
- cropped raw (14-bit) to 12-bit raw
- file write task

[tihon]

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?)

That so you can write 2.5k with 44 MB/s card? (10bit)) It can give a new live to mark 2

I think that it can be possible to wite a  2350x1100px on 5dm2 in 1:1 mode  with 12bit

[vicnaum]

That so you can write 2.5k with 44 MB/s card? (10bit)) It can give a new live to mark 2
I think that it can be possible to wite a  2350x1100px on 5dm2 in 1:1 mode  with 12bit

44 MB/s is 1.922.389 bytes per frame @24fps, or 1.537.911 pixels in 10bit - that makes something around 1660x930px frame.

[t2scorp]

44 MB/s is 1.922.389 bytes per frame @24fps, or 1.537.911 pixels in 10bit - that makes something around 1660x930px frame.

Meaning that resolutions up to 2240x1260 @ 24fps at 83MB/s and 1920x1080 @24fps at 62MB/s should be possible?

[a1ex]

No, according to the benchmarks.

[Andy600]

This is great news for the 50d. It should be able to record all it's available frame sizes unrestricted 

[savale]

Cool stuff! Don't know how to understand the benchmarks. Is that the "needed" bandwidth because of the less needed bits, or is it the actual bandwidth because of the extra calculations needed? (in that case the bandwidth is too low?)

I really want to look at the raw14_to_raw12 and raw14_to_raw10 methods, where can I find them?

[nanomad]

They are inside the .o file d provided. In ARM ASM code once you de-compile it

[eyeland]

This is one of the threads that will wear down my F5 key ...

[AnotherDave]

Do we know if this could be applied to higher resolutions than 1080p, or would the camera not be able to handle it?

[AdamTheBoy]

I'm pretty much a lamen, but it looks like you guys are figuring out how to retain the quality of RAW but save on space? This is such wonderful news.  So this means we may have longer record times and if the frames are a smaller size, fewer dropped frames?

Thanks to everyone involved, it's always exciting to see what people are achieving here.