Hello everyone,
I think I have found a bug in the CometAlignment process, and a fix too, which I’d like to share with the community.
A few days back I was having problems while processing a 50-sub image of Comet Iwamoto crossing in front of M95 and M96 in Leo. I had successfully calibrated and star-registered my light frames, then I had comet-registered them and I had integrated them into a master star-less (or almost so) image of the comet. But whenever I tried to subtract the comet image from the star-registered frames, I couldn’t get a satisfactory result with the Linear Fit option enabled. I could get a half-decent result if I kept LinearFit disabled (only half-decent because sky conditions had improved during the sequence, so the comet had become brighter compared to the background, which LinearFit would supposefly fix), but as soon as I enabled LinearFit I would get all sort of colored artifacts: in one comet-subtracted frame I could maybe see a magenta ghost of the comet, which would turn green in the following one, and maybe blue in the next.
To diagnose the issue I checked out the PixInsight Class Library, which comes with the source code for CometAlignment. I modified the code to output the operand files after applying the homography transformation and the linear fit, and by blinking them I saw what you can see in this video:
https://youtu.be/KGtMtPU8X_cReally colorful indeed! Each frame seems to have a different overall color cast. No wonder I would see colored ghosts of the comet.
To understand a bit better, I modified the code again to output the operand files after homography but
before linear fit, and I observed what you see in this video:
https://youtu.be/67cqcY13KawAs you can see, the comet image itself doesn’t have any strange colors, but as the image shifts due to the homography transformation, the borders which are left uncovered show all sorts of colored garbage. Chances are the linear fit operation is fooled into considering those colored garbage areas as part of the operand image, and throws a color cast all over the operand. And it’s not possible to remove it by tweaking the rejection limit, because it looks like the “garbage” actually resembles some starfield image, and so has a set of pixel values that, statistically, is similar to the operand.
At that point, I decided to check the source code for the HomographyApplyTo function, and at the very beginning I saw this:
GenericImage<P> output;
output.AllocateData(wi, hi, n1, input.ColorSpace());Now, the PCL documetation for the AllocateData function of the GenericImage class says:
Note: Newly allocated pixel samples are not initialized, so the image will contain unpredictable values after calling this member function.
So, my theory is that the “garbage” is actually the unpredictable data of the note, and just happens to be data that used to belong to some other image used by the process, once de-allocated. The comet image, i.e. the operand, is pasted on top of the garbage, but the garbage still shows in the areas left uncovered by the homography transformation.
My fix for the issue is just to follow the documentation, not assume that the areas left uncovered will have any useful data, and fill the output of the homography transformation with black before doing any actual transformation:
GenericImage<P> output;
output.AllocateData(wi, hi, n1, input.ColorSpace()).Black();This simple change has completely fixed the problem for me. Now linear fit works predictably and removes my comet from the star-registered subs much better than I could do by not using it.
I hope you can fix the problem for everyone else in an upcoming update. Let me know if you want me to create a pull request for the public PCL repository.
Francesco
