Welcome to our community

Be a part of something great, join today!

Register 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 :)

Any chance for Cineform Export on Windows?

Axel Mertes said:
One very big difference between our Converter and the CineForm own R2CF tool is the way the color is interpreted:

While CineForm wants to keep everything "sensor flat" to provide maximum fidelity in further post, it thereby ignores simply all settings in the RED metadata, be it while recorded or from custom RMD files. So in the end most users are disappointed with the results, as they did not match what they have seen on-set or in RED CINE-X. While technically CineForms approach is OK, its not the best decision for the user experience in this particular case

Our Converter instead uses all the RED metadata information to process the final CineForm DPC, AVI and MOV files with exact those colors your expect. And clearly with full 12 bit CineForm depth, way enough to handle 16+ bit data in a log format, better than standart DPX files in most cases.

We will shortly provide demo versions of the Converter for interested people. You can mail me if you are interested.


Axel
Click to expand...

Likely my own limitation but I've never been able to achieve the quality of color through Cineform tools that I see with Redcine-X. To have access to the CineForm codec and the sophistication of FirstLight 3D tools with the color from my RMD files sounds like the holy grail to me.

I would be very interested in working with the demo of your Converter when it is available. Axel, please check your PMs.
 
Oh I believe,
You guys are pretty clever....

Just surprised that's all
 
So you are calling the command line version of RCX with a GUI, right Axel ?
A good tool to automate that, like a little render manager.
How much ?
 
Les Dittert said:
So you are calling the command line version of RCX with a GUI, right Axel ?
A good tool to automate that, like a little render manager.
How much ?
Click to expand...

Hi Les,

no - we do not call RCX with a GUI. We use the CineForm SDK and the RED SDK and our software reads R3D including all your RMD settings (so pregrading in RED CINE-X is recommendet, not to say "mandatory"). The conversion is send to our own network rendering engine (which needs no configuration at all, just start the exe file on each machine, you may even mix MACs and PCs). It makes a proxy or full deBayer, depending on your settings and creates a CineForm DPC sequences (aka DPX-C) or e.g. CineForm Quicktime MOV file (including timecode!) with your desired settings that you can use in post. The difference over using orignal R3D files is blank speed. You need a ROCKET to come close in terms of speed, but will never match the quality of Graeme's magic software deBayer algorythm, which is kept in the CineForm RGB444 files at faster decoding speed than R3D software decode.

So IMHO this workflow is the better option for many users that won't do a offline/online workflow, but work on final quality out of the beginning. An additional computer for transcoding may be cheaper and of more use than the ROCKET for some users, thinking very tight budgets here and there. But we can even use the ROCKET, no problem, if you are fine with the results. The point for us is that having a ROCKET in each workstation would be way to expensive and unaffordable for most users (we have over 30 machines here). Our approach has a much lower total price tag, a good alternative for small shops or independent film makers. You may have one or few ROCKETs for a very quick transcoding, though, if that is desired.

When dealing with visual effects scenes (VFX) we can only recommed working in DPC format, which lets your systems run on steroids throughput wise without the high cost of uncompressed workflows, racks full of disks, ingest, playout, archive cost etc.

I can give more details on our workflow soon, just preparing for release of some tools first. Stay tuned.

Price is not yet fixed, we will have a decision soon.

Cheers,
Axel
 
axel,

can you also re-bayer to cineform raw?
much smaller filesize then 444...a nice option to have at least
 
Mike Harrington said:
axel,

can you also re-bayer to cineform raw?
much smaller filesize then 444...a nice option to have at least
Click to expand...

Yes - we can!

We can actually perform a re-bayer on any image, even those not coming from a sensor. To get best results one needs to know which of the four possible options for the Bayer pattern orientation is to be used. Maybe we can auto-detect at some point, but for RED for instance its known. That function is in all our CineForm related tools, such as the Converter, CineForm for Fusion or CineForm for Nuke.

Its good thing for emulating camera stuff etc. or when you really need very small files for some reasons (such as playback of 4K via Gigabit Ethernet). I'd prefer RGB444 in most cases, as it simply retains obviously more of the original image. On the other hand it can be useful if you want to use third party deBayering methods such as those provided in CineForm or even in SpeedGradeDI via GPU (these soon surely among Adobe products). THAT is more interesting to me.

Send me a link to an R3D and I can convert it for you in all interesting format variations, such as using RMD file or camera orignal, using RGB444 or RAW, using different quality options etc., so you have something you can play with and get an idea.

Regards,
Axel
 
when do you expect to have a demo?

with this tool....effectively you are saying we can get redgamma 3 curves via your tool and cineform before we can get it natively in adobe?
that is pretty cool

I am just starting a project now, and was not sure if I would go native Red or cineform converted Red....but if this gives me RedGamma3 that may change it for me.
 
We are working on the demo for FinalDCP and the current installer is aimed to have the demo for the Converter all along, its the same core technology at work.

We are counting hours already, so I think there is chance you can play around with it during easter times.

We have the latest RED SDK in, so RED Color 3 is supported. Maybe I should use a clip, apply the values and share it here? Maybe tomorrow!

Press thumbs!

Axel
 
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.




Axel Mertes said:
Yes - we can!

We can actually perform a re-bayer on any image, even those not coming from a sensor. To get best results one needs to know which of the four possible options for the Bayer pattern orientation is to be used. Maybe we can auto-detect at some point, but for RED for instance its known. That function is in all our CineForm related tools, such as the Converter, CineForm for Fusion or CineForm for Nuke.

Its good thing for emulating camera stuff etc. or when you really need very small files for some reasons (such as playback of 4K via Gigabit Ethernet). I'd prefer RGB444 in most cases, as it simply retains obviously more of the original image. On the other hand it can be useful if you want to use third party deBayering methods such as those provided in CineForm or even in SpeedGradeDI via GPU (these soon surely among Adobe products). THAT is more interesting to me.

Send me a link to an R3D and I can convert it for you in all interesting format variations, such as using RMD file or camera orignal, using RGB444 or RAW, using different quality options etc., so you have something you can play with and get an idea.

Regards,
Axel
Click to expand...
 
Last edited:
Les Dittert said:
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.
Click to expand...

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
 
Axel Mertes said:
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
Click to expand...

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.
B002_R046_0218RR.0000005b.jpg
 
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 said:
Here is the r3d.

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

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

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

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
 
Tom Lowe said:
I have no idea of the politics of this, but this would be very useful to me.
Click to expand...

I agree! I'm sure someone will have to mediate this... but it would be awesome!
 
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
 
The CineForm SDK is restricted to 12 bit, so its technically impossible as of now to have a 16 bit CineForm file.

However, CineForm is real 12 bits, and if you use a log encoding curve, you can easily store an equivalent of 16..20 bits in 12 bits log - if you consider that a 10 bit log DPX was examined "fine" for representing 16 bit linear data...

With our encoder we convert from 16 bit linear R3D decoding into 12 bit log CineForm or CineForm RAW encoding.


One important point:
Going from RED R3D RAW to CineForm RAW is possible. However, in most cases I'd recommend to use R3D full deBayer into CineForm RGB 444 FS2 or FS1 instead. It gives you the better quality and higher performance. Its clearly bigger in size (about 2.5 times on average if I remember correctly) but decodes significantly faster (except in SpeedGrade, which handles the deBayer on the GPU).

We did a lot of post production using CineForm, especially in native 4K or UHD. So did we the "Götter wie wir" god comedy series. See here a bit of the workflow:

http://www.reduser.net/forum/showthread.php?86748-URGENT-quot-G%F6tter-wie-wir-quot-airing-in-german-zdf-kultur-and-ONLINE-in-for-one-week

We also often use our converter, which allows us to extract just selected take footage (with adjustable head and tail) using RED R3D and RMD support, directly into CineForm (both RAW and RGB, with any setting you like).


We also made a lot of tests that demonstrate that 1000 iterations in CineForm RGB 444 FS1 or FS2 or FS3 is by far better quality than the very first generation of RED ROCKET uncompressed output... Think about this in post.
If someone is interested, I can show the examples.

Cheers,
Axel
 
You must log in or register to reply here.
Back
Top