Pre-Cropping

[mjpost1]

I have a full-frame CCD array that produces 71.6 MB sub frames.  Often I am only interested in a small part of the entire frame, say the central area, that may be as small as 1/10 the area of the entire frame.  It seems a waste of time and computing resources to process full frames for calibration and integration, when in the end I'll be cropping away, perhaps, 90% of the data.  Besides, for quality indicators and cosmetic fixes, I'm only interested in properties of pixels in the smaller area, not the entire frame.

It would be nice to be able to define an arbitrary, smaller area of my full frame up front, before calibration and integration, and then calibrate and integrate only that smaller area henceforth in all the subframes, using exactly the same pixels from the full-sized master bias, dark, and flat frames.

Any chance of getting such a pre-cropping ability into PixInsight, so I won't have to pre-crop all my subframes and calibration frames externally, say in Maxim DL?

[pfile]

im sure you can pre-crop them in PI using ImageContainer and Crop or DynamicCrop... at least you don't have to do it externally.

rob

[mjpost1]

After MANY frustrating hours I discovered that I cannot use DynamicCrop on non-debayered images, as suggested.  When I do, I lose all color information.  I have to debayer full-sized light images and all calibration masters first, then apply dynamic crop to the debayered, full-sized images and masters.  I am not rotating the crop box - simply keeping it centered and pulling in the top, bottom, right, and left edges. This defeats the normal process for calibrating OSC images using non-debayerd master files, and adds a lot of extra work

The inability to pre-crop as suggested is a pain!  Can DynamicCrop be fixed so it can operate on raw OSC images and calibration masters without first debayering them, and still retain all the vital color infomation contained therein?

[bulrichl]

What is the problem with cropping of non-debayered images?

Use the 'Crop' process and make sure that the top and left margins are EVEN numbers.

Bernd

[mjpost1]

Thanks Bernd!  The key is getting the cropped image to register properly with the CFA matrix.   The original (full size) image has pixel numbers (0,0) for top left corner, so for proper registration the cropped image must have both pixel values even in the top left corner (which you pointed out so expertly).  I can make that happen in Crop process, but have not yet succeeded in DynamicCrop process, where two decimal places are found in the pixel coordinates.

I reiterate to the PI team - it would be nice to be able to use DynamicCrop on OSC raw images and master files, but I cannot find a way to make that happen.  Only Crop seems to be able to do the job properly.

The need to have top left corner of a cropped OSC image to have even pixel coordinates should be documented.  I could find it nowhere.

[msmythers]

Not trying to be rude but I'm I missing something. If the Crop tool works then why not use it? Why the need for the DyanamicCrop tool in this use? Just asking.


Mike

[blueridgeDSIA]

I hope I am understanding your issue correctly, and if I am please read the last post by OldWexi in this link  https://pixinsight.com/forum/index.php?topic=9324.0
I use Blink to pre batch crop my data all the time, I have a 60d with the CFA scraped off and the edges need to be cropped so I always use teh blink cropping feature on calibrated data before going into the registration process.  I think you should have no problem cropping a dso in your images and saving those batch cropped files to further process.   

[pfile]

ahh - good one. forgot that blink could do that.

rob

[mjpost1]

Thanks, all!  Using Crop on 10-20 individual, raw images before any pre-processing is what I've been doing, but its cumbersome.  Hence my wish for DynamicCrop to work.  I'll see if I can make Blink work with Crop, as suggested.  That sounds much friendlier!