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 3 Guests are viewing this topic.

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

Quote from: 1% on May 23, 2013, 02:52:07 AM
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'   :o

1%

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

Mayo

Quote from: 1% on May 23, 2013, 02:59:37 AM
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



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


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:

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


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?
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

vicnaum

Quote from: tin2tin on May 23, 2013, 11:26:52 AM
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

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?)
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
Cinema, cinema, cinema

vicnaum

Quote from: tihon on May 23, 2013, 12:07:13 PM
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

Quote from: vicnaum on May 23, 2013, 12:30:47 PM
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  :)
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

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
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

eyeland

This is one of the threads that will wear down my F5 key ...
Daybreak broke me loose and brought me back...

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.