PYXIS 6K

If I had a point with that comment, it is in regards to ANY flavor of RAW. Steve Yedlin can say it much better than I can, but to paraphrase: "RAW has no picture quality advantage over an RGB encoding, it's just more efficient to store and transfer."

I still don't really agree with Yedlin on this. Debayering may be a fairly established science by this point, but knowing that capturing in raw gives you the ability to access new and better algorithms in the future is pretty rad.

Hopefully, they know what they are doing. Given TV's obsession with interlaced format and given that ProRes typically records 4:2:2 then if they do it wrong there may be unpleasant surprises during deinterlacing in the future.

No one is shooting 422 ProRes or using it to archive.

It’s all 12bit 444.

When I want to shoot with the 12k BRAW the first argument pushback is usually we can’t handle the file size.

Then I show them that 12k BRAW is smaller. And then it goes fine.

JB

If I had a point with that comment, it is in regards to ANY flavor of RAW. Steve Yedlin can say it much better than I can, but to paraphrase: "RAW has no picture quality advantage over an RGB encoding, it's just more efficient to store and transfer."

I still don't really agree with Yedlin on this. Debayering may be a fairly established science by this point, but knowing that capturing in raw gives you the ability to access new and better algorithms in the future is pretty rad.

Also the devil is in the detail.

I believe he’s talking about RGB encoded ProRes which no one really does.

JB

Yedlin talks a lot of sense to my mind. And his message is stop worrying about the resolution, which I think makes perfect sense. And for most people and most grades 'raw' isn't essential.

While I agree with a lot of Yedlins general statements, they are now from quite some time ago.

He also has done a lot of custom work to make it all seem so simple behind the scenes.

I was just working with some of the team at the post company that prepared these videos and there’s an awful lot of very much code based work going on here within non-conventional color grading tools like Nuke.

JB

With A.I. coming in strongly I'm sure that sooner or later it can convert RGB into a workable raw footage its been done from jpeg so who knows in the future raw will be available to all.


Ric Marty

I was just working with some of the team at the post company that prepared these videos and there’s an awful lot of very much code based work going on here within non-conventional color grading tools like Nuke.

This is true John, but post technology has moved on too; you don't need Nuke or coding to achieve the same results in almost any high end NLE, nor is it the same concern as it was then. Colour management for scene to display CSTs, such as RCM and Aces; better codecs that sample up and down well, such as Braw; better scaling and NR algorithms with things like Topaz and dare I say it AI, such as we're seeing now in Resolve; have all moved on a long way even for the casual user. Resolution has too with most cameras well beyond just 4K. Someone here said it was a myth that you could make any camera look like another in post; well I can say that is BS, I have to do it all the time with lesser cameras than we're talking about here. Now the obsession is all rolling shutter and dynamic range. Perhaps someone like a Yedlin or better a John Brawley should cover that one now.

If I had a point with that comment, it is in regards to ANY flavor of RAW. Steve Yedlin can say it much better than I can, but to paraphrase: "RAW has no picture quality advantage over an RGB encoding, it's just more efficient to store and transfer."

I still don't really agree with Yedlin on this. Debayering may be a fairly established science by this point, but knowing that capturing in raw gives you the ability to access new and better algorithms in the future is pretty rad.

That flexibility is indeed great for a one-click change to "color science". For example, Gen5 was so much better than Gen4 that I stopped making a correction LUT ... BUT ... that's not a picture quality advantage. It's a convenience feature. RGB data can be similarly transformed.

If camera manufacturers were more open about what they do when, more people would realize most manipulation, even in the RAW control panel, is done AFTER debayering. Instead, they communicate in a way that makes it seem as if things like white balance and exposure aren't baked into a RAW file, when of course they are.

That flexibility is indeed great for a one-click change to "color science". For example, Gen5 was so much better than Gen4 that I stopped making a correction LUT ... BUT ... that's not a picture quality advantage. It's a convenience feature. RGB data can be similarly transformed.

Converting RAW to RGB causes information loss that cannot be recovered.

If I had a point with that comment, it is in regards to ANY flavor of RAW. Steve Yedlin can say it much better than I can, but to paraphrase: "RAW has no picture quality advantage over an RGB encoding, it's just more efficient to store and transfer."

RAW contains more information than RGB so that statement is mathematically incorrect.

Also the devil is in the detail.

I believe he’s talking about RGB encoded ProRes which no one really does.

JB

True, no readily-available for sale camera records pure, uncompressed RGB data - it would be far too unwieldy, for no real benefit. Doesn't even BRAW "partially debayer" to YCrCb before further compressing?

I don't want to put words into Yedlin's mouth, so my version is this: So long as you capture the color data at sufficient quality (bit depth, etc.) then - again purely talking about PQ - RAW has no special abilities over any other way of representing the same amount of information. RAW's primary PQ advantage is being able to compress and record an unmolested signal to a reasonable size.

Yedlin's somewhat long, but very well-stated words quoted from here: https://www.yedlin.net/NerdyFilmTechStu ... index.html

RAW itself is not a sham, but some inflated superstitions about how it works are.

Remember, in the technical definition and not general English-language definition, RAW means “not yet converted from Bayer to RGB." And it really is that, but nothing more than that (though some other non-inherent attributes may be coupled with RAW due to real-life implementation restrictions).

What I explain in the Followup is that doing color transforms like applying gains, tone maps, and matrices does not yield any better result by doing them in Bayer rather than doing them in RGB (in fact, you CAN’T apply the matrices in Bayer).

So, I was showing that it’s a fallacy when some believe, for example, that they can get more actual information by increasing the nominal ISO (brightening) or by changing white balance if they do so in the Debayer software than they can by doing it downstream in the computation chain. The brightness (ISO) and white balance and tone map adjustments that manufacturers offer in Debayer software is a handy tool that they kindly offer for us to do at the same time as the Debayer geometry, so it's nice of them to put it there, but it’s not magically better quality color transformation for being done at that position in the computation stack.

RAW itself is real, not a sham, and has other advantages (just not the fake advantage that some believe it has of magically having more color data).

The main (real) advantage is that, since real-world sensors are Bayer, RAW is much more efficient -- meaning that Bayer is more efficient for storage and throughput than RGB. As you saw in the Followup, converting Bayer to RGB requires inventing 2 non-existent channel values at each pixel position. This means the file is being inflated to triple its size with artificial code values that are not real scene data.

So, to use RGB instead of Bayer transport files, the camera would first have to do the increased processing and throughput in real time to run the demosaic algorithm that invents those code values, and then it would need to write to the capture card at triple the speed. Throughput, processing, read/write speed, and storage are all valuable commodities, and there’s no reason to waste them, especially not with an unnecessary 300% inflation.

For example, why unnecessarily triple the write speed requirements when we already wish the max framerate of the camera would be higher than it currently is?

So, the main advantage of RAW is that it’s not unnecessarily inflated, not that it has magically more inforation than the same data converted to RGB. Folks sometimes act as though the scene hasn’t been shot yet and we can go back in time and somehow retrieve information from the original scene that was never actually captured by the camera if we use not-yet-debayered transport files. This is a mental construction that does not represent how RAW or any real-world thing works. RAW doesn’t have more information than RGB; it’s just a more efficient file type to transport sensor data.

There is another advantage that RAW transport files sometimes (but not always!) have over RGB transport files that’s purely conventional and not inherent: it’s that some cameras allow you to get fully uncompressed files out of the camera, but only if they’re RAW. In which case it’s not an advantage because it’s RAW per se (not yet converted to RGB), it’s just that, in these cases, to get the advantage that we're after (uncompressed), we also have to take along with it another attribute (RAW).

Present day cameras that fall under this description would include all of Arri’s Alexa family and most DSLR or mirrorless system cameras. Arri’s camera allows you to retrieve the fully uncompressed sensor data, but only if using a RAW (not-yet-debayered) transport file (ArriRaw). If we take an already-debayered file out of the camera, it’s also compressed (ProRes or DNxHD). RAW is a quality advantage in this case not because it's RAW, but because it's uncompressed.

Same with most still cameras: they will deliver RAW (not-yet-Debayered) files that are uncompressed or they’ll deliver already-debayered JPEG files, which are very compressed. So, again, the main advantage of RAW is that it’s uncompressed. The fact that it’s RAW per se (not-yet-converted-to-RGB) is not so much a quality advantage as just a dry technical requirement for getting uncompressed files out of the camera.

See: it's just a convention of some camera models that RAW and uncompressed go together. But those are two separate attributes.

And there are cameras where those two separate attributes do not go together, such as the Red family of cameras. Red cameras deliver .R3D files that are both RAW and compressed. So, in that case, RAW still means “not-yet-debayered,” but doesn't mean uncompressed, which is the attribute that’s actually a big deal for quality. Don’t get me wrong: R3D is pretty darn good compression, but it’s still compression. That’s less info than the original sensor got. There is simply no way to get uncompressed files out of those cameras, so in those cases, RAW does not have the quality advantage of being uncompressed, even though it is still truly RAW, meaning only not-yet-debayered.

Do you have any examples of the "uncharted territory," boundry pushing looks that are possible with the manipulation of 3D color values? I am wondering what interesting creative choices you think could be possible in the future when software developers allow us to push these boundaries.

I don’t know; don’t expect too much of me, I’m just one person. I’m working hard on creating tools that don’t exist off-the-shelf and then using those tools to create my own look. I don’t know what exciting other looks filmmakers are going to create down the road, but that’s why I’m trying to inspire image authors to start thinking this way, so I can get to see all the cool stuff I haven’t yet imagined.

That flexibility is indeed great for a one-click change to "color science". For example, Gen5 was so much better than Gen4 that I stopped making a correction LUT ... BUT ... that's not a picture quality advantage. It's a convenience feature. RGB data can be similarly transformed.

Converting RAW to RGB causes information loss that cannot be recovered.

At an abstract level that is sort of true (misleading but technically true), but is irrelevant in practical terms.

I think a more useful way of stating that is: Converting RAW to RGB forces additional synthetic information to be created (RAW is missing 2/3 of the scene data at each pixel), so unless you know the specific debayer algorithm, you cannot accurately reverse the process.

Yedlin wrote:
"As you saw in the Followup, converting Bayer to RGB requires inventing 2 non-existent channel values at each pixel position. This means the file is being inflated to triple its size with artificial code values that are not real scene data."

The mistake Yedlin makes is mixing up the effective information content with derived and thus redundant information. The redundancy of RGB as introduced by the debayering can be easily compressed.

I think a more useful way of stating that is: Converting RAW to RGB forces additional synthetic information to be created (RAW is missing 2/3 of the scene data at each pixel), so unless you know the specific debayer algorithm, you cannot accurately reverse the process.

No, the process is non-reversible even if you know the algorithm.

RAW contains more information than RGB so that statement is mathematically incorrect.

That is simply false. The real world scene data recorded by a bayer pattern sensor is missing 2/3 of the color information at every photo site. At any given resolution (spatial and depth), RGB represents 300% more information. (But it would be a big ass file.)

RAW is an efficient way to store unmolested bayer pattern data. That's basically it. When we try to attribute much more to it, we start trending into hand-waving voodoo.

RAW contains more information than RGB so that statement is mathematically incorrect.

That is simply false. The real world scene data recorded by a bayer pattern sensor is missing 2/3 of the color information at every photo site. At any given resolution (spatial and depth), RGB represents 300% more information. (But it would be a big ass file.)

It is not false
I believe you misunderstand what information means.

No, the process is non-reversible even if you know the algorithm.

Why? Explain.

It is not false
I believe you misunderstand what information means.

Then define "information".

At any given sample point, a "raw" pixel is a single number from 0-x, x depending on the bit depth. To view it as image data, it would be a monochrome channel. At any given sample point, RGB can store 3 of those values instead of one.

Let's fully saturate a red sample point on a bayer sensor and record that as a 10-bit value. The "raw" data is the number 1024. The RGB data for that same sample point is 1024,0,0. What information is missing? The problem isn't missing data, the problem is that the RGB signal wastes tons of space. It's unnecessarily bloated unless you're using a sensor that can deliver full color information for each "pixel".

The mistake Yedlin makes is mixing up the effective information content with derived and thus redundant information. The redundancy of RGB as introduced by the debayering can be easily compressed.

I don't see, at all, that Yedlin is making any such mix up, but if you really believe he's uninformed or (more to the point) that his ignorance has led him to wrongly insist that raw doesn't have the unique qualities routinely claimed for it in the lesser bylaws and off-ramps and fora of production (like here), he's reachable and fair-minded. By all means point out to him where he's gone wrong and see what he says.

Then I show them that 12k BRAW is smaller. And then it goes fine.

JB

This is BRAW's super power. It is a well designed modern codec that capitalizes on how sensors actually record. Very high quality at very small file sizes that can be decompressed without melting processors.

Said it before, I'll say it again, I love me some BRAW.

Speaking the truth about what RAW can and can't do shouldn't be construed as a knock against BRAW or REDCODE or whatever. They are good ways of transporting sensor data.

ProRes files are unnecessarily large because they are bloated with data the camera didn't actually record, they're not inferior in how much PQ they can represent.

It is not false
I believe you misunderstand what information means.

Then define "information".

information theory is getting way out of scope let me just say within the context of what we are discussing that an algorithm never increases the amount of information.

i just asked my big friend ChatGPT to make a relevant example that hopefully explains it to you:

Scenario: Temperature Data Between Cities
Suppose we have a dataset containing the average daily temperatures for a particular day from several cities along a straight highway: City A, City B, and City C. These cities are equidistant from each other, and we have exact temperature measurements for each city.

Dataset Original:

City A: 70°F
City B: 75°F
City C: 80°F

Algorithm Application: Spatial Interpolation
We decide to interpolate temperatures for multiple points between these cities to create a more detailed temperature map of the area. An algorithm is used to estimate temperatures at several points between each pair of cities based on a linear gradient between the known temperatures of these cities.

Expanded Dataset
After applying the spatial interpolation algorithm, our dataset now includes temperatures not just for Cities A, B, and C, but also for several points between them. For example, halfway between City A and City B, the temperature is interpolated to be 72.5°F, and so on along the highway.

Analysis of Information Content
Original Information: The original dataset contained exact, measured temperatures for each city.
Expanded Information: The new dataset contains estimated temperatures for points between the cities. These interpolated values are based on a simple average of the temperatures of the nearest cities.

Key Points on Information Content
No New Measurements: Like in the time-based interpolation example, the spatially interpolated temperatures are not new measurements; they are estimates based on existing data between known points. No additional temperature measurements were taken at these new points.
Predictability and Redundancy: The interpolation introduces predictability; the temperatures at interpolated points are predictable if one knows the temperatures at Cities A, B, and C. This redundancy means that the interpolated values are heavily dependent on the original data and do not introduce new independent data.
No Resolution of Additional Uncertainty: The interpolated points do not resolve any additional uncertainties about temperature variations that were not already implicit in the measurements from Cities A, B, and C. The new data points are derived and do not add information about anomalies, microclimates, or other factors that could be present if actual measurements were taken at those points.

Conclusion
In this spatial interpolation scenario, while the dataset grows larger and provides a smoother gradient of temperature data across a geographic region, the actual informational content — insights into the temperature variations that are independent of the known city data — does not increase. This illustrates how spatial interpolation, like demosaicing in imaging, uses existing data to create a fuller but not necessarily more informative dataset. The true information content, which would involve capturing new and independent data points, remains the same as before the interpolation was applied.

Um ... fascinating as this is, perhaps it's time to return to discussing the particular camera this thread is supposedly discussing?

Sent from my SM-S908U using Tapatalk

ProRes files are unnecessarily large because they are bloated with data the camera didn't actually record, they're not inferior in how much PQ they can represent.

While ProRes encoding is rather ancient and straightforward (it is DCT-based) the RGB redundancy should be no problem to compress.

No, the process is non-reversible even if you know the algorithm.

Why? Explain.

What math is not invertable? An RGB pixel is derived (Bayer) from several samples. While it would be impossible to invert the Debayer and find the value of 1 RGB pixel (not enough information), the image as a whole represents a vast Sudoku puzzle with one solution.

ProRes files are unnecessarily large because they are bloated with data the camera didn't actually record, they're not inferior in how much PQ they can represent.

When Prores was invented 3 chip cameras ruled the day, and still do within broadcast, each R/G/B sample references a discrete pixel. I imagine it's too expensive to develop a S35 prism so we're stuck with Bayer on the big chips.

Good Luck

When Prores was invented 3 chip cameras ruled the day, and still do within broadcast, each R/G/B sample references a discrete pixel. I imagine it's too expensive to develop a S35 prism so we're stuck with Bayer on the big chips.

When Prores was invented it was as a post mastering codec, Howard; not for cameras at all. 3 chip sensors were all 4:2:2 too, whatever the codec. True raw is a camera technique to extract and retain the original sensor data from the shoot; RGB is the post and mastering output and 12bit 4:4:4 can carry every drop of maximum quality available; notwithstanding it no longer contains the original sensor data; or any. Horses for courses and all that. And I agree it's way off topic again; for which I take some blame from before. The Pyxis deserves more talk, and as I say I'm liking it more and more.

No, the process is non-reversible even if you know the algorithm.

Why? Explain.

What math is not invertable? An RGB pixel is derived (Bayer) from several samples. While it would be impossible to invert the Debayer and find the value of 1 RGB pixel (not enough information), the image as a whole represents a vast Sudoku puzzle with one solution.

Turning RAW to RGB is not only using demosaicing, there are lots of other things happening. We could have noise reduction, white balance adjustments, interpreting sensor values, color space conversion, etc).

So if all intermediate processing is maintained in metadata and the RGB data is not lossy-compressed then, in theory, I suppose we could reconstruct it.

Turning RAW to RGB is not only using demosaicing, there are lots of other things happening. We could have noise reduction, white balance adjustments, interpreting sensor values, color space conversion, etc).

So if all intermediate processing is maintained in metadata and the RGB data is not lossy-compressed then, in theory, I suppose we could reconstruct it.

You're now conflating a bunch of other processing with debayering. None of those things are an actual benefit of recording RAW. Yedlin addresses this quite well, so no need for me to repeat.

ProRes files are unnecessarily large because they are bloated with data the camera didn't actually record, they're not inferior in how much PQ they can represent.

While ProRes encoding is rather ancient and straightforward (it is DCT-based) the RGB redundancy should be no problem to compress.

Given the same compression technique, monochrome data will always be smaller than three channel data. This is RAW's file size advantage.

i just asked my big friend ChatGPT to make a relevant example that hopefully explains it to you:

Scenario: Temperature Data Between Cities
Suppose we have a dataset containing the average daily temperatures for a particular day from several cities along a straight highway: City A, City B, and City C. These cities are equidistant from each other, and we have exact temperature measurements for each city.

Dataset Original:

City A: 70°F
City B: 75°F
City C: 80°F

Algorithm Application: Spatial Interpolation
We decide to interpolate temperatures for multiple points between these cities to create a more detailed temperature map of the area. An algorithm is used to estimate temperatures at several points between each pair of cities based on a linear gradient between the known temperatures of these cities.

Expanded Dataset
After applying the spatial interpolation algorithm, our dataset now includes temperatures not just for Cities A, B, and C, but also for several points between them. For example, halfway between City A and City B, the temperature is interpolated to be 72.5°F, and so on along the highway.

Analysis of Information Content
Original Information: The original dataset contained exact, measured temperatures for each city.
Expanded Information: The new dataset contains estimated temperatures for points between the cities. These interpolated values are based on a simple average of the temperatures of the nearest cities.

Key Points on Information Content
No New Measurements: Like in the time-based interpolation example, the spatially interpolated temperatures are not new measurements; they are estimates based on existing data between known points. No additional temperature measurements were taken at these new points.
Predictability and Redundancy: The interpolation introduces predictability; the temperatures at interpolated points are predictable if one knows the temperatures at Cities A, B, and C. This redundancy means that the interpolated values are heavily dependent on the original data and do not introduce new independent data.
No Resolution of Additional Uncertainty: The interpolated points do not resolve any additional uncertainties about temperature variations that were not already implicit in the measurements from Cities A, B, and C. The new data points are derived and do not add information about anomalies, microclimates, or other factors that could be present if actual measurements were taken at those points.

Conclusion
In this spatial interpolation scenario, while the dataset grows larger and provides a smoother gradient of temperature data across a geographic region, the actual informational content — insights into the temperature variations that are independent of the known city data — does not increase. This illustrates how spatial interpolation, like demosaicing in imaging, uses existing data to create a fuller but not necessarily more informative dataset. The true information content, which would involve capturing new and independent data points, remains the same as before the interpolation was applied.

While it might be fun to see how ChatGPT pretends to understand something, that output has little to do with anything we've been debating. In fact, if anything, its conclusion alludes to my point: bayer sensor data directly represents much less real color information than an RGB signal would, and therefore we can delay the transform into something viewable until delivery without a loss of quality. Synthesizing it into RGB doesn't lose information, it builds (useful) fake information.

Um ... fascinating as this is, perhaps it's time to return to discussing the particular camera this thread is supposedly discussing?

Sent from my SM-S908U using Tapatalk

True. How did we get started on this? Apologies, I find it hard to not get sucked into the film is magic or RAW is magic, or x manufacturer's color "science" is magic debate.

ProRes files are unnecessarily large because they are bloated with data the camera didn't actually record, they're not inferior in how much PQ they can represent.

While ProRes encoding is rather ancient and straightforward (it is DCT-based) the RGB redundancy should be no problem to compress.

Given the same compression technique, monochrome data will always be smaller than three channel data. This is RAW's file size advantage.

RAW contains more information than RGB and RGB has redundant data that can easily be compressed.

If you disagree on that then I suppose we simply have to agree to disagree and leave it like that.

It builds (useful) fake information.

Um ... fascinating as this is, perhaps it's time to return to discussing the particular camera this thread is supposedly discussing?

They are in a technical blood-rage

Um ... fascinating as this is, perhaps it's time to return to discussing the particular camera this thread is supposedly discussing?

One of the top three or so complaints about the PYXIS is lack of ProRes, and Apple's disciples got triggered when I and others added nuance to (critique of) the Church of ProRes. I'm glad the experts showed up to prove it's bloated and outdated (never meant for camera acquisition, even though it persists from the days of drought when ARRI and Blackmagic ironically also treated it as an "intermediate" compromise). Sensor-specific debayering RAW codecs are the whole future, plain and simple.

When Prores was invented it was as a post mastering codec, Howard; not for cameras at all. 3 chip sensors were all 4:2:2 too, whatever the codec.

I'm talking about 3 chip broadcast cameras and 10 bit 4:2:2 on the wire not consumer camcorders which were more often 4:1:1 or 4:2:0 but thanks again for the meaningless incorrection.

Good Luck.

and Apple's disciples got triggered when I and others added nuance to (critique of) the Church of ProRes.

Relax mate.

Ah ...

Sent from my SM-S908U using Tapatalk

RAW contains more information than RGB and RGB has redundant data that can easily be compressed.

What "more information"? I made an attempt at describing the information RAW samples (a monochrome channel at x bit depth), you did not.

It builds (useful) fake information.

A bayer pattern sensor lacks 2/3 of the actual scene color information at any sample point. (BMDs sensors are missing ALL color information at one of the four sample points.) This missing data has to be inferred/guessed/extrapolated/synthesized from what data is there. Call this "fake" color information whatever you want, but it wasn't sampled by the sensor. So why record it? THAT's the advantage.

One of the top three or so complaints about the PYXIS is lack of ProRes, and Apple's disciples got triggered when I and others added nuance to (critique of) the Church of ProRes. I'm glad the experts showed up to prove it's bloated and outdated (never meant for camera acquisition, even though it persists from the days of drought when ARRI and Blackmagic ironically also treated it as an "intermediate" compromise). Sensor-specific debayering RAW codecs are the whole future, plain and simple.

None of ProRes' disadvantages make an ounce of difference if it is the de facto standard, "good enough", and your client demands it. Acknowledging that practical reality no more makes someone a zealot than acknowledging that RAW doesn't offer a PQ advantage makes someone an anti-raw zealot.

I'm talking about 3 chip broadcast cameras and 10 bit 4:2:2 on the wire not consumer camcorders which were more often 4:1:1 or 4:2:0 but thanks again for the meaningless incorrection.

Sorry Howard the bulk wasn't intended for you but that other bollix. But you said:

When Prores was invented 3 chip cameras ruled the day, and still do within broadcast, each R/G/B sample references a discrete pixel. I imagine it's too expensive to develop a S35 prism so we're stuck with Bayer on the big chips.

And I can only go off that. I have the utmost respect for your knowledge and opinions, which I often read with interest. Good luck mate!

Please get back on topic and take the debate to another thread, thanks!

Not to start another debate about (not) shooting low light, but since Pyxis will have the same sensor as the BMCC 6K, do you think they'll address this? It seems to be more severe than other cameras featuring this sensor.

Hi guys,

Just wanted to know what's the latest take on this matter? Should this banding/striking effect be viewed as something you have to deal with (whit this camera) or simply a sensor error?

I'm trying out the camera at the moment and am LOVING the image in the right conditions but feel hesistant about this thing.

See my testing here:

Thanks.

Lack of low light capabilities is one of the reasons I went back to a P6kPro.

Yeah, I wish there was a 6K S35—WITH AN OLPF—version of this too.

+1

Not to start another debate about (not) shooting low light, but since Pyxis will have the same sensor as the BMCC 6K, do you think they'll address this? It seems to be more severe than other cameras featuring this sensor.

Hi guys,

Just wanted to know what's the latest take on this matter? Should this banding/striking effect be viewed as something you have to deal with (whit this camera) or simply a sensor error?

I'm trying out the camera at the moment and am LOVING the image in the right conditions but feel hesistant about this thing.

See my testing here:

Thanks.

I hope they do but I doubt it since they won’t even acknowledge the low light noise issues with the 6K CC. It’s why I returned mine and bought a 6K G2 and won’t be buying a pyxis.

It’s a stretch to say ProRes is dead.

The majority of the TV and streaming content you watch is shot ProRes.

I’m working at Warner Bros on a TV series and can say every single WB TV series is shot 4K ProRes. I know this because even though I shoot with cameras that don’t shoot ProRes, they have to be converted to 4K ProRes for archiving because that’s the format WB use for their archiving. If you shoot any other codec, including raw, it’s transcodeoded. The cost of that transcode falls on the individual production so guess what….Every WB TV show shoots 4K ProRes. If they aren’t then they are certainly transcoding to it.

https://www.warnerbros.com/tv

ProRes is still the defacto origination and archiving format of many of the big studios, no matter what someone here posts about.

Luckily for me I can shoot BRAW as the show deems the value of what the BRAW shooting camera brings as being worth the extra cost.

JB

Although I don’t work in broadcast but have many friends who do, they too say that ProRes is the primary content codec and for archival. Yet similarly from my experience shooting and doing post for independent distribution internationally, every client distributor I have encountered requires a ProRes delivery, some wants it in 2K others in 4K. Therefore, we always ship the ProRes to the distributor. When shooting, there are some clients, usually the ones who have better budget, have me shoot in Prores and hand them over the files right at the end of each day. Those are the folks who I don’t usually do the Post for, but I have one client who let me handle the post ingesting only ProRes files. They had a few Sony that I had to convert into ProRes first as they demanded it.
I’m confident that ProRes will still be around for a while.

What is the rationale behind BMD pushing BRAW only and ditching Prores in their recent cameras?
Now RED is no more (maybe) seems like BMD want to be the new RED and go even further

None of us users would know, I think. Although BM seems very like unto Apple, in wanting to have their own isolation toy box, to me.

Not that my thoughts on the matter have any hard data to them.

As a mostly solo operator who loves BRAW, and can use it easily in both Resolve and Premiere, it's OK for me. I can see why for many others it's a really negative choice.

Sent from my SM-S908U using Tapatalk

What is the rationale behind BMD pushing BRAW only and ditching Prores in their recent cameras?
Now RED is no more (maybe) seems like BMD want to be the new RED and go even further

Maybe BMD knows the market and is embolden by it. This could be its charge to overcome and conquer. Maybe they want to make braw the acquisition codec and lave pores as the delivery codec.


Ricardo Marty

Does anyone know the distance between the two top/front quarter twenty screws? I'm looking to get a nato rail for it.

And one more question. Does anyone know the rough time we could expect from BP-U 30,60, and 90 batteries?