Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Canon enables RAW video recording inc. 160fps @ 2k

I could see how those who only read the first part got suckered in. Well done and some good in-jokes too!

: )
 
But if you were to go "pure" RAW as I think your suggesting Dan, and even if they had a "RAW module" wouldn't that be A LOT of uncompressed data? I mean R3D files as it stands aint exactly the smallest and they are TOO heavily compressed but I can't imagine what a pure RAW file would be like...probably a heck of a lot though...

EDIT:
Same applying to if they opened up bandwidth for REDCODE surely that'd also lock out some of the options that are limited currently, CF Cards? HDD I think has just a few limitations compared to SSD but hardly anything that matters...
 
I installed the new firmware but all I get is Celine raw on the monitor.:blink:
 
Simultaneously I thought the joke means also that ALEXA is able to recording 4K onboard and on CF.
 
Ha ha ha ha ha ha! I just got "Dion-ed"
 
Dan Hudgins said:
Not having a true RAW module to tap out the Scarlet and Epic sensor data, leaves one way for other companies to make lower power use, lighter weight, cooler running Digital Cinema Cameras that also might give better image results under some conditions, or at least give less cooked in problems, like the blue spots the guy was complaining about (seems caused by not having the back balance done right before compression, if it had not been lossy compressed their would not have needed to have been a data loss, since the full sensor data would be there to re-adjust the black level in post, and do the dark field subtraction.)
Click to expand...

Dan, Jim announced a mathematically lossless version of REDCODE (2.5:1) last night.

Jannard said:
For those that missed my post on another thread... EPIC has a REDCODE mathematically lossless compression option (2.5:1) that records to onboard SSD module (not to CF).
Jim
Click to expand...
 
Zack Birlew said:
I don't like April Fools jokes period. This one is potentially dangerous though since there wasn't an "April Fools!" at the end of it, I hope nobody takes it seriously.
Click to expand...

Curious to know why you think it's dangerous?
 
Zack Birlew said:
I don't like April Fools jokes period. This one is potentially dangerous though since there wasn't an "April Fools!" at the end of it, I hope nobody takes it seriously.
Click to expand...

That makes it all the better!
 
Zack Birlew said:
I don't like April Fools jokes period. This one is potentially dangerous though since there wasn't an "April Fools!" at the end of it, I hope nobody takes it seriously.
Click to expand...

You are right. The Canon marketing team was probably in tissy - "Conference room everyone - ASAP!"
 
Lossless delta-encoding

Lossless delta-encoding

Justin O'Neill said:
Dan, Jim announced a mathematically lossless version of REDCODE (2.5:1) last night.
Click to expand...

Yes, April 1 2010. What is the link to that post?

See this page,

http://www.reduser.net/forum/showpost.php?p=564536&postcount=59

2.5:1 would be very hard to get with real sensor data without noise filtering which would make it not lossless.

Readout noise at 24fps in a real sensor makes ratios between 2:1 and 1:1 for Bayer data with typical ratios about 1.5:1 to 1.3:1 in my tests with low CPU overhead. If you optimize the word size then you can get a little better but with much more CPU power needed, although not as much as REDCODE needs perhaps.

It would be good to have lossless recording for 24fps shooting though which is 95% - 100% of what you use in a movie of traditional method. Just as DSLR give you a choice between "RAW" and JPEG.

REDCODE is a RGB wavelet compressed system (similar to JPG2000 without white balance before compression) so the more you increase the bandwidth you get to a point where it uses more bandwidth than delta-encoding and still introduces artifacts and burned in issues.

Drew Ingram said:
RED discusses how large these files would actually be without REDCODE here:
http://www.red.com/faq/what-is-redcode/
Click to expand...

Quote: [Without REDCODE, a 4K 24 fps information stream approaches two gigabytes per second.]

That must be talking about 4K RGB files rather than Bayer data, and should be edited to say so that it is not misleading, REDCODE seems to have the red and blue images at 1/4 resolution so is smaller than a RGB TIF file, if you had a 12bit RGB file with the un-equal red/blue and green resolution of R3D files it would be smaller and use less bandwidth.

(4096x2048x1.5 [G]) + (2048x1024x1.5x2 [R+B]) = 18.9MB*24=453.6MB/s or less than 0.5GB/s for RGB, Bayer data delta-encoded is less, and RGB delta-encoded would be less also on average.

Drew Ingram said:
And more info here:
http://www.red.com/faq/what-is-redcode-28-vs-redcode-36/
Click to expand...

Quote: [using less compression, would be beneficial for high detail or complex scenes.]

Imran Farouk said:
But if you were to go "pure" RAW as I think your suggesting Dan, and even if they had a "RAW module" wouldn't that be A LOT of uncompressed data? I mean R3D files as it stands aint exactly the smallest and they are TOO heavily compressed but I can't imagine what a pure RAW file would be like...probably a heck of a lot though...
Click to expand...

If REDCODE 42 is about 42MB/s and 4K delta-encoded data would average about 179MB/s then,

179/42=4.3x more for 2.35:1

229/42=5.5x more for 1.85:1

238/42=5.6x more for 16:9

If they could get 2.5:1 lossless then the ratio of improvement between the higher REDCODE rates used in Epic and the lossless rate get closer together until they become close to equal bandwidth for unequal quality and power use, at which point it is better not to use the wavelet compression at all, but to use delta-encoding to save the full sensor data.

Less than 6x the data is not beyond reach, Acam dII already outputs 2048x1092 DNG files with Bayer data. I have tested delta-encoding on Acam dII data in the de-Bayer program I am working on and it seems to return 100% of the image data, it checks using DOS FC command for zero errors.
 
Yeah, the 2.5:1 mathematically lossless record option isn't a joke. And it's not going to be cheap or for the faint of heart. For 5K 2:1 it's a bit over 180MB/s and will be recordable to a high-speed SSD option, presumably the 128GB (and larger) RED-MAG SSD.

On the bright side, lower compression ratios mean faster wavelet performance in many situations. A decent post workstation with a 220MB/s or faster disk system should have no trouble ripping right through this just as easily as lower bit-rate REDCODE 4K and 5K. The recordable media costs, additional online storage requirements and bandwidth in post will be a big consideration though.
 
2.5:1

2.5:1

Justin O'Neill said:
The link for the post is: http://www.reduser.net/forum/showthread.php?p=574842#post574842

Jim originally announced it around 3pm on March 31st so it is not an April Fools: http://www.reduser.net/forum/showthread.php?p=574807#post574807
Click to expand...

Thanks for the info, its not clear if that will be 100% of the sensor data or not, I was talking to someone who also use the phrase "mathematically lossless" but in fact it was lossy it seemed, the delta encoding I have been testing as a lower ratio of about 2:1 to 1:1 with about 1.5:1 being typical for average frames is actually lossless 100%.

At any rate, if they get "close" to saving all the Bayer data, will they have a DNG output as Bayer data (not the "Linear DNG" which is interpolated non-white balance data like a greenish TIF).

If Epic can output true Bayer DNG files, that would be great news over-all for getting the most quality out of the sensor without "baked in" problems from the wavelet based REDCODE options. Although the DNG spec says the bad pixels should be fixed before saving the data, its also good to have a true RAW option and save just the sensor data bad pixels and all to the DNG file's data area for later processing in software.

REDROCKET could be adjusted to work with true RAW data just as it does for wavelet compressed R3D data. The only change is that the true RAW data, bit packed 12 or 14 bits, would be in files about 6x as large, so there is some extra disk I/O on the input, but that will be less and less of an issue as HD speed and size go down, 1.5TB now go for less than $100 or so and in a few years TB will be the new GB.

As far as image quality goes, saving 14bit data as "log" into 12bit packed data would not degrade the images enough to notice I guess, so that would be a good option, save into 12bit packed DNG files, like Acam dII, but put a slight log curve or gamma adjustment to lift the shadows enough to take full advantage of the M-X lower noise, the 12bit packed data can be re-linearized for the debayer using 16bit works in the de-Bayer software later. Going from 14 bit linear 10bit log is not enough data, you need 12bits at the RAW archive point and give maximum grading range later without histogram gaps above the 9th bit.

The DNG filesize for 5K 12bit packed files (semi-log or gamma lifted) would be,

(5120x2178x1.5)+512 = 16.73MB per frame, or 402MB/s for archive. (41.4 minutes per TB)

The 2.5:1 frames would be smaller by some ratio, they did not say what they are using as the base size for uncompressed data, if that is 16bits per pixel or 14bits per pixel or 12bits per pixel, you can make the ratio look bigger using 16bits per pixel, but since the ADC is 14bits that is not the right base size to use for the reduction ratio of the encoding method.
 
You must log in or register to reply here.
Back
Top