Processing Images with and without overscan

Howard Maron

I asked this on CN yet I sense only Adam will know the causality and solution.  I was in the middle of a project when I upgraded my QHY600 ASCOM driver. In doing so I inadvertently failed to check the box "Remove Overscan Area" on the driver.  So data was gathered which had different sizes reflected in entirely different FITS headings. (NAXIS 1 and 1 were 9600/6422 vs my usual 9573/6388.  Well, processing in PI delivered a variety of errors, on most distinctively being "incompatible image geometry" .

Any ideas?  I would love to use the data I acquired with my prior data.  In reality, it's just data. No big deal. But more importantly I would love to learn from this and have a have a better understanding of the overscan area, how Pixinsight "thinks" and just some best practices.  One thing I have learned is I will never upgrade a camera's ASCOM driver mid-project. As I say that, even on that matter, I need advice.

Thanks for your help.

H

BlockHead

This isn't an area I know about really.

My understanding (which could be wrong without doing research) is that the overscan pixels are simply reserved pixels that are generally used to measure sensor characteristics (like bias level). So... If you literally crop (using DynamicCrop and an Image Container) all of your images to be the usual size- I think everything works out. If your camera/sensor is OSC (for anyone reading this)- and you crop a raw image- you also "change" the bayer matrix pattern- since it may start with a different pixel. So you have the additional step of debayering properly. 

Remember, all calibration data (darks and flats) must match the light data. So you either calibrate everything with unusually sized darks, flats, and lights... and *then* crop the results. OR you crop those calibration data as well as the lights in the beginning. 

You will not want to mix these calibration data with any new data- they should only be matched with the like stuff. 

I hope that makes sense. I wonder what was said on CN? Post the link to the thread- there should be *some* knowledgable people there...

-the Blockhead

Howard Maron

It does, of course. And 'm sure I can calibrate these with darks and flats shot with the overscan included. But thats a pain. And in the end I will have integrate those calibrated frames ultimately ultimately with the already acquired data that I acquired without the overscan area included

So how to crop on the dot!? I want to nail it. Given the pixel dimensions (which I posted from the header), I would suspect there is a method to numerically and precisely nail the crop so that I can produce its counterpart as if the overscan region was never there.  Dynamic crop I regard as "visual"  I was thinking something more numeric.
Simply stated, how do I easily make pixel box 0,0  be the same as an image without overscan? Again, I suspect Adam would bang that out like second nature!

BlockHead

This is Adam... lol .

In DynamicCrop you can specify the image size by typing in the number. Then you would make an image container from the process instance. You are doing this before you register your images. You do not need to crop to match pixels. You just crop to get the correct image size and then register all images as part of the workflow.

Let me know if that makes sense. A small video could be in order if it does not.

-the Blockhead

Howard Maron

Thank you Blockhead. You are probably correct (sorry about the "probably" but I wouldn't be using that word if it was, in fact, Adam ;-)  )

The proof will be in the pudding when I actually get around to it.  I wish to make 2 points that are potentially relevant. Firstly, the overscan region is on the left and lower side. Dynamic crop therefore allows you to use an anchor point too.  And as you point out it DOES allow for numeric entries. So, with that being the case, I can use the upper left corner as the anchor point. Specifically I can change the numeric values from 9600-6422 to exactly 9573-6388 with the anchoring point that is the 9600,0 pixel on the "overscaned images". I believe, that will provide pixel for pixel overlaps. Why do I think that matters when images vary from frame to frame and dramatically so with dither?  The reason is that I don't know what Pixinsight "needs" to not balk at image geometry.....I don't know how it thinks or what it actually cares about).

Which is part and parcel with the fact that after the crop the FITS header will still show 9600/6422 in the header. That won't change because of the crop. Thus, Pixinsight might object to that discrepancy just in the FITS header differences when integrating.  I simply don't know. 

I am probably overthinking this but it would not surprise me that there still might be errors reported.  As I said the proof will be in the pudding, but I haven't been able to get to my processing computer in these past several days so I haven't tried.

Thanks

BlockHead

PixInsight only cares about the number of pixels (dimensions) and the number of channels (color layers) of an image.These are the geometries it "worries" about.  When you crop and save the image- the header will indeed be updated if you change these attributes. 

-the Blockhead

Howard Maron

Thanks. You are 100% correct....once I saved it and reopened the header changed. You're probably thinking, "well duh!"  But, for me, it wasn't obvious. Again, thanks for your help.