Red file conversion at DVinfo.net

Geoff Gartside · February 21st, 2010, 01:33 PM

Just realised when re-reading the First Light manual that the de-bayer filter is only applicable to CineForm RAW files.

So I'm wondering what kind of de-bayer filter is applied when you convert R3D files to CineForm HD 2K (YUV 422) using the script?

David Newman · February 21st, 2010, 01:46 PM

Red's debayer is part of the R3D SDK.

Mike Harrington · February 21st, 2010, 03:14 PM

Unfortunately the only debayering of R3D is done through reds debayerer, there are no other options at the moment.
You can debayer and re-bayer to cineform raw through the r3d to CF raw script...then you can use the various real time cinefrom debayer methods, this is much smaller filesize then cineform 4k but needs a little bit of horsepower

Geoff Gartside · February 21st, 2010, 06:23 PM

Thanks for the quick responses.

Does it mean that by upgrading to Prospect 4K and using CineForm RAW I will get better de-bayering performance from FL and, being able to stay with RGB 444 format, see a further quality improvement, even at 2K?

David Newman · February 21st, 2010, 06:47 PM

CineForm RAW is not 444, is in CFA Bayer RAW. We can convert R3D RAW to CineForm RAW at the native resolution (2K, 3K, 4K etc. -- you don't scale RAW.) Once in CineForm RAW you do get to control the Demosaic, and we do think extra flexibility from the demosaic is part of making your images look the best.

Kaspar Kallas · February 22nd, 2010, 01:23 AM

Hi

Let me get this straight, to get RED RAW to CF RAW the image is first de-bayered by RED SDK then the RGB image from that is again bayered in CF?
That dose not sound too good......

Thank You
-Kaspar

David Newman · February 22nd, 2010, 01:36 AM

Yes if you don't under the science, however we can exact the original CFA bayer alignment, and we did user tests and no one could pick (correctly) original from extracted. With extracted you have files almostly one third the size and choice over demosaic during post, not much of a compromise.

Mike Harrington · February 22nd, 2010, 11:15 PM

kasper...
if you think about it, the bayer pattern of the sensor would be known...
and for a given pixel...it would have RGB values. only one of those channels is native to a particular pixel. during demosaicing the other color channels are interpolated into the pixels which do not contain those values

If the given pixel was in a position known to be under the Green bayer sensor filter, you could just subtract the red and blue channels and be left with the origional Green...
because there should be no sharpening or other cross pixel enhancements the origional recorded value for that pixel can be precisely determined

I have run my own comparasons between R3D raw and CF raw converted from R3d raw, and there is no real discernable difference. And I compared them by layering the images over one another and cropping one...you cannot tell where one begins and the other ends.

There would obviousely be another pass of wavelet compression from the origional sensor data...but that is pretty well visually lossless.

It would be better and faster if Red gave others access to do the debayering through the SDK though....but this is a very viable workflow.

Geoff Gartside · February 23rd, 2010, 01:52 AM

Mike, this CineForm Tech note explains the process, as you describe it, for Mac workflow, I hope that it's the same for Windows: http://techblog.cineform.com/?p=2397

Extract
".... We’ll get slightly geeky on you for a moment, but it’s important to realize that back-sampling to uncompressed RAW extracts the original Bayer samples from your R3D recording prior to the Red DeBayer process. To understand this, you must first remember that a Bayer sensor is a grid of R, G, and B sensor sites. At each cell site there is only one pixel – either R, G, or B. When a DeBayer algorithm is performed it interpolates missing color information at each pixel location so the resulting pixel site has all three R, G, and B values. So for each R cell site new G and B values are computed (interpolated) by the DeBayer algorithm. Similarly for each G cell site new R and B values are computed. The output of the Red SDK provides traditional uncompressed RGB as computed by the Red DeBayer algorithm. Second, and this is important, a properly implementated DeBayer algorithm never changes the value of the actual pixel recorded at each cell site, it only calculates the missing values. This means that if you back-sample an RGB image to RAW (that was created by a DeBayer process) you are throwing away the computed values, but you retain the originally recorded pixel values (because the DeBayer algorithm did not alter them). This is what is being performed by CineForm’s back-sampling algorithm to restore the original uncompressed RAW data as recorded on the Red sensor. With the original uncompressed RAW data restored it is now possible to reencode into CineForm RAW...."

February 21st, 2010, 01:33 PM	#1
Geoff Gartside Regular Crew Join Date: May 2009 Location: Llangernyw Posts: 38	Red file conversion Just realised when re-reading the First Light manual that the de-bayer filter is only applicable to CineForm RAW files. So I'm wondering what kind of de-bayer filter is applied when you convert R3D files to CineForm HD 2K (YUV 422) using the script?

February 21st, 2010, 01:46 PM	#2
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	Red's debayer is part of the R3D SDK. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

February 21st, 2010, 06:47 PM	#5
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	CineForm RAW is not 444, is in CFA Bayer RAW. We can convert R3D RAW to CineForm RAW at the native resolution (2K, 3K, 4K etc. -- you don't scale RAW.) Once in CineForm RAW you do get to control the Demosaic, and we do think extra flexibility from the demosaic is part of making your images look the best. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

February 22nd, 2010, 01:36 AM	#7
David Newman CTO, CineForm Inc. Join Date: Jul 2003 Location: Cardiff-by-the-Sea, California Posts: 8,095	Yes if you don't under the science, however we can exact the original CFA bayer alignment, and we did user tests and no one could pick (correctly) original from extracted. With extracted you have files almostly one third the size and choice over demosaic during post, not much of a compromise. __________________ David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman

February 21st, 2010, 03:14 PM	#3
Mike Harrington Regular Crew Join Date: Jan 2009 Location: Edmonton, Canada Posts: 91	Unfortunately the only debayering of R3D is done through reds debayerer, there are no other options at the moment. You can debayer and re-bayer to cineform raw through the r3d to CF raw script...then you can use the various real time cinefrom debayer methods, this is much smaller filesize then cineform 4k but needs a little bit of horsepower

February 21st, 2010, 06:23 PM	#4
Geoff Gartside Regular Crew Join Date: May 2009 Location: Llangernyw Posts: 38	Thanks for the quick responses. Does it mean that by upgrading to Prospect 4K and using CineForm RAW I will get better de-bayering performance from FL and, being able to stay with RGB 444 format, see a further quality improvement, even at 2K?

February 22nd, 2010, 01:23 AM	#6
Kaspar Kallas Regular Crew Join Date: Oct 2007 Location: Estonia Posts: 142	Hi Let me get this straight, to get RED RAW to CF RAW the image is first de-bayered by RED SDK then the RGB image from that is again bayered in CF? That dose not sound too good...... Thank You -Kaspar

February 22nd, 2010, 11:15 PM	#8
Mike Harrington Regular Crew Join Date: Jan 2009 Location: Edmonton, Canada Posts: 91	kasper... if you think about it, the bayer pattern of the sensor would be known... and for a given pixel...it would have RGB values. only one of those channels is native to a particular pixel. during demosaicing the other color channels are interpolated into the pixels which do not contain those values If the given pixel was in a position known to be under the Green bayer sensor filter, you could just subtract the red and blue channels and be left with the origional Green... because there should be no sharpening or other cross pixel enhancements the origional recorded value for that pixel can be precisely determined I have run my own comparasons between R3D raw and CF raw converted from R3d raw, and there is no real discernable difference. And I compared them by layering the images over one another and cropping one...you cannot tell where one begins and the other ends. There would obviousely be another pass of wavelet compression from the origional sensor data...but that is pretty well visually lossless. It would be better and faster if Red gave others access to do the debayering through the SDK though....but this is a very viable workflow.

February 23rd, 2010, 01:52 AM	#9
Geoff Gartside Regular Crew Join Date: May 2009 Location: Llangernyw Posts: 38	Mike, this CineForm Tech note explains the process, as you describe it, for Mac workflow, I hope that it's the same for Windows: http://techblog.cineform.com/?p=2397 Extract ".... We’ll get slightly geeky on you for a moment, but it’s important to realize that back-sampling to uncompressed RAW extracts the original Bayer samples from your R3D recording prior to the Red DeBayer process. To understand this, you must first remember that a Bayer sensor is a grid of R, G, and B sensor sites. At each cell site there is only one pixel – either R, G, or B. When a DeBayer algorithm is performed it interpolates missing color information at each pixel location so the resulting pixel site has all three R, G, and B values. So for each R cell site new G and B values are computed (interpolated) by the DeBayer algorithm. Similarly for each G cell site new R and B values are computed. The output of the Red SDK provides traditional uncompressed RGB as computed by the Red DeBayer algorithm. Second, and this is important, a properly implementated DeBayer algorithm never changes the value of the actual pixel recorded at each cell site, it only calculates the missing values. This means that if you back-sample an RGB image to RAW (that was created by a DeBayer process) you are throwing away the computed values, but you retain the originally recorded pixel values (because the DeBayer algorithm did not alter them). This is what is being performed by CineForm’s back-sampling algorithm to restore the original uncompressed RAW data as recorded on the Red sensor. With the original uncompressed RAW data restored it is now possible to reencode into CineForm RAW...."