Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - fmeschia

Pages: [1]
1
Bug Reports / Bug in the CometAlignment process?
« on: 2019 February 23 20:16:22 »
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_c

Really 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/67cqcY13Kaw

As 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:

Code: [Select]
GenericImage<P> output;
output.AllocateData(wi, hi, n1, input.ColorSpace());

Now, the PCL documetation for the AllocateData function of the GenericImage class says:

Quote
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:

Code: [Select]
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

2
Hello,

I noticed what I think is a strange, or inconsistent, behavior in PixInsight when I drag one process step from the history of an image onto another image. In short, what I observe is that the process step is applied to the target image without any regard for the mask that was listed in the history for that step, although the history for the second image shows the step as being applied with the original mask.

Proof of concept:
1 - create one 512x512 pixel greyscale image, with fixed value 0.5. Give this view the name “Image01” (if not automatically done by PI)
2 - duplicate Image1 and give the new view the name “Mask”
3 - apply the following pixelmath expression to the view “Mask”: iif(xpos()>128 && xpos()<384, iif(ypos()>128 && ypos()<384, 1, 0), 0) – The result should be like the one visible in the first attachment.
4 - duplicate Image1 again, and give the new view the name “Image02”
5 - apply “Mask” to “Image01”
6 - apply the following pixelmath expression to the view “Image01”: 0 (a fixed value of 0). The result should be like the one visible in the second attachment, i.e. a black square in the middle of the image
7 - open the history explorer for “Image01”, verify that the pixelmath step is there, masked with “Mask”
8 - drag the pixelmath step from the history of “Image01” onto “Image02”. The image will turn entirely black, as it would be if the mask associated with the process step in the history had been ignored.
9 - open the history explorer for “Image02”. Note how the pixelmath step for Image02 is also listed as being masked with “Mask”. However, this is not true, as Image02 clearly shows that the mask was not honored. The two histories for Image01 and Image02 show the same step applied to two identical sources, with different results, which seems inconsistent.

Am I missing something?
Thanks,
Francesco

Pages: [1]