Yep I know, which camera......

[michael.h.f.wilkinson]

45 minutes ago, vlaiv said:

How did you find calibration of that ASI183MC - given that it does not have set point cooling and suffers from amp glow?

With the short exposures, and Bortle 4-5 skies, amp glow is manageable, as long as you take darks at (approximately) the same temperature as the lights. 

[DaveS]

4 hours ago, vlaiv said:

I think that reason for having two green as opposed to two blue or red pixel is human eye sensitivity. It also adds to resolution, as we are most sensitive in brightness rather than color change and brightness that we perceive is closely related to shape of green channel.

Lack of mono sensors is tied to economics of scale I believe - it is much more cost efficient to have OSC sensor in consumer cameras and these are driving force behind mass production of the sensors.

I think there would be some benefit to daytime photography from having one G pixel replaced with L. Better color rendition is one, improved low light sensitivity is another.

There has to be some rationale behind using RGGB instead of say RLGB. Not sure what it is, but I doubt that they "simply did not think of that"

Never underestimate the power of human stupidity

[rotatux]

On 02/02/2021 at 14:05, vlaiv said:

There has to be some rationale behind using RGGB instead of say RLGB.

It may have something to do with color management : the cheapest for cams is to output images with a color model similar, if not identical, to our display devices, which are near exclusively RGB. Using alternative color models at capture time such as LRGB, (L)LRB, (L)Lab, Cmyk, Yuv etc would incur an in-camera processing cost which means more complex embedded code, more power consumption, more latency to display image, and so on.

Now we start to have S-log light curves and the like used at capture time in some devices, which has a non null processing cost too, so lines are starting to move. Maybe a few years from now we could hope for other color models to appear.

[vlaiv]

41 minutes ago, rotatux said:

It may have something to do with color management : the cheapest for cams is to output images with a color model similar, if not identical, to our display devices, which are near exclusively RGB. Using alternative color models at capture time such as LRGB, (L)LRB, (L)Lab, Cmyk, Yuv etc would incur an in-camera processing cost which means more complex embedded code, more power consumption, more latency to display image, and so on.

Now we start to have S-log light curves and the like used at capture time in some devices, which has a non null processing cost too, so lines are starting to move. Maybe a few years from now we could hope for other color models to appear.

Well, actually raw RGB of camera space is significantly different than sRGB that is commonly used in display devices.

All color conversion processing usually boils down to one matrix multiplication - that is already there to convert from raw RGB to sRGB and possibly gamma function (needed in case of sRGB).

For example - this is response of RGB sensor:

and this is virtual response of sRGB (note the negative values - this is because sRGB has narrower gamut than human vision and can display some colors that humans can see):