Any chance for Cineform Export on Windows?

[Axel Mertes]

Axel, I asume you are ' re-bayer-ing' by doing the SDK de-bayer with Red's demosaic, and then sampling that to stuff the 4 color planes into Cineform RAW ?

If so, this still crushes out some detail from the image, as the Red SDK , ala their demosaic looks like a Gaussian blur 0.5 applied to the red rocket outputs.

I have encoded Red R3D as true Cineform RAW with the real 4 bit planes , before red demosaic. I am still looking for an easy way to do it, however, as it is a slow process.

edit: I have no intentions of offering this as a product ever.

Hi Les,

I am not sure I got you completely understood.

We actually do a full debayer using RED SDK, then we have an RGB image with several color pixels being "invented" by the RED SDK debayer. We throw those away and remain with those that have been seen by the sensor, so a G1 R B G2 representation for example.

Clearly this is not exactly the same as REDs internal RAW data, but as they closed that approach in the past, its the only way remaining. The good point is, that this virtual RAW image contains already final color rendition from the RED SDK, so its quite ok.

Still I recommend using RGB444 instead, except you really need smaller files or different deBayer filters (such as sharp for contours / keying, but soft for inner image data like skin).

Do you say you can bypass RED's deBayer to access their RAW data?
Thats not possible anymore, as to my knowledge with the SDK at all.
If you really can access the original RAW data prior to deBayer, then it should be a fairly fast process.

And what do you mean the image looks like a 0.5 gaussian blur being applied to the ROCKET output?
I'd say you might just witness the different quality between software deBayer and the ROCKET deBayer...

Regards,
Axel

[Les Dittert]

Hi Les,


Do you say you can bypass RED's deBayer to access their RAW data?
Thats not possible anymore, as to my knowledge with the SDK at all.
If you really can access the original RAW data prior to deBayer, then it should be a fairly fast process.

And what do you mean the image looks like a 0.5 gaussian blur being applied to the ROCKET output?
I'd say you might just witness the different quality between software deBayer and the ROCKET deBayer...

Regards,
Axel

Yes, the SDK is what it is . I did not use it.

Indeed: Take the Red Rocket image, blur it with Gaussian blur... presto , you have the SDK style output !

ps: Did you notice when you run the SDK at max detail and sharpness there are math errors that cause out of place dark or bright pixels ?
This happens on contrasty edges. a few pixels will get much darker than they should.
This should be looked into.

300% blowup below, see the obvious 'odd' pixel values. This is not noise, the values are way off statistically to be noise, if you know what I mean.

[Axel Mertes]

Hi Les,

this sounds interesting. Can you mail me via axel.mertes -at- magnamana -dot- com?
We haven't yet seen such artefacts in the RED footage, but - we are picky - I would like to learn about the details and check footage that we have here.

Regards,
Axel

[Les Dittert]

Here is the r3d.

You have to sharpen a lot to see the odd pixels.

http://dl.dropbox.com/u/61349012/B00...R.0000005F.R3D

edit: Above blowup is the cord hanging into window.
grab is from 'A channel ' of HDRX.

[Axel Mertes]

Here is the r3d.

You have to sharpen a lot to see the odd pixels.

http://dl.dropbox.com/u/61349012/B00...R.0000005F.R3D

edit: Above blowup is the cord hanging into window.
grab is from 'A channel ' of HDRX.

Hi Les, all others,

here some sample conversions done in various CineForm format options like AVI, MOV, DPC (when renaming to DPX you can see the thumbails in DPX compatible software, sometimes without renaming).

We can get as low as around half the size of the original RED file when using CF RAW Filmscan2, which is already very good. But we do have uncompressed RAW, if anyone is picky... :)
A CF 444 Filmscan1 or Filmscan2 is roughly 50%-70% larger than the original RED R3D file, but full RGB and MANY times faster to decode.


Here is the link to the archive:

http://dl.dropbox.com/u/22067399/Les.zip

Best regards,
Axel

[Curt Pair]

I have no idea of the politics of this, but this would be very useful to me.

I agree! I'm sure someone will have to mediate this... but it would be awesome!

[Axel Mertes]

Hi All,

regarding our converter it would be interesting which kind of functionality you'd like to see.
Right now we do not plan to build a second RED CINE-X, so pregrading etc. should be performed there (no need for re-inventing wheels) and results should be saved as RMD files. These can already be processed by the SDK and therefor our converter.
But there are other things which we could implement, such as scaling / cropping / padding or simply support for EDL, XML, AAF or the like.

So it would be very interesting to hear your workflow ideas to make a tool that fits the needs better.

Regards,
Axel