2600MC Pro - Green tint in raw files ZWO ASI2600MC Pro · Matt Crognale · ... · 35 · 1375 · 12

mcrognale 0.00
...
· 
I upgraded to the 2600MC Pro a month ago and I've been getting very strange and inconsistent results in individual light files in imaging sessions. In most of the sessions, the image previews were the normal grayscale that Sequence Generator Pro provides. However, a handful of the images had an awful green tint in them but those were easily discarded. The weather finally cleared and I was able to shoot again last night. Every one of my raw files has the heavy green tint. Post processing in PI isn't touching it, even stacked with new flat and bias files. The tint isn't as strong in the flats but I can see echos of it. Looking at the camera settings I see that it's detecting RGGB and that matches the value in the fits header. Looking at the histogram in a fits viewer it's clearly green heavy and overpowering the other channels.

Has anyone seen anything like this in the past? I've changed the USB cable, updated to the latest driver version, and installed the latest firmware on the camera. Nothing helps.

green_tint.png
Like
tboyd1802 3.34
...
· 
·  1 like
Assuming this has just been screen stretched with colors locked together, kinda looks normal to me. If you unlock the colors before screen stretching it should look more like you would expect. Have you stacked, extract the background, and color calibrate the result? That should take care of the green tint...
Like
jsg 8.77
...
· 
·  1 like
Did you shoot that with a filter?   The kind of green cast that OSC images often have is more subtle, nothing like the image you posted.  Did you do any processing at all with it?

In PixInsight, there's a process called "SCNR" which removes a particular color cast.   Removing a red, green or blue color cast is easy.  If you need to remove cyan, magenta or yellow color cast, invert your image and use red (cyan), green (magenta) or blue (yellow) and then re-invert the image.

I downloaded your image and tried to color correct it using SCNR but it's far too green to get an acceptable result with that process.  If you haven't done any processing and you did not shoot using a filter, I suspect there *might* be a problem with your camera.  I have the ASI2600MC and have never seen that.
Edited ...
Like
Sderamus 0.00
...
· 
·  1 like
Got the same camera. Never seen this.
Like
lthughes 3.82
...
· 
·  1 like
This is completely normal. When you use the Screen Transfer Function to stretch in PI, make sure the RGB channel link icon (top, left side of tool) is de-selected.
Like
mcrognale 0.00
...
· 
That's an unlocked screen stretch of a single frame. Attaching an unlocked and locked screen stretch of the stacked output. I've done the extraction, calibration, etc with no real impact on the amount on the end result. I can get the gradient under control but the colors are still horribly off.

The really crazy thing? If I use SCNR to reduce the green channel the result is almost a grayscale image.
tint_locked.png
stacked_tint.png
Edited ...
Like
Cellotina 0.00
...
· 
·  1 like
Did you happen to crop first? or was it at the end of the processing?

Is the previous camera's specs being used?

Best,
Edited ...
Like
mcrognale 0.00
...
· 
Jerry Gerber:
Did you shoot that with a filter?   The kind of green cast that OSC images often have is more subtle, nothing like the image you posted.  Did you do any processing at all with it?

In PixInsight, there's a process called "SCNR" which removes a particular color cast.   Removing a red, green or blue color cast is easy.  If you need to remove cyan, magenta or yellow color cast, invert your image and use red (cyan), green (magenta) or blue (yellow) and then re-invert the image.

I downloaded your image and tried to color correct it using SCNR but it's far too green to get an acceptable result with that process.  If you haven't done any processing and you did not shoot using a filter, I suspect there *might* be a problem with your camera.  I have the ASI2600MC and have never seen that.

It's the same with or without a filter in place. Last night I had the L-Pro installed but when I shot on the new moon I didn't use one and still saw a decent number of images with that tint. I'm leaning towards it being an issue with the camera at this point. Using SCNR on a stacked image, the result is almost grayscale.
Like
AstroDid35 0.00
...
· 
Hello Matt
perhaps use the RGGB for Debayer process and, when you get the image of pretreatment (green image I think) you apply the process "automaticbackgroundextractor" or "dynamicbackgroundextractir"
With Pixinsight of course
Like
WhooptieDo 9.24
...
· 
·  2 likes
Almost looks like a debayering issue.   There's no red in that Histogram at all. 

See if you can upload a raw sub for one of us to debayer for you.    Disclaimer, make sure you strip the location data from the header if you image from your backyard, for security reasons.
Like
mcrognale 0.00
...
· 
Al Haines:
Did you happen to crop first? or was it at the end of the processing?

Is the previous camera's specs being used?

Best,

The crop was done at the end of the WBPP run. I double checked and the equipment profile is using the specs for the new camera. This is so bizarre.
Like
mcrognale 0.00
...
· 
·  1 like
Brian Puhl:
Almost looks like a debayering issue.   There's no red in that Histogram at all. 

See if you can upload a raw sub for one of us to debayer for you.    Disclaimer, make sure you strip the location data from the header if you image from your backyard, for security reasons.

Max file size is 20M so here's a dropbox link:

sample frame with location data removed.
Like
JethroXP 2.39
...
· 
·  1 like
Can you upload and share one of the files, perhaps to Dropbox or OneDrive, so we can take a look?

Nevermind, you just did, looks like we posted about the same time.  I'll take a look.
Edited ...
Like
WhooptieDo 9.24
...
· 
·  1 like
I went through every possible debayer pattern in Pix,  VNG does not work at all, bilinear with RGGB made the most sense, but the results were just like yours, very green. 

Red and blue channels are completely absent of signal, nothing at all.

I'd say something is wrong with your camera.   Double check your power source maybe, as a last resort.. but I don't think it's saving things properly.
Edited ...
Like
AstroDan500 5.63
...
· 
·  1 like
I downloaded the file, ran through APP, opened in Pix, applied SNR.
Looks normal to me.



ss2.jpg
Like
WhooptieDo 9.24
...
· 
·  2 likes
Here is the sub you sent, seperated by color channels.   Whats interesting is I don't see the pixel pattern at all in the green channel, which tells me all the data is getting saved to the green channel, no debayer was involved during the save.   Could you have enabled some sort of mono mode, luminance, black and white, or something to this effect on accident?     I don't know if that's a thing, but that's what it looks like.



c52e3c9da3b62058338d70837fde0e64.png
Like
AstroDid35 0.00
...
· 
The green color is normal at the and of the pretreatment. You just must apply automaticBackgroundExtractor after crop and the image will be allright.
Like
WhooptieDo 9.24
...
· 
·  1 like
Dan Kearl:
I downloaded the file, ran through APP, opened in Pix, applied SNR.
Looks normal to me.



Normal if it was mono, but it's a OSC camera.  There should be color.
Like
JethroXP 2.39
...
· 
·  1 like
I see your gain is 100 but your offset is 50.  Is that deliberate?  I looked at one of my own subs for M31 (120s for mine vs. 60s for yours) and there is far more data in mine.  My gain is also 100 but I use an offset of 1, resulting in an eADU value of 1.00 while yours is 0.242.  I found this on the ZWO website:

Understanding the unity gain and offset the cameras - ZWO User Forum (astronomy-imaging-camera.com)

--------------
6. What is offset and why/when use it? (seems to lower constrast)offset is just avoid data clip by zero, so you don't need to worry about it because our ASCOM driver already set it well 

7. Is there a way to compute or test to determine the ideal offset to use? I read people using histogram median values from bias frames.just make sure all data higher than 0
--------------

This is why I just leave mine at 1.  Maybe try recapturing with Offset at 1 instead of 50?
Edited ...
Like
AstroDid35 0.00
...
· 
The process SNRC IS very destructor and must be use just to kill green very softly
Like
paulsson 0.00
...
· 
·  1 like
Once had something similar, when I used calibration frames for stacking in Pixinsight that have been taken with another software. I do imaging with Nina and Indigo, and both need their own darks, flats, etc.
Think they they have some different implementation of the fits format.
Like
mcrognale 0.00
...
· 
·  2 likes
Jason Coon:
I see your gain is 100 but your offset is 50.  Is that deliberate?  I looked at one of my own subs for M31 (120s for mine vs. 60s for yours) and there is far more data in mine.  My gain is also 100 but I use an offset of 1, resulting in an eADU value of 1.00 while yours is 0.242.  I found this on the ZWO website:

Understanding the unity gain and offset the cameras - ZWO User Forum (astronomy-imaging-camera.com)

--------------
6. What is offset and why/when use it? (seems to lower constrast)offset is just avoid data clip by zero, so you don't need to worry about it because our ASCOM driver already set it well 

7. Is there a way to compute or test to determine the ideal offset to use? I read people using histogram median values from bias frames.just make sure all data higher than 0
--------------

This is why I just leave mine at 1.  Maybe try recapturing with Offset at 1 instead of 50?

I set the offset to 50 based on a few threads I read here and on CN. In theory it will be another clear night tonight. I'll adjust the offset to 1 and see what comes from it. The other thing I think I'm going to do is have the sequence take a series of exposures at 60s, 120s, 180s, 240s, and 300s to compare the results. if the change in offset clears helps with the green tint, a longer exposure may provide more valid data to work with.

I'm still not 100% convinced that there isn't a problem with the camera itself but I'd like to try everything I can before starting an RMA / warranty replacement process.
Like
JethroXP 2.39
...
· 
Good idea, it would suck to RMA a good camera!  I'm guessing that with offset at 50 and only 60s exposures you are likely clipping all the blue and red, given that they each only account for 25% of the data.
Like
SemiPro 7.67
...
· 
·  6 likes
Something is very wrong here. The 2600MC follows a RGGB bayer pattern, but the values on your R and B pixels are essentially zero and do not vary. Either Sequence Generator Pro is doing something really funky, or your camera is failing to read the R and B values from the sensor.
image.pngimage.png

This is over a star. It doesn't matter where I check on the image, values for the R and B pixels are always 0.0076.

Try a different acquisition program and if that does not work I think you are going to have to RMA the camera. The fact that it was intermittent before becoming a permanent issue suggests to me its a mechanical fault in the camera.

You don't even have to use the night sky to test. Your problem is that you are getting no values for R and B, so you should just be able to test this by pointing your telescope at literally anything.
image.png

You are looking for variations in the R and B pixels. If there are some then you know that the camera is doing something.
Edited ...
Like
jGaillard 0.00
...
· 
·  1 like
I’ve got this camera too. I have never seen such a thing. Probably your camera has got a problem.
If you belong it since just a month, I believe you should use the guarantee.
Like
 
Register or login to create to post a reply.