Initial attempt at image combination API#4
Conversation
|
I agree about the offsets--clarified that language. For the helper functions, what do you think about something like this (which would avoid the business of passing around the output of each intermediate step with a variable like combiner = ccdproc.Combiner()
combiner.threshold_reject(ccddata1, ccddata2, ccddata3,...) # options for setting min/max
# omitted for brevity
combiner.clip(ccddata1, ccddata2, ccddata3,...) #options omitted for brevity
combiner.calc_weights(cddata1, ccddata2, ccddata3,...)
combined_image = combiner.combine(cddata1, ccddata2, ccddata3,...)Actually, if we went down this road, then the images could be passed into the initializer for the combiner = ccdproc.Combiner(ccddata1, ccddata2, ccddata3)
combiner.threshold_reject(...) # ONLY options for setting min/max
# go in here because the combiner instance
# knows what images will be combined.
combiner.clip(...) # again, only clip options need to be specified.
combiner.calc_weights(...) # and scale/offset options..
combined_image = combiner.combine(...) |
My thought had been to construct, behind the scenes, a "weighting array" for each image that incorporates the original pixel mask, the threshold rejection, clipping and incorporate scaling/zero offsets/weights, then multiply each image by its "weighting array", then feed the result into median or mean to avoid re-implementing those. Either way, I suppose the option can accept a string and how we handle that behind the scenes doesn't really matter. |
|
+1 to the combiner class and that the list of images is initialized on input. that looks good to me. |
This also updates the API for ccdproc.Keyword to allow string values.
|
I've put in the combiner class and rebased on the most recent version of the logging branch to ease merging--let me know if you see further improvements to be made here, though! |
Initial attempt at image combination API
To be honest, I don't really like the details of the API proposed here because it requires the user to shuffle to much information from one step to the next. something like a
Combinerclass with methods for each of the steps that are currently functions might make more sense.I'm also not sure how much of the functionality of IRAF's
combinewe should provide. There are a large number of options in IRAF for rejecting pixels from a combination and I wonder how many are actually used in practice.I've also completely sidestepped two issues:
nkeep, the minimum number of pixels to keep in doing a combination, primarily omitted at the moment because I'm not excited about the number of decisions IRAF makes automatically if the number of falls belownkeep.This is a starting point though...