Week 1 & 2: Coding Officially Begins!
Hey Sid, did the coding period officially begin?
The community bonding period ended by the end of last month and the coding period officially began, I started to work on basic structure of the package and setting up the (not so user-friendly, PS: from astronomer’s perspective) interface for the image reduction methods.
Hey, what did you build in these two weeks?
I have set up the basic methods required for processing of astronomical images, let me explain it to you one by one:
The first method implemented was subtract_bias, this de-biases the image with the help of a bias frame, it has a mutating version as well which de-biases the image in place.
Next comes subtract_overscan, every CCD plate has some region which is unexposed to light and this is called overscan region. For pre-processing average of this region has to be obtained (there are models as well, that can fit into this region PS: model part has to be implemented later) and then subtracted from the whole image. It also has a mutating variant clubbed together.
Next in line was flat_correct, this method removes the effect of variations in pixel to pixel sensitivity of detectors and by distortions in the optical path. The interesting point I learned while implementing this is fused broadcasting, believe me Julia keeps on blowing my mind with its speed and succinct syntaxes.
Next, I implemented some basic functionalities for modifying the image sizes i.e. trim and crop. They are not much different but they are different, let me explain! Trimming is instructing the computer to remove some parts from the image, whereas cropping is instructing the computer to keep a certain part in the image (Yes, that’s the difference!). Sound’s pretty similar, right? The implementations were not that similar, crop was a bit tricky as compared to trim (check out the source code to find the difference). These functions are inherently non-mutating type, but I have also implemented a version of crop as cropview, this returns the view of the passed array. Mutating the view will mutate the initial frame passed, an analogous version for trim here is trimview.
Next in line was the function combine, it basically takes a variable number of frames, stacks them together, and then finally combines them using medians (users can also have their custom combining functions).
Okay, this one is last, subtract_dark, a way to reduce image noise in photographs shot with long exposure times, at high ISO sensor sensitivity, or at high temperatures. It takes advantage of the fact that two components of image noise, dark current and fixed-pattern noise, are the same from shot to shot. This function also has a mutating version clubbed along with it.
Hmmm, interesting… What’s next?
Wait, it’s not yet over! I have also implemented these functions to interface directly with FITS files and ImageHDU (an element of the FITS files), putting it simply, a user can load the data (stored in FITS format) directly from the disk and then can play with all these functions!
Okay, cool! So what’s next? Do you still have something in the pipeline?
Yes, the combine function still needs to be interfaced with FITS files, and once done, I will go for a release of the package. The next steps would be user-friendly processing pipelines, iterator reductions, and lot’s of documentation to be packed up together with the package.
Stay tuned to know more!
-sl