QHY600 Banding issues and Mode choices QHYCCD QHY600PH M · Mark · ... · 14 · 553 · 3

MarkUS_UK_Astro 0.00
...
· 
Hi all,

I've been running this camera for about a year, mostly in Mode 1 (High Gain) with Gain at 56, offset 30 and USB at 40 (this latter setting, after a lot of work getting horizontal banding down to an absolute minimum and achieving clean Bias).

This mode seems to be very effective for Nebula etc,. However, when there is a very large bright star (or stars) in the region, I get a horizontal dark band (like dark bloom?) from that star (or stars) that runs across the entire sensor and I cannot seem to calibrate that out. It is extremely feint in a single sub but gets accentuated on stacking.

Because of the above, and because I also wanted to shoot some brighter targets, I tried to find an alternative mode to see if I could avoid this issue. At the very least, a mode that offered maybe a larger Full Well capacity, to see if that helped mitigate it. (In fact, *any* set up that would avoid this problem!)

Well...in trying other modes, I cannot seem to get a usable setup. Whilst (I think) I can achieve a better result than the aforementioned "bloom", the horizontal banding noise in the various different modes is quite painful. Then, for each one, I'm trying different USB traffic settings, which does change the effect, but still does not give what I would call a desirable (or for me, a "usable") result. Once I got to something half decent, (Mode 3 EFW 2CMS, Gain 0, Offset, USB 3), it was still far to heavy in horizontal banding/noise. Another challenge is that the time needed to be spent on this is also painful.

The result, so far, is that I either live with my "working" mode and modify imaging and framing accordingly to compensate OR I test out every single other combination to find a compatible working setup for brighter targets.

My questions therefore are:
1: Have you experienced same or similar issues above and how did you mitigate the issues?
2: Are you also running different modes for dark or bright targets? If so, which ones? (Where should I focus my attention?)
3: Does excessive banding lean more towards external issues, power, cables etc.,? (This is remote, so not as easy to test).?
4: Or is this, "keep testing, you'll find something works" ???

Thanks in advance for sharing your experiences!
Mark
Like
jeffbax 13.12
...
· 
·  1 like
Hello Mark. Horizontal banding is usually linked to USB Traffic. Try to change this parameter. Or even the USB cable.

JF
Edited ...
Like
MarkUS_UK_Astro 0.00
...
· 
·  1 like
Jeffbax Velocicaptor:
Hello Mark. Horizontal banding is usually linked to USB Traffic. Try to change this parameter. Or even the USB cable.

JF

Thanks JF, yes, as per my message, I’ve been doing that meticulously. But in looking for the best mode and then combination of Gain and USB I’ve found there are almost too many choices. I resorted to some binary chopping to narrow down. But still struggling to get the right/workable settings.
Like
Jeff_Reitzel 1.51
...
· 
·  1 like
deleted-already answered sorry
Edited ...
Like
MarkUS_UK_Astro 0.00
...
· 
·  2 likes
As I go through this....I was running High Gain - Mode 1 G56 O30 U40 and I just switched to Mode 5 High Gain G56 O30 U5 and the dark bias frame looks very clean! Jeff Reitzel, your deleted message may have been useful!
Like
Jeff_Reitzel 1.51
...
· 
Sorry about that Mark. I felt like I ended up just repeating what was said in a different way. I wasn't sure if you had one of the cameras with the firmware that would allow mode 5 operation either. Glad you found a solution. 
CS,
Jeff
​​​​​​
Edited ...
Like
MarkUS_UK_Astro 0.00
...
· 
·  1 like
Jeff Reitzel:
Sorry about that Mark. I felt like I ended up just repeating what was said in a different way. I wasn't sure if you had one of the cameras with the firmware that would allow mode 5 operation either. Glad you found a solution. 
CS,
Jeff
​​​​​​

I think my world just changed in the 5 minutes after reading your post. The lesson should be….post and never delete,,,,you have no idea how your experience might help!
Thanks!
Edited ...
Like
jwillson 3.27
...
· 
·  1 like
This isn't related to USB traffic. It's not traditional banding--it's specifically related to rows where there are saturated stars. I know since I have the same issue. The problem is worst in Mode 1, so you can try switching to Mode 3 and optimizing the USB traffic as usual. If your camera is like mine, though, it won't completely resolve the issue.

While I have had the camera for years, I only recently broke down and logged a support request with QHY. I was told it's a known issue and what to reference when I returned the camera for repair. It requires a fix to "internal circuitry". I have not yet send in my camera since it is at a remote observatory out of state, so I can't tell you whether the repair will be successful, whether the turn around time is slow or quick, etc. I would, at least, recommend you contact QHY support and find out for yourself what they think.

- Jared
Like
MarkUS_UK_Astro 0.00
...
· 
Jared Willson:
This isn't related to USB traffic. It's not traditional banding--it's specifically related to rows where there are saturated stars. I know since I have the same issue. The problem is worst in Mode 1, so you can try switching to Mode 3 and optimizing the USB traffic as usual. If your camera is like mine, though, it won't completely resolve the issue.

While I have had the camera for years, I only recently broke down and logged a support request with QHY. I was told it's a known issue and what to reference when I returned the camera for repair. It requires a fix to "internal circuitry". I have not yet send in my camera since it is at a remote observatory out of state, so I can't tell you whether the repair will be successful, whether the turn around time is slow or quick, etc. I would, at least, recommend you contact QHY support and find out for yourself what they think.

- Jared

Hi Jared, I agree. Once I get chance to test (after I have now eliminated modes/usb traffic etc.,) -  I will probbaly prove that the original issue remains. I did, in fact, recently open a ticket with QHY and they want to see samples, which I am yet to send.

Thanks again.
Like
jwillson 3.27
...
· 
@Mark ,

Here is a sample of what I see with my camera. This is an image of NGC 3628 and its tidal tail. A few things to note...

- The image is very, very heavily stretched to emphasize the issue
- I ran 'starxterminator' to make it easier to see the issue which is why there are no saturated stars
- The image is down-sampled 4x for the web

You can see several horizontal dark bands that lead, eventually, to a faint halo where a star has been removed. The one near the top of the frame is the most prominent, but if you look closely you will see a few more. You can even see a faint satellite trail or two that snuck through the error rejection.

Based on your description, I expect your images are showing something like this, yes?

USB traffic settings can't have anything to do with it since the bands move as the frame is dithered. Banding from USB traffic settings might mask the issue simply because they introduce additional bands, but they can't be the cause. The dark bands in my images always correspond to where there is a saturated star in the frame, and they move when I dither which is why they won't go away with stacking. I can run debanding algorithms to address the problem, but those generally introduce worse artifacts than the original problem. I generally mask the area and raise the ADU using pixelmath. It's a pain--can add more than an hour to my processing time--but it works and doesn't require any cloning, so it leaves the original signal substantially in tact.

This happens to be a stack of a little over twenty hours of data. It takes a fairly robust set of data for me to see the artifacts. The dark banding/dimming is very minor in absolute terms. In the sample provided, the band was somewhere between 1 and 2 ADU dimmer than the areas immediately above and below the band. That's a shift of just 0.002% or so.  Hopefully, this is something QHY can resolve. Because my telescope is remote, I haven't sent it in yet. Some logistics to sort.

- Jared

Banding.jpg

If this isn't what you are describing, we may have different issues.
Like
MarkUS_UK_Astro 0.00
...
· 
Hi Jared, it is the very same issue that I have. My stuff is also remote hence I’m working around it. Mode 5 (High Gain 2 CMS) is really working well for me, the problem still occurs in Mode 1, which was my default narrowband setting before.
Like
jrista 8.59
...
· 
Jared Willson:
@Mark ,

Here is a sample of what I see with my camera. This is an image of NGC 3628 and its tidal tail. A few things to note...

- The image is very, very heavily stretched to emphasize the issue
- I ran 'starxterminator' to make it easier to see the issue which is why there are no saturated stars
- The image is down-sampled 4x for the web

You can see several horizontal dark bands that lead, eventually, to a faint halo where a star has been removed. The one near the top of the frame is the most prominent, but if you look closely you will see a few more. You can even see a faint satellite trail or two that snuck through the error rejection.

Based on your description, I expect your images are showing something like this, yes?

USB traffic settings can't have anything to do with it since the bands move as the frame is dithered. Banding from USB traffic settings might mask the issue simply because they introduce additional bands, but they can't be the cause. The dark bands in my images always correspond to where there is a saturated star in the frame, and they move when I dither which is why they won't go away with stacking. I can run debanding algorithms to address the problem, but those generally introduce worse artifacts than the original problem. I generally mask the area and raise the ADU using pixelmath. It's a pain--can add more than an hour to my processing time--but it works and doesn't require any cloning, so it leaves the original signal substantially in tact.

This happens to be a stack of a little over twenty hours of data. It takes a fairly robust set of data for me to see the artifacts. The dark banding/dimming is very minor in absolute terms. In the sample provided, the band was somewhere between 1 and 2 ADU dimmer than the areas immediately above and below the band. That's a shift of just 0.002% or so.  Hopefully, this is something QHY can resolve. Because my telescope is remote, I haven't sent it in yet. Some logistics to sort.

- Jared

Banding.jpg

If this isn't what you are describing, we may have different issues.

That kind of looks like a saturation rebound problem. That was more common with certain kinds of CCDs in the past. I had never seen it with a CMOS before. I'm not sure if QHY could fix that...it may be something Sony would have to address, if it is indeed with the integrated readout circuitry.

BTW, the depth on that image looks amazing. Interested in that final result!
Edited ...
Like
jwillson 3.27
...
· 
·  1 like
Yeah, so far I 
Jon Rista:
Jared Willson:
@Mark ,

Here is a sample of what I see with my camera. This is an image of NGC 3628 and its tidal tail. A few things to note...

- The image is very, very heavily stretched to emphasize the issue
- I ran 'starxterminator' to make it easier to see the issue which is why there are no saturated stars
- The image is down-sampled 4x for the web

You can see several horizontal dark bands that lead, eventually, to a faint halo where a star has been removed. The one near the top of the frame is the most prominent, but if you look closely you will see a few more. You can even see a faint satellite trail or two that snuck through the error rejection.

Based on your description, I expect your images are showing something like this, yes?

USB traffic settings can't have anything to do with it since the bands move as the frame is dithered. Banding from USB traffic settings might mask the issue simply because they introduce additional bands, but they can't be the cause. The dark bands in my images always correspond to where there is a saturated star in the frame, and they move when I dither which is why they won't go away with stacking. I can run debanding algorithms to address the problem, but those generally introduce worse artifacts than the original problem. I generally mask the area and raise the ADU using pixelmath. It's a pain--can add more than an hour to my processing time--but it works and doesn't require any cloning, so it leaves the original signal substantially in tact.

This happens to be a stack of a little over twenty hours of data. It takes a fairly robust set of data for me to see the artifacts. The dark banding/dimming is very minor in absolute terms. In the sample provided, the band was somewhere between 1 and 2 ADU dimmer than the areas immediately above and below the band. That's a shift of just 0.002% or so.  Hopefully, this is something QHY can resolve. Because my telescope is remote, I haven't sent it in yet. Some logistics to sort.

- Jared

Banding.jpg

If this isn't what you are describing, we may have different issues.

That kind of looks like a saturation rebound problem. That was more common with certain kinds of CCDs in the past. I had never seen it with a CCD before. I'm not sure if QHY could fix that...it may be something Sony would have to address, if it is indeed with the integrated readout circuitry.

BTW, the depth on that image looks amazing. Interested in that final result!

So far I have been wary about sending it in to QHY for fear that it is not something they can address. It takes no more than an hour or so for me to address the issue in post using pixelmath (depending on the number of rows involved), and I may even build a script to completely automate the solution. I simply identify the affected rows visually, and add a value that brings them up to the average of the neighboring rows. Seems like a better solution than cloning out the row since it leaves all of the measured values in place, and it's quite a bit faster. Typical adjustment value is something like 0.15 ADU so it's a really small adjustment; it's only even visible with extreme stretching. 

In the past, QHY had suggested (in reference to the IMX461, so a different sensor in the same family--someone else's camera) that the fix would need to come from Sony.  I'm not really holding my breath even though QHY did offer an RMA. I'm not going to get it serviced without a much higher confidence level that the repair would address the issue. 

I think you've seen the final result before--I posted it on CloudyNights. I had some questions regarding the apparent halo around the galaxy that has some separation from the galaxy itself. 

- Jared
Like
jrista 8.59
...
· 
·  1 like
Jared Willson:
So far I have been wary about sending it in to QHY for fear that it is not something they can address. It takes no more than an hour or so for me to address the issue in post using pixelmath (depending on the number of rows involved), and I may even build a script to completely automate the solution. I simply identify the affected rows visually, and add a value that brings them up to the average of the neighboring rows. Seems like a better solution than cloning out the row since it leaves all of the measured values in place, and it's quite a bit faster. Typical adjustment value is something like 0.15 ADU so it's a really small adjustment; it's only even visible with extreme stretching. 

In the past, QHY had suggested (in reference to the IMX461, so a different sensor in the same family--someone else's camera) that the fix would need to come from Sony.  I'm not really holding my breath even though QHY did offer an RMA. I'm not going to get it serviced without a much higher confidence level that the repair would address the issue. 

I think you've seen the final result before--I posted it on CloudyNights. I had some questions regarding the apparent halo around the galaxy that has some separation from the galaxy itself. 

- Jared

Oh, hey Jared! Sorry, didn't know you were the same person.

I think taking a cosmetic correction approach with a script is probably the most viable solution, unless Sony decides to fix the issue. Which seems like a rather remote possibility. ;) Given how faint the bands are, you could probably even build a little PI UI to help you select the rows (say just with a click) and save them out to some config file somewhere. Then you could apply that map. It might even be possible to look for that approximate ADU deviation from the mean on a row-by-row basis, say taking the 15-20 prior and 15-20 following rows, and if there is a deviation greater than some configurable amount, normalize the row. Then you wouldn't even need to build a map, you could just automate the process. 

You really did go DEEP on this one. There is something going on around that one limb of the galaxy, that may be connected to that dark streak. Dark  dust or something. Its an amazingly deep image.
Like
msl 0.00
...
· 
I've had my QHY600M for several months but only just noticed the horizontal banding in some recent images that were overall quite bright. Initially I thought that the banding was the result of after-images from my own eyes. Apparently that is not the case nor is the banding related to bright stars. 

On pages 4 and 5 of the QHY600 user manual (astronomical-camera-qhy600_20231226073111911.pdf) there is an explanation and sample images illustrating the banding problem and QHY's official remedy of "adjusting the USB traffic." Their before and after images are quite convincing. Unfortunately, they don't explain exactly how to make the adjustments or if they are dependent on a particular camera mode.  

Interestingly, QYH's own User Images example of M78 on p. 6 of the manual seems to have the banding although somewhat rotated from true horizontal.

There are previous posts here that suggest that adjusting USB traffic hasn't been successful in removing the bands. Does anyone have a particular USB traffic setting that does work?

Michael
Like
 
Register or login to create to post a reply.