[Paul MaudDib]

I don't think you need something like OpenGL to protect their IP. Just a simple API that has commands that for example can demand the raw data from the sensor, or that tells the sensor to move by a certain amount..

Well, what I mean by that is actually to control the low-level action of reading out the sensor, in the same fashion that shader languages (GLSL) control rendering the actual pixels in an image. What I want is not just to demand raw data from the sensor- that's the equivalent of an OpenGL rendering call - but to demand that raw data from the sensor be read in a specific set of processing operations, pixel by pixel, the equivalent of a GLSL shader.

In other words - what we can do right now is ask for a RAW file. I want to be able to control how that RAW file is generated. In order to protect the intellectual property of the company (low level implementation details of the sensor) we come up with some generic language, and the image processor implements the commands that are possible in that language. Physical operations are controlled by signal pins from the image processor (as now, except on a per-pixel basis) and also by interconnecting them via an FPGA (for setting the overall signal path).

Some things just aren't possible to alter once the data has been read out from the sensor (eg analog signal amplifier gain setting). Some things (dark current, etc) vary across time and can't really be recovered after the fact. Right now camera companies use "general" approaches to these things, and I don't think those are necessarily the best approach for every single situation. Perhaps you can just outright do better than the defaults in certain situations, or trade off certain aspects of the sensor's performance to boost other aspects. I'm not even convinced that the defaults are "the best" overall - there's certainly no "right way" to render an image, I don't see why there would be a "right way" to capture one.

For an example of what can be accomplished with this, check out Magic Lantern's "Dual ISO" feature. By reading out alternate lines of the sensor at different ISOs, they can boost the dynamic range by 3 stops, at the cost of losing half of the vertical resolution. Right now what they have is awkward hacks on top of the default software. What would be possible with much finer grained control, or by tweaking other operations/parameters in the process?

---

Last edited by Paul MaudDib; 10-21-2014 at 04:16 PM.

[jsherman999]

Well, what I mean by that is actually to control the low-level action of reading out the sensor, in the same fashion that shader languages (GLSL) control rendering the actual pixels in an image. What I want is not just to demand raw data from the sensor- that's the equivalent of an OpenGL rendering call - but to demand that raw data from the sensor be read in a specific set of processing operations, pixel by pixel, the equivalent of a GLSL shader.

In other words - what we can do right now is ask for a RAW file. I want to be able to control how that RAW file is generated. In order to protect the intellectual property of the company (low level implementation details of the sensor) we come up with some generic language, and the image processor implements the commands that are possible in that language.

Some things just aren't possible to alter once the data has been read out from the sensor (eg analog signal amplifier gain setting). Some things (dark current, etc) vary across time and can't really be recovered after the fact. Right now camera companies use "general" approaches to these things, and I don't think those are necessarily the best approach for every single situation. Perhaps you can just outright do better than the defaults in certain situations, or trade off certain aspects of the sensor's performance to boost other aspects. I'm not even convinced that the defaults are "the best" overall - there's certainly no "right way" to render an image, I don't see why there would be a "right way" to capture one.

Interesting, but I suspect that control over things down at the dark current level isn't going to bring anything very useful beyond what the raw generation already does. I mean it's already about as optimized as you're going to get - you could tweak things but it's probably not going to get you significant SNR, DR or color improvement. The analog gain setting is just going to mirror a brightening via ISO bump, no?

It might be nice to be able to completely turn off the raw NR 'smoothing', or have a rheostat on that, but any other control would probably be 'fun to play' realm and not 'IQ improvement' realm. Or what specifically did you have in mind that you wanted to be able to change.

[Paul MaudDib]

Interesting, but I suspect that control over things down at the dark current level isn't going to bring anything very useful beyond what the raw generation already does. I mean it's already about as optimized as you're going to get - you could tweak things but it's probably not going to get you significant SNR, DR or color improvement. The analog gain setting is just going to mirror a brightening via ISO bump, no?

ISO bump adjusts the analog gain setting. However, it typically only works in whole stops. The rest of it is done by digital adjustment. So if you dial in ISO 800, it sets the amplifier for 800. If you ask for ISO 540 - it sets the amp to 800 and digitally amplifies -0.67 stops. That's why non-whole ISO steps are bad - you get the noise of the next whole setting and you lose some of your color depth too, as you squished the curve down into a smaller range of bits.

Basically the analog signal gain controls mapping electrical signals into digital values - digital signal gain controls what happens to the digital values after that. Over-amplifying and then squishing your digital signal produces worse results than applying the proper amount of amplification in the first place. They aren't equivalent due to clipping, bit-depth limitations, etc.

As a practical example of what you can do, the Magic Lantern guys got a 3 stop DR improvement by tweaking the amp setting during readout (at the cost of half of their vertical resolution). Check out "Magic Lantern Dual ISO".

If you assume that the signal path is fixed, then yeah there's some limitations on what you can do - you can turn some knobs, but the bulk of it is fixed. But the Samsung guys basically turned their image processor into an FPGA, so they can reconfigure the signal path on the fly. Attach or detach electrical elements, determine the order things happen, and so on. In combination with some signal pins from the processor, pixels could (theoretically) be processed in several different ways in arbitrary patterns as the image processor dictates.

Couple dumb ideas:

• Reading out a fraction of the normal video rows for a "high speed camera" setting
• For low light, you read out a 2x2-pixel block into the signal amplifier at once, to produce higher signal level (2 stops) at 1/4 the normal resolution
• Adjusting signal amplifier gain for a 16x16 pixel block by taking one picture, finding best gain settings for each block, and then taking a second with adjusted gain for each block. Use the 2 raws to produce a final adjusted image that smooths the joins between the different Zone settings. The idea being to control contrast kind of like a staining developer - get lots of contrast out of each region while keeping everything within the DR of the sensor. The first exposure is the "stain layer", the second is the "silver layer". This would increase color depth.

[kadajawi]

Well, what I mean by that is actually to control the low-level action of reading out the sensor, in the same fashion that shader languages (GLSL) control rendering the actual pixels in an image. What I want is not just to demand raw data from the sensor- that's the equivalent of an OpenGL rendering call - but to demand that raw data from the sensor be read in a specific set of processing operations, pixel by pixel, the equivalent of a GLSL shader.

In other words - what we can do right now is ask for a RAW file. I want to be able to control how that RAW file is generated. In order to protect the intellectual property of the company (low level implementation details of the sensor) we come up with some generic language, and the image processor implements the commands that are possible in that language. Physical operations are controlled by signal pins from the image processor (as now, except on a per-pixel basis) and also by interconnecting them via an FPGA (for setting the overall signal path).

Some things just aren't possible to alter once the data has been read out from the sensor (eg analog signal amplifier gain setting). Some things (dark current, etc) vary across time and can't really be recovered after the fact. Right now camera companies use "general" approaches to these things, and I don't think those are necessarily the best approach for every single situation. Perhaps you can just outright do better than the defaults in certain situations, or trade off certain aspects of the sensor's performance to boost other aspects. I'm not even convinced that the defaults are "the best" overall - there's certainly no "right way" to render an image, I don't see why there would be a "right way" to capture one.

For an example of what can be accomplished with this, check out Magic Lantern's "Dual ISO" feature. By reading out alternate lines of the sensor at different ISOs, they can boost the dynamic range by 3 stops, at the cost of losing half of the vertical resolution. Right now what they have is awkward hacks on top of the default software. What would be possible with much finer grained control, or by tweaking other operations/parameters in the process?

Oh, ok. Thanks! While I'd still be happy with just being able to get the raw data and having control over the sensor placement etc., your suggestion would be even better (but even less realistic, given that apparently Pentax has rejected the idea of an API already).

[civiletti]

Still no Pentax full frame digital? I guess I'll sell all my aps-c gear, spend the proceeds on lottery tickets, and buy the 645z if I win.

[ElJamoquio]

Still no Pentax full frame digital? I guess I'll sell all my aps-c gear, spend the proceeds on lottery tickets, and buy the 645z if I win.

wait til NEXT year!!!!!


(actually I think it's true, but I've thought that since 2012).

[Clavius]

wait til NEXT year!!!!!


(actually I think it's true, but I've thought that since 2012).

A nice old Italian saying goes: "Tomorrow is always the busiest day of the week."

[JimmyDranox]

Latest rumor from Canon speaks about a full modular DSLR to come at NAB 2015.

Canon Working on a Modular DSLR « NEW CAMERA

So, a modular camera is not impossible, if someone really wants to make it. And in my opinion, is quite desirable from a user perspective.

[Clavius]

Latest rumor from Canon speaks about a full modular DSLR to come at NAB 2015.

Canon Working on a Modular DSLR « NEW CAMERA

So, a modular camera is not impossible, if someone really wants to make it. And in my opinion, is quite desirable from a user perspective.

So now Canon is making the LX-D? It seems like all camera brands take very good notice of this forum EXCEPT Pentax themselves.

[Fogel70]

Latest rumor from Canon speaks about a full modular DSLR to come at NAB 2015.

Canon Working on a Modular DSLR « NEW CAMERA

So, a modular camera is not impossible, if someone really wants to make it. And in my opinion, is quite desirable from a user perspective.

I suspect this will be a "professional" camera designed like some of the medium format systems.
There has also been rumors that Canon is looking into making medium format cameras, so maybe this is part of that.

Edit: looking further into this, it looks like it's a video oriented DSLR that is to be of modular designed. So maybe it's done for better optimizing the camera for handling it like a video camera.
With a grip optimized for video. LCD that can be attached to the side of the camera, OVF that can be replaced by EVF...

[rawr]

a video oriented DSLR that is to be of modular designed.

Inspired by Red, competing with Red, probably. No menace to Pentax.

[kadajawi]

I agree. Probably professional video gear, nothing that competes with Pentax as Pentax doesn't want to compete in the video or professional segment.

[RonHendriks1966]

Modular, yes possible, but probably very expensive. The 645Z is much cheaper then al those Hasselblads who are somehow modular.

[Poit]

So now Canon is making the LX-D? It seems like all camera brands take very good notice of this forum EXCEPT Pentax themselves.

My thoughts exactly. We should be getting royalties!

[Big Dave]

I personally love flippy screens, but the flippy screen may not be a good example of camera company conservatism, just design priorities at work.

The Sony Alpha 99 and then A7 series were the first full-frames with flippy screens, despite full-frames being on the market for years. Pentax innovated by putting a flippy screen on the 645Z, perhaps showing that flippy screens were a useful add-on to even high-end professional grade cameras. Then after the 645Z broke the ice, the Nikon D750 followed, and is still the only conventional full-frame DSLR to have a flippy screen from either Canon or Nikon.

Even a recent 'pro grade' shooter like the Canon 7DII was designed without one, despite many other Canon DSLR's having flippy screens. So it seems like camera makers choose flippy screens if they have design reasons to do so, rather than the lack of a flippy screen being emblematic of conservatism per se.

But I certainly hope any new Pentax FF has one.

My K5 II lacks the articulated screen, but my A7R has it. This causes me to grab the A7R more often for creative work. It allows easy shooting at ground level and over the heads of crowds too. I can see where it would be invaluable on the 645Z in a studio setting.