Elphel camera with Cineform RAW at DVinfo.net

Serge Victorovich · September 9th, 2007, 03:40 AM

Elphel camera platform is flexible and OPEN!You can add any codec and another feature.
One codec for acquisition and editing - CineformRAW.
(Check 2k samples: http://www.siliconimaging.com/Digita...y_footage.html)

CineformRAW is the Best and highly optimized codec for Intel CPU.
(Jason Rodriguez said: Pentium D 3.0 Ghz was able to handle dual-stream RAW 4K/24P playback with a color-correction and title-overlay)

Now only one problem - we need to hire programmer who do porting the CineformRAW code to VHDL(verilog for FPGA).

Are you ready to pay deposit now and getting camera after NAB2008 ?

P.S. Year 2008. Any camcorder without CineformRAW is obsolete.
Before to buy camera - ask about possibility to record into Cineform RAW.

Richard Leadbetter · September 9th, 2007, 05:47 AM

As you know Serge, virtually everything I do involves CineForm, because as you say, it's the best. The question is, how much money do you envisage the camera costing? Part of the problem with R&D is that costs generally only ever go one way: up!

Serge Victorovich · September 9th, 2007, 07:26 AM

Richard, i think price to do R&D (port CineformRAW to VHDL) around $50K.

If only 100 people believe in this idea and can pay ahead $500-1000 we can start most amazing project than RED !:)
I'm personally ready to pay deposit for R&D, because i believe in David Newman and Andrey Philipov.

Because Elphel camera is modular and flexible you can order configuration with choice
any cmos image sensor from 1/3" to 1" and all desirable functions.
Now cost of Elphel 353 camera ~$800. With Cineform codec and 1/3" sensor ~$1000 without lenses, vf, monitor...
just like camera body of RED, but at very affordable price. We need also ask this question to David and Andrey.

Chris Swartz · September 9th, 2007, 04:31 PM

Wow, now if I only knew some programming. Sounds like a promising project. What codec does it capture to natively? MJPEG?

Chris

Jason Rodriguez · September 9th, 2007, 10:59 PM

Quote:

Originally Posted by Serge Victorovich

(Jason Rodriguez said: Pentium D 3.0 Ghz was able to handle dual-stream RAW 4K/24P playback with a color-correction and title-overlay)

BTW, Serge, while that demo at NAB did work, for dual-stream 4K, I would *not* use a machine that slow for a full-blown project . . . i.e., three clips on a timeline as a demo for one guy is not the same as 500 clips on a timeline and 1000 source media files in bins. The demo looked great, and is a wonderful demonstration of the speed and optimization of the CineForm codec, but that doesn't mean Premiere Pro itself will hold up under the strain of a full-blown 4K+ project.

For practical 4K editing, I would suggest something in the Core 2 Duo family as a minimum, but then again, a PC like that with a lower-end Core 2 Duo you can buy/build for like $800 right now (and then easily over-clock it up if needed).

But hey, I'm rooting for you guys . . . CineForm in a FPGA would be a very tasty package.

Serge Victorovich · September 10th, 2007, 09:07 AM

Jason, thank you for the additional information and these words:

Quote:

CineForm in a FPGA would be a very tasty package.

Biel Bestue · June 8th, 2009, 04:35 AM

why not try to do the same with Dirac? dirac is completely free

Andrey Filippov · June 8th, 2009, 07:18 AM

Yes, I do plan it for the model 373 camera that I'm working on now (Elphel Development Blog Andrey’s Journal). We'll first port the existent functionality, then - move to Dirac and higher performance sensors.

Andrey

Matteo Pozzi · June 8th, 2009, 07:52 AM

good news Andrey

Juan M. M. Fiebelkorn · June 8th, 2009, 12:13 PM

At last!!!!! great!!

Juan M. M. Fiebelkorn · June 8th, 2009, 07:52 PM

Please try to look into the DIRAC Pro branch, although I guess you'll need to create some slight variation for managing correctly Bayer mosaic data...

Steven Mingam · June 9th, 2009, 04:22 AM

Not too sure if Dirac is a very good idea at all

Sebastian Pichelhofer · June 9th, 2009, 11:46 AM

You have to differentiate between dirac (a consumer format) and dirac pro (as the name says: a format for professional video production).

Being developed by the BBC definitely is not a bad reference as well, of course it does not mean its unquestionable but it think its a good basis and don't forget it's open source.

Quoting: Optimised for professional production, Dirac Pro compresses high definition (HD) signals so they can be sent down standard definition (SD) circuits where HD infrastructure is not available.

The BBC Resources team will use it in Beijing at venues where it is unable to secure part or full HD links.

Dirac Pro provides virtually lossless compression and low latency as it squeezes 1.5 GBit per second HD SDI links into 270 MBit per second SDI.

Wikipedia:
Dirac employs wavelet compression, instead of the discrete cosine transforms used in most older codecs (such as H.264/MPEG-4 AVC or SMPTE's VC-1). Dirac is one of several projects attempting to apply wavelets to video compression. Others include Rududu[1], Snow, RedCode and Tarkin. Wavelet compression has already proven its viability in the JPEG 2000 compression standard for photographic images.

Steven Mingam · June 15th, 2009, 07:33 AM

Well I have to disagree (because I totally agree with what Dark_Shikari -one of the x264 developper- explained in the linked thread). Wavelets visually sucks, optimising PSNR at the expense of visual quality. Intra-coding scheme of H264 beats hands on JP2K (you can find some threads on doom9) at decent bitrate (wavelet are interesting when quality is not acceptable anymore and that's not really our goal here.)

Granted, Dirac is opensource but if there is any way to choose it, H264 is IMHO a better solution (and an industry standard)
(and well, JPEG is doing alright atm so I don't think it's the most important problem right now :))

Dan Hudgins · June 18th, 2009, 04:42 AM

H.264 is a medium for finished graded images, it is not a good medium for recording as a camera negative. I have done 35mm filmout tests from H.264 data and as still frames they do not look as bad as when moving. I have also dowe test 35mm prints with R3D data from the RED ONE, and from film scans. Uncompressed 24fps is the way to go to avoid non-filmlike artifacts that compression can introduce.

There is no reason why a 2.5K camera cannot record 24fps with true RAW sensor data, so you can process the frames to get the best quality and widest dynamic range.

Please see another post I made on this subject,

http://www.dvinfo.net/conf/apertus-o...ml#post1160076

Also true RAW senor data does not require a licence fee or restriction of any kind, and can be re-processed later with improvements to the de-mosaic filters to get improved results. Nothing is better than true RAW sensor data, it eliminates the need to upgrade the camera's firmware all your footage will always be as good as the sensor can deliver so long as the camera does not drop bits or frames.

You can convert the de-moasiced RAW data to any compressed format you want to use for editing, and still have an archive of the 1/3 size Bayer data for later use to get a higher quality render. The Bayer data can be delta encoded to reduce the archive file size for storage without any loss of quality.

I am developing full uncompressed NLE/DI/CC/MIX software for use with any source of frames, but am mostly interested in uncompressed true RAW sensor data to get the most film-like images on the 35mm print stock for uncompressed true 24fps projection.

Dan Hudgins
The official DANCAD3D (tm) Beta Test Web site.
tempnulbox [at] yahoo [dot] com

September 9th, 2007, 03:40 AM	#1
Serge Victorovich Major Player Join Date: Oct 2005 Posts: 376	Elphel camera with Cineform RAW Elphel camera platform is flexible and OPEN!You can add any codec and another feature. One codec for acquisition and editing - CineformRAW. (Check 2k samples: http://www.siliconimaging.com/Digita...y_footage.html) CineformRAW is the Best and highly optimized codec for Intel CPU. (Jason Rodriguez said: Pentium D 3.0 Ghz was able to handle dual-stream RAW 4K/24P playback with a color-correction and title-overlay) Now only one problem - we need to hire programmer who do porting the CineformRAW code to VHDL(verilog for FPGA). Are you ready to pay deposit now and getting camera after NAB2008 ? P.S. Year 2008. Any camcorder without CineformRAW is obsolete. Before to buy camera - ask about possibility to record into Cineform RAW.

September 9th, 2007, 05:47 AM	#2
Richard Leadbetter Major Player Join Date: Dec 2005 Posts: 323	As you know Serge, virtually everything I do involves CineForm, because as you say, it's the best. The question is, how much money do you envisage the camera costing? Part of the problem with R&D is that costs generally only ever go one way: up! __________________ Company Website: Digital Foundry Ltd Video Games HD Blog: Digital Foundry@Eurogamer

June 8th, 2009, 07:18 AM	#8
Andrey Filippov Major Player Join Date: Apr 2006 Location: Magna, Utah Posts: 215	Dirac Yes, I do plan it for the model 373 camera that I'm working on now (Elphel Development Blog Andrey’s Journal). We'll first port the existent functionality, then - move to Dirac and higher performance sensors. Andrey

June 18th, 2009, 04:42 AM	#15
Dan Hudgins Regular Crew Join Date: Feb 2009 Location: San Francisco, CA Posts: 82	Not H.264 PLEASE! H.264 is a medium for finished graded images, it is not a good medium for recording as a camera negative. I have done 35mm filmout tests from H.264 data and as still frames they do not look as bad as when moving. I have also dowe test 35mm prints with R3D data from the RED ONE, and from film scans. Uncompressed 24fps is the way to go to avoid non-filmlike artifacts that compression can introduce. There is no reason why a 2.5K camera cannot record 24fps with true RAW sensor data, so you can process the frames to get the best quality and widest dynamic range. Please see another post I made on this subject, http://www.dvinfo.net/conf/apertus-o...ml#post1160076 Also true RAW senor data does not require a licence fee or restriction of any kind, and can be re-processed later with improvements to the de-mosaic filters to get improved results. Nothing is better than true RAW sensor data, it eliminates the need to upgrade the camera's firmware all your footage will always be as good as the sensor can deliver so long as the camera does not drop bits or frames. You can convert the de-moasiced RAW data to any compressed format you want to use for editing, and still have an archive of the 1/3 size Bayer data for later use to get a higher quality render. The Bayer data can be delta encoded to reduce the archive file size for storage without any loss of quality. I am developing full uncompressed NLE/DI/CC/MIX software for use with any source of frames, but am mostly interested in uncompressed true RAW sensor data to get the most film-like images on the 35mm print stock for uncompressed true 24fps projection. Dan Hudgins The official DANCAD3D (tm) Beta Test Web site. tempnulbox [at] yahoo [dot] com

September 9th, 2007, 07:26 AM	#3
Serge Victorovich Major Player Join Date: Oct 2005 Posts: 376	Richard, i think price to do R&D (port CineformRAW to VHDL) around $50K. If only 100 people believe in this idea and can pay ahead $500-1000 we can start most amazing project than RED !:) I'm personally ready to pay deposit for R&D, because i believe in David Newman and Andrey Philipov. Because Elphel camera is modular and flexible you can order configuration with choice any cmos image sensor from 1/3" to 1" and all desirable functions. Now cost of Elphel 353 camera ~$800. With Cineform codec and 1/3" sensor ~$1000 without lenses, vf, monitor... just like camera body of RED, but at very affordable price. We need also ask this question to David and Andrey.

September 9th, 2007, 04:31 PM	#4
Chris Swartz Regular Crew Join Date: Jan 2006 Posts: 58	Wow, now if I only knew some programming. Sounds like a promising project. What codec does it capture to natively? MJPEG? Chris

June 8th, 2009, 04:35 AM	#7
Biel Bestue Regular Crew Join Date: Jul 2005 Posts: 96	why not try to do the same with Dirac? dirac is completely free

June 8th, 2009, 07:52 AM	#9
Matteo Pozzi Regular Crew Join Date: Jul 2005 Location: Milan, Italy Posts: 169	good news Andrey

June 8th, 2009, 12:13 PM	#10
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	At last!!!!! great!!

June 8th, 2009, 07:52 PM	#11
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	Please try to look into the DIRAC Pro branch, although I guess you'll need to create some slight variation for managing correctly Bayer mosaic data...

June 9th, 2009, 04:22 AM	#12
Steven Mingam Regular Crew Join Date: Aug 2004 Posts: 91	Not too sure if Dirac is a very good idea at all

June 9th, 2009, 11:46 AM	#13
Sebastian Pichelhofer Regular Crew Join Date: Jan 2007 Location: Vienna, Austria Posts: 112	You have to differentiate between dirac (a consumer format) and dirac pro (as the name says: a format for professional video production). Being developed by the BBC definitely is not a bad reference as well, of course it does not mean its unquestionable but it think its a good basis and don't forget it's open source. Quoting: Optimised for professional production, Dirac Pro compresses high definition (HD) signals so they can be sent down standard definition (SD) circuits where HD infrastructure is not available. The BBC Resources team will use it in Beijing at venues where it is unable to secure part or full HD links. Dirac Pro provides virtually lossless compression and low latency as it squeezes 1.5 GBit per second HD SDI links into 270 MBit per second SDI. Wikipedia: Dirac employs wavelet compression, instead of the discrete cosine transforms used in most older codecs (such as H.264/MPEG-4 AVC or SMPTE's VC-1). Dirac is one of several projects attempting to apply wavelets to video compression. Others include Rududu[1], Snow, RedCode and Tarkin. Wavelet compression has already proven its viability in the JPEG 2000 compression standard for photographic images.

June 15th, 2009, 07:33 AM	#14
Steven Mingam Regular Crew Join Date: Aug 2004 Posts: 91	Well I have to disagree (because I totally agree with what Dark_Shikari -one of the x264 developper- explained in the linked thread). Wavelets visually sucks, optimising PSNR at the expense of visual quality. Intra-coding scheme of H264 beats hands on JP2K (you can find some threads on doom9) at decent bitrate (wavelet are interesting when quality is not acceptable anymore and that's not really our goal here.) Granted, Dirac is opensource but if there is any way to choose it, H264 is IMHO a better solution (and an industry standard) (and well, JPEG is doing alright atm so I don't think it's the most important problem right now :))