Risingcam IMX571 not a gamble?

[ONIKKINEN]

Thanks @gorann, i might need thinner tilters too as im at 56-57mm with a paracorr, Askar OAG and a ZWO tilter with nothing that can be removed at the moment.

[pipnina]

Hi guys.

I've been using my RisingCam 571 mono for a while now. Controlled on Linux with INDI and Kstars. And it seemed to have an ADU floor around 600-800 in darks and bias frames when I first got it. But now it seems so low it can't possibly be correct!

Example: a 20 minute (!!) dark frame at -5c. High amp mode, 100gain 0 offset (Didn't know offset was useful until I read this thread!). Many pixels are blank (0 adu. and the average values are only 4 and 10!).

 

When imaging a faint HII region these last 2 nights, I realised the average ADU reported here was only around 300 or so... During a full-moonlit night, and with 10 minute exposures on an F4 newt (3nm H-alpha filter). Something sounds fishy!

I am wondering if it has something to do with how inconsistant my flat calibrations are. I can take some flats before imaging, and then I get massive over-correction. But then I image the next night, same settings (I think!) and same flats, and an untouched scope (sans it having gone through thermal expansion and contraction between the two nights). And on night 2 the flats from night 1 might start working! But ONLY on lights captured during night 2.

Wondering if anyone else has seen the same? Wondering if a setting has changed That's reduced the floor of my sensor or if my camera has gone wonky...

[Stuart1971]

Why are you using zero offset, that is not good, you have to have some offset, to move the histogram away from the left side of the graph, that is the point…an offset of about 25-30 is normally all that is needed, so the “min” setting is not zero, and more like 200-600

[Adam J]

8 hours ago, pipnina said:

Hi guys.

I've been using my RisingCam 571 mono for a while now. Controlled on Linux with INDI and Kstars. And it seemed to have an ADU floor around 600-800 in darks and bias frames when I first got it. But now it seems so low it can't possibly be correct!

Example: a 20 minute (!!) dark frame at -5c. High amp mode, 100gain 0 offset (Didn't know offset was useful until I read this thread!). Many pixels are blank (0 adu. and the average values are only 4 and 10!).

 

When imaging a faint HII region these last 2 nights, I realised the average ADU reported here was only around 300 or so... During a full-moonlit night, and with 10 minute exposures on an F4 newt (3nm H-alpha filter). Something sounds fishy!

I am wondering if it has something to do with how inconsistant my flat calibrations are. I can take some flats before imaging, and then I get massive over-correction. But then I image the next night, same settings (I think!) and same flats, and an untouched scope (sans it having gone through thermal expansion and contraction between the two nights). And on night 2 the flats from night 1 might start working! But ONLY on lights captured during night 2.

Wondering if anyone else has seen the same? Wondering if a setting has changed That's reduced the floor of my sensor or if my camera has gone wonky...

Never use zero offset as it means you clip the lower pixel values. Think of it as a distribution of values that sit around a mean value (the offset) if offset is zero then negative values (relative to the offset) can't exist / are clipped. That leads to calibration issues. 

[pipnina]

I think I now realise what's going on.

If I simply launch the indi server, connect on Kstars and immediately take a picture, I get a noise floor of 600ADU or so.

If I touch any camera settings related to gain mode (such as the auto exposure setting, what does that even do?) it applies the default settings LISTED in the indi control panel, but I presumed it was showing me the values already set in the driver.

Apparently that wasn't so. The offset must have been loaded at 750 or so by default, then applied at 0 when I changed anything. No wonder my calibrations are so inconsistent! My gain and offset change depending on whether I have touched the settings panel or not...

Seemingly on a 0.2s bias frame I can use an offset of 200 and get minimum ADU values between 40 and 28. I guess I'll use that value then...

What kind of difference between min and average pixel values do you guys see on your cameras in bias and dark frames?

[ONIKKINEN]

Just set the offset to at least 700 and dont touch it again. 200 sounds way too low and you will still regularly get plenty of 0 value pixels which will ruin your flats calibration.

Noise is not constant and while you did get min values of 40 now, you will definitely get a min value of 0 some time later. Testing with my own camera i found that offset values below 500 are guaranteed to have 0 pixels at some point and at some gain levels, so just leave it at the default value of 768 and call it a day.

Does Kstars have a way to set default offset that is applied in case no particular offset was ordered by the image sequence? NINA does and unless i go out of my way to change the offset value it will stay at 768, so no confusion possible.

[pipnina]

17 minutes ago, ONIKKINEN said:

Just set the offset to at least 700 and dont touch it again. 200 sounds way too low and you will still regularly get plenty of 0 value pixels which will ruin your flats calibration.

Noise is not constant and while you did get min values of 40 now, you will definitely get a min value of 0 some time later. Testing with my own camera i found that offset values below 500 are guaranteed to have 0 pixels at some point and at some gain levels, so just leave it at the default value of 768 and call it a day.

Does Kstars have a way to set default offset that is applied in case no particular offset was ordered by the image sequence? NINA does and unless i go out of my way to change the offset value it will stay at 768, so no confusion possible.

I think I'm going to do this then.

I can't find a way to set the default at first glance, I guess I'll have to make setting the gain and offset part of my routine.

[Stuart1971]

1 hour ago, ONIKKINEN said:

Just set the offset to at least 700 and dont touch it again. 200 sounds way too low and you will still regularly get plenty of 0 value pixels which will ruin your flats calibration.

Noise is not constant and while you did get min values of 40 now, you will definitely get a min value of 0 some time later. Testing with my own camera i found that offset values below 500 are guaranteed to have 0 pixels at some point and at some gain levels, so just leave it at the default value of 768 and call it a day.

Does Kstars have a way to set default offset that is applied in case no particular offset was ordered by the image sequence? NINA does and unless i go out of my way to change the offset value it will stay at 768, so no confusion possible.

700 😮😮 I and many others only use 25-30 offset…..what so high…?

[ONIKKINEN]

18 minutes ago, Stuart1971 said:

700 😮😮 I and many others only use 25-30 offset…..what so high…?

Are you talking about the rising cam or some other model of IMX571 camera here? There is absolutely no chance an offset of 30 is enough.

[pipnina]

4 minutes ago, Stuart1971 said:

700 😮😮 I and many others only use 25-30 offset…..what so high…?

I had my offset at 200 at first after realising I needed to set it manually, my minimum ADU in a bias frame was only 40. So I guess you need at least 200.

 

Out of interest, what does bias actually do in terms of electronics? Just add charge to the signal pre-amplifier or something?

[Stuart1971]

34 minutes ago, ONIKKINEN said:

Are you talking about the rising cam or some other model of IMX571 camera here? There is absolutely no chance an offset of 30 is enough.

Ah, ok mine is the QHY version, did not realise there was so much difference….sorry….👍🏼

[ONIKKINEN]

8 minutes ago, Stuart1971 said:

Ah, ok mine is the QHY version, did not realise there was so much difference….sorry….👍🏼

Actually, there is a difference even within the Rising Cam camera itself, depending on which driver and capture software was used.

The native driver has a 1:1 offset value to ADU scale, so 30 offset would be 30 ADUs. With the ASCOM driver there is an arbitrary offset slider between 0 and 31. I am guessing the ratio here is around 100:1 ADUs per offset value so here i might use an offset of 7 to get it up to 700.

I wish it were simpler and everyone just agreed to use only 1:1 offset to ADU ratio in their driver implementation, its just unnecessarily convoluted with the same values meaning different things in different software...

Also, gain used for imaging must be taken into context for appropriate offset. The default value of 768 is enough to keep images taken with a gain less than 500 (between 100-10 000) from having any 0 value pixels in my camera. I guess this value was chosen because it is unlikely anyone will be using higher gain than this for deep sky imaging where the smallest issues in calibration due to clipped pixels will be apparent, this gain is already IMO too high for any DSO work. The highest i would go for is gain 251 with 0.1e/ADU but still a decent 6.6k full well. Could be used for narrowband under very dark skies for example where read noise should be minimised to the extreme. For planetary and lunar with much higher gain than this, the clipped pixels are not nearly as relevant so the compromise of 768 offset will do just fine.

[Stuart1971]

1 minute ago, ONIKKINEN said:

Actually, there is a difference even within the Rising Cam camera itself, depending on which driver and capture software was used.

The native driver has a 1:1 offset value to ADU scale, so 30 offset would be 30 ADUs. With the ASCOM driver there is an arbitrary offset slider between 0 and 31. I am guessing the ratio here is around 100:1 ADUs per offset value so here i might use an offset of 7 to get it up to 700.

I wish it were simpler and everyone just agreed to use only 1:1 offset to ADU ratio in their driver implementation, its just unnecessarily convoluted with the same values meaning different things in different software...

Also, gain used for imaging must be taken into context for appropriate offset. The default value of 768 is enough to keep images taken with a gain less than 500 (between 100-10 000) from having any 0 value pixels in my camera. I guess this value was chosen because it is unlikely anyone will be using higher gain than this for deep sky imaging where the smallest issues in calibration due to clipped pixels will be apparent, this gain is already IMO too high for any DSO work. The highest i would go for is gain 251 with 0.1e/ADU but still a decent 6.6k full well. Could be used for narrowband under very dark skies for example where read noise should be minimised to the extreme. For planetary and lunar with much higher gain than this, the clipped pixels are not nearly as relevant so the compromise of 768 offset will do just fine.

Wow, very overly complicated, glad I got the simple QHY version…my brain would not cope with that Rising Cam, although I have been looking at getting the mono version, as it’s so much cheaper….than the QHY or ASI versions

[pipnina]

Out of interest, what do you guys master dark images look like? I'm trying to work out if my light-sealed room is as dark as I hope it is. (Camera plugged up, tin foil over the pesky lights at the back, inside a cupboard draped with old curtains and towels, inside the cellar which has tin foil over the door's window.)

High gain mode, 100gain, 768 offset. -5c cooler temp

I think maybe once I stack them together there might be some little bits of glow near the bottom edge, but it's too early to say just yet.

Cheers

Edited August 14, 2022 by pipnina

[ONIKKINEN]

6 minutes ago, pipnina said:

 there might be some little bits of glow near the bottom edge, but it's too early to say just yet.

I did see this in an extreme example i did a while back. I was curious if i get any cosmic ray hits on the chip with very long subs, so i took in total 27x 3600s subs at -10 with the camera fully plugged so no chance of stray light anywhere. Everything in the image is either some kind of external hit (like a cosmic ray or nearby radiation source) or something in the camera = ampglow.

9x 3600s stacked with maximum combination and autostretched:

27x 3600s with maximum combination and autostretched:

I doubt it would show up in any meaningful way with more reasonable exposures though. I also noticed that the glow creeping up from the top edge increased as the night went on. I had left the camera running overnight and the later exposures had more glow visible, possibly some kind of thermal leak in the camera itself when its left running at 80%+ cooling power in ambient temperatures for very long times.

[tomato]

45 minutes ago, Stuart1971 said:

Wow, very overly complicated, glad I got the simple QHY version…my brain would not cope with that Rising Cam, although I have been looking at getting the mono version, as it’s so much cheaper….than the QHY or ASI versions

I don’t make it complicated, QHY268c in DSO photographic mode, Risingcam IMX571c at gain 100, offset 768, same exposure times. I regularly combine these subs with no problem that’s apparent to me.

Edited August 14, 2022 by tomato

[pipnina]

7 minutes ago, ONIKKINEN said:

I did see this in an extreme example i did a while back. I was curious if i get any cosmic ray hits on the chip with very long subs, so i took in total 27x 3600s subs at -10 with the camera fully plugged so no chance of stray light anywhere. Everything in the image is either some kind of external hit (like a cosmic ray or nearby radiation source) or something in the camera = ampglow.

9x 3600s stacked with maximum combination and autostretched:

 

27x 3600s with maximum combination and autostretched:

 

I doubt it would show up in any meaningful way with more reasonable exposures though. I also noticed that the glow creeping up from the top edge increased as the night went on. I had left the camera running overnight and the later exposures had more glow visible, possibly some kind of thermal leak in the camera itself when its left running at 80%+ cooling power in ambient temperatures for very long times.

Hmm yours do still seem a bit more flat than mine... I'm only taking 300s exposures at the moment (planning on building a library for 1m, 5m, 10m, and 20m each)

Maybe I'll have to take things even slower and only do these calibrations at night.

Cheers for showing them to me!

[pipnina]

21x5 minute darks, -5c 768 bias 100gain, high mode.

I manually stretched it to make any gradients easier to spot. Does it seem like light is still getting in or could this be natural variations in heat. The stretch I applied was pretty extreme.

Pixinsight autostretch on the right for comparison

[Phillyo]

Good morning all.

I'm now using this camera and it all seems fine, however I'm having issues with the flats over correcting and I can't figure out why. My flats and flatdarks are both around 4.3s long, using 50 of each. Yet when I calibrate my lights with the flats (or master flat) I get a large over correction. Any ideas? 

Phil

[Phillyo]

1 hour ago, Phillyo said:

Good morning all.

I'm now using this camera and it all seems fine, however I'm having issues with the flats over correcting and I can't figure out why. My flats and flatdarks are both around 4.3s long, using 50 of each. Yet when I calibrate my lights with the flats (or master flat) I get a large over correction. Any ideas? 

Phil

Ignore this. I've fixed the issue by retaking all my dark library frames again. I assume I had some gain or ofset setup differently. Seems to be working ok now  

[pipnina]

I've noticed that because the camera doesn't seem to perform "blinks" or have a mechanical shutter, any pictures I take after s short pause in imaging can either contain ghosts if what's been seen over the last few minutes or have a horizontal banding effect.

For example after platesolving, I run my guide routine. Then the first picture that comes off the risingcam contains the star trails if my PHD calibration! No doubt this will mean my images end up containing things like dither movements and such too.

Has anyone else noticed this with theirs? Wondering if I can make it blink before every exposure in ekos or mitigate this some other way...

[ONIKKINEN]

16 minutes ago, pipnina said:

I've noticed that because the camera doesn't seem to perform "blinks" or have a mechanical shutter, any pictures I take after s short pause in imaging can either contain ghosts if what's been seen over the last few minutes or have a horizontal banding effect.

For example after platesolving, I run my guide routine. Then the first picture that comes off the risingcam contains the star trails if my PHD calibration! No doubt this will mean my images end up containing things like dither movements and such too.

Has anyone else noticed this with theirs? Wondering if I can make it blink before every exposure in ekos or mitigate this some other way...

I have not noticed this in normal exposure situations, but have actually noticed that if i shine a bright light down the tube when the camera is not exposing but still connected, such as when checking if the mirrors are dewed up mid session, the next exposure will be either completely white or have half the screen white, or some other fully saturated banding. Only happens when i blast the scope with light though. I am guessing the pixels somehow remain saturated even though the camera was not exposing and this is not purged for some reason (the blink you mentioned?).

So far has not happened with actual exposures and i definitely cant see any ghosting between pre and post dithers.

[Phillyo]

Good evening all.

So, I've been having some issues with vignetting using the Risingcam on my Samyang, which surprised me as it's a camera lens designed for full frame cameras. Anyway, I've just done the Sharpcap sensor analysis and I noticed that there seemed to be a bit of vignetting directly from the sensor. So I've just ran the Flat Wizard in NINA and strangely my camera sensor has a vignette even when NOT connected to any lens/telescope. Is this normal? I'd have thought it should be designed without any kind of vignette if it isn't connected to anything? Can anyone else perhaps check or tell me if they have the same issue please?

Thank you.

[Stuart1971]

1 hour ago, Phillyo said:

Good evening all.

So, I've been having some issues with vignetting using the Risingcam on my Samyang, which surprised me as it's a camera lens designed for full frame cameras. Anyway, I've just done the Sharpcap sensor analysis and I noticed that there seemed to be a bit of vignetting directly from the sensor. So I've just ran the Flat Wizard in NINA and strangely my camera sensor has a vignette even when NOT connected to any lens/telescope. Is this normal? I'd have thought it should be designed without any kind of vignette if it isn't connected to anything? Can anyone else perhaps check or tell me if they have the same issue please?

Thank you.

I would say that’s pretty normal, it will always be very slightly darker in the corners, well in my experience anyway…if your darks come out nice and uniform across the image then the sensor is fine, it’s purely down to the light cone entering the camera…

[Phillyo]

7 hours ago, Stuart1971 said:

I would say that’s pretty normal, it will always be very slightly darker in the corners, well in my experience anyway…if your darks come out nice and uniform across the image then the sensor is fine, it’s purely down to the light cone entering the camera…

Ok thank you 🙂