cannot reproduce ImageSolver with Distortion Correction checked generates error

[Juan Conejero]

Juan
I included this is Post #4 but it was at the very bottom.

Below is the link to an image file.

Iris Int.xisf

drive.google.com

1. I have been troubleshooting this problem and found that the Error is occurring with the ReferSpline call in the WCSmetadata.jsh file.

2. It appears to only go through the first for loop two times before crashing. p1.length = 1164, p2.length =1164.

3. Do your Macs have more than 16GBytes of memory? I not sure that it matters since my understanding is less memory only slows down processing because Swap files may need to be used.

Thanks for your help
Jack

Hi Jack,

I already downloaded your Iris image when you posted the above link. It can be solved perfectly with default ImageSolver parameters on our Mac machines:

==================================================================================================
Creation time ............ 2025-01-02 15:48:25 UTC
Creation software ........ PixInsight 1.9.2 / ImageSolver 6.3.1 (macOS)
Reference catalog ........ Gaia DR3
Linear transformation matrix (world[ra,dec] = matrix * image[x,y]):
 +2.79762053e-05  +2.72574082e-04  -6.56600105e-01
 -2.72622277e-04  +2.79682386e-05  +7.93803207e-01
WCS transformation ....... DDM thin plate spline
Control points ........... 10145
Spline lengths ........... l:3879 b:3998 X:3990 Y:3935
Surface residuals ........ l:0.154 px b:0.172 px X:0.087 as Y:0.110 as
Projection ............... Gnomonic
Projection origin ........ [3125.945054 2088.048943] px -> [RA: 21 01 48.322  Dec: +68 11 40.39]
Resolution ............... 0.987 arcsec/px
Rotation ................. -95.854 deg
Reference system ......... ICRS
Observation start time ... 2022-07-30 08:12:35 UTC
Observation end time ..... 2022-09-02 06:52:35 UTC
Geodetic coordinates ..... 120 46 26 W  42 55 33 N  0 m
Focal distance ........... 786.16 mm
Pixel size ............... 3.76 um
Field of view ............ 1d 42' 47.6" x 1d 8' 39.6"
Image center ............. RA: 21 01 48.321  Dec: +68 11 40.39  ex: -0.004565 px  ey: -0.013304 px
Image bounds:
   top-left .............. RA: 20 54 28.909  Dec: +68 58 43.34  ex: -1.156715 px  ey: -1.740921 px
   top-right ............. RA: 20 56 49.017  Dec: +67 16 41.80  ex: +0.108549 px  ey: -1.113858 px
   bottom-left ........... RA: 21 07 12.425  Dec: +69 05 59.95  ex: -1.094887 px  ey: +1.103070 px
   bottom-right .......... RA: 21 08 38.435  Dec: +67 23 27.22  ex: +0.189772 px  ey: +1.752220 px
==================================================================================================

1. I have been troubleshooting this problem and found that the Error is occurring with the ReferSpline call in the WCSmetadata.jsh file.

2. It appears to only go through the first for loop two times before crashing. p1.length = 1164, p2.length =1164.

As noted, we can solve this image with default parameters without problems. On all supported platforms. On all our machines.

3. Do your Macs have more than 16GBytes of memory? I not sure that it matters since my understanding is less memory only slows down processing because Swap files may need to be used.

None of our machines has less than 32 GB of RAM. None of our working workstations has less than 128 GB. I have just solved this Iris image on a MacBook Pro M1 Max with 64 GB of RAM running macOS Sequoia 15.2. I can also solve it on an Intel core i9 MacBook Pro with 32 GB of RAM running macOS Sonoma 14.7.2.

However, memory size is not a problem here. Although the new DDM thin plate splines require about 2.5x - 3x more memory than the old implementation, we are talking of hundreds of kilobytes or a few megabytes in the worst cases, compared to previous versions. This cannot represent a practical problem even on machines with severe RAM limitations.

Are you sure you have Gaia DR3 XPSD database files well configured and stored in a folder where they can be accessed with your user account? Are you running an antivirus application on your Mac? A file backup service running as a background task? Any other utility that could interfere with normal disk I/O access?

 

[Juan Conejero]

Juan
I have uploaded a cropped version of the original image I put on Google drive. This file is 1420x1420 and ImageSolver with DistortionCorrection checked works with this cropped version. If I make the crop slightly larger then ImageCorrection fails.

Iris IntCrop1420x1420.xisf

drive.google.com

Jack

As expected, this one can also be solved perfectly with default ImageSolver parameters:

==================================================================================================
Creation time ............ 2025-01-02 16:16:19 UTC
Creation software ........ PixInsight 1.9.2 / ImageSolver 6.3.1 (macOS)
Reference catalog ........ Gaia DR3
Linear transformation matrix (world[ra,dec] = matrix * image[x,y]):
 +2.79582715e-05  +2.72475699e-04  -2.13305285e-01
 -2.72475160e-04  +2.79675307e-05  +1.73584981e-01
WCS transformation ....... DDM thin plate spline
Control points ........... 342
Spline lengths ........... l:342 b:342 X:342 Y:342
Projection ............... Gnomonic
Projection origin ........ [709.942883 709.995459] px -> [RA: 21 01 48.321  Dec: +68 11 40.43]
Resolution ............... 0.986 arcsec/px
Rotation ................. -95.860 deg
Reference system ......... ICRS
Observation start time ... 2022-07-30 08:12:35 UTC
Observation end time ..... 2022-09-02 06:52:35 UTC
Geodetic coordinates ..... 120 46 26 W  42 55 33 N  0 m
Focal distance ........... 786.52 mm
Pixel size ............... 3.76 um
Field of view ............ 23' 20.2" x 23' 20.2"
Image center ............. RA: 21 01 48.320  Dec: +68 11 40.44  ex: +0.003407 px  ey: -0.004326 px
Image bounds:
   top-left .............. RA: 20 59 29.721  Dec: +68 22 00.59  ex: -1.163352 px  ey: -1.730371 px
   top-right ............. RA: 20 59 57.438  Dec: +67 58 50.55  ex: +0.162786 px  ey: -1.100666 px
   bottom-left ........... RA: 21 03 41.537  Dec: +68 24 24.58  ex: -1.148846 px  ey: +0.123575 px
   bottom-right .......... RA: 21 04 05.086  Dec: +68 01 12.00  ex: +0.110644 px  ey: +0.109704 px
==================================================================================================

 

[01blueglide]

This is baffling. I have the same exact issues as others have described and the only commonality among us at this time appears to be Mac users with 16gb of RAM. I have been actively shopping for a computer with more RAM believing that was the fix for my problem. After Juan's explanation that the distortion correction feature shouldn't be extremely memory intensive I may be wasting my time buying more computer. All of the other troubleshooting suggestions (turn off Time Machine, disable antivirus, make sure Gaia is correct, etc.) have not corrected the issue.

 

[cloudbait]

None of our machines has less than 32 GB of RAM. None of our working workstations has less than 128 GB. I have just solved this Iris image on a MacBook Pro M1 Max with 64 GB of RAM running macOS Sequoia 15.2. I can also solve it on an Intel core i9 MacBook Pro with 32 GB of RAM running macOS Sonoma 14.7.2.

However, memory size is not a problem here. Although the new DDM thin plate splines require about 2.5x - 3x more memory than the old implementation, we are talking of hundreds of kilobytes or a few megabytes in the worst cases, compared to previous versions. This cannot represent a practical problem even on machines with severe RAM limitations.

While the logic behind suggesting that memory size isn't a problem is reasonable, things don't always work out the way we think they should. Empirically, there's reasonable evidence here that a problem is only showing up with 16 GB Macs.

You specify minimum system requirements for all three operating systems. It seems to me you need to have at least one test machine configured to those minimum requirements for each platform.

 

[pfile]

This is baffling. I have the same exact issues as others have described and the only commonality among us at this time appears to be Mac users with 16gb of RAM. I have been actively shopping for a computer with more RAM believing that was the fix for my problem. After Juan's explanation that the distortion correction feature shouldn't be extremely memory intensive I may be wasting my time buying more computer. All of the other troubleshooting suggestions (turn off Time Machine, disable antivirus, make sure Gaia is correct, etc.) have not corrected the issue.

it's actually not the first time we've seen an issue with macs with smaller memory sizes. there is a problem in PhotometricMosaic that only manifests on macs with smaller amounts of RAM. in that case it's some kind of javascript engine problem and the issue goes away if you lower the number of control points PMM attempts to use.

i don't know how much of the heavy lifting in ImageSolver is done directly in JavaScript but there's always the possibility that we're looking at a similar problem.

 

[01blueglide]

You specify minimum system requirements for all three operating systems. It seems to me you need to have at least one test machine configured to those minimum requirements for each platform.

I couldn't agree more. It is somewhat frustrating to think my hardware is within parameters for a particular application only to be told there is no problem on machines with 2x, 3x, or 4x more resources. I will certainly upgrade equipment if required but don't want to just 'throw money' at a problem hoping it gets solved.

 

[AstrGerdt]

While I agree with cloudbait, that it is possible that there is some connection to the RAM requirement of the machine that is not easily detectable, this really seems very far fetch from my POV.

I often have the Taskmanager open while processing images in PixInsight on my Windows 11 machine with 32gb of RAM.
Except for WBPP (and alle the included processes), I never see PixInsight comsuming more than 5gb of RAM under normal workload, so a memory consumption issue seems very unlikely.
Especially after Juan confirmed the low memory usage of the distortion correction algorithms.

Regarding the GAIA files: PixInsight provides a hash for each file. Have you verified them? I one had problems because one of the files was damaged, probably (but not sure) while downloading it. Verifying the file integrity could help in this case.

As I haven't read all of this thread, I don't remember perfectly whether this has already been suggested.

Also, you could try running ImageSolver with an online catalog. That could further reduce the dependency on the GAIA catalog and completely exclude any errors from this part.

CS Gerrit

 

[01blueglide]

This again is kind of an 'apples and oranges' debate. A windows machine with 32gb of RAM doesn't compare to MacOS with 16gb. Another common issue among us having problems is once we turn off distortion correction the frame solves. My Gaia files are fine, in the correct place, and allow image Solver to work fine as long as I don't use distortion correction. I also have had unexplained, random crashes, on PI 1.9.2 that never happened on Ripley. They aren't frequent or reproducible but they occur and nothing has changed except the updated program.

 

[AstrGerdt]

My intention was not to say that our machines are comparable.
My point was more about the fact that PI never used so much RAM to hit any limitations there with your system, so this is an unlikely and unpromising point to look for errors from an outsider (not PTeam member) perspective.
It is not impossible that there is a problem, but again, we have a low chance of finding such a problem as outsiders.

However, we can exclude certain parts.
As with the RAM limit, it is possible that there is some relation or side effect that we are not aware of, so excluding some components leaves further options to look.

That is why I came up with the idea to use an online catalog, to completely eliminate the dependency on the GAIA process.
The GAIA process is called rather often during distortion correction, judging from the console logs.
Thus, excluding this (significant) process could benefit the error search, for you and for Juan.

CS Gerrit

 

[cloudbait]

My intention was not to say that our machines are comparable.
My point was more about the fact that PI never used so much RAM to hit any limitations there with your system, so this is an unlikely and unpromising point to look for errors from an outsider (not PTeam member) perspective.
It is not impossible that there is a problem, but again, we have a low chance of finding such a problem as outsiders.

However, we can exclude certain parts.
As with the RAM limit, it is possible that there is some relation or side effect that we are not aware of, so excluding some components leaves further options to look.

That is why I came up with the idea to use an online catalog, to completely eliminate the dependency on the GAIA process.
The GAIA process is called rather often during distortion correction, judging from the console logs.
Thus, excluding this (significant) process could benefit the error search, for you and for Juan.

CS Gerrit

In my experience, resource monitors are useful for certain kinds of diagnostics, but not others. In particular, they do not generally show transient resource demands. So if there's something in the code somewhere (possibly involving some third-party library) that attempts to allocate a large amount of memory and fails to handle that exception well, it probably won't show up in a resource monitor.

Broadly, I think an issue that shows up on multiple platforms is a consequence of PI code (and usually these issues get addressed quickly), while those that show up on one platform suggest problems with third-party code.

 

[tom886]

The memory management on Mac is much better than on Windows, so this part can't be compared.

My Gaia files are fine, in the correct place

I still would suggest to compare the hashfiles of the downloaded Gaia files, it can't hurt, but would eliminate one possible error source.
Now the unpopular question: What's the difference between the MACV machines where the error doesn't happen and the machines where it happens.
Could it be a QT mismatch?

Cheers
Tom

 

[01blueglide]

The memory management on Mac is much better than on Windows, so this part can't be compared.

I still would suggest to compare the hashfiles of the downloaded Gaia files, it can't hurt, but would eliminate one possible error source.
Now the unpopular question: What's the difference between the MACV machines where the error doesn't happen and the machines where it happens.
Could it be a QT mismatch?

Cheers
Tom

I'll take a look at the hashfiles tomorrow. I have my rig imaging the Iris Nebulae tonight so I want to do some processing tomorrow. What is QT?

 

[tom886]

What is QT

QT is a module allowing developers to include web views, render web pages, and run JavaScript within their Qt applications
This is included in Pixinsight, unfortunately the latest version 6 caused a lot problems in Pixinsight, which even went so far, that version 1.90 and 1.9.1 were shipped with v6.5.6 LTS (only for MAC) and from v1.9.2, QT v6.8.1 was used for all platforms (incl. MAC).

Cheers
Tom

 

[cloudbait]

Quicktime.
This is included in Pixinsight, unfortunately the latest version 6 caused a lot problems in Pixinsight, which even went so far, that version 1.90 and 1.9.1 were shipped with v6.5.6 LTS (only for MAC) and from v1.9.2, QT v6.8.1 was used for all platforms (incl. MAC).

Cheers
Tom

Qt isn't Quicktime. It's a cross-platform UI development tool.

 

[tom886]

You are right, I am still mixing this up with QuickTime from long time ago.

This module allows developers to include web views, render web pages, and run JavaScript within their Qt applications.

I'll correct my statement.

Cheers
Tom

 

[Jkcolli]

1. My images solve fine with 1.8.9.3. Is this an indication that I have the GAIA files configured properly?

2. My images solve fine with 1.9.2 if Distortion Correction is not checked. Is this an indication that I have the GAIA files configured properly?

3. My image solves fine with 1,9.2 with Distortion Correction checked if I reduce the size of the image to 1420x 1420. Is this an indication that I have the GAIA files configured properly?

Jack

 

[Jkcolli]

Please see post 4 which shows a screenshot of my GAIA setup. Does anyone see anything incorrect?
Jack

 

[Jkcolli]

I am redownloading the GAIA files.
Can someone explain how I check the checksum on a Mac.
Thanks
JaCK

 

[Jkcolli]

Juan
Do you have any thoughts on why the smaller file succeeds, while larger files fail.
Thank you
Jack

 

[talbotj]

I am experiencing exactly the same issue on both my Macs when using large images. Both Macs have 16gb of Ram. The first Mac is an iMac with Monterrey 4GHz quad core I7. The second is 2019 MacBook Pro with Sequoia 15.2, 2.3 GHz 8 core I9. If distortion correction is checked, error. If distortion correction is unchecked then the plate solve works but takes significantly longer than the previous version of PI. I have the entire Gaia set and it's in a separate directory. Tried both local xpsd server and online server.
As Jkcolli, if I reduce my image size to 1197x798, plate solve works with distortion correction. My native size image size is 9576x6388.

Plate solving has always worked on both machines with PI 1.8 versions and earlier.

Jon