Welcome to our community

Be a part of something great, join today!

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

Arri Alexa and Mysterium-X...

Status
Not open for further replies.
Actually, it's not just the postponing of the choice of white balance. Consider that the order of operations has the white balance followed by a colour correction matrix. These two operations concatenate nicely. If you separate them by an integer representation, like in recording (even uncompressed) you will have the matrix magnifying rounding errors in the integer conversion. This is undesirable.

Graeme

I see this in the audio world a lot and it is hard to explain to some people what is going on. Audio is stored as either a 16-bit or 24-bit value. When you read that audio in, it is used as 32-bit float. What I show people is this:

Let's say you have the value 123456 and you read that in, then you apply a gain reduction to the value so it becomes 12.3456 and write out the file back at 24-bit. You read that file back in, and you have 12. Now, you decide to gain that value back up to the range it was before (let's assume in this example, you want to remove the operation you did before). Now the value us 120000. Clearly you can see that data precision has been lost.

However, if you had done those two operations in the same session and didn't write out an intermediate file, no precession would have been lost.

I believe this is what is trying to be explained as the reasoning for not baking in the white balance. Because if the color correction and white balance work in opposition to each other, like the gain down/gain up above, then ultimately you CAN introduce quite a bit of error into the result.
 
I see this in the audio world a lot and it is hard to explain to some people what is going on. Audio is stored as either a 16-bit or 24-bit value. When you read that audio in, it is used as 32-bit float. What I show people is this:

Let's say you have the value 123456 and you read that in, then you apply a gain reduction to the value so it becomes 12.3456 and write out the file back at 24-bit. You read that file back in, and you have 12. Now, you decide to gain that value back up to the range it was before (let's assume in this example, you want to remove the operation you did before). Now the value us 120000. Clearly you can see that data precision has been lost.

However, if you had done those two operations in the same session and didn't write out an intermediate file, no precession would have been lost.

I believe this is what is trying to be explained as the reasoning for not baking in the white balance. Because if the color correction and white balance work in opposition to each other, like the gain down/gain up above, then ultimately you CAN introduce quite a bit of error into the result.

Great example, Rick.
 
Actually, it's not just the postponing of the choice of white balance. Consider that the order of operations has the white balance followed by a colour correction matrix. These two operations concatenate nicely. If you separate them by an integer representation, like in recording (even uncompressed) you will have the matrix magnifying rounding errors in the integer conversion. This is undesirable.

Graeme

So, I think I understand this part of the reasoning behind postponing your WB, as it seems to correspond (somewhat ironically) to the generational loss images can suffer through multiple iterations of compression.

Graeme Nattress said:
I'd also be worried about premature highlight clipping in any channel with increased gain.

But isn't avoiding clipping highlights in channels exactly the reason that one WANTS to white balance at the time of recording? For example, in my experience shooting with the R1 under tungsten light, the red channel starts to clip well before the green and blue. Because there is no in-camera white balance feature, I must choose between under-exposing my green and blue channels (noisy) or clipping my red channel (very ugly!). My other option, of course, is to optically white balance to 5000K (as per Dwight Tudor) via some form of 80 series filtration. This, as it has been noted, comes at the expense of overall sensitivity, which on the R1 is usually unacceptable under tungsten lighting, as stop is generally at a premium anyway.

Of course, the M-X sensor seems like it will significantly help this problem. But purely theoretically, I don't understand how PROPERLY white balancing via analogue gain could increase the risk of clipping in a given channel.
 
Unless they bake it on the analog side, then you can still get all data stored as an integer.

No, the example I posted still stands. Let's say the sensor is generating 123456 and you use analog gain reduction to make it 12.3456 then you read that in. The A/D reads in 12 and that 3456 gets pushed down, into the noise of the A/D converter as well. Then you gain that up later, and that 12000 now has noise in it that you would not have had before.

This is why I am an advocate of using fixed gain pre ADC in these designs. It means your sensor and ADC noise are ALWAYS going to be consistent between shots. With variable analog gain, the difference between ADC and sensor noise vary if you change settings. It becomes one more difference you have to work around.

Arri might in fact do their white balance in analog. That would explain why it is baked in as it would have to be. They may have reasons why they did this relative to their sensor design. The picture and design considerations might be A LOT bigger than changing their firmware.
 
I never said it was a "gimmick" I said that (unless mathematically lossless) by strict definition compressed is not raw.

Who's definition are you going by there Michael.. because Camera RAW can be either compressed or uncompressed.. and we are definitely not the first company to use Compressed RAW.

We have never claimed that REDCODE RAW was uncompressed RAW, because we think uncompressed RAW is rather dumb :)
 
Who's definition are you going by there Michael.. because Camera RAW can be either compressed or uncompressed.. and we are definitely not the first company to use Compressed RAW.

We have never claimed that REDCODE RAW was uncompressed RAW, because we think uncompressed RAW is rather dumb :)

I agree and if you read my post (and I realize this thread is monstrous and my posts tend to be long) you will see that I was both defending RED's terminology and usage and trying to clarify RAW with no modifiers.

To my understanding true RAW RAW RAW RAW is the actual grayscale values of each pixel of the bayer pattern such that if you store ALL of those values either through one to one storage or true mathematically lossless storage then their is essentially no difference between what you have in storage and what you would get if you took the same camera back in time and place and shot the same thing over. Any non-mathlossless difference would change that.

I said that "compressed RAW" is in fact a useful marketing term (and NOT a "gimmick") because it indicated that we are much, much, much closer to those actual RAW, RAW, RAW values than say the AVCHD RGB-type codec in my Canon HFS100s which also uses a bayer pattern sensor.

In my "Idiots guide to Raw", I understand the big benefit of having that original grayscale data for each pixel is that for example if the normal debayering simply looked at the four pixels and created the average, since there is possibly something happening in the picture between those pixels, while you could guess at what it was, it might not be as accurate as if you evaluated those pixels in conjunction with what was happening on the surrounding 16, or 24, or 48 etc. pixels. Obviously, that requires more and more sophisticated algorithms and processing power, but if you have the original grayscale values, you can improve things as processors become faster or you better understand the nature of the sensor, or your algorithms better understand the nature of potential subjects. For instance face recognition was nonexistent 15 years ago, now it is commonplace so your algorithm could recognize a face and know that green or purple is probably not likely as a fleshtone. (If Graeme can write a zit removal algorithm, you'll sell one to every yearbook photographer in the country! :biggrin: )

The farther you move from the RAW RAW, presumably the less you are able to take advantage of that sort of thing - although again compressed RAW is still much better in that regard than compressed RGB types.

And all I'm saying in the context of this thread is that since both companies are doing some modification to the raw, let's not get too far into hardcore comparisons or "I'm raw and your not" based on varying (reasonable) definitions of RAW until we get some in depth experience and samples.

Doesn't mean I'm pushing ARRI - there's like 0 chance I'll buy an Alexa and I've already ordered my Epic!

PS I don't know if it kosher to quote yourself but here's a snip of the original:

Other than MATHEMATICALLY LOSSLESS compression, once you decide to discard some of the information you are almost by definition NOT providing the RAW sensor data and "Compressed RAW" is an oxymoron. I do think it is a useful marketing term because it indicates that the compression takes place before the debayering and there isn't a lot of confusion among those of us that are following it. I think RED has proven that this can be a successful compromise, but at this point it seems that everyone is messing with the TRUE RAW and has debased the term to the point where you have to explore more deeply.

PPS "Oxymoron" isn't inherently a bad thing:

"noun, plural oxymora or oxymorons
A figure of speech in which two contradictory terms appear together for emphasis, for example, "deafening silence".
 
From Arri's own digital fact book*:

RAW DATA (A.K.A. SOURCE DATA)
Data that has not been processed for use. Digital cinematography cameras can generally output raw data of images that includes the full brightness range it can extract from a scene, and a signal that has not been processed for color or to suit any target viewing conditions – such as cinema or gamma corrected for home TV viewing.

*it should be noted that quantel really wrote this

Also I am a bit confused. Arri states 3.5k but all the info I have seen states:

Arri Raw 16x9 is 3072 x 1728
EVF with look around is 3168 x 1782
 
But isn't avoiding clipping highlights in channels exactly the reason that one WANTS to white balance at the time of recording? For example, in my experience shooting with the R1 under tungsten light, the red channel starts to clip well before the green and blue. Because there is no in-camera white balance feature, I must choose between under-exposing my green and blue channels (noisy) or clipping my red channel (very ugly!). My other option, of course, is to optically white balance to 5000K (as per Dwight Tudor) via some form of 80 series filtration. This, as it has been noted, comes at the expense of overall sensitivity, which on the R1 is usually unacceptable under tungsten lighting, as stop is generally at a premium anyway.

Of course, the M-X sensor seems like it will significantly help this problem. But purely theoretically, I don't understand how PROPERLY white balancing via analogue gain could increase the risk of clipping in a given channel.

If white balance occurs after the sensor (as in it's not done optically), then the clipping has already occurred. Negative gain on the red channel in your tungsten scenario won't bring anything back, it just would make the data you did get, darker. Similarly, gaining up blue won't stop the red clipping, and it will increase any blue clip.

In the tungsten situation, optically balancing would help red clipping, but any filter will make everything darker as no filter is perfect. In some situations this might work out fine, but it's not a universal fix.

That's what I meant earlier about there being no one perfect way to do this, but there are ways that can be reasoned to be more appropriate than others, on balance.

With analogue gain, for every stop of gain that is applied, you loose a stop of highlights. On some cameras, analogue gain looks better than digital gain, so it does make sense to use some analogue gain. However, on some cameras, digital gain looks better, and digital gain can be done with a FLUT like technique to preserve highlight information, or you could do an HDR like process to retain shadows and highlights.

I did some tests the other day with the Canon 1d Mk III, which has pretty darn good high ISO. It goes up to ISO6400, and can make quite usable stills. So, using the M-X like a stills camera, I shot them both, metered ISO6400, F2.8, same shutter speed. The Canon is using a lot of analogue gain (and some digital) to reach that high ISO. The M-X was obviously only using digital gain on the FLUT system. Noise levels were utterly comparable, but there was visibly a vaster dynamic range on the M-X because it rolled off the highlights beautifully, rather than crushing them off the top via the mechanism of analogue gain (and some straight digital gain).

It's experiments like that which have shown us that well done digital gain is preferable for us to analogue gain, and that's why we do white balance in post, concatenated with the colour correction matrix to ensure no magnification of rounding errors. It works very well for us.

Graeme
 
If white balance occurs after the sensor (as in it's not done optically), then the clipping has already occurred. Negative gain on the red channel in your tungsten scenario won't bring anything back, it just would make the data you did get, darker.

Graeme

Thanks Graeme, that clears it up for me. I had assumed that 'analogue gain' involved manipulating the sensitivity of the sensor itself, so that in the tungsten situation, the red could be 'gained down' to match the other channels, recovering the highlights in the process.

Knowledge gap filled. :-) Thanks for the info.
 
I am wondering what this modification will entail...?? Semi-fixed ND? Seriously doubt it. This is way over my head... what the heck could it be that it requires a little time? Can't be a different card, could it?



As far as I understand the reason why Lucas is using 7D/5D's is because they want cameras mounted in the cockpits of old airplanes. If they fall of who cares, and since they are light and small they won't add too much weight, affect aerodynamics as much, and fit into tight spots. That's my guess anyway, I am imagining 5 of them strapped to an old plane at once. But no matter the resolved detail, if moire can pop out of nowhere the camera is dangerous. Perhaps they modified theirs with a custom OLPF that allows ~720p detail and effectively cuts off the moire... or they did extensive testing with the best softening filters to match each lens... so in that case, sure, 7D could be "good enough", but for me "good enough" isn't good enough for my projects. I know you feel the same way.

I feel the same way too. I sometimes spend an entire night on the lighting diagrams for a single shot, because I know if I just think about it longer, I'll find an even better way, and I still feel my own work is not good enough yet. After spending that much time carefully planning everything, I could care less about a slightly heavier (or even more expensive) camera. the Red could be twice as heavy and twice as much it would still be worth it, because it's heartbreaking to point a crappy line-skipping system at so much hard work.
 
The thing with Red's business model is that they will always continue to provide updated firmware that improves the image somehow. So the excuse that whatever tests were using the "old" firmware is rather mute. If a company is releasing a product to the public, in ANY form, it should be the best product that company has to offer.

I'm tired of hearing "oh they were using build xxx, so we shouldn't take that as what the camera can really do." I thought RAW meant nothing was done to the images. So why should the latest firmware matter on how the test results come out. I'm talking about test results for the M sensor not the MX. I understand they are still trying to calibrate that sensor. I'm just tired of always have to use an unfinished product from Red.

Any product is the best a company CAN offer at a given time. If they followed your philosophy, they would be like Panny and Sony and sell you a new camera instead of giving you a free upgrade.

The Red is only "unfinished" because they continue to improve it. Other companies call their products "finished" because they don't.
 
Any product is the best a company CAN offer at a given time. If they followed your philosophy, they would be like Panny and Sony and sell you a new camera instead of giving you a free upgrade.

The Red is only "unfinished" because they continue to improve it. Other companies call their products "finished" because they don't.

Free upgrade? I'm not exactly 100% on the deals for red myself but I'm pretty certain an upgrade isn't free.
 
Free upgrade? I'm not exactly 100% on the deals for red myself but I'm pretty certain an upgrade isn't free.

I assure you Craig that we have given more meaningful functionality upgrades (for free) upgrades over the last 2 years in one camera then all other professional cameras combined.
 
I assure you Craig that we have given more meaningful functionality upgrades (for free) upgrades over the last 2 years in one camera then all other professional cameras combined.

If RED was like other companies, there would be NO upgrade to MX, it would be a whole new camera, and another $17k - $20k to buy it. Then after everyone bought the new RED MX, they would announce EPIC and it would come out in 6 months...suckers.
 
If RED was like other companies, there would be NO upgrade to MX, it would be a whole new camera, and another $17k - $20k to buy it. Then after everyone bought the new RED MX, they would announce EPIC and it would come out in 6 months...suckers.

That sounds painfully familiar and right.
 
I could care less about a slightly heavier (or even more expensive) camera. the Red could be twice as heavy and twice as much it would still be worth it, because it's heartbreaking to point a crappy line-skipping system at so much hard work.

Hi,

I had the thoughts with video cameras v Film for the last 20 years.
 
Status
Not open for further replies.
Back
Top