Messages

Then we have to stick to the original int thing

But the color level is still 2^14 >> 2^12 or >> 2^10, right? Mighty developers

int x; // 14 bit number, in a 16/32 bit format
x = (x +2) / 4; // rounding closer to normal rounding, not CPU binary world.

// x is 12 bits now

2 => 1; 3 => 1; 4 => 1; 5 => 1; 6 => 2; 7 => 2; 8 => 2;

Double is 64 bit, and by now is totally fine on modern CPU. But for raw handling in our Canons we need more integer performance for packing all this raw data into something more space efficient. Floats, though, are nice to have at times too.

I don't understand your code very much.

ARM9 has 16 32bit floating units, let us assume that a double calculation costs 4 times more time to calculate than a float calculation, then the 16 32bit floating units' efficiency is like 16/4 = 4, so it can mean that there are 4 double's running at the same time, that can be translated to 4 frames at the same time. If all the calculation costs around 16-32 CPU cycles per frame(including time waiting for CPU's task scheduling), the CPU should by far have enough power to process 24fps in real-time. I reckon. So my modification should work, theoretically.

Why don't you just divide by 4? Which would be similar to bit shift by 2 bits >>

Bit shift was handy since the 80286 era, when x*320 was = x <<  8 + x << 6. But since then mul and div became very cheap.

Granted, if your integer isn't right alinged (least mening bits) you have to bit shift more to the right, and then back to the left. Masking would do the job too, but would require either a register or mem op.

BTW, according to spec ARM9 has 16 32bit MAD units, should be more than capable of basic integer math, no?

EDIT:

I see, you probably are trying to get a better rounding. For that purpose you can ADD/SUB something, prior to dividing. But dividing and then multiplying a double number won't give you the result, it is caled a floating number, for a reason. There is a set of specialty rounding operations for doubles. However, I doubt double operations are fast on such hardware.

What I worried was that accuracy problem, using int might not be accurate enough, and if the data were too small, divide by (2^14) might make it unusable at all, so I change it to floating point, and, I worried that float might not be accurate enough too, so I wanted it to use double instead. Modern CPU might be fast enough to handle double, my wild guess. If not, you can still change to use float, that might be accurate enough already. But if I have got the full source code, I will definitely compile it into my way, before loading it to my camera, including meddling a bit with that raw.c too.

BTW, ARM9's 16 x 32bit MAD unit is in floating point to my understanding.

But if x is int, and it is divided by a very large number, it will change to value 0 perhaps,


so I would rather change it to:

int x; //YUV brightness grade

register double y = x; //temporarily change it to double precision

y = y / (2^14);
y = y * (2^12);

x = y; //change the value back into int

What do you say developers?

Or the other way:

int x = x * (2 ^ 12);
x = x / (2^14);

Another maybe immature thought. 14bit color in raw video actually means 2^14 grade brightness, according to wiki.  So the 14bit to 12bit conversion seemingly should be:

int x; //brightness grade

x = x / (2^14);
x = x * (2^12);

Now things start to make sense to me.

Just my 2 coins.

It's just the compression ratio, it's the same for width and the whole image buffer. (to tell fwrite how much to write).

@mucher: not sure if you're serious, but all your assumptions are wrong... 

I know nothing about camera, nothing about programming, but only waiting too anxiously to see when this good ML stuff will come to 7D(for me a jpg sequence is perfectly fine, because it is picture style compatible--so one does not have to correct the clips' color one by one, and jpg sequence can be true color full resolution too)

I have noticed another thing:

static int buffer_size_compressed = 0;

If  buffer_size_compressed is divided by 14, the result is in float point, you might need to change it back to int. That is a pain in the axx thing too I guess.

I might be wrong.

buffer_size_compressed = (buffer_size_used * 12) / 14;

I don't know what is this, but if it changes to:

buffer_size_compressed = buffer_size_used  / 14;
buffer_size_compressed = buffer_size_compressed * 12;

It might have higher accuracy, I heard that some CPU cannot multiply too many times, or very soon it will have accuracy problem.

HA, I have been messing around. I quit.

Or simply changes to:
buffer_size_compressed = (buffer_size_used / 14) *12;

Because if buffer_size_used is something big, *12 might make it very big, making it difficult to be divided by 14, so I think that it might be better to divide first, and then multiply. But this trick might not work anyway.

buffer_size_compressed = (buffer_size_used * 12) / 14;

I don't know what is this, but if it changes to:

buffer_size_compressed = buffer_size_used  / 14;
buffer_size_compressed = buffer_size_compressed * 12;

It might have higher accuracy, I heard that some CPU cannot multiply too many times, or very soon it will have accuracy problem.

HA, I have been messing around. I quit.

I don't know programming much. But it sounds to me that the program itself stalled itself and exit somewhere(or suspended by the OS), my wild guess.

Using -16 flag in ML's menu, I got around 12mb/s bitrate,  only slightly more than the stock around 11mb/s bitrate, but the artifacts in screen are lookingly less than the stock bitrate.

This is beautiful. Thank you very much, and I will try it when I have time.

Thanks for the white paper. Good exercise for the brain.

Here I've found a link to convert DNG to tiff first, saidly, Resolve can open the tiff sequence.

http://www.completedigitalphotography.com/?p=521

For me, it is seemingly the write process uses DMA bypassing the CPU, so any EOS should be able to do that RAW "Video" shooting regardless of the CPU speed, so long as  the CF/SD card supports the writing speed. So I wish one day that I can see this raw video feature appear on 7D. Cannot use picture style is a disappointment but the stunning details and high DR making the pictures looking very real, so it is worth it to go that extra mile I guess.

if the raw video is enable, I calculate that it will be producing 500m/s plus bitrate, which is bigger than most 4:4:4 cinema cameras I suppose, and it will be hugely demanding for the CF card and HD and post-processing. For the moment,  this raw output feature is veryvery nice, but I still wish to see than it can be compressed someway, or that 4:2:2 video file output will be better for me.

Surely if the Blackmagic Pocket Camera is going to be writing 1080p Cinema DNG to an SD card then the write and read speeds of cards we have already shouldn't be a problem?

as far as I know, that BPC uses a lossless compressed format:CinemaDNG 12bit RAW, that will take a processor that can compress the file in real-time, obviously 5d2, 5d3 and 7d or likes do not have that ability built-in.

I can see the color band in the sky in the video captured by 7D, so I am very sure 7D's video capture capacity is 8 bit color depth in the output end, which means that in the footage/clip, the video color depth is 8bit wide(total 256 grade grey tone)

Provided that the LV is 32bit and the hardware h.264 process is not 8 bit wide, anything capture at the LV can pass through into a video will be way better in color depth

I think for now the safest bet will be either: capture can turn it into small jpg files on the fly and jam them through into the CF card, or, jam the capture video through the camera's hardware encoder(get your fingers crossed that the camera's hardware encoder is not 8bit wide, but I dont think that it is likely so)--anything, 4:2:2, 4:4:4 or 4:2:0. Either way you will get better results than it is now.

7D is not UDMA6 bounded (UDMA7 compatible), so its CF writing bandwidth is limited 133mb/s, that should be around 1000x CF, I believe that there is no way one can jam through anything by raw video mode through to the CF card, even the CF card is 4000x CF and I don't think the 5D2 or 5D3 will be able to exceed that CF card performance enough to write video raw into a CF card. I personally see no reason to look into that direction.

Or, one can use a HDMI recorder...

i am still working on YUV422 videos (continuous 12.5 fps works already).
i think it is able to record in RAW also, but first i want to get YUV422 working flawless.
will test it on 7D as soon it works on 5D3

Comparing with 4:2:0, 4:2:2 sounds like exactly 2 times more calculation to me (I don't know very well about video encoding), I am just wondering that if there is any ways to split the task into the two processors. Will it be possible to turn on some multi-threading flags in the compiler ( I heard a rumor that in Windows, you can use the -safethread flag to enable parralel threading, or some like that.

Another thought. If the developers can add silent pic to 7D, and take the screen dump like 24fps, then I can later convert the dump to jpg, and use jpg to create an avi file, then import to software to process(I can crop the clip into 16:9 in video editing software I hope) -- so all the developers need to do is to add a 24 fps interval timer. Or...port the dump the silent video to h.264, that will save me some work.

The current 7D video is so bad, which doesn't match with its jpg capture very much in many ways(black point, white point,...)

I would mind to donate money for that function because it can enlever my 7D's video capture capability.

Honestly, I was wonding if it was possible to feed the buffer into the "crappy" hardware h.264 encoder, it might get a better result than the current one.

One ideal resolution is asking Canon to develop a new video format by adding jpg files together and, with a timeline built in, making it a video, then the 7D's two DIGIC4 processor can be used, which might be able to make it fast enough for 2k@24fps.

Just thinking out loud.