Beware ROI

Discussion of features and issues relating to Altair Astro Cameras
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Beware ROI

#1

Post by oopfan »

I have an uncooled Altair 290M. The matrix is 1920x1080 maximum. Most times I image at that size however my last imaging session I chose 1280x1024. Big mistake. Apparently the camera's firmware implements ROI. It appears to be CPU intensive thus creating heat. Using FITS Liberator my dark frames had a mean pixel value of 5150 out of 65535. Ordinarily it reads around 375 when using 1920x1080 at similar ambient temperature. (In both circumstances I used the same gain and offset.) I had a clue that something was awry when I was taking darks and I saw a wide gap on the left-hand-side of the histogram. Later, in post-processing it became evident that I had a problem with thermal noise.

Whether or not you have an Altair camera I highly recommend that you do a simple test before you waste an entire night of imaging.

Brian

EDIT: Due to the lack of a temperature sensor my initial diagnosis was incorrect. The cause was not an overheated sensor but appears to be a "rogue" offset value (i.e. black level). I specified offset of 20 but it is behaving as if it is 320. Even more peculiar is that it happens on some nights but not others. I will update to the latest version of 3.1 and keep an eye on it.
Last edited by oopfan on Sun Jul 15, 2018 1:22 am, edited 1 time in total.
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Beware ROI

#2

Post by admin »

Hi,

this intrigued me - it sounded possible that extra work in the camera CPU could increase temperature, but ROI should not really add much work, so I was surprised.

I decided to test this myself and so far I can't reproduce this effect with an Altair 290M (USB2) or Altair 290C (USB3).

I tested with 5s exposures, maximum gain, 12 bit, low black level (same for both resolutions).

With the 290M I recorded

1280x1024 ROI - Mean pixel value ~4270
1920x1080 (no ROI) - Mean pixel value ~4800

So actually I get a higher mean pixel value with the full frame - I think this is just due to the region around the edge of the frame having most of the amp glow effects in it. Cut down to 1280x1080 and you exclude this brighter part of the frame.

With the 290C3 I looked at the sensor temperature instead of the pixel values (since this camera has a temperature readout). The temperature gradually increased after turning the camera on from room temperature to about 35C. There was no significant jump in temperature when I moved from 1920x1080 to 1280x1024 or any drop when I moved back again (allowing several minutes after each change for any temperature change to show up).

So, in summary I can't reproduce Brian's results above - if there is something going on then it is more subtle than just depending on ROI.

cheers,

Robin
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#3

Post by oopfan »

Robin,

There is a possibility that the ZWO Filter Wheel is the culprit (see attachment) except for that one anomaly with NGC 6888 on the second row of data. I am not using a USB hub. There only two USB cables, one to the Mini EFW and the other to the camera. They are one-meter in length from the manufacturer. Until I can figure this out I'll have to go back to my leaky Orion manual filter wheel. Wonderful.

Thanks for looking into this,
Brian
Attachments
Spike in Dark Current.jpg
Spike in Dark Current.jpg (103.81 KiB) Viewed 4748 times
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#4

Post by oopfan »

Robin,

I hooked up my camera and filter wheel indoors and put it through its paces but I could not see any anomalies.

I went back to the data as shown in the spreadsheet from my last post and dug deeper. I found something very curious that makes me think that this is related to SharpCap Settings: "Save 10/12/14 bit images in FITS files without stretching to 16 bit (Altair, QHY, ZWO cameras only)"

For photometry I check the box. For astrophotography I uncheck the box. I have not done photometry since April so the box has been unchecked for three months.

So let's look deeper:

For the target "V1331" I see a crazy-high minimum pixel value of 5008 in FITS Liberator. When I open up "histogram.csv" It says that the first non-zero pixel value occurs at 313 ADU. If you multiply 313 by 16 you get 5008.

For the target "NGC 6888" I see a minimum pixel value of 192 in FITS Liberator. When I open up "histogram.csv" it says that the first non-zero pixel value occurs at 12 ADU. If you multiply 12 by 16 you get 192.

This relationship holds true for each and every target in the spreadsheet. My experience with darks is that the minimum pixel value is in the range of 200 to 300 for the settings I use and average ambient temperature. That is what I would describe as normal. So it appears that under some peculiar circumstance that the ADU value is being multiplied by 16 twice.

I am running version 3.1.5181. I will install the latest 3.1 and keep my eye on it.

Brian
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#5

Post by oopfan »

Robin,

Perhaps this option of scaling back to original ADU counts is a bad idea since it is the camera drivers that are doing the stretching. From what I understand Altair, QHY, and ZWO give you enough information for you to unstretch it but things seem to change on a whim without any consideration for the downstream effects.

My feeling is that if someone wishes to do photometry, xe should already know the bit depth of the camera. In my case it is 12 bits. It is not difficult for me to pre-process my images in CCDStack2.

An alternative is for me to explicitly tell SC the bit depth: 8 bits for MONO8 and 12 bits for MONO12. Of course this changes with the camera being used so it makes the settings dialog more complex.

Just a thought.

Thanks,
Brian
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#6

Post by oopfan »

Robin,

Another bit of information that might help to make sense of things is this: prior to slewing to the target to prepare for imaging in MONO12, I spend a good deal of time in MONO8 during the learning phase of my periodic error correction. The scaling factor for MONO8 is 256 which is 16*16. Perhaps under some circumstances when I switch from MONO8 to MONO12 SharpCap is retaining 256 instead of changing it to 16.

Fortunately when I am done with periodic error correction I have no further need for MONO8. I could easily switch to MONO12, close the camera, close SC, and restart it.

Brian
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#7

Post by oopfan »

Robin,

I imaged NGC 6791 over the course of two nights, June 11 and June 15, when I captured 50-second subs in Red. SharpCap applied the correct stretch factor of 16 on June 11th but on June 15th it applied a factor of 256.

I attached a screenshot of FITS Liberator side-by-side. (I like to do the ArcSinh stretch in FITS Liberator in order to reveal the shape of the histogram.)

I was using the same version of SharpCap and my ZWO EFW. I used the same procedure for PEC learning that I described in an earlier post. Unfortunately I cannot recall anything that I did differently that would account for this difference.

Thanks,
Brian
Attachments
NGC 6791 Abby Normal Stretch.jpg
NGC 6791 Abby Normal Stretch.jpg (281.85 KiB) Viewed 4710 times
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#8

Post by oopfan »

Robin,

The more I look at the data it looks like someone or something is adding 300 ADU counts to each pixel. That's an odd number 300. Perhaps it's 256 and the difference can be explained by different temperature and transparency.

So that's my theory: something is adding 256 ADU counts to each value when it gets into this aberrant mode sometime before the scaling factor of 16 is applied.

EDIT: I just thought of one other possibility. All of my imaging is performed with Offset of 20. I don't know where Offset is applied but it would make sense if it was in the firmware on the sensor. I find it curious that 20 times 16 is 320. That is awfully close to the "300 ADU counts" I mentioned above. Do you think that it is possible that SC is multiplying my stated Offset by 16 before sending it to the camera?

Brian
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Beware ROI

#9

Post by admin »

Hi Brian,

please can you send me a frame of each type and the corresponding .capturesettings.txt files so that I can investigate further? I don't want to jump to any conclusions just yet, but I'm sure we can come up with an explanation eventually.

cheers,

Robin
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: Beware ROI

#10

Post by oopfan »

Sent to you
Post Reply