Welcome to our community

Be a part of something great, join today!

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

REDRAY Comments

Paul Harb said:
Proprietary :badputer:
Click to expand...

You mean CineForm?
Not as much as ProRes and DNxHD. The latter two are definetly proprietary when you look at the contract side behind.

CineForm, however, is currently being standardised as VC5 by SMPTE (the codestream, not the metadata part). That changes a LOT.
And CineForm is DEFACTO the ONLY cross-plattform codec for single frames (DPC, aka. DPX-C) and streaming files in MOV and AVI containers (all can be cross-converted by copying bitstreams, not re-encodes).
Due to being purely wavelet, CineForm is on par with JPEG2000 with a ~15% data rate drop in favor of ~7 times faster speed.
And CineForm has 12 bits, RAW, YUV and RGB, Alpha, Linux, Windows, MAC OSX, 3D, selectable DaBayer, FIrstlight, log, lin, 4K, 8K, 10:1 size reduction without visible artefacts ...

Show me any other codec that is somewhere "close" to what CineForm does NOW.

Just because RED and CineForm didn't partner up on the RED ONE development doesn't mean its a bad codec. And many things have changed since.

The iterative recompression stability of CineForm is AMAZING. I personally helped sorting out the latest bugs there 2 years ago. You can do 1000 recompressions iteratively and have less than 0.01% change in your image...

Btw, CineForm has different compression qualities, so you can get quite decent quality up to lossless if required.

The only point is that the codec itself isn't improved much since the acqusition by GoPro. However, it IS quite feature complete and still ahead of the competition.
 
Gunleik Groven said:
LOL!

Aft breaking them down (not the Cineform), I allways thought THAT was DNX(HD)

They share the "powdery" degradation, at least...

QUOTE]
Gunleik, can you clarify that "powdery degradation"? I often see things that fit the description, but don't know if what I see is what you mean.
Click to expand...
 
Axel Mertes said:
You mean CineForm?
Not as much as ProRes and DNxHD. The latter two are definetly proprietary when you look at the contract side behind.

CineForm, however, is currently being standardised as VC5 by SMPTE (the codestream, not the metadata part). That changes a LOT.
And CineForm is DEFACTO the ONLY cross-plattform codec for single frames (DPC, aka. DPX-C) and streaming files in MOV and AVI containers (all can be cross-converted by copying bitstreams, not re-encodes).
Due to being purely wavelet, CineForm is on par with JPEG2000 with a ~15% data rate drop in favor of ~7 times faster speed.
And CineForm has 12 bits, RAW, YUV and RGB, Alpha, Linux, Windows, MAC OSX, 3D, selectable DaBayer, FIrstlight, log, lin, 4K, 8K, 10:1 size reduction without visible artefacts ...

Show me any other codec that is somewhere "close" to what CineForm does NOW.

Just because RED and CineForm didn't partner up on the RED ONE development doesn't mean its a bad codec. And many things have changed since.

The iterative recompression stability of CineForm is AMAZING. I personally helped sorting out the latest bugs there 2 years ago. You can do 1000 recompressions iteratively and have less than 0.01% change in your image...

Btw, CineForm has different compression qualities, so you can get quite decent quality up to lossless if required.

The only point is that the codec itself isn't improved much since the acqusition by GoPro. However, it IS quite feature complete and still ahead of the competition.
Click to expand...

Axel, as you have worked with them, maybe you can answer a question for me. I have been suspicious that the acquisition of cineform and the movement to standardisation, might mean they are planning a go pro or still/video camera on cineform? I was around at the very beginning of cineform bayer, when David came up with it. Back then it was getting extremely good compression with Bayer. I think 6:1 was near lossless, plus bayer was already 3 times smaller than 4:4:4. It would be very suitable for a camera like the go pro or handheld still or video. Cineform was one of the greatest losses to the camera industry of it's time. The still, and the pro video, had no effective answer for raw. If I was bmc, or ambarella, or even Sony (the scheme should be adaptable to custom sensor patterns) I would arrange something straight away.

Anyway, expanding the theory a bit. Cineform were quickly developing a mini tablet like field recorder based on fpga, which design should easily fit on an asci in a gopro hero like camera these days. Not only that, I wonder if some ambarella camera chipsets have the configuration to be programmed to do cineform raw, they certainly would have the silicon foundry access for a custom design.

Thanks Axel.
 
Rob McDonough said:
Gunleik, can you clarify that "powdery degradation"? I often see things that fit the description, but don't know if what I see is what you mean.
Click to expand...

I haven't bothered to do anything than grade and render.
So I guess that what you see is as good as anything I see. But there's some kind of "grainb-like" powdery stuff happening in the lowlights after a couple of renders and that goes from the lows into the rest of the image.
But I find it a lot more pleasing than traditional macroblocs...

Graeme is the right man to answer, but even when talking with the head image-ingeneer at the Broadcastcorp during a session where codecs were tested, that's just what we refered to it as, as that was what we all saw (and I am seeing right in this minute...)
 
Wayne Morellini said:
Axel, as you have worked with them, maybe you can answer a question for me. I have been suspicious that the acquisition of cineform and the movement to standardisation, might mean they are planning a go pro or still/video camera on cineform? I was around at the very beginning of cineform bayer, when David came up with it. Back then it was getting extremely good compression with Bayer. I think 6:1 was near lossless, plus bayer was already 3 times smaller than 4:4:4. It would be very suitable for a camera like the go pro or handheld still or video. Cineform was one of the greatest losses to the camera industry of it's time. The still, and the pro video, had no effective answer for raw. If I was bmc, or ambarella, or even Sony (the scheme should be adaptable to custom sensor patterns) I would arrange something straight away.

Anyway, expanding the theory a bit. Cineform were quickly developing a mini tablet like field recorder based on fpga, which design should easily fit on an asci in a gopro hero like camera these days. Not only that, I wonder if some ambarella camera chipsets have the configuration to be programmed to do cineform raw, they certainly would have the silicon foundry access for a custom design.

Thanks Axel.
Click to expand...

Hi Wayne,

you mix something up here. CineForm made a *proposal* for a FPGA based CineForm encoder, but never actually implemented it. We had been discussing such development with them, but at that time overall resources were too limited to accomplish the task. However, its not out of question that someone is working on something like this - it would still make a lot of sense.

All the other codecs are simply nowhere near the option set of CineForm. And codecs such as ProRes, which is still mainly an Apple-only thing including gamma issues, are IMHO not the right alternatives. DNxHD is evolving, but its DCT based as far as I know and therefor will never be as efficient as Wavelets are.

The BIGGEST point that most users out there miss is the FACT that with wavelets you can decode a lower resolution at full quality with less resources. Neither DNxHD nor ProRes can do this. The latter codecs are fine if your system keeps up. But in 4K you need to fully decode all 4K images or drop frames. With wavelets you can decode at lower resolutions, saving serious processing resources. That is IMPOSSIBLE with any DCT based codec.

So when you view a wavelet based file at 1/4 size (1/2 width, 1/2 height), you see a perfect 4:1 downscale, averaging 4 pixels 4K resolution into 1 pixel 2K viewing resolution. Its not skipping lines or rows or anything else. Its just *perfect* quality downscale. This is the amazing nature of wavelets.

Cheers,
Axel
 
Axel Mertes said:
…codecs such as ProRes, which is still mainly an Apple-only thing including gamma issues, are IMHO not the right alternatives.
Click to expand...

ProRes does not inherently have gamma issues. The issues are with QuickTime itself, so Cineform can have gamma issues too if used in a QuickTime wrapper.

I have seen serious gamma and levels related issues with QuickTime wrapped Cineform files from a Cinedeck Extreme.

Equally I have designed ProRes based pipelines which had no gamma issues whatsoever.
 
Gavin Greenwalt said:
DPX is good, but half-float EXR would be welcome too.
Click to expand...

The problem with EXR is that it is linear to light, and does not define what the display transfer function (VLUT) should be.

ACES EXR would be ok, since that has (or will have once finalised) a defined conversion to display space. Whether you like that conversion is another debate altogether…

Here is the same EXR viewed through three different, but equally valid, VLUTs.

EXR_LUTs.png


And these are all just 1D display LUTs. Colour space conversion adds a whole other later of complexity.
 
Nick Shaw said:
The problem with EXR is that it is linear to light, and does not define what the display transfer function (VLUT) should be.

ACES EXR would be ok, since that has (or will have once finalised) a defined conversion to display space. Whether you like that conversion is another debate altogether…

Here is the same EXR viewed through three different, but equally valid, VLUTs.

And these are all just 1D display LUTs. Colour space conversion adds a whole other later of complexity.
Click to expand...


I assume that REDRay also has a defined output colorspace. And I assume it can be configured somewhere in the REDRay output settings. If I'm outputting to a Rec709 display I would hope I can choose the gamma of my display output in the HDMI settings. Similarly if I'm attaching to a computer display calibrated for sRGB I would hope that I could specify that in REDRay (Like Nuke's viewer). I would assume that cineon DPXs are getting ingested and transformed into rec709 or similar.

Speaking of ProRes. Someone posted this handy dandy chart.

http://www.stopp.se/lab/wp-content/uploads/2012/12/Stopp_ProRes_Test_Chart.pdf
 
Can I get cineform in a avi wrapper or is it in mov?
 
Gavin Greenwalt said:
I would assume that cineon DPXs are getting ingested and transformed into rec709 or similar.
Click to expand...

I was assuming the opposite! I was imagining that DPXs for the .RED encoder would not be Cineon, but would be in display space, and have any required LUTs baked into them. Again there is no one defined transform to go from Cineon to e.g. Rec709.

But you know what they say about assuming!

Rob… Graeme… ?
 
Joel Arvidsson said:
Can I get cineform in a avi wrapper or is it in mov?
Click to expand...

CineForm can be either single frames (DPC, aka DPX-C) or as streaming files in an AVI or MOV container.
You can rewrap a CineForm AVI to become a CineForm MOV file and vice versa.

Was that what you wanted to know?
 
Nick Shaw said:
ProRes does not inherently have gamma issues. The issues are with QuickTime itself, so Cineform can have gamma issues too if used in a QuickTime wrapper.

I have seen serious gamma and levels related issues with QuickTime wrapped Cineform files from a Cinedeck Extreme.

Equally I have designed ProRes based pipelines which had no gamma issues whatsoever.
Click to expand...

Hi NIck,

yes and no. Yes, if using CineForm files through the Quicktime engine itself you may encounter the very same gamma shift issues you can experience with basically EVERY Quicktime codec out there.

However, in our pipeline we relay in may apps on plugins (mostly our own) that read Quicktime MOV files without the need of having Quicktime installed at all. We read the MOV files natively, bypassing any Quicktime engine. Due to that, we have no gamma issues there as Quicktime is completely bypassed.

I am not sure we could do the same with ProRes, as its not that open to us. OK, there are open implementations now, but the question is always if there is any reliable legal background for e.g. the FFMPEG implementations.

But you are totally right - it depends on the workflow and the tools you use.
 
Nick Shaw said:
ProRes does not inherently have gamma issues. The issues are with QuickTime itself, so Cineform can have gamma issues too if used in a QuickTime wrapper.

I have seen serious gamma and levels related issues with QuickTime wrapped Cineform files from a Cinedeck Extreme.

Equally I have designed ProRes based pipelines which had no gamma issues whatsoever.
Click to expand...

OK - question for you, Nick: have you ever hit gamma issues with an Avid DNxHD wrapped in a QuickTime?

I haven't, which is kinda amazing. And also why I am excited about a 4K DNxHD format...

Bruce Allen
www.boacinema.com
 
If you use Animation compression with quicktime it also doesn't shift gamma. So it's definitely possible to implement color stable quicktime codecs. That being said... except for uncompressed and Animation (LZW) I haven't seen many codecs. I've had a couple cases with DNxHD shifting.
 
You must log in or register to reply here.
Back
Top