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 1 Guest are viewing this topic.

1%

You guys could be looking at the registers to see if 10bit can be made in camera.. there are functions like set_craw bits, etc. Just have to find the correct one.

vicnaum

Quote from: 1% on May 28, 2013, 02:50:00 PM
You guys could be looking at the registers to see if 10bit can be made in camera.. there are functions like set_craw bits, etc. Just have to find the correct one.

Could you tell please where can we look at these?

kgv5

Quote from: Northernlight on May 28, 2013, 01:01:30 PM

Q2: Do you at this point have any estimates of what the DNG file size could be eg. @1920x1080, should you succeed with 10bit RAW?
(I am just curious to where 10bit might take us in case of fps/resolution)

I have found this:

video bitrate calculator, shows frame size and bitrate with any resolution, framerate and bit depth.

http://web.forret.com/tools/video_fps.asp?width=1720&height=720&fps=24&space=raw&depth=14
www.pilotmovies.pl   5D Mark III, 6D, 550D

xNiNELiVES

There is a specific canon raw video calculator.  I forgot where I found it. Google magic lantern raw and go to news.  There's dome Germany website and on the website there is a link to use it.

Never mind here it is: http://www.slashcam.de/tools/ml-raw-calc.html

kgv5

Yep, but it doesnt have bit depth (or I cannot find this) so cannot compare 14 to 12 and 10 bits. This one I have found has this feature so we can calculate theoretical performance for 12 and 10 bit.
www.pilotmovies.pl   5D Mark III, 6D, 550D

Audionut

Guys, lets please stop with the, "oh wow with only 3 bit recording we can record 8k resolution" type posts, and please leave this thread solely for actual development discussion pertaining to the implementation of this feature.

Thanks.

inozcenterod

hello everybody im from VEN , basic knowedge of c++, how can I start with the ML 10 bits source, and if is possible to use some kind of lossles compression algorithm to minimize the size of data, or level up the cpu voltaje. (SORRY for my english)

1%

QuoteCould you tell please where can we look at these?

Look at regs touched by lv_save_raw and look for setcraw in strings.. there are 2 functions that set bits but it doesn't seem to be doing anything.

IliasG

Quote from: Northernlight on May 28, 2013, 01:01:30 PM
Hi, I came across this article reg. the Canon C500 and it's 10-bit RAW capabilites.
Not sure if this was relevant under this thread or under discussion of ETTR, but I found it interesting (and I am sure most you already know this).

http://nofilmschool.com/2012/11/canon-c500-shipping-raw-4k/

"Adding gain adjustments at the sensor level produces a consistent stop range above and below the middle grey level, even at high ISOs, and reduces the overall noise in the image."

As I understand this; Canon's RAW format is special in the sense that the C500 add gain at sensor level before outputting the RAW stream, is this in a way, approaching a little more to ETTR? (to improve DR and SNR)

Q1: Could this "approach" be possible to do also with the RAW module from ML ? (if you hopefully succeed with 10bit RAW!)

BTW! I have no chance to follow the technical discussion in this thread, but:
Q2: Do you at this point have any estimates of what the DNG file size could be eg. @1920x1080, should you succeed with 10bit RAW?
(I am just curious to where 10bit might take us in case of fps/resolution)

I wouldn't say Canon does this at the sensor Level, but at the Digic after digitization. There, they use the full 14bit depth to make calculations that a raw converter would have to do, which is problematic on 10bit data. They fight the problems described below

Quote from: IliasG on May 27, 2013, 06:04:27 PM
...., yes with 10bits raw bayer we need very careful rounding and even with careful rounding 10bits depth can be inadequate. While with RGB 10bits can be (and are) OK with raw Bayer "master" there is the need to apply some heavy manipulations not needed for the ready to use RGB file. Demosaic, WB (which is a 1+ stop digital amplification for the weak channel), Color transformation from Bayer R-G1-B-G2 TO RGB (once again about 1 stop amp for the weak channel)

But with a lookup table we can have untouched the low values (keep the sampling at the same density as the 14bit starting data) where the problem is significant and gamma encode the rest.

Canon say that:

- They have "baked" in raw the ISO.
Well, in photo mode, Canon 5DIII has the ISO fully "baked" in raw for analog ISO settings (100, 200 ... 12800, no gaps in raw histograms) and partially for intermediate and expanded ISOs where its mixed analog-digiral (we can see gaps in the raw histograms).
So do Sony (and others with Sony sensors) but it happens that they stop analog ISOs lower (1600 is usual).
BlackMagic uses only the base analog gain and every ISO higher than the basic is just a metadata flag (look for "Baseline exposure" in Exif)
Canon 1Dx uses analog ISO up to 51200 and for intermediate ISOs also. All raw histograms are without gaps so either it is analog ISO up to 51200 or the DAC digitize at 16bits and after 16to14bit conversion the histogram looks full (If I had to I'd put a bet on the second).  Maybe C500 goes up to same analog ISO also.

- They apply WB on the full bitdepth (14 or 16bit) raw data and then downconvert to 10bit. They gain accuracy this way and better tonality over all the range.
WB is in fact multipliers at each channel. For Canon's "Daylight" the multipliers are about R=2.0 G=1.0 B=1.5. The first thing a raw converter will do is apply these multipliers so the R & B channels will loose sampling density accordingly.

We could also "bake" a midway WB (say temp.4500K) in the proposed LUT but then we would need one LUT for each color and (if separate LUTs was possible) in the end any known raw converter would get crazy with WB/color transformations ... until someone decides to support the "crazy" ML-DNGs ..

- They use a log LUT on the 10bit output. This means they keep dense sampling where it counts (at the darks) and the sampling density decreases logarithmically as we go upright to the highlights. This way they can fit a 13-14 stop DR in 10bit log file.
It is the same we will do with the proposed 14 to 10bit LUT .. wish it is fast enough with the available resources ...

KMikhail

Quote from: IliasG on May 28, 2013, 07:58:49 PM
...
The best way to use 10 bit space is to calculate the topmost value for each channel of the RAW, record it elsewhere and align all channels to the 11111111111111b. Likely after applying 14 bit LUT for highlights compression, then cleverly getting rid of last 4 bits. In the post, upon conversion to a normal DNG (which in fact might have all information in the lower of 14 bits after shiftin channels back and appying inverse LUT!) opposite operations should be performed.

IliasG

Quote from: KMikhail on May 28, 2013, 08:22:42 PM.

I suppose you talk generally and assuming the available computation resources are enough, not like what ML has currently available ..

Just aligning to the topmost channel is in many cases ineffective as even a single specular highlight drives all channels to align at the White Level cutoff point. Take a look at raw histograms of many video-raw samples, it happens very frequently for either all chanells or the 2 of 3. And  this is usually the case of a high DR shot when we mostly need the best behavior.

g3gg0

another way could be:
- converting the 14 bit value into a CString by using sprintf and new CString(buffer)
- then using strlen to get the string length
- subtract 4 from that length
- copy that number of characters in an UTF-16 string
- code some utf16_atoi
- and save that value to CF card.

this can be done in VB too.

SCNR
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!

IliasG

@ g3gg0,

and .. will this be fast enough ?.

What we all wonder is ... if ML cannot find the lower bit-depth version ready from Canon (and this version can be of an acceptable quality or not at all ..), then which is the way to go ??

mucher

I cannot find that things mentioned in EOS SDK

1%


KMikhail

Quote from: IliasG on May 28, 2013, 10:17:01 PM
I suppose you talk generally and assuming the available computation resources are enough, not like what ML has currently available ..

Just aligning to the topmost channel is in many cases ineffective as even a single specular highlight drives all channels to align at the White Level cutoff point.

1) Generally, yes, aligning to the right might be not possible on the embedded cpu, though, could be done cleverly.
2) Nonetheless, that's the best way in general.

fotojohni

Isn't the camera converting to 8bit during h.264 encoding?  Maybe you could just grab it there.  Anyway, I believe this is missing link.  Made a 2 minute youtube vid and I ended up with hundreds of GB's of footage in various formats along my workflow production line.  10 bit is better for a lot of reasons.


Clemens

Is there some progress on this topic? Would really love to test a 10 or 12 Bit build and help you with some feedback.

xNiNELiVES


1%

The asm module wasn't fast enough... tried it.

xNiNELiVES

Quote from: 1% on June 04, 2013, 06:58:55 PM
The asm module wasn't fast enough... tried it.

So what does this mean.  It's not possible for live conversion to 12 bit?

1%

Yea, it just stopped working immediately.. it never flushed a single buffer. Maybe on 255M you'd get a decent string of frames.

fotojohni

I think someone may have mentioned simply truncating the lower (or upper) two bits of data.  It's a loss of 2-3 stops of DR, but maybe worth it for low DR scenes where you don't need that extra data anyway.  I actually run into this situation quite frequently.

Another option could be to truncate the U+V (YUV, I'm assuming) then do a better algorithm for Y channel, just a thought.

g3gg0

in raw data there is no YUV. its RGB. thats what is all about.
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!

vicnaum

Quote from: 1% on June 04, 2013, 07:21:08 PM
Yea, it just stopped working immediately.. it never flushed a single buffer. Maybe on 255M you'd get a decent string of frames.

So does it work slowly, or doesn't work at all? Maybe a buggy asm? If try at 320x240 or 160x120 res - is the concept working?

Maybe d's from canon, and he gave us an incomplete puzzle that we need to solve ourselves?
Or maybe d's from canon and he gave us a non working code sample so we lose our heart and don't try 10-12 bit raw again?