Will the new cams do uncompressed stills?

[Stokestack]

Given the positioning of this modular system as "DSMC", I'd expect that they'd shoot uncompressed (or mathematically lossless) raw stills as other SLRs do.

Si?

Gavin

 

[Shane Nassiri]

Jim has posted such. I'm thinking there will be some sort of quality slider for best still performance depending on what FPS you are shooting at. Single shot stills being the best and burst or full motion modes being lower quality.

 

[Dan Hudgins]

REDCODE

REDCODE

Given the positioning of this modular system as "DSMC", I'd expect that they'd shoot uncompressed (or mathematically lossless) raw stills as other SLRs do.

The true RAW sensor data would not look good because the heavy processing to get the EI up to 800 requires various low pass filters.

I do not think RED is going to do anything other than REDCODE from now on.

Most people don't realize that so called "RAW" on DSLRs is not raw sensor data, it is processed to remove various issues such as bad pixels. How much more it is processed may vary from one camera to another and the ISO selected.

Thats one of the probelms with DNG as a file format, it cannot be optimized for a given sensor since the Adobe code is not fully open (as far as I can tell), yes you can USE their de-Bayer SDK, but you cannot branch the code as needed to work best with a given sensor at a given ISO.

Same thing with REDCODE, it is very much mated to the sensor for a given ISO so you cannot change very much without getting less than good results for the most part.

There are many RAW converter programs out there, but do they produce better results on a Nikon or Canon DSLR RAW file than the MFGs program under various ISO?

 

[Dan Hudgins]

Other?

Other?

Jim has posted such.

Do you have the link saying that the cameras will save something other than REDCODE?

REDCODE is NOT "shoot uncompressed (or mathematically lossless)" it is a lossy wavelet form of RGB compression, the "visually lossless" depends on how far you are away from the images and how they are processed, that is "mathematically lossless" means you can recover 100% of the original sensor data without ANY loss, like Delta Encoding, "visually lossless" means whatever anyone wants it to.

For the most part you would not want to turn off the low pass filters used before REDCODE compression aka "noise reduction" because you would see more snow in the images, REDCODE is part of the RED camera "look" without it the cameras would not produce images that have that "unique" quality.

 

[Stokestack]

For the most part you would not want to turn off the low pass filters used before REDCODE compression aka "noise reduction" because you would see more snow in the images, REDCODE is part of the RED camera "look" without it the cameras would not produce images that have that "unique" quality.

I don't think anyone's asking to eliminate necessary cleanup processing. I'm asking whether, in stills mode, these cameras will record "raw" images in a mathematically lossless format as Canon and Nikon DSLRs do. There's no need to compress these images lossily when data throughput isn't being maxed out by frame rate.

I'm not really interested in the "special character" imparted to an image by lossy compression. If anyone is, they can add that later.

 

[Dan Hudgins]

Ever?

Ever?

I'm asking whether, in stills mode, these cameras will record "raw" images in a mathematically lossless format as Canon and Nikon DSLRs do.

Yes, your question was easy to understand, but I do not think RED will ever do that because:

1) If somehow one is able to get better results from the true RAW data it makes people ask why they cannot have better quality also in movie mode. How would it help sales if people could make their own side by side of REDCODE and true RAW results?

2) The way the camera is build is made to process REDCODE and not to save RAW data, there may not be a data path for that in the design.

3) The sensors have maybe hundreds or thousands of bad pixels and other defects, to process true RAW data you would need to save dark-field frames for use in the data processing, that adds another step to shooting since the dark-field bias can drift with the Temperature of the camera, maybe, so you may not be able to use the same dark-field data from one days shoot for frames made on another day?

You ask, how do Nikon and Canon do it, well they have their own software to process the images, and their sensors and processing grew out of the early Bayer processing ideas, for something like the RED sensor doing that sort of processing may produce results worse than what REDCODE and its mating software produces. Even more so with higher ISO ratings, how does a CANON or NIKON "RAW" file look at ISO 24000 in DCRAW or ADOBE LIGHTROOM?

It would be nice to see a side by side, but since they are not going to make the true RAW port for the RED ONE we cannot see, and since they made that decision why would they reverse it?

 

[Kwan Khan]

Agreed...

 

[Stokestack]

Yes, your question was easy to understand, but I do not think RED will ever do that because:

1) If somehow one is able to get better results from the true RAW data it makes people ask why they cannot have better quality also in movie mode. How would it help sales if people could make their own side by side of REDCODE and true RAW results?

Hm, that hasn't stopped other camera companies from adding motion-picture capability. Widely used 35mm motion-picture cameras don't take pictures with quality equivalent to that of 35mm still cameras (because the image area is smaller), and people never seemed too worried about that either.

The sensors have maybe hundreds or thousands of bad pixels and other defects, to process true RAW data you would need to save dark-field frames for use in the data processing, that adds another step to shooting since the dark-field bias can drift with the Temperature of the camera, maybe, so you may not be able to use the same dark-field data from one days shoot for frames made on another day?

You ask, how do Nikon and Canon do it, well they have their own software to process the images, and their sensors and processing grew out of the early Bayer processing ideas, for something like the RED sensor doing that sort of processing may produce results worse than what REDCODE and its mating software produces.

That is some perplexing reasoning there. Given that all this cleanup and compensation is necessary, you're assuming that Red doesn't already do it to create clean data before compressing the frame. Not to mention that they've designed their own Bayer chips and supporting software; I don't know what you're getting at with the "early Bayer processing ideas" comment.

It would be nice to see a side by side, but since they are not going to make the true RAW port for the RED ONE we cannot see, and since they made that decision why would they reverse it?

No one is asking that they reverse it, because this has nothing to do with the raw port. The raw port was a major architectural element that would have required pumping giant boatloads of data at high speed. We're talking about recording raw data to a memory card at a leisurely pace, to support still pictures.

 

[Eki Halkka]

Do you have the link saying that the cameras will save something other than REDCODE?

REDCODE is NOT "shoot uncompressed (or mathematically lossless)" it is a lossy wavelet form of RGB compression

I recall reading Jim specifically stating that DMSC still mode includes mathematically lossless compression as an option.

 

[David Rasberry]

Redcode compression at the highest quality is pretty low. Base on a 40 second 4k 24fps clip, which is a 1.5 gig file, that I have on my laptop to play with it is only about 10 to 1.
This is the raw file size before any debayer algorithm is applied in Redcine.

 

[Craig Schober]

i've always assumed that redcode 250 would more than suffice for a visually lossless data rate for stills. too fast for current media to capture reliably at 24fps but great for a few stills. not exactly uncompressed but the nature of dsmc is slight compromise on both ends to deliver the best value to the user.

 

[Dan Hudgins]

mathematically lossless

mathematically lossless

I recall reading Jim specifically stating that DMSC still mode includes mathematically lossless compression as an option.

Do you have a link to that statement?

When someone says "mathematically lossless" another issue comes into play, that is what data is being compressed as "mathematically lossless" and do you have the option of saving the sensor data to compare it with or do you take their word for it?

The RED cameras seem to use these steps in the image processing:

1) Sensor

2) Bad pixel removal dark field subtraction

3) interpolation of green pixels

4) Low pass filtering for noise and bandwidth removal

5) Buffering of small Red and Blue images along with large Green image

6) Wavelet compression of three primary images

Step 4) needs some adjustments for higher ISO ratings and under low K light to reduce some of the bandwidth issues.

In other DSLR there are other steps in processing the sensor data. What gets saved as RAW is not necessarily the values that come out of the sensor, but some "processed" version of that data. While less compression would maybe reduce the wavelet artifacts the processing steps used in the camera could still be applied to the sensor data before being saved.

If you do not apply the processing before saving the data in the camera, then you need to apply the processing after downloading it. That would require the software used for converting the "mathematically lossless" images to do more processing on the PC etc.

Will their "mathematically lossless" algorithm be open an public for anyone to use, or will it be closed and encrypted like REDCODE, if it is not fully open then you would not have the freedom to use third party software (using independent code) to open images and you would not have the option to write your own reader code.

Common true RAW sensor data would be open to anyone and all programs that can convert it. Saying that the SDK is "open" is not the same as true open algorithm because using the SDK limits the end look of the images to the one they came up with.