Jump to content

NLC-Banner.thumb.jpg.acb5ba835b9e8bf0718b90539633017d.jpg

Why all the green….?


Stuart1971
 Share

Recommended Posts

Hello all,

First of all this is an awful image, of the Eastern Veil, sorry for that, this is a stretched stack out of Astro Pixel Processor, no darks or flats as you can see, with just a few levels to exaggerate the issue.

Taken with an SXVR M25c OSC camera with an Idas P2 light pollution filter last night…I don’t get why it’s so green, the nebula should be reddish AFAIK, and I did not think this filter added a green tinge unlike the Astronomik CLS. Also the subs were all with a red tinge .

Can’t seem to shift it in processing…

‘Any ideas….

 

 

AF707304-226F-4860-9D52-1ED7BF85B81F.jpeg

Edited by Stuart1971
Link to comment
Share on other sites

1 hour ago, tomato said:

Fair enough, I did introduce the FES words, albeit in praise of what had gone before. 

Glad the SGL community sorted the green Veil out.

Me too, it was bugging be a bit, and I never even thought the bayer pattern would be wrong, I had assumed APP always sorted that automatically, but you live and learn…it also is wrong in NINA, had to change it in there too, it’s a glitch with the SX ASCOM driver……according to the guys at NINA…🤔

  • Like 1
Link to comment
Share on other sites

6 minutes ago, Stuart1971 said:

Me too, it was bugging be a bit, and I never even thought the bayer pattern would be wrong, I had assumed APP always sorted that automatically, but you live and learn…it also is wrong in NINA, had to change it in there too, it’s a glitch with the SX ASCOM driver……according to the guys at NINA…🤔

Not necessarily.

There is always a problem of "direction".

Most people agree that pixels should be read from left to right - as that is the way we are used to read text (apart from some languages that are right to left or up / down oriented).

However - there is problem of vertical direction. Is pixel 0 top left pixel of the sensor or bottom left pixel of the sensor?

For mono images - it does not matter much - you read out image and if it's flipped - you just flip it back. Odds are - it will be flipped one way or another - because of scope (mirrors / lens thing). For OSC - it is a big deal - changing image orientation changes bayer matrix order (at least readout part - how scope flips the image is independent of that).

Maybe developers of NINA work in one convention - like top/bottom while developers of ASCOM driver did it in other - bottom/up, so it's not really a glitch - more lack of uniform convention.

Link to comment
Share on other sites

16 minutes ago, vlaiv said:

Not necessarily.

There is always a problem of "direction".

Most people agree that pixels should be read from left to right - as that is the way we are used to read text (apart from some languages that are right to left or up / down oriented).

However - there is problem of vertical direction. Is pixel 0 top left pixel of the sensor or bottom left pixel of the sensor?

For mono images - it does not matter much - you read out image and if it's flipped - you just flip it back. Odds are - it will be flipped one way or another - because of scope (mirrors / lens thing). For OSC - it is a big deal - changing image orientation changes bayer matrix order (at least readout part - how scope flips the image is independent of that).

Maybe developers of NINA work in one convention - like top/bottom while developers of ASCOM driver did it in other - bottom/up, so it's not really a glitch - more lack of uniform convention.

Well this was the reply I got from Terry at SX, to my question asking what is the correct bayer pattern to use for this camera…and if you understand it then good on you….😂😂
 

There isn’t an easy answer to this, as it varies with the software that you use. I always recommend taking an image of objects with a known colour ad then trying the various colour decode settings to get a good image. 
The wrong settings are usually easy to spot, as they give completely the wrong colour and often have a residual ‘grid’ pattern.
 
The start point defines the array pattern, so the pixel and line at the top corner of the image array will set the RGB pattern for decoding. As we do not have direct control of the third party software, it may start on a red, green or blue pixel and this swaps the decode pattern between RGGB, GRBG, GBRG and BGGR, depending on the start point.
 
Once defined for your software, it is reliable, but different programs may have different patterns.
 

 

  • Like 2
Link to comment
Share on other sites

14 minutes ago, Stuart1971 said:

@vlaiv did you understand where Terry was coming from, with his answer….? 🤔🤔

Yes - same thing I wrote above.

Camera pixels have certain bayer matrix over them - and that is fixed and can't change, however - once you read out image, actual bayer pattern in data will depend on "which way" you look at the image.

For example - I wrote above comment in two lines. You will read that text left to right, top row first, downwards. That is how we read text, and that is how text makes sense. If you try to read the text - some other way - it will not make sense to you.

Drivers read out "text" or pixels in certain way - but all you get is sequence of numbers. Was it read top to bottom, or bottom to top?

That depends on software that is reading in pixels - it decides what is "correct" order. Nothing wrong with that - except for the fact that bayer matrix order reverses.

image.png.92aa36bd8dec142a091ae6f4ff2a2f7c.png

Here we have RGGB bayer matrix - because we are reading it top/down, left to right.

But if you start reading pixels as you would say function graph in mathematics - in "coordinate system" order:

image.png.7199ba84f4235e9d17a1a232fa103f68.png

where Y grows in up direction so you'd read bottom / up and left/right - what would letters be then:

GBRG (GB for first or bottom row, and RG for second / top row)

Now you have to tell the software that uses "coordinate system" order that your bayer matrix is not really RGGB - but that it is GRBG and it will decode bayer matrix properly.

That is important bit in the end - how software interprets pixels - like in "text" - going from top to bottom, or as in "coordinate system" - going form from bottom up.

 

Edited by vlaiv
  • Thanks 2
Link to comment
Share on other sites

2 minutes ago, vlaiv said:

Yes - same thing I wrote above.

Camera pixels have certain bayer matrix over them - and that is fixed and can't change, however - once you read out image, actual bayer pattern in data will depend on "which way" you look at the image.

For example - I wrote above comment in two lines. You will read that text left to right, top row first, downwards. That is how we read text, and that is how text makes sense. If you try to read the text - some other way - it will not make sense to you.

Drivers read out "text" or pixels in certain way - but all you get is sequence of numbers. Was it read top to bottom, or bottom to top?

That depends on software that is reading in pixels - it decides what is "correct" order. Nothing wrong with that - except for the fact that bayer matrix order reverses.

image.png.92aa36bd8dec142a091ae6f4ff2a2f7c.png

Here we have RGGB bayer matrix - because we are reading it top/down, left to right.

But if you start reading pixels as you would say function graph in mathematics - in "coordinate system" order:

image.png.7199ba84f4235e9d17a1a232fa103f68.png

where Y grows in up direction so you'd read bottom / up and left/right - what would letters be then:

GBRG (GB for first or bottom row, and RG for second / top row)

Now you have to tell the software that uses "coordinate system" order that your bayer matrix is not really RGGB - but that it is GRBG and it will decode bayer matrix properly.

That is important bit in the end - how software interprets pixels - like in "text" - going from top to bottom, or as in "coordinate system" - going form bottom up.

 

Thanks for explaining, I thought if anyone would understand then it would be you, or maybe it’s just me being thick….😂😂👍🏼

Edited by Stuart1971
  • Like 1
  • Haha 1
Link to comment
Share on other sites

3 hours ago, Stuart1971 said:

Thanks for explaining, I thought if anyone would understand then it would be you, or maybe it’s just me being thick….😂😂👍🏼

To err is human to mess things up takes a computer you are not alone..... head banging over other matters yet to the younger generation simples.... To us mortals that different. 

  • Like 1
Link to comment
Share on other sites

I tried to learn one of those 'bottom to top' languages but it was an uphill struggle...

With an unfamiliar OSC camera, and stacking in AstroArt, it's a matter of seconds to try all the Bayer permutations. The right one is pretty obvious. (That's how I discovered that the Veil is really turquoise and orange.)

:Dlly

 

  • Haha 4
Link to comment
Share on other sites

Ok so same image but different issue, this is the final calibrated image with darks and flats, but as you can see still not that good and the stars are very big, and if you zoom in they are also elongated across the whole image pretty evenly, so I thought as I used 5 min subs unguided, maybe it’s a bit of drift…BUT over the 5.5 hours IMabel for, the Nebula never moved at all from the centre of the frame, so if it was drift surely it would have….it was exactly where it was on the firs frame, with drift I would have expected it to have moved quite a way up of down depending on the drift direction…

So what else can cause this…

kit used was a Tak FSQ85

SXVR M25c camera

EQ8 pro mount

Idas P2 LP FILTER

 

 

CHEERS ALL👍🏼

7B40B5F3-0978-4E38-A97C-6207B68D9DBA.jpeg

Edited by Stuart1971
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.