BMCC6K Bitrate Readout

My understanding is that the BMCC6K uses the IMX410 sensor from Sony.

This sensor can do 14 bit readout at 4K ~35 frames per second.

Does the BMCC6K use this 14 bit readout when in the 4K crop 30 frames per second mode?

My understanding is that the BMCC6K uses the IMX410 sensor from Sony.

This sensor can do 14 bit readout at 4K ~35 frames per second.

Does the BMCC6K use this 14 bit readout when in the 4K crop 30 frames per second mode?

Not sure, we don't actually know if the sensor that BM sources has the exact specs as Sony lists on their website. Maybe they source a modified version? But my guess is whatever the readout bit depth is, they keep it consistent across all frame sizes and frame rates.

My understanding is that the BMCC6K uses the IMX410 sensor from Sony.

This sensor can do 14 bit readout at 4K ~35 frames per second.

Does the BMCC6K use this 14 bit readout when in the 4K crop 30 frames per second mode?

Not sure, we don't actually know if the sensor that BM sources has the exact specs as Sony lists on their website. Maybe they source a modified version? But my guess is whatever the readout bit depth is, they keep it consistent across all frame sizes and frame rates.

It's interesting, because the XH2s and the new 4D-8K have 12 bit readout as a baseline and tap into the 14 bit readout in their higher resolution / lower frame rate modes, and the dynamic range benefit is quite significant if you look at CineD and Gerald's tests (albeit with more rolling shutter).

I suppose it's also reliant on the BMCC6K having sufficient processing power, but if it's driving 6K/36 12 bit you would imagine it could reasonably drive 4K/24 14 bit.

My understanding is that the BMCC6K uses the IMX410 sensor from Sony.

This sensor can do 14 bit readout at 4K ~35 frames per second.

Does the BMCC6K use this 14 bit readout when in the 4K crop 30 frames per second mode?

It definitely doesn't because BMD just lists one readout speed for the 4K crop.

viewtopic.php?f=2&t=156200

The IMX410 can do 35.34 with a 4K crop and 19.20 fps open-gate. "Open-gate" in this case of it's spec sheet is actually 6064 x 4040. The read-out speeds appear to scale pretty linearly so the sensor should be able to just squeeze out 14-bit 6K 17:9 at 24 fps but it would have the worse rolling shutter on this list (40.73ms). Luckily at around 3072 rows (5804 x 3072 if it were 17:9, it would only be about 32ms and at 4K it could be only 28.29ms. Unfortunately, BMD's own readout measurements for 4K at 12-bit are lower than Sony's so if you adjust it, it's 30.97ms. CineD's measurements seem to show faster readouts than BMD is even claiming but both numbers fall short of Sony's numbers.

Point is, an optional DR boot mode for shooting low-action, HDR scenes would be dope but it would have to be optional so user's aren't forced to deal with additional wobble.

It's interesting, because the XH2s and the new 4D-8K have 12 bit readout as a baseline and tap into the 14 bit readout in their higher resolution / lower frame rate modes, and the dynamic range benefit is quite significant if you look at CineD and Gerald's tests (albeit with more rolling shutter).

I suppose it's also reliant on the BMCC6K having sufficient processing power, but if it's driving 6K/36 12 bit you would imagine it could reasonably drive 4K/24 14 bit.

The XH2s has a very different sensor with insane readout speeds though. The readout speeds that BMD is getting for a 4K DCI crop is 15.13ms which would allow a 66.09fps at max. The IMX410 spec sheet says it should be able to read the same crop at 72.36fps in one 12 bit mode and 97.57 in another. Meanwhile the XH2s can read out 4K at 9.7ms or 103.09 fps in it's 14-bit readout mode. Even in it's 6K open-gate mode, which higher resolution than the BMCC6K's sensor can do, it can do 86.95 fps. It's a readout beast. Also it should be noted that CineD believes there's still some additional in-camera noise reduction being done and they didn't test DR in 12-bit modes so we don't know how much the 14-bit readout effects DR.

BMD could definitely add higher DR-modes that use the 14-bit readout and higher readout (and I assume lower DR) modes that use the other 12-bit readout mode and even the 11 bit readout modes to get higher frame rates without having to crop as much. That would certainly make the most of the sensor but I don't think BMD is interested in doing any of this.

While I would prefer to have the option of 14-bit readout modes at lower frame rates, I actually think those lower DR, higher frame rate modes would be easier to convince them to add. They can just automatically switch to them above certain frame rates and nobody would be losing anything that they don't already have. User's wouldn't complain if they lose DR in 4K above 60fps because they literally couldn't shoot 4K above 60fps before anyway.

In another thread, I mentioned that I feel like there's some resolution/frame rate gaps that feel missing for a camera that is targeting filming for down-sampled 4K DCI delivery. In that thread I mentioned a 3024 x 1600 crop so you wouldn't have to drop down to less than 1/4th 4K resolution to get above 60 fps. I hadn't consider using the sensor's other 12-bit mode and it's 11-bit modes as well, though. That should comfortable allow close to 96 fps at 4K DCI. With a 3K crop, it should be able to close to 120 fps which would be muuuch better than having to drop down to 1920x1080 (really 1920 x 1016 if you consider how it would scale to 4K DCI) to get the same speed. Now I need to revise that post lol

One area where they could really always use 14-bit readout would be for timelapses and still. The fastest timelapse speed is 1 frame every 2 frames which would equate to 16 fps in open-gate.

It’s not that easy to just change the clock speed.

The hardware of the camera is designed around assumptions about the clock speed. The media pipeline, the recording modes. You can’t just flick a software switch to engage a whole different sensor architecture.

A lot of sensor experts like to look up the specs but a lot of the time these other modes can also have other imaging costs, and in this case I’m assuming the RS would be slower being the main one. I say this with no actually knowledge other than generalities whenever I ask these kinds of questions.

JB

It’s not that easy to just change the clock speed.

The hardware of the camera is designed around assumptions about the clock speed. The media pipeline, the recording modes. You can’t just flick a software switch to engage a whole different sensor architecture.

A lot of sensor experts like to look up the specs but a lot of the time these other modes can also have other imaging costs, and in this case I’m assuming the RS would be slower being the main one. I say this with no actually knowledge other than generalities whenever I ask these kinds of questions.

JB

It's not about clock speed changes though. The sensor's input clock is always 72mhz. The change in readout speed between modes is simply how long the ADC on the chip can digitize a row of photo sights. The 14-bit readout definitely has slower readouts then the 12-bit mode that BMD is currently using. With a full sensor readout, it can only do 19.2 fps max as opposed to 39.3 and 40.58 in the 12-bit modes.

Neither of us is under the assumption that there aren't disadvantages of these modes but both have their advantages, too, and it would be nice to take advantage of those when possible. 14-bit readout should help with dynamic range but would need to crop to have good enough readout for even 24 fps but in DR-limited scenes without a lot of motion, that would be useful to have as an option.

Likewise, the other 12-bit mode, I'll call it 12-bit B, must have some quality disadvantage but we know it has faster readouts: about 3.3% faster without a horizontal crop and a pretty consistent 34% improvement with. Considering the only other way to currently shoot above 60 fps, for example, is to switch to a much greater crop with much less resolution, users already have to make a pretty significant trade-off for higher frame rates. Having extended HFR modes using 12-bit B would be nice alternative. If that drops dynamic-range at 4K DCI when shooting above 60 fps then maybe that's worth it for the particular shot in order to keep the same crop and resolution.

The extended HFR modes with 12-bit B would require much less work on BMDs side. If they add a 3K crop on top of that, it should be able to get like 96 fps in 12-bit A and 120 in 12-bit B which I personally think is a more attractive option than shooting 1080p to get the same frame rate.

The media pipeline, the recording modes. You can’t just flick a software switch to engage a whole different sensor architecture.

Switching the readout modes is literally a switch though. I believe it just requires writing a register. The actually readout and digitization is all self-contained in the sensor package. The FPGA is just getting data packets which would look the same in 12-bit A and B. Then obviously in 14-bit they would include 2-bits more data but after it's encoded down to 12-bit (like in the Ursa Cine 12K), the rest of the media pipeline would remain the same.

I’m not an engineer.

Everytime I get into these kinds of conversations with the engineering crew they smile and shake their heads. It’s really not as simple as it seems. Thats all I can say.

They do know what they’re doing. The 4.6k is a dual 11 bit sensor, making a 22 bit image that gets turned into 16 bit lin internally before being stored as 12bit log.

If they thought it was worthwhile going to a 14 bit mode they would. They aren’t in the business of holding back features or having different price point tiers.

More importantly.

No way would they do 14bit if it can only do 19fps full sensor.


JB

I’m not an engineer.

Everytime I get into these kinds of conversations with the engineering crew they smile and shake their heads. It’s really not as simple as it seems. Thats all I can say.

Of course, but what we're talking about are advertised features of the sensor, not something that BMD would have to figure out.

They do know what they’re doing. The 4.6k is a dual 11 bit sensor, making a 22 bit image that gets turned into 16 bit lin internally before being stored as 12bit log.

If I recall correctly, it had two gain circuits so one 11-bit value was pulled from each circuit. If you average those values with 16-bits of precision then you can get in-between values. That's just how the sensor was intended to be used though. I'm not sure what that has to do with the IMX410.

If they thought it was worthwhile going to a 14 bit mode they would. They aren’t in the business of holding back features or having different price point tiers.

More importantly.

No way would they do 14bit if it can only do 19fps full sensor.

But like we said, you can do 14-bit for full-sensor time-lapse recording or for 5K or lower crops of the sensor at at least 24fps. Either way, we both acknowledge that a 14-bit mode would limiting. The other 12-bit readout mode could absolutely be used full-sensor or with crops.

They do know what they’re doing.

Nobody said they're doing anything incorrectly on a technical level but for every product they're going to make a judgement on what they think people would or wouldn't want in a camera and any company can get that wrong. For example, they didn't seem to think people wanted Super 16 or anamorphic crops on the P4K but after enough demand, they added them. I even remember people fighting with me before then that they couldn't be added but once that was added it not only offered a S16 crop, it also basically removed any need for the 1080p crop because it handled the same frame rates at higher resolution. Similarly they assumed an S16 crop would be desirable on the BMCC6K even though there isn't much a point. As a result, the BMCC6K and PYXIS have way worse options for sub 4K HFR shooting than the P4K and P6K.

And actually I'd argue that there are a few things technical things that got past them. Like how the BMPCC6K's highest resolution modes exceeds the bandwidth of an recording media it supports at max quality and frame rate: 6K Q0 at 50 fps can use up to 805MB/s but the fastest recording media it supports caps out at 640MB/s.

What I'm suggesting with the extended frame rates with 12-bit B wouldn't be taking away from the camera at all even if the DR at those frame rates suffered.

It would be nice if someone from BMD chimed in on this.

Of course, but what we're talking about are advertised features of the sensor, not something that BMD would have to figure out.

You keep saying it like it’s no big deal. I bet it is and i bet there are technical reasons they have made this choice.

If I recall correctly, it had two gain circuits so one 11-bit value was pulled from each circuit. If you average those values with 16-bits of precision then you can get in-between values. That's just how the sensor was intended to be used though. I'm not sure what that has to do with the IMX410.

It proves that for years when the sensor has high DR and it’s worth using higher bit depths they will design the camera to do so.

But like we said, you can do 14-bit for full-sensor time-lapse recording or for 5K or lower crops of the sensor at at least 24fps.

We don’t know if the hardware can do it. You keep saying the sensor has a switch, but there’s a whole different firmware that likely has to be stored and loaded not to mention calibrated. Most people don’t notice this on the existing cameras but that two or three second flash when you switch codecs or between 12K and 8K is actually rebooting the camera and loading an entirely different firmware. You need to be able to store that, spend the time to develop it and code for it, usually a different calibration of the sensor. It all takes time and resources and has to be PLANNED for. The shipped camera may not even have enough memory to store this builds that frankly i don’t see any value in.

Even if you could store a 14 bit file is there any evidence the sensors’ DR would be any better? I’m not sure it has enough DR to warrant a 14 bit file anyway.

They do know what they’re doing.

Nobody said they're doing anything incorrectly on a technical level but for every product they're going to make a judgement on what they think people would or wouldn't want in a camera and any company can get that wrong.

I don’t think anyone wants a 14 bit 19fps mode even if it could be done on the existing hardware.

For example, they didn't seem to think people wanted Super 16 or anamorphic crops on the P4K but after enough demand, they added them.

Because that kind of feature is easy to add.

6K Q0 at 50 fps can use up to 805MB/s but the fastest recording media it supports caps out at 640MB/s.

It’s very scene dependent and isn’t at that rate sustained all the time.

What I'm suggesting with the extended frame rates with 12-bit B wouldn't be taking away from the camera at all even if the DR at those frame rates suffered.

But you don’t know.

It would be nice if someone from BMD chimed in on this.

They won’t.

JB

You keep saying it like it’s no big deal. I bet it is and i bet there are technical reasons they have made this choice.

Or maybe there aren't. Sometimes things just don't occur to people. It happens.

It proves that for years when the sensor has high DR and it’s worth using higher bit depths they will design the camera to do so.

Not really. I'm pretty sure the Fairchild sensors they used were technically for scientific use, not for consumer cameras. There was probably a scientific purpose to making the sensor provide two 11b readouts at different gains and combining them was the only way the sensors could provide a dynamic range usable for cinema camera purposes. And of course, that's the only way they could get 12b footage out of the camera. I don't even think that sensor has an option for readout modes less than 22b.

Again, while I think it would cool to have a 14b readout mode for certain situations, I'm really more-so pushing for the extended frame rate thing with the second 12b readout mode.

We don’t know if the hardware can do it. You keep saying the sensor has a switch...

I mean I don't know what to tell you. The sensor literally can do it according to it's own spec sheet and there literally is a "switch" to set modes. I couldn't find a full datasheet for the IMX410 specifically but I could find one for another Sony sensor, the IMX415, and the sensor is a peripheral that you send commands to and setup by writing to memory-mapped registers. It gives you the address in memory (or maybe it's address offset?) for the horizontal start position, for example, and you write to address to set it. It's not all that any different from how you interact with any other memory mapped IO device.

...but there’s a whole different firmware that likely has to be stored and loaded not to mention calibrated. Most people don’t notice this on the existing cameras but that two or three second flash when you switch codecs or between 12K and 8K is actually rebooting the camera and loading an entirely different firmware. You need to be able to store that, spend the time to develop it and code for it, usually a different calibration of the sensor. It all takes time and resources and has to be PLANNED for. The shipped camera may not even have enough memory to store this builds that frankly i don’t see any value in.

Maybe that happens on the Ursa's but there aren't two of three second flashes when switching between crops on the 6K FF or P4K. It's instant. That does happen when switching between BRAW and ProRes and when switching between playback and record mode though but that makes sense.

They are switching firmware, but you're misunderstanding what that means in this case. The data that an FPGA is flashed with to reconfigure itself is often called firmware. That's likely what they're talking about. That has nothing to do with the sensor.

An FPGA only has a limited amount of gates so instead of wasting them by having encoders and decoders for ProRes and BRAW when only one will be used at any time, it reconfigures the FPGA to only make those things available as they're need. For example, in the camera's record mode you don't need hardware DEcoding of BRAW or Prores, just ENcoding so it's just configured to encode whichever codec you have selected. Once you switch codecs, it reconfigures it again. Then once you're in playback mode it reconfigures it for DEcoding and probably shuts off the sensor or puts it in standby. On the P4K you can even see some signs of a reset when you play a Prores clip then play a BRAW clip right afterwards.

Changing settings on the sensor does not require the camera to reset though because the sensor is a separate peripheral. Sony makes image sensors for most cameras including the Fujifilm X-H2S which we know uses a 14-bit readout for it's lower frame rates then switches to 12b at higher frame rates.

On the 6KFF, a 14-bit readout mode would require more gates to be used by the BRAW encoder in order to handle a 14b source but it wouldn't require any change to handle image data from the alternate 12b readout mode. The packets from the sensor would be no different and the FPGA would be blind to the change. From it's point of view, it's still just receiving 12b image data.

.
Even if you could store a 14 bit file is there any evidence the sensors’ DR would be any better? I’m not sure it has enough DR to warrant a 14 bit file anyway.

I don't personally know how much 14b readout would help dynamic range. If it doesn't though then why does the Ursa 12K do it? Why does the X-H2S do it? They record to 12b and 10b codecs respectively so it's not for post-processing.

When Gerald Undone tested dynamic range at F-log2 on the X-H2S at 24p (14b readout) vs 60p (12b readout), it showed like the 12b readout had about 0.7 stops less DR. How much would it effect DR in the BMCC6K? I don't know but doesn't appear to be pointless.

I don’t think anyone wants a 14 bit 19fps mode even if it could be done on the existing hardware.

Where did anybody ask for that in this topic? The only thing similar that I said was that it could be used in timelapse mode...which it can.

Because that kind of feature is easy to add.

A bunch of people told me it wasn't though. They told me it was impossible. Even after I told them that sensors allow you to select the number of rows and columns it reads out I got "The sensor doesn't support it". Then they added it. You know what that probably required? It required them to write to some registers to enable Window Cropping mode, then they set the start offset, width, and height. Then I'm sure they did a ton of testing of course.

What I'm getting at is that it didn't require them to load new firmware just to switch the sensor into Window Cropping mode.

It’s very scene dependent and isn’t at that rate sustained all the time.

Of course but unless they're curbing the max bitrate for the Q0 mode as frame rate goes up (which wouldn't be constant quality any more) it still means that the top resolutions and framerates the camera can shoot can drop frames even if you're using the fastest recording media the camera can use. That's strange. Had they upgrade the USB-C port to 10Gb or used CFexpress then that wouldn't be an issue.

But you don’t know.

Know what? That it wouldn't take away from the camera at all to added extended frame rates? Actually I do know that. I understand where you're coming from. You think it would require adding alternate firmware and that it may not have the memory for that and whatnot but that's not how these things work even if an FPGA is in the mix. I know you're in contact with BMD and you have been working with them since they first started making cameras but you definitely misunderstood what they were telling you about the firmware thing.

They won’t.

Well that sucks. Hope you're wrong.

You keep saying it like it’s no big deal. I bet it is and i bet there are technical reasons they have made this choice.

Or maybe there aren't. Sometimes things just don't occur to people. It happens.

It is. I talk to these guys daily at the moment.

We don’t know if the hardware can do it. You keep saying the sensor has a switch...

I mean I don't know what to tell you. The sensor literally can do it according to it's own spec sheet and there literally is a "switch" to set modes.

And I keep saying it’s not just as simple as setting a register on a sensor. Theres a bunch of stuff happening after the sensor. Or if the camera can even store the firmware for such a mode. Of if they even have the engineering time or resources to make this a priority. There’s a zillion reasons.

Well that sucks. Hope you're wrong.

Historically BMD never ever comment on this stuff. I mean i feel like I’m travelling back to 2014 when these conversations used to happen all the time, especially around using different sensor modes for the common 4K sensor they were all using back then. Back then DB, Aperture and CION were all going to show BMD how it’s done. And they didn’t.

I’m just telling you what I know from casual second hand conversations when these topics come up.

I do know that it’s really fast and easy to get the image to 85% good. The last 15% is really really complicated and really hard. I know this from more than 10 years of being on the sidelines and testing many many iterations of many cameras some that never even made it to market because the issues couldn’t be resolved. It’s disheartening to see posters saying it’s “easy” to just flip a register in a camera and activate some other alternate mode. It’s never ever ever as simple as that. I know that first hand.

JB

And I keep saying it’s not just as simple as setting a register on a sensor. Theres a bunch of stuff happening after the sensor. Or if the camera can even store the firmware for such a mode. Of if they even have the engineering time or resources to make this a priority. There’s a zillion reasons.

Again there's no additional firmware they need for a 14 bit readout. The firmware for the FPGA is for codecs, LUT processing, scaling, maybe the histogram: post processing things that need speed. A 14-bit readout doesn't need a separate codec. It would need some modification to the current BRAW encoder to support 14-bit source packets but not an entirely separate firmware. Using the other 12 bit readout mode wouldn't require any changes to the BRAW encoder and the decoder wouldn't need to be changed for either of these things. Even if they needed to change more than a few registers, which I'm sure is the case, those are things are set by the general purpose CPU when the mode is changed and the settings are maintained by the sensor until they're changed or the sensor is reset.

The P4K came out 6 year prior to the 6K FF and includes encoders and decoders for BRAW and Prores. Just a month or two ago, it got a file browser, webcam support that requires simultaneously encoding an MJPEG stream, internet access via USB-C with upload to FTP, SMB, and BMD Cloud. These are features it definitely was not designed with in mind but it was able to get them because cameras don't ship with just enough storage to support features at launch.

The P4K has a 8GB of eMMC storage, 2GBs of RAM, and a Xilinx Zynq FPGA which includes at least one ARM core. The 6K FF has at least that and that's a lot of space for an RTOS. Hell, that's enough memory and space to install Gnome OS. Granted, I'm sure they have that partitioned to some degree. They probably even have a duplicate copy of the OS is upgrades go wrong or at the very least there's a recovery partition but still, that's plenty of space considering FPGA firmware takes up tens of MBs without compression.

Honest question. What do you think would be required to change the camera's post-processing in order to support this faster 12 bit readout mode that the sensor has?

Well that sucks. Hope you're wrong.

It’s disheartening to see posters saying it’s “easy” to just flip a register in a camera and activate some other alternate mode. It’s never ever ever as simple as that. I know that first hand.[/quote]

Nobody is saying it's an afternoon's worth of work. Read what I'm saying, not what you think I'm saying. For all I know, the other 12 bit readout mode has no quality difference and just requires additional power or something. If that's the case then they'd have to test what crops and frame rates they could handle at that power draw and that takes time. Like I said, I don't have the IMX410's full data sheet so I don't know what that mode is called and what it's trade-offs are but I do know that it wouldn't require completely different firmware to support changing the sensor's readout mode.

I'm aware that you've been deeply involved in testing their cameras but firmware development of a finished product is very different from camera prototyping which is going to require a bunch of revisions of board designs and hardware combinations. When BMD is making a camera, they're creating boards that didn't exist with soldered on combinations of parts that likely haven't been used together in an enclosure they've never been used in before so testing is definitely required. However the way they interact with these parts is consistent with how anyone else would have to interact with them and that includes the sensor.

Here's the data sheet for the IMX415-AAQR-C. It's much smaller sensor and it's only UHD but it's still a Sony sensor and it gives you a sense of how a manufacturer would interact with this package that Sony made.

https://www.alldatasheet.com/datasheet- ... AQR-C.html

Look through it a little and you'll see how software/hardware communicates with it. These things are platforms that are made to offer functionality in way that abstracts away the complexity of what they do. They're not plug and play but they BMD definitely doesn't need to write and alternative OS or something to handle different bits being set on the sensor.

I guess you know best. You know exactly what is in this camera and you have a history of building and making your own camera with this sensor too right?

I’ll stop contributing as all you’re doing is bringing up engineering knowledge of which i have no specialised understanding.

I’m only reporting what I’ve been told working intimately with the development of most of their cameras….

…And years of seeing these kinds of outside engineer posts about why the cameras aren’t being designed or used to their full potential.

JB

I guess you know best. You know exactly what is in this camera and you have a history of building and making your own camera with this sensor too right?

No, and you know that's not what I'm saying. Just because the way that this stuff works is magic to you doesn't mean it's magic to everybody. Do you think BMD are a company full of the only people in the world who know how electronics and software interact? No. There are people all over the world who varying degrees of knowledge on how this stuff works. You can find hobbiest on Youtube making their own PCBs, firmware, etc. that are essentially doing the same thing BMD does just a smaller level with less money and less access to parts. What they're doing is that same though: they get components, wire them up, and communicate with them via a microprocessor using whatever interface it provides.

There's even projects like the Mister FPGA which is an ecosystem built around a specific FPGA board where people are writing "cores" (same thing as firmware in this conversation) that reconfigure the FPGA to function like old computers and video game consoles. Others use boards like that to do things like hardware accelerated decompression, encoder, and signal analysis in the absence of any already available ASICs that can do those task for them. They're doing exactly what BMD is doing for the same reasons that BMD is doing them.

I'm not claiming I know better than BMD but I'm not coming from zero knowledge and complete speculation. I know the chips inside the P4K because I found a teardown of the camera and looked up the part numbers of the chips. I know the 6K FF has at least those specs because it's 6 years later and those parts or better ones are much cheaper. I don't know exactly what's in the 6K FF but I'm not guessing either.

I've been very clear about the fact that I don't know everything about the IMX140. I said repeatedly that I haven't been able to find it's full data sheet and I don't know the specifics of how it achieves faster 12-bit readouts. I just know it can do that based on the limited information that's available in Sony's flyer about it. I've been clear about what I don't know, what I'm speculating on, and what I do know.

I’ll stop contributing as all you’re doing is bringing up engineering knowledge of which i have no specialised understanding.

Exactly! I'm not expert on this stuff either but I have some knowledge in programming and electronics that I can work from. You're assuming that I'm just saying "I can make a camera better than BMD" but I'm not saying that and don't think that. That's why I was hoping they would chime in.

I’m only reporting what I’ve been told working intimately with the development of most of their cameras….

…And years of seeing these kinds of outside engineer posts about why the cameras aren’t being designed or used to their full potential.

I've seen them for years, too, and I'm usually the one keeping people in check about how complicated these things are. You're misunderstanding what I'm saying and misrepresenting what the task requires to such an extent that I had to link to a data sheet for another Sony sensor to show you that, actually, just because these things can be complicated doesn't necessarily mean that they require moving the earth to do. The way you were describing it is as if Sony just gave them the parts for a sensor and BMD had to put it together and get it working themselves. That's why I kept reiterating that it's a self-contained peripheral that gets interacted with by poking at memory locations that set registers in the sensor to change what it outputs.

A lot of us wish that we had the same level of access and communication with BMD that you do so we can ask questions and stuff but we don't. We have to just bring stuff up on forums and hope that someone from BMD sees and maybe even responds to them.