Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

RGB vs. LRGB worked example

imaging astrophotography
  • Please log in to reply
274 replies to this topic

#1 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:11 AM

Here is a worked example of the noise behavior when doing a raw stack of RGB vs. RGB combined with L.  This is about the same as comparing OSC to RGBL - assuming OSC gathers the same data in 3 1m exposures as 3 1m exposures of r, g, b.  That isn't exactly right because the g pixels in OSC are doubled - but it's close.

 

A key point in studying the noise behavior in different scenarios is to have well defined signal and a well defined noise model.  For RGB vs. LRGB the main driver is total time - and the main driver for that is to reduce the impact of Poisson or shot noise.  So in this study I assume the only noise is shot noise and it is well behaved.  I also assume the colors are well calibrated and that the L filter has the net response of the sum of R, G, B.  Even if these things aren't exactly true they will modify the results only slightly - through a different noise model.

 

The first thing I plot is a single pixel and its values after 1m exposures in R, G, B.  And I calculate the L value as the sum of the pixels.

 

In such a short exposure you can't be sure what the color or luminance is.  It may appear to be red but with more exposure time you realize it is blue.

 

Also note that the signal here ultimately corresponds to an electron arrival rate in electrons per minute.

 

1mrgb.png

 

The error bars in each bar correspond to the shot noise in that channel - and as you can see the noise is relatively large and the SNR in each channel is not great.  Given the spread in R G B values it looks strong in red and weak in blue - but you can't be sure.

 

This is with a total of 3 minutes exposure time - 1m in each channel.

 

Frank


  • bilgebay and vdb like this

#2 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:13 AM

If we then do 10 more 1m exposures in each channel, we might get results like this:

 

10mrgb.png

 

With more exposures to compare, you can see the green clearly dominates - but it's hard to tell how the red compares to the blue.

 

Frank



#3 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:14 AM

If we sum 10 1m exposures in each channel and calculate the luminance from them - it represents 30m exposure time - and you can see the color is much more defined - and the SNR in all terms is higher.

 

NoiseIn10mrgb.png

 

Frank

 

 



#4 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:16 AM

Since that improved things - let's go for a full hour of exposure, for 20x1m in each channel.  The SNR improves across the board:

 

20mrgb.png

 

Frank



#5 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:18 AM

But if we are more concerned about luminance - let's just do 30m of rgb and then 30m of luminance.  The rgb snr won't improve - but lum will.

 

10mrgbAnd30mL.png

 

You can see that compared to the full one hour of rgb, the lum snr has gone way up - but the rgb snr is back down to where it was when we only did 30m total of rgb.

 

Is this better than 1 hour of rgb?

 

Frank



#6 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 04:26 AM

But there is one more trick to pull.  Let's smooth out the rgb data and leave lum unbinned.  When you bin a channel by 2x2, its signal will go up by x4 and the noise will go up by x2 - so the snr will double.

 

This is what you get when you do 30m of rgb followed by 30m of L - and then bin the RGB after calculating L unbinned:

 

10mBinnedrgband30mL.png

 

Look at that!  This is a clear winner in SNR - both in color and luminance.  LRGB wins hands down compared to the same amount of time on RGB.

 

...  EXCEPT ...  we have binned the color information and have no idea what the result actually looks like.

 

We could have also binned the L and made its SNR go up x2 - but then it would look soft and lose detail.

 

The same happens with the color info when you bin it - but the theory is that you won't notice that blurring.  The combination of higher detail and SNR in lum will dominate the improvement - combined with the smooth and high SNR color info.

 

There is no way I can show that trade off in a single graph - you would need to actually compare the resulting images after processing - and see which one you like more.  You could also try binning the lum x2 and see if you like that even more.

 

In terms of snr unbinned, spending part time on rgb and part time on lum will boost lum but leave color info noisy.  If you then bin the color info - its snr will go up - but your eye may pick up that the data have been manipulated - particularly in areas of detail and small stars.

 

Which works better?  Well - opinions differ in CN - and that is what you would expect since it involves personal preference and imaging tastes.  Since it is a trade off combined with a processing trick.

 

Frank


  • happylimpet and 42itous1 like this

#7 Stathis

Stathis

    Messenger

  • -----
  • Posts: 490
  • Joined: 05 Oct 2007
  • Loc: Greece

Posted 30 October 2017 - 07:20 AM

Some people say not to bin color because you will lose finer color detail, but I have not observed this. It would be nice for a comparison that actually shows any loss in color detail when binning 2x2.


Edited by Stathis, 30 October 2017 - 07:21 AM.


#8 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 07:39 AM

When LRGB first became a thing - it was directly connected with the additional benefit of reducing the impact of read noise when binning the rgb *during acquisition*.  What I show above does not include any benefit you get by binning color during acquisition with a ccd.  If you binned during acquisition with a cmos sensor - you would only get the x2 win in snr that I talk about.  But in the past, read noise was more of a concern - and ccd's had more read noise that would benefit from binning - so there was a motivation to do LRGB rather than RGB - and to bin the RGB during acquisition to reduce read noise.

 

Nowadays I think the people who do LRGB realize that binning during acquisition doesn't win much anymore.  So you can take it all unbinned.  But they still want to do additional shots of pure L, then smooth the rgb - and mix in with the L.

 

The problem with "doing a comparison" is that there is a lot of processing involved - and it is no longer a simple noise model and comparison of SNR's.  It amounts to personal preference and how you process.  So there is no clear win and no clear recommendation.

 

Furthermore, there is no clear ideal amount of how much rgb you should take vs. L for a given amount of time.  It's just not a well defined problem that has a clear path for best results.

 

Frank


  • R Botero likes this

#9 maxmir

maxmir

    Ranger 4

  • ***--
  • Posts: 382
  • Joined: 03 Oct 2005

Posted 30 October 2017 - 08:48 AM

Looks like your shooting 50% L of total time. Most shoot 20-30% of L per unit time.

#10 Stathis

Stathis

    Messenger

  • -----
  • Posts: 490
  • Joined: 05 Oct 2007
  • Loc: Greece

Posted 30 October 2017 - 12:21 PM

There are still people that have cameras with 10e + read noise. A lot of people. So binning the RGB applies as it did years ago. Also, no processing is necessary for a comparison, just an LRGB combination in Pi with STF for preview. It would show any differences.


Edited by Stathis, 30 October 2017 - 12:22 PM.


#11 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 03:31 PM

Looks like your shooting 50% L of total time. Most shoot 20-30% of L per unit time.

That's just an example for clarity.  No matter where you make the cut to stop shooting rgb and instead shoot lum, you will no longer be getting color info and the SNR in the color channels will not improve - unless you bin and exchange cleaner looking color for less detail in that color.

 

People can try different things and see what ratio of lum time to color time works best.  You say that 20-30% is a typical number.  There is no clear win anywhere - so for others it might be 0% lum.  The fact that there is no clear optimum value for lum in terms of the final image quality is indicative it depends heavily on personal preference and how the processing is done.

 

Frank



#12 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 03:40 PM

There are still people that have cameras with 10e + read noise. A lot of people. So binning the RGB applies as it did years ago. Also, no processing is necessary for a comparison, just an LRGB combination in Pi with STF for preview. It would show any differences.

My impression is that fewer people are binning during acquisition of the r g b - but I could be wrong.  It used to be thought that all ccd's would count only one hit of read noise when reading binned - but it depends on the ccd - so there is less guaranteed win by binning during acquisition, as opposed to capturing the colors unbinned and smoothing later.

 

There is also a changed attitude nowadays that for RGB or LRGB, sky background usually dominates read noise so it is less of a concern.

 

Either way - it's the same idea of exchanging detail in the color for less noisy looking color.  It's just a slightly different noise model.

 

As for processing - there may be a pushbutton in PI to combine lum with color - but it is still doing a form of processing - and there isn't just one way to make that combination.  And if people are doing additional processing on top of that to make the final picture - and the only goal is a better looking end result - it makes it hard to compare one to another.

 

Do LRGB people with PI just accept the way it blends lum with rgb - or do they tweak the settings - in effect controlling how heavily the lum is folded in?  There are a lot of knobs to turn when trying for the best results, whereas when you combine just r, g, b it is more well defined.

 

Frank



#13 AndreyYa

AndreyYa

    Vostok 1

  • *****
  • Posts: 138
  • Joined: 05 Dec 2006
  • Loc: Los Gatos, CA

Posted 30 October 2017 - 08:53 PM

Hi Frank, 

 

May I clarify the influence of dithering during signal accumulation for Bayer cameras?

As I understand, when you drizzle Bayer color array sensor, you have to sample every of four pixels in RGGB quadruple. So each of these pixels obtain only 1/4 of exposure time (multiply by ~ 1/3 for R or B channel due to the filter).

Does it mean that we have 12x signal drop comparing with L channel at BW sensor?



#14 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 30 October 2017 - 09:37 PM

Hi-

 

If you can imagine a special OSC sensor that had a uniform layout of r, g and b pixels in a regular pattern - then if you took three exposures and dithered them perfectly, you would have exactly the same as 3 mono exposures with r, g, b.  Each pixel would have one sample of each color in 3 exposures.

 

Of course - actual bayer arrays have an extra green pixel - and when you dither randomly you can't be sure each pixel will sample the same colors as others.  But with a number of dithered exposures they should be pretty equal, except for a little oversampling of green with osc.

 

And this assumes the drizzle is just dropping each bayer pixel onto the final accumulating image - and it doesn't shrink it - as can be done with drizzle.  Again I'm not sure how other people are doing this - but it used to be that with OSC the standard was to convert each osc exposure into separate r, g, b channels.  And that requires a debayering algorithm that has to look at all the r,g,b values near a location and deduce the full color there.  That inherently blurs the color information and involves tricks of its own that are hard to model in terms of noise.

 

But if you just dither and drizzle, pure osc would collect about the same amount of color info in the same time as mono with filters - except for that duplicated green pixel.

 

And if you are using something like Astrodon type E filters, OSC might collect more light than mono because the passbands are wider and overlapping.  I think Astrodon tend to have higher transmission at peak, but are narrower and have intentional gaps meant to even out the light in each color band - and reduce light pollution.  But things are evened out by narrowing one of the channels and producing a band where photons are blocked - and that amounts to loss of signal.

 

Frank



#15 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,253
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 30 October 2017 - 11:44 PM

Do LRGB people with PI just accept the way it blends lum with rgb - or do they tweak the settings - in effect controlling how heavily the lum is folded in?  There are a lot of knobs to turn when trying for the best results, whereas when you combine just r, g, b it is more well defined.

I think PI is actually doing a lot more than simply multiplying the RGB by the L, which would be the most basic form of a luminance combination. You have mentioned in the past that combining RGB with L can dilute the purity of the color. I agree there, if you are just multiplying in the L channel, since it is indiscriminate about color. PixInsight however, seems to preserve the proper color when doing an LRGBCombination (that's the process that is usually used).

 

Many processes, most color processes, in PI will make use of an internal thing called RGB working space. This is a set of weights for each color channel, along with an algorithm that determined how L combines with RGB, or how RGB combine with each other. There is another process, RGBWorkingSpaces, that allows you to adjust the channel weights. The LRGBCombination tool definitely uses the RGB working space, and I think however PI does the combination, it does it in such a manner that it preserves the original color accuracy as best as possible. It isn't perfect, I have done some testing and noticed slight changes in color, so there can be a loss in purity...but overall the results are actually very good and very close to the original RGB data when combining L. 

 

One thing that can be important with PI is to make sure you have properly weighted the RGB channels before doing a combination. If you just combine L with an RGB without using RGBWorkingSpaces to normalize the weights (the simplest way would be to just set them all to 1.0 in both RGB and L before combining, but you can get more advanced than that), then it's possible to experience "pinking", where rich reds soften up and become pink instead. With proper RGB working space weights, however, that either does not happen, or the effect is significantly mitigated. Oh, and I will usually use 50/50 balance for the L vs. RGB channel these days. The LRGBCombination tool actually has various weight sliders as well as two sliders that basically control a midpoint stretch for L and RGB. I used to reduce the L stretch and increase the RGB stretch when combining, usually around 60/40 (anything above 50 reduces and below 50 increases), however this is a non-linear operation and I decided I would rather handle that differently, if I decided to do any additional non-linear adjustments at all. 

 

Anyway...PI seems to be a lot more intelligent under the surface than it appears when it comes to LRGBCombination. It's very good at it, and maintains color purity quite well. Even with unbinned RGB data, I have been able to realize meaningful improvements in SNR with minimal loss to color purity:

 

ORIGINAL RGB:

68pKkgv.jpg

 

ORIGINAL L:

mygwflp.jpg

 

LRGB COMBINATION:

gf0uR5q.jpg


  • mikefulb, Joe F Gafford, jhayes_tucson and 1 other like this

#16 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 31 October 2017 - 12:01 AM

Hi Jon-

 

I didn't mean to imply what PI was doing was simple.  In fact I was saying the opposite - it is probably doing something non-trivial.  So it's hard to model if it is better or not - and in fact the model wouldn't tell you since it ultimately depends on what the viewer sees and wants to see.

 

The example you show is nice - but since I don't know what really happened to combine L with RGB I can't tell what trade offs were made.

 

And if there sliders to apply to suit personal taste - that makes it even more complicated.

 

I know there are people other than me who prefer to use RGB over LRGB based on past experiments - so I wonder if there are any who tried it in PI and came to the same conclusion.  And if they really compared equal total time of RGB, and manipulating it as much as possible, vs. LRGB in the same total time - and also manipulating it as much as possible.

 

It's fine either way since the final goal is how happy they are with the result anyway.  And that is hard to model and compare when the images came from different data sets - each with more of this and less of that.

 

Frank



#17 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • Posts: 7,388
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 31 October 2017 - 12:03 AM

Jon,
Thank you!!  I didn't have the patience to pull together this kind of demo in the original discussion about RGB vs LRGB imaging and you'd done a superb job of making the point that I was trying to get across.  Your description of the LRGBCombination tool is spot on!  Obscure calculations, graphs and charts are one thing, but a picture is worth a 1000 words.  Very well done.

 

John


  • Jon Rista and dead_butt like this

#18 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,253
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 31 October 2017 - 12:19 AM

 

I didn't mean to imply what PI was doing was simple.  In fact I was saying the opposite - it is probably doing something non-trivial. 

 

Sure. I wasn't saying you did. I just wanted to add to the conversation, that whatever PI is doing, it seems to be designed to at least try and preserve color. 

 

I have noticed that if I stack only RGB data, the color is richer. This seems to be particularly true of the reds, which seem to be most impacted by combination with L. And whenever I've tried to manually combine L with RGB using say PixelMath, just using a multiplication or something similar, my "simplistic" attempts always resulted in obviously worse color. Pinking for sure, general softening and muting of color. 

 

Anyway. I appreciate the LRGBCombination tool in PI. I don't know exactly how it works, but whatever it does, it's pretty amazing. tongue2.gif

 

Oh, and for the record, in the above example I did not tweak any sliders. I used LRGBCombination in it's default state. The one thing I did do was use RGBWorkingSpaces to set all the channel coefficients to 1.0 in both the RGB and L before combining. So it was basically the least weighted example I could muster. 


Edited by Jon Rista, 31 October 2017 - 12:23 AM.

  • dead_butt likes this

#19 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,253
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 31 October 2017 - 12:22 AM

Jon,
Thank you!!  I didn't have the patience to pull together this kind of demo in the original discussion about RGB vs LRGB imaging and you'd done a superb job of making the point that I was trying to get across.  Your description of the LRGBCombination tool is spot on!  Obscure calculations, graphs and charts are one thing, but a picture is worth a 1000 words.  Very well done.

 

John

 

Yeah, I think it is always good to have some visuals to back up the theory. But I do like understanding the theory as well, which is something Frank excels at. Many of Frank's comments in the past have made me reevaluate LRGB combinations, and how they affect color. I think part of the issue some times is that we often use different tools, and sometimes those tools do very different things to arrive at the same general kind of results. 



#20 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 31 October 2017 - 12:28 AM

 

 

I didn't mean to imply what PI was doing was simple.  In fact I was saying the opposite - it is probably doing something non-trivial. 

 

Sure. I wasn't saying you did. I just wanted to add to the conversation, that whatever PI is doing, it seems to be designed to at least try and preserve color. 

 

I have noticed that if I stack only RGB data, the color is richer. This seems to be particularly true of the reds, which seem to be most impacted by combination with L. And whenever I've tried to manually combine L with RGB using say PixelMath, just using a multiplication or something similar, my "simplistic" attempts always resulted in obviously worse color. Pinking for sure, general softening and muting of color. 

 

Anyway. I appreciate the LRGBCombination tool in PI. I don't know exactly how it works, but whatever it does, it's pretty amazing. tongue2.gif

 

Well - the whole point of the technique is to smooth the color and leave lum sharp - and if you don't notice any loss of detail - that is thanks to your perceptual system.  So if it is doing something smart it will make the final image look as good as possible - without looking processed or artificial.  But some people like a processed and artificial look - others don't.

 

If you had instead used the equivalent time on pure RGB, you could play the same tricks of smoothing the color and separately processing Lum.  There is no simple SNR argument that guarantees one result will be better than another - since it involves perception and taste.

 

As for different results with different tools - again - LRGB has been touted for nearly 20 years and all kinds of tools have come and gone.  The main one used at one time was just photoshop - and it was all said to work well because LRGB is 'better.'  The tools may have changed - but they would have benefits for pure RGB also.  Which works better and how much Lum should you spend time on?  These are all personal choices to explore.

 

Frank



#21 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,253
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 31 October 2017 - 12:54 AM

FTR, my ratios were 116 minutes L, 40 minutes R, 30 minutes G and 20 minutes B. So just shy of 2 hours L, which puts it about 3x more than red, 4x more than green and 6x more than blue. However, red was at the greatest disadvantage in terms of sensor sensitivity, whereas blue and green were higher. So the SNRs of the color channels are similar but not identical. The SNR of the L channel is much higher (as apparent in the example images above.) 

 

Also, I DO usually smooth the color, although with spatial filtering, rather than with downsampling. But yes, I agree, smooth the color, since it's not really where you are getting your detail from. 

 

As for personal choices, certainly. And there is more than one way to skin the L channel cat. uan Conejero has covered LRGB combination as well. His assessment is largely the same as yours, that there is definitely a statistical/theoretical benefit when using binned RGB with unbinned L, although his conclusions were based on CCD data. Juan also proposed something along the lines of a super luminance, where you use the ImageIntegration process in PI, which applies robust normalization algorithms to the channels, to combine the individual LRGB integrations into an optimized luminance. I've tried this on some of my data (and I don't so far have as much LRGB data to really try this on). I've had some mixed results, but so far in every case where my RGB integrations were particularly short relative to L, I did not see much benefit (I presume because the L SNR was dominating the results). In one case in particular, where I acquired a more reasonable amount of RGB data, the optimized luminance was definitely cleaner under the same stretch:

 

L only:

iekHuzf.jpg

 

Optimized L:

7iJ6XpZ.jpg

 

Suffice it to say, I aim to get more RGB now anyway to get better color, particularly on fainter stuff. But with more RGB, I can create optimized luminance integrations that have significantly lower noise, improving the potential benefits of combining L with RGB. 


Edited by Jon Rista, 31 October 2017 - 12:55 AM.

  • BenKolt likes this

#22 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 31 October 2017 - 01:08 AM

Just to clarify - a key point of my plots above is to say that you cannot actually point to one being better than the other - because one is only better in terms of quantifiable SNR - if at the same time you ignore color detail.

 

I'm not sure what the PI people say - but I thought some of them do prefer RGB for various reasons.

 

If color detail played no role at all then there would be no limit to how much you should smooth the color.  Bin color x2, x3, x4 - more is always better if you only care about snr in the resulting big pixel.  And it's no different if you low pass filter somehow - there will always be that trade off - and at some point your eye will pick it up as you combine sharp lum with soft color.

 

And keep in mind if you do pure rgb - you can low pass filter both color and lum - to improve both in terms of snr and "noisiness."  That would be "even better" than lrgb - since the lum snr doubles along with color snr.

 

Any time you make a fundamental trade off of detail for "smoothness" - you need to assess whether it actually improves the image.

 

The problem with using all the bells and whistles of processing software is that you don't know if it is actually respecting the measurements in a meaningful way.  You could do pure lum and press an instagram button to make it amazingly colored - from no color data at all - and it might be a pleasing picture to someone.

 

But I think the main thing playing a role in preferring RGB to LRGB is light pollution and limited exposure time in the first place.  That combined with personal preference makes the choice different for different users - and exploration is needed.

 

In a nutshell that is the point I am making.  In terms of signal and noise models there is no clear win.  So experiment and see what works best for you.

 

Frank



#23 vdb

vdb

    Surveyor 1

  • -----
  • Posts: 1,531
  • Joined: 08 Dec 2009

Posted 31 October 2017 - 02:07 AM

Question, could you run these simulations against the 2 technologies CCD/CMOS one being mono the other being OSC, one problem I see is that maybe not all QE figures are known for CMOS camera's ... Preferable the 11000 ccd and the Sony FF 36 MP CMOS ...

 

Thanks,

Yves


  • TestnDoc likes this

#24 freestar8n

freestar8n

    Vendor - MetaGuide

  • *****
  • Vendors
  • topic starter
  • Posts: 9,488
  • Joined: 12 Oct 2007

Posted 31 October 2017 - 02:43 AM

Question, could you run these simulations against the 2 technologies CCD/CMOS one being mono the other being OSC, one problem I see is that maybe not all QE figures are known for CMOS camera's ... Preferable the 11000 ccd and the Sony FF 36 MP CMOS ...

 

Thanks,

Yves

Hi Yves-

 

The charts above are all based on the simplest situation where the only noise is shot noise in the arriving photons.  The QE could be anything - but it's assumed to be the same in each filter - and the luminance signal is equal to the sum of the filter signals.

 

I could fold in read noise and other differences - but none of it would actually help me decide between RGB and LRGB - or how much L to use.  This is because I don't know how to factor in the effect of losing color detail.

 

LRGB assumes you can tolerate a great deal of blurriness in the color - with no downside.  But at some point it will be noticed - just as binning lum would be noticed.

 

The main difference between CCD and CMOS is that cmos tends to be lower read noise - which means the charts above are more representative (they assume no read noise).

 

I think that in terms of OSC vs. mono - independent of LRGB - it would be interesting to compare a modern high QE osc cmos camera, with a ccd that used Astrodon E filters.  That would be a direct comparison of signal acquired in R G B for osc vs. mono - and it would be more clear cut because there is no blurring or binning going on.

 

For the specific question of signal acquired in R G B, osc may in fact beat mono.  It may not - I'm not sure.  But the filter passbands are very different.

 

I'd be interested to hear if someone can try.

 

If OSC actually captures more color signal than mono in a given time - then it throws even more of a wrench in comparing OSC with LRGB.

 

Frank



#25 vdb

vdb

    Surveyor 1

  • -----
  • Posts: 1,531
  • Joined: 08 Dec 2009

Posted 31 October 2017 - 04:14 AM

The question was more of, today we have 2 types CCD/CMOS.

How does a mono CCD with LRGB technique compare to a CMOS OSC RGB technique ...

 

I know this really will not tell the subjective appreciation of craftsmanship in processing both of them and the lack of color info in one and lack of luminance in the other ... it all is difficult to compare, but I'm interested in the theoretical numbers comparison ...

 

/Yves




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: imaging, astrophotography



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics