DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   Apertus: Open Source Cinema Project (https://www.dvinfo.net/forum/apertus-open-source-cinema-project/)
-   -   Elphel camera with Cineform RAW (https://www.dvinfo.net/forum/apertus-open-source-cinema-project/103145-elphel-camera-cineform-raw.html)

Serge Victorovich September 9th, 2007 03:40 AM

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.

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 (Post 741492)
(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

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

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

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


All times are GMT -6. The time now is 09:51 PM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2024 The Digital Video Information Network