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

Looking for Astroberry tool(s) for Color Balance

  • Please log in to reply
16 replies to this topic

#1 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 30 April 2021 - 05:00 PM

Hi folks,

 

Note:  There is a parallel thread on color balance for this camera here:  Instead of hijacking that thread, for this thread, I'm looking more at specific tools to do the analysis.  Subtle difference, though definitely related.

 

Given the various (and conflicting) recommendations on what values to use for proper color balance on ASI cameras (ASI2600MC-Pro in particular), I thought I'd try some tests to prove which is "correct".  Quick answer:  None of them.  Which leads me to this post...

 

What tools can one use to determine the proper color balance settings for the ASI2600MC-Pro camera?  I don't want to simply judge what the screen looks like, since my sense of color is not the best, and what is displayed is dependent on a bunch of other system settings that have nothing to do with what is recorded in the FITS file.

 

Constraint:  The camera is hooked to a Raspberry Pi 4B running Astroberry, so I need to use that as the base for any software tools used.  I'm not opposed to loading something additional to the distro, but doing the calibration with, say, a Windows laptop with ASCOM and then assuming they apply to Astroberry / INDI is a leap I'd rather not take.

 

Background:  Yes, I "know" that RAW imaging means "direct bits from the sensor", but fact is that there are red and blue white balance settings in INDI, and they do make a difference.  From the factory, and according to the thread above, the camera came with WB_R set to 52, and WB_B set to 95.  (My recollection is that it was the other way around, but no matter...)  Green is apparently assumed as 50.   Recommendations just after I got the camera said that the factory settings are odd, and should be overridden to 50/50.  I've been imaging with 50/50 since then, and have been happy with the results.  Image background has been pretty evenly gray, with no glaring color tint.  Stars are relatively assorted in color, etc.

 

Then the above referenced thread pops up, noting they got an 85/74 setting from ASIStudio.  Whoa.

 

Since I cannot run ASIStudio on the Pi, I thought I'd try playing with INDI and the acquisition app that I do use, which is CCDciel.  I put my Flat display on top of the scope, and snapped away.  CCDciel displays at the bottom of the window the R/G/B values of the pixel your mouse is over, giving a quick and easy way to display the results of the settings.  Trying the current 50/50 setting gives a decidedly unbalanced result.  Best seems to be 85/99, which is yet different from all the others.

 

In tabular form:   (1 second exposure)

RB/BB    Red    Green    Blue

-----   -----   -----   -----

50/50:  18831 / 25284 / 25284

52/95:  15006 / 25130 / 25130

85/74:  25197 / 25197 / 15425

85/99:  25156 / 25156 / 21388

 

So, three questions, really:

 

1.  What tool should I use (available for Astroberry) to figure out what setting I should be using?

2.  How sensitive is the specific color of "white" from my Flat screen is the result?  I.e., could my results be different than the OP in the other thread due only to my choice of what "white" is?  Does it even matter?

3.  Why am I seeing "stuck" values, such as 25284 in the 1st row, and 25130 in the 2nd?  These values are common across a wide area in the image, which is unexpected.  At lower exposures, it may be only "stuck" for one color.

 

Bonus question:  In CCDciel I can specify a color balance (R, G, B sliders) for use in Preview.  While this doesn't affect the saved image, it very much affects what I see on the screen.  I have had to set the Green slider to 50% in order to see a reasonably balanced image from the sky, taken with the 50/50 settings in INDI.

 

Thanks for the help!



#2 sharkmelley

sharkmelley

    Aurora

  • *****
  • Posts: 4,605
  • Joined: 19 Feb 2013
  • Loc: UK

Posted 01 May 2021 - 01:18 AM

 

In tabular form:   (1 second exposure)

RB/BB    Red    Green    Blue

-----   -----   -----   -----

50/50:  18831 / 25284 / 25284

52/95:  15006 / 25130 / 25130

85/74:  25197 / 25197 / 15425

85/99:  25156 / 25156 / 21388

 

 

Those figures make no sense to me.  For instance the level of the blue channel (relative to the green) didn't move when you changed the blue multiplier from 50 to 95

 

Check those raw files in a different application and make sure the correct Bayer mosaic pattern is being used. 

 

Mark



#3 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 01 May 2021 - 06:05 PM

Um, ok, good point.  So, true to the thread, this is a tools question.  But otherwise the numbers do seem sane - values with Darks are about 500, which is others seem to be getting, and saturated stars peak at 65k in all 3 channels, which is also correct (it's a 16 bit camera).

 

Opening a random Light image in ASTAP instead of CCDciel does show different numbers.  But they're in the same scale - Darks at about 500 and star centers about 65k, and

 

Fishing around in the settings, one thing I do notice is that the white balance CCDciel applies to preview (on-screen) images is reflected in the numbers, and I don't recall what I had it set to when I was doing the testing.  I've mostly done preview with the Green channel at 50%, and 100% for Red and Blue.  If it was set that way during the test, that might explain the odd scaling of the numbers.  The tests were Flats, so there weren't any saturated stars to look at.  I wonder if there was any stretching going on, which might also be reflected in the numbers of either application.

 

I'll re-do the tests early next week; other commitments until then.  Thanks for the observation!

 

EDIT:  I just opened a saved Flat from a prior imaging session.  VERY different numbers there.  ASTAP shows pixel values of about 9,200 across all three channels, while CCDciel (with all preview sliders at 100%) has 13k, 22k, and 8.6k.  Sheesh...

 

So, if I believe ASTAP (this is the question for the thread!), is my color balance correct on these flats?  They were taken with 50/50 for red and blue on the camera.   Which tool should I trust?


Edited by TelescopeGreg, 01 May 2021 - 06:12 PM.


#4 lambermo

lambermo

    Apollo

  • -----
  • Posts: 1,100
  • Joined: 16 Jul 2007
  • Loc: .nl

Posted 01 May 2021 - 06:14 PM

Why not use the color balance tools in post ?

I never bother with color balance settings in my acquisition software, I just want raw sensor data.

Then in post processing, that is after image reduction, I use tools like Photometric Color Calibration of PixInsight and maybe a background neutralization.

Or are you trying to use live viewing or something like that ?



#5 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 01 May 2021 - 09:47 PM

Why not use the color balance tools in post ?

I never bother with color balance settings in my acquisition software, I just want raw sensor data.

Then in post processing, that is after image reduction, I use tools like Photometric Color Calibration of PixInsight and maybe a background neutralization.

Or are you trying to use live viewing or something like that ?

Oh, the color is definitely adjusted in post (I use StarTools), but I want to get the best data going in.  As the other thread notes, there are data fidelity issues when funky values are used in the camera.  Live View is a potential consideration as well, in support of EAA at slightly-post-Covid star parties.

 

Bottom line, I don't want to trust what I think "looks good".  Worse, how the image looks is very different depending on how it is being viewed.  Rather, I'd like to start with something that is at least close to what "reality" is by the numbers, and to the thread's main focus, wonder what tools I can use to determine that.  (And, no, buying into PI is not an option I would consider.)



#6 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 02 May 2021 - 01:34 AM


EDIT:  I just opened a saved Flat from a prior imaging session.  VERY different numbers there.  ASTAP shows pixel values of about 9,200 across all three channels, while CCDciel (with all preview sliders at 100%) has 13k, 22k, and 8.6k.  Sheesh...

 

So, if I believe ASTAP (this is the question for the thread!), is my color balance correct on these flats?  They were taken with 50/50 for red and blue on the camera.   Which tool should I trust?

That is strange. Is in CCDCiel the Bayer preview switched on? Have a look in CCDCiel to the Bayer preview setting the popup menu.



#7 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 156
  • Joined: 04 Jul 2017

Posted 02 May 2021 - 02:58 AM

Greg,

 

For this kind of testing be sure the following option are set in the CCDciel preferences:

- Preview color balance slider all to 1.0.

- Preview background neutralization is unchecked.

- Preview bayer matrix set to the right value, or test with a real image if Automatic work for you.



#8 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 04 May 2021 - 12:09 AM

That is strange. Is in CCDCiel the Bayer preview switched on? Have a look in CCDCiel to the Bayer preview setting the popup menu.

 

Greg,

 

For this kind of testing be sure the following option are set in the CCDciel preferences:

- Preview color balance slider all to 1.0.

- Preview background neutralization is unchecked.

- Preview bayer matrix set to the right value, or test with a real image if Automatic work for you.

Han, Patrick, thanks for the help!

 

As promised, I ran some more tests this afternoon, taking a bit more care in reviewing the settings.  INDI has the on-camera white balance set to 50/50.  In CCDciel, Bayer preview is on.  I turned off the background neutralization and that made a small difference, but the overall dramatic differences in the three colors is still way off.  All 3 sliders are at 100%.  Turning on/off "DSLR color balance" didn't seem to matter.  Bayer matrix automatic was used, but forcing all 4 patterns failed to yield a proper balance in all three numbers. 

 

ASTAP turns out to have its own puzzle.  A short enough Flat (1 second with the panel on its dimmest setting) loaded into ASTAP shows a very nice, even ADU at about 10k each.  It actually looks like a flat!  On this same image, CCDciel shows 13k, 24k, and 9.5k, and a very lime green on-screen color.  BUT, double the exposure (so, looking for 20k ADU), yields a blown-out white image under ASTAP, with ADUs pegged at 32k.  Note, this is a 16 bit camera.  Even dropping that back to 1.5 seconds yields the same 32k value across the entire image.  CCDciel shows the about expected increase in ADU values as the exposure is ramped through the range for each of the 3 colors, but the balance between the colors remains odd.

 

A bit of a surprise about the ASTAP numbers is that they include fractional values.  I'm guessing this is a reflection of the on-screen scaling of the image?  Nice.

 

Both programs show almost exactly the same values for Dark images, which I guess is reassuring.

 

I've uploaded screen shots of the two programs captured with a roughly center-positioned mouse pointer for 1.0, 1.5, and 2.0 seconds flats, along with the FITS files themselves.  If you have a moment, please take a look and provide some sanity.  This is driving me nuts.

 

https://www.dropbox....StOf1bHyaa?dl=0


Edited by TelescopeGreg, 04 May 2021 - 12:13 AM.


#9 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 156
  • Joined: 04 Jul 2017

Posted 04 May 2021 - 07:40 AM

OK, it appear ASTAP is configured to do some color equalization, Han can tell us more about that.

 

The green tint is what I expect without any color correction for your debayered flat image.

I look more in detail at the 1 second flat and the green pixel are really at 24000, the red and blue are at 9000 and 13000.

 

See the original file (non debayered) in DS9 with big zoom on individual pixel. The white square are the green pixel, the one under the cursor is exactly 24425. The darker square are the blue and red pixels. If you move the mouse on the gray pixel the value is around 13000, on the dark it is around 9000.

flat1s.png

 

So this image color is really not balanced with the green level the double of the other color.

You can try to repeat with different setting in the INDI panel then look at the individual pixel value with ds9. This method as the advantage to not expect anything from the display software.

 

Also a flat panel is probably not a good white reference because of the color spectrum of the white led. Maybe a white surface lighted by a half clouded Sun is better, but more difficult to work with.

 



#10 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 04 May 2021 - 01:01 PM

Greg,

 

Depending on the setting, ASTAP will adjust the red, green and blue levels to get average white stars and a grey background. This is option autolevel ASTAP 1). Also de demosaic routine could be different 3). The simplest is Bilineair and I assume compatible but CCDciel but  the others like AstroSimple or AstroC are recommended for astro work. And finally to fix star colours there is an option 2) to smooth the star colours.

 

So best is to compare the raw values both in CCDciel and ASTAP. In ASTAP you have to disable demasaic 0),.

 

If you want to compare the images in ASTAP and CCDCiel in colour, you should switch off option 1) and 2) and select bilinear 3) as demosaic method.

 

 

If you disable 1) auto level in ASTAP it is very likely your flats are coloured as indicated by Patrick. For raws there is no camera colour correction applied which is optimised for daylight and there will be no white balance. ASTAP substitution for that is autolevel option 1)

 

Han

 

Untitled.png

 



#11 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 04 May 2021 - 01:19 PM

Greg,

 

Looking to one of your flats, the green is very strong (if auto level is switched off and demosaic method  bilinear. I have seen that in many other raw camera image. This is normal for some cameras. See also the colour histogram:

 

Han

 

Colour:

Untitled2.png

 

Raw:

Untitled3.png

 

 

 

 

 

 


Edited by han.k, 04 May 2021 - 01:23 PM.


#12 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 04 May 2021 - 07:45 PM

Thanks, Patrick and Han,

 

Results and thoughts from today:

 

Patrick - good point about the color spectrum of the LED "tracing panel".  While we see it as "white", as a calibration tool it probably leaves something to be desired.  I grabbed a flat this afternoon with the old "Daylight with T-Shirt Method", aiming the scope roughly at the sky above the house across the street, but not in the sun.  If it matters, it's the same T-Shirt I use between the LED panel and the scope, to even out and reduce the light from the panel.  Anyway, the results are pretty much the same as with the panel; R/G/B at 20k / 28k / 15k.  So at least as a first order of approximation, the panel's results appear to be valid enough, and are much easier to get repeatable results with.  But, a good thing to check; thanks.

 

Han - I need a bit more explanation about the comment "This is normal for some cameras. See also the colour histogram".  Two parts.  First, if this is "normal" does that mean it's correct, and that I shouldn't be messing with it?  That your processing seems to be giving me a nice neutral color balance, I conclude that making changes isn't required.  But to getting the best images (from a color perspective) should I be?

 

Second, the color histogram that I see looks pretty even in the position of the three colors, all bunched together in the middle (as you would expect for a Flat), not separated as your example shows.  Why are your screen shots different than mine?

 

Regarding those adjustments, regardless what I do, I can't get ASTAP to display the color numbers I see in CCDciel or DS9, or in your screen shots.  CCDciel and DS9 do seem to agree, but I like the numbers I'm getting in ASTAP a lot better :)

 

One thing I notice is that images in ASTAP are inverted top/bottom compared to CCDciel.  Is there a reason for this?  Could that be affecting the de-Bayering in some way?

 

And, is there a reason that ASTAP seems to be maxing out at 32k, when a 16 bit camera should give me 65k?

 

PRE-POSTING EDIT:  I was just about to hit "Post"...  Ha!!  I can reproduce the CCDciel results if I switch from using the recommended dcraw (or dcraw-astap) to LibRaw.  LibRaw gives me exactly what you are showing, and what CCDciel is displaying.  So, which should I trust?  It's the same data, no?



#13 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 05 May 2021 - 03:16 AM

Greg,

 

RAW images should be without any daylight colour correction. DCRAW and Libraw raws should display be the same pixel values. I compared one of your flats using libraw and dcraw and they look the same and show the same statistics (popup menu statistics).

 

>>Second, the color histogram that I see looks pretty even in the position of the three colors, all bunched together in the middle (as you would expect for a Flat), not separated >>>as your example shows.  Why are your screen shots different than mine?

 

I have switched off the the adjustment settings "auto level" and selected bilinear method in tab stack method. For the one second flat the maximum pixel value is 52k.

 

 

>>One thing I notice is that images in ASTAP are inverted top/bottom compared to CCDciel.  Is there a reason for this?  Could that be affecting the de-Bayering in some way?

 

You can flip the image any way in the the view menu of the viewer.

 

 

I would not worry too much about the pixel levels. More important is to get in the final image a good colour balance. So for me  the average stars colour is white and the sky background is a dark grey.

 

Han



#14 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 06 May 2021 - 11:51 AM

Hi Han,

 

Ok, so I guess the "Test pattern" button doesn't include De-mosaic method nor the Raw conversion library, if they changed.  I must have made more than one change at a time, and didn't notice.  They appear to only apply when loading an image, correct?

 

So, remaining puzzles:

 

1.  Is it expected that the Auto levels process maxes out at 32k ADU for the pixels?  I'm wondering if there's a signed 16 bit int, where it might want to be unsigned or longer.  (I'm on a 32 bit Raspbian system, if that matters.)

 

2.  "I have switched off the the adjustment settings "auto level" and selected bilinear method in tab stack method. For the one second flat the maximum pixel value is 52k."  Um, I'm only seeing 28k in that image...  Am I still not doing something right?

 

2.  What is the scope of the "flip vertical" under View?  Is it just for displayed images, or does it affect the file output of a stacking procedure.  I noticed that the stacks from ASTAP have been flipped as compared with Deep Sky Stacker.  Also, is there a way to know which way the flipping flags are set?  They seem to be remembered across program restarts.

 

3.  Similarly, what is the scope of the Auto levels and Color smooth functions?  Do they only affect the displayed image, or are they applied to the output file of a stack?  I use StarTools for post processing, and I believe Ivo is very insistent that images not be color balanced before processing.

 

4.  And finally, do I leave the camera at 50/50, even though it's decidedly NOT balanced?  If left as-is, how (what tools) do I use to get the final color "right".  I've learned to not trust my own color sense in this regard, and am not interested in scientific renderings (aka the Hubble Pallet).



#15 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 07 May 2021 - 05:11 AM

Hi Greg,

0) The test button does all check marked actions if used. You can see that in the log:

11:24:01  De-mosaic bayer pattern used RGGB
11:24:01  Adjusting colour levels as set in tab "stack method"
11:24:03  Applying colour-smoothing filter image as set in tab "stack method". Factors are set in tab "pixel math 1"

 

1) The autolevel has no preference except it tries keep red as reference and adjusts green and blue to get the white stars and dark grey background. You can see that behavior if you demosaic an image (e.g. bilinear) with autolevel switched off. Then go to pixel math 1 and click on "auto" at the autolevel option. This is using the same colour balance routine. See screenshot. the screenshot below shotw the adjustment of the flat (made with a white light I assume) you provided earlier:

 

Untitled1.png

 

So to get the green flat is reduced to a white flat it is multiplying the green with 0.534.   Note it doesn't matter if it result is around 32k (since the red was weak) since all processing and saving is done with floating point numbers. ASTAP and e.g MaximDL try to keep it in the original 0..64k range Some program like PI and APP try to keep the result in the 0..1 range. For the image quality it doesn't matter since it are all floating point values.

 

 

2) The level is not important since it all pixel values are processed as floating points. Since ASTAP adjust only green and blue and red is a little weak the result will be around 32k. Nothing to worry about. 

 

 

3) Autolevels effect the original image so the FITS file. If you don't want that you have to switch of autolevel and colour smooth. I also understand StarTools recommend bilinear demosaic method and no level adjustment(reason?). My experience is that bilinear demosaic is doesn't give the best results. If you want to process the images completely in ASTAP, I would recommend demosaic method "astrosimple"  which is a different method developed for and only available in ASTAP and use "autolevel" and colour smooth. If the stars in images are all very saturated method AstroC could give better results. But please try out all and compare with Astrotools or others and find out what works best for you.

 

 

4) 50/50, I'm not aware of what this does, but in principle the information in the raw image is unaltered. I would put "gain" always on unity gain and apply colour balance settings later in ASTAP, or Startools or GIMP, Photoshop or Affinity as you like. Once the image is a floating point type, the pixel values are no longer important.

 

Han

 

 



#16 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • topic starter
  • Posts: 2,942
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted Yesterday, 01:25 PM

4) 50/50, I'm not aware of what this does, but in principle the information in the raw image is unaltered. I would put "gain" always on unity gain and apply colour balance settings later in ASTAP, or Startools or GIMP, Photoshop or Affinity as you like. Once the image is a floating point type, the pixel values are no longer important.

 

Han

Ah.  This.

 

The other thread (referenced in the OP) discussed the peril of scaling the integer values inside the camera, so by doing the correction in a tool such as this with floating point math, that issue is removed.  Therefore, leave the camera at 50/50 for red and blue, so all channels are treated equally.  That the sensitivity is skewed skewed among the various channels should be fixed in post.

 

That said, I tried doing a stack in ASTAP with color correction turned on, and didn't notice a difference.  Still very green.
 

 

Working back...

 

So to get the green flat is reduced to a white flat it is multiplying the green with 0.534.   Note it doesn't matter if it result is around 32k (since the red was weak) since all processing and saving is done with floating point numbers. ASTAP and e.g MaximDL try to keep it in the original 0..64k range Some program like PI and APP try to keep the result in the 0..1 range. For the image quality it doesn't matter since it are all floating point values.

 

 

2) The level is not important since it all pixel values are processed as floating points. Since ASTAP adjust only green and blue and red is a little weak the result will be around 32k. Nothing to worry about.

So I guess I wasn't clear.  It's not that the level is around 32k, it's that all 3 colors are exactly 32767.  That's a special number to this old machine language programmer, one that "does not occur in nature".  Especially for a 16 bit camera, something is being clipped.

 

Doing a bit more experimenting, it looks like this "32k issue" is related only to the AstroC debayer method.  Given that, is the effect expected?  If so, what is going on?

 

 

3) Autolevels effect the original image so the FITS file. If you don't want that you have to switch of autolevel and colour smooth. I also understand StarTools recommend bilinear demosaic method and no level adjustment(reason?). My experience is that bilinear demosaic is doesn't give the best results. If you want to process the images completely in ASTAP, I would recommend demosaic method "astrosimple"  which is a different method developed for and only available in ASTAP and use "autolevel" and colour smooth. If the stars in images are all very saturated method AstroC could give better results. But please try out all and compare with Astrotools or others and find out what works best for you.

Ok, interesting.  So, both the debayer choice and Auto levels DO affect what goes into a stack.  If one wants a strictly non-color balanced stack, auto level needs to be turned off, and the debayer needs to be strictly bilinear.  Yes? 

 

What is the difference between Bilinear, AstroSimple, and AstroC, and how do they interact with Auto levels?
 



#17 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 534
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted Yesterday, 02:27 PM


So I guess I wasn't clear.  It's not that the level is around 32k, it's that all 3 colors are exactly 32767.  That's a special number to this old machine language programmer, one that "does not occur in nature".  Especially for a 16 bit camera, something is being clipped.

 

Doing a bit more experimenting, it looks like this "32k issue" is related only to the AstroC debayer method.  Given that, is the effect expected?  If so, what is going on?

 

 

Ok, interesting.  So, both the debayer choice and Auto levels DO affect what goes into a stack.  If one wants a strictly non-color balanced stack, auto level needs to be turned off, and the debayer needs to be strictly bilinear.  Yes? 

 

What is the difference between Bilinear, AstroSimple, and AstroC, and how do they interact with Auto levels?
 

The 32 k is the level of red. Red is not changed. Only green and blue are adjusted by "autolevel" to the red level.

 

Each light is de-mosaiced and then added to the stack master. If autolevel is check-marked, the final stack result is processed, so adjusting the green and blue level to match with the red level, The result should have in average white stars and dark grey background.  You can leave autolevel off and do it later in tab pixel math.

 

Bilinear, AstroSimple, and AstroC are all demosaic methods. Bilinear is straight basic algorithm with in general works good. But for small stars it could cause red, green or blue pixel artefacts because the imaged stars are very small. Bilinear uses pixel values up to 3 pixels width to determine the colour. If you star HFD value is near two pixels, you will not get homogene coloured stars. AstroSimple is a created to only look to 2x2 pixel areas giving better star colours so less colour artefacts, Especially for low HFD value image this AstroSimple will make a difference.

 

AstroC is also variation of  Bilinear but it guesses the colour of the saturated star center. Saturated star centers will become normally white since R, G and B colour have all the same maximum pixel value.

 

The the last option "colour smooth" is to smear out the colour and get homogeneous star colours. Like autolevel executed after stacking. There is also an manual colour smooth activation in tabs pixel math 1. So you could just do stacking and apply autolevel and colour smooth later.

 

Many people expose too long for OSC cameras.  50 seconds or less give much better unsaturated stars and better star colours.

 

Han


Edited by han.k, Yesterday, 02:29 PM.



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






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics