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.

Messages - fmeschia

Pages: [1] 2
Thank you, Juan!

Bug Reports / Re: Bug in the CometAlignment process?
« on: 2019 February 24 09:38:02 »
Hi Francesco,

Your pull request is now merged with the master branch of PCL. Thank you and welcome!

Thank you Juan, glad if I could be of a little help.

Bug Reports / Re: Bug in the CometAlignment process?
« on: 2019 February 24 09:07:18 »
Hi Francesco,

Excellent analysis. This is obviously a bug, and an important one indeed. Please contribute your changes with a pull request to our official GitLab repositories, so they can be attributed to you as deserved. Then I'll release an update as soon as possible.

If you want I'll be glad to add you to our group of members at GitLab. Let me know your GitLab user name or place a request to join us.

Thank you so much for discovering and fixing this problem.

Thank you very much, Juan. I’ll be happy to contribute back this small fix. Can you please add me to the group members, so I can create the merge request? My username is “fmeschia”.


Bumping this topic... I wonder if Juan had a chance to take a look.

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:

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:

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:

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.


i think it's always been like this (at least 10 years anyway) and so i've assumed that this works the way juan intended it to...? he'd have to chime in.


Thanks. Yes, it’s been there for a while, but I still think it’s inconsistent to show the mask as being honored in the history, whereas it is actually ignored.

The same happens when I drag and drop individual process steps from a ProcessContainer (as opposed to applying the entire process container – which honors the masks associated with each step correctly)

Attached you can find the two histories.


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?

Yes they fixed it yesterday. Thank you, Juan!

Bug Reports / Re: error in subframe selector
« on: 2019 January 30 11:55:44 »
Outstanding, thanks! Glad it wasn’t related to my hardware...

Edit: I just compiled the SFS module from the sources. The bug is gone... thank you!

Same problem here, macOS 10.14.2 and macOS 10.14.3.

Bug Reports / Re: error in subframe selector
« on: 2019 January 28 22:42:15 »
And it gets even weirder: if I launch the SubframeSelector process by double-clicking on its icon in Process Explorer, it always works correctly: no errors, and the graphs are always present. 100% of the time.

Bug Reports / Re: error in subframe selector
« on: 2019 January 28 20:27:11 »
Some additional oddity: if I invoke the SubframeSelection process just at the program start, before the splash screen has faded out, I reliably don’t get any error in the UI, I see the graph panel, and i don’t see the "js: Uncaught ReferenceError: getApprovalIndex is not defined” message in the standard output.

Bug Reports / Re: error in subframe selector
« on: 2019 January 28 19:21:21 »
The problem here is the Intel graphics driver, which is the only one available on your Mac. The driver is probably buggy but unfortunately is not being detected and blacklisted by the Chromium browser component. Also unfortunately, Apple won't update this driver because your MBP has been discontinued.

This is the first time I see one of these problems on macOS. For now, the only solution is running PixInsight from the command line. Open the Terminal application and enter the following command:

/Applications/PixInsight/ --opengl=software&

This will disable the use of hardware acceleration. Let me know if it works this way.

Thank you very much! Unfortunately, the problem persists even by launching PI in this way.
What I find puzzling is that, if I understand correctly, the problem is related to the chart component, but isn’t that the same component used for the charts in PCC? I don’t have any problem with those...

I updated to the latest version of the SubframeSelector process today, but unfortunately the error is still there.
Not sure if it’s related, but when I launch PI from the command line, the following message is printed in the Terminal window when I invoke the SubframeSelector process:

Code: [Select]
$ /Applications/PixInsight/

PixInsight Core Ripley (x64)
Copyright (c) 2003-2019 Pleiades Astrophoto

js: Uncaught ReferenceError: getApprovalIndex is not defined

Pages: [1] 2