1.8RC4 Mac PJSR view.window.keywords bug?

[mschuster]

Hi Juan,

The drop below has a fits file and a small test script, a clip from WCSHeader.

view.window.keywords appears to become corrupted.

1) Launch PI 01.08.00.0990 Ripley (x86_64) on Mac OS X 10.7.5.
2) Open the FITS file pinpoint.fit
3) Execute the script.
4) Choose pinpoint.fit from the view list.
5) Repeat step 4) 10 times, at some point you will see the error.

When the failure occurs, view.window.keywords appears to be a FITS keyword object rather than an array object.

It could be a bug in my script, but I sure don't see it.

Thanks,
Mike

https://dl.dropbox.com/u/109232477/Keywords.zip

[Juan Conejero]

Hi Mike,

I can reproduce this problem on all platforms. I've never seen something like this. I've checked the relevant code in the core application and can't see anything able to cause this. Definitely, looks like a problem in the JavaScript engine.

I have found a workaround that seems to work reliably. Just perform an exhaustive garbage collection before returning from the check() function:

Code: [Select]

function check() {
   // Sometimes keywords is set to a non-array, causing keywords.length to return undefined.
   var keywords = parameters.targetView.window.keywords;
   console.writeln("keywords.length: ", keywords.length);
   var equinox = null;
   for (var i = 0; i != keywords.length; ++i) {
      if (keywords[i].name == "EQUINOX") {
         equinox = keywords[i];
      }
   }
   gc( true/*exhaustive garbage collection*/ ); /* bug fix */
}

This is not the first time we've had weird garbage collection problems. SpiderMonkey's garbage collector is very efficient and reliable, but sometimes it gives 'surprises'. Let me know if this fix works for you.

[Juan Conejero]

By the way, I have checked the astrometric referencing data of your image, and I think they can be improved significantly with Andres' ImageSolver script. This is a quick test:

1. Apply the AnnotateImage script to your image, with default parameters.

2. Apply the ImageSolver script to your image, with default parameters. Note that it performs two iterations.

3. Apply AnnotateImage again with default parameters. Compare the annotated result with the one from step 1, before ImageSolver.

[mschuster]

Hi Juan,

Regarding ImageSolver, yes you are right, some stars are better positioned, but maybe some are no better and maybe worse too?

PinPoint: RA 05 41 32.77, Dec 36 06 51.6, PA 180 11.6
ImageSolver: RA 05 41 32.46, Dec 36 06 51.6, PA 180 11.3

Image scale is 4.2"/px. RA and Dec are basically identical given image scale plus noise. Rotation appears to be the biggest difference.

Looking at StarAlignment matricies over the past year, it is not unusual to see small differences in rotation angles and perspective coefs on multiple runs - RANSAC randomness plus noise effects.

I have also run RANSAC using different software with affine model - no perspective, just rotation, scale and translation. RMS errors are usually somewhat lower. I believe the simpler model (fewer parameters) at least for my strongly undersampled plus lots of noise (3nm Ha) subs may work slightly better. But I am not positive about this conclusion - more work is needed.

Here is what I did: StarAlignment star mask -> DynamicPSF (to get subpixel star barycenters) -> RANSAC with affine model. Since my subs are well aligned except for dither, no need for triangle searching.

On topic, I will try the gc. thank you very much for your quick response. I hope to make progress on the other scripts too.

Mike

[mschuster]

Hi Juan,

gc works on Mac and Win. Thank you.

Also FYI:

For some unknown reason in RC4 Resources>Updates>Check for Updates hangs on Mac. Works fine on Win. On Mac I have to kill PI and relaunch. So far I have not been able to install updates on Mac.

Also, on Mac I see a PSJR script editor styling issue. The code

   this.__base__ = Dialog;
   this.__base__();

look as above on Win but on Mac it looks like this

   this.  base   = Dialog;
   this.__base__();

E.g, black colored "_" characters are rendered as spaces on Mac.

Also, in 1.7 I always added a zero width final column in TreeBox to get stretching to work. In 1.8, this column renders differently on Mac and Win. There is a visible column separator on one platform and not on the other.

One more thing. On Win would it be possible in the future to use different version numbers in the PixInsight64.ini file name? Running multiple versions concurrently and not have to rename the .ini would ease development.

Thanks,
Mike

[Andres.Pozo]

Hi Juan,

Regarding ImageSolver, yes you are right, some stars are better positioned, but maybe some are no better and maybe worse too?

PinPoint: RA 05 41 32.77, Dec 36 06 51.6, PA 180 11.6
ImageSolver: RA 05 41 32.46, Dec 36 06 51.6, PA 180 11.3

Image scale is 4.2"/px. RA and Dec are basically identical given image scale plus noise. Rotation appears to be the biggest difference.

Looking at StarAlignment matricies over the past year, it is not unusual to see small differences in rotation angles and perspective coefs on multiple runs - RANSAC randomness plus noise effects.

Mike, what version of the script did you use for these tests? Juan published yesterday a new version that has a fix that improves slightly the precision.

Anyway, you have to have in mind that when you need sub-arcsecond precision the geometric distortion of the optic can not be ignored. An affine transformation like the used by StarAligment can not model the distortions present in most images. If your image has a resolution of 4"/px it probably was taken with a focal of about 500mm. With this focal it would not be strange that the corners have a small distortion invisible to the eye but measurable. The difference between the result of PinPoint and Image solver is less than 0.5" that in that image is less than 0.2 pixels...

I don't know how PinPoint o StarAlignment work, but they probably manage the errors produced by the distortions in different ways.

In any case, I have been working in another script and I have done an analysis of the residual errors of ImageSolver. I have to recheck the results that I got, but perhaps there could be a way to improve the precision of ImageSolver.

Andrés.

[mschuster]

Hi Andres,

I understand and agree with your points.

Below is data comparing PinPoint and ImageSolver solutions, both in 1.7 and 1.8. You can see small differences. Whether these differences are "important" or just to due to coarse image scale and noise is unclear to me.

Looking at the annotated results for three versions, I don't think any one is better than the others, IMO. 1.8 anti-aliases the cross marks, this is the most significant difference between 1.7 and 1.8 IMO. I think 1.8 is better due to the antialiasing, at price of small bluryness which I think is acceptable.

One thing I think would be helpful: StarAlignment output a table of matched position pairs, of reference and target images. These pairs are plotted offline to compare reference position of each star with transformed target position. This would help identify systematic errors across the images due to distortion and what-not.

Thanks,
Mike


2012_06:
PinPoint: RA 20 25 03.78, Dec +40 19 23.7, PA 180 02.5 (mirrored)

ImageSolver 1.51/1.7: RA 20 25 03.402, Dec +40 19 23.66, PA 0.051
ImageSolver 1.51/1.7: RA 20 25 03.404, Dec +40 19 23.68, PA 0.051
ImageSolver 1.51/1.7: RA 20 25 03.408, Dec +40 19 23.71, PA 0.051

ImageSolver 1.7.3/1.8: RA 20 25 03.601, Dec +40 19 25.84, PA 0.051
ImageSolver 1.7.3/1.8: RA 20 25 03.600, Dec +40 19 25.81, PA 0.051
ImageSolver 1.7.3/1.8: RA 20 25 03.602, Dec +40 19 25.83, PA 0.051

2012_07:
PinPoint: RA 20 14 53.45, Dec +41 25 30.2, PA 179 56.4 (mirrored)

ImageSolver 1.51/1.7: RA 20 14 53.050, Dec +41 25 29.68, -0.060
ImageSolver 1.51/1.7: RA 20 14 53.050, Dec +41 25 29.66, -0.060
ImageSolver 1.51/1.7: RA 20 14 53.051, Dec +41 25 29.68, -0.060

ImageSolver 1.7.3/1.8: RA 20 14 53.240, Dec +41 25 31.78, -0.059
ImageSolver 1.7.3/1.8: RA 20 14 53.244, Dec +41 25 31.81, -0.059
ImageSolver 1.7.3/1.8: RA 20 14 53.246, Dec +41 25 31.82, -0.059

2012_08:
PinPoint: RA 20 22 43.75, Dec +39 00 50.7, PA 180 09.0 (mirrored)

ImageSolver 1.51/1.7: RA 20 22 43.430, Dec +39 00 51.00, 0.153
ImageSolver 1.51/1.7: RA 20 22 43.432, Dec +39 00 51.03, 0.153
ImageSolver 1.51/1.7: RA 20 22 43.440, Dec +39 00 51.11, 0.153

ImageSolver 1.7.3/1.8: RA 20 22 43.622, Dec +39 00 53.19, 0.154
ImageSolver 1.7.3/1.8: RA 20 22 43.623, Dec +39 00 53.18, 0.153
ImageSolver 1.7.3/1.8: RA 20 22 43.623, Dec +39 00 53.18, 0.154

[Andres.Pozo]

Hi Mike,

I have solved the same image using ImageSolver 1.7.3 and MaximDL+PinpointLE and I get very similar results for the image center. Also, checking the coordinates of several stars, the results are similar along all the image.

[mschuster]

Thanks Andres,

The FITS RA and Dec keys don't always match the matrix entries. Do you know why?

Here is a drop of WCSHeader script that displays the matrix solution recorded in the header. It uses Juan's patch above.

It should work on both 1.7 and 1.8RC4. I tested it on both Win and Mac.

Maybe someone could try it on 1.8RC4 linux and let me know if it works or not. Please try selecting a view 10 times in a row to see if it crashes.

Thanks,
Mike

https://dl.dropbox.com/u/109232477/WCSHeader.0.6.js

[mschuster]

FYI Juan,

Several of my scripts that access view.window.keywords fail similarly.

You implied SpiderMonkey but IMO gut feeling says something else in RC4 related to keywords may be at fault.

Thanks,
Mike

[Juan Conejero]

Hi Mike,

For some unknown reason in RC4 Resources>Updates>Check for Updates hangs on Mac. Works fine on Win. On Mac I have to kill PI and relaunch. So far I have not been able to install updates on Mac.

The update system in PI 1.8 uses secure connections (TLS/SSL) by default. This works without problems on all platforms, including Mac OS X, so the problem you're having must be specific to your machine (some system settings perhaps). A workaround is using insecure repositories. Select Resources > Updates > Manage Repositories and replace:

https://pixinsight.com/update/

with:

http://pixinsight.com/update/

Also, on Mac I see a PSJR script editor styling issue. The code

   this.__base__ = Dialog;
   this.__base__();

look as above on Win but on Mac it looks like this

   this.  base   = Dialog;
   this.__base__();

This happens indeed. This is a font rendering problem on Mac OS X (it seems that Apple doesn't like open-source fonts, e.g. the DejaVu Sans family used by PI ... which works perfectly even on Windows ... ). Open Script Editor, select Edit > Preferences (from SE's menu) and set a font size of 13 points instead of the default 12 points. This fixes the problem. Alternatively, you can select a different (Apple's) monospaced font, such as Courier.

Also, in 1.7 I always added a zero width final column in TreeBox to get stretching to work. In 1.8, this column renders differently on Mac and Win. There is a visible column separator on one platform and not on the other.

There should be no need to add a zero width column. The following method:

void TreeBox.adjustColumnWidthToContents( int col )

can be used to resize all columns automatically. For example:

TreeBox.adjustAllColumnsToContents = function()
{
   for ( var i = 0; i < this.numberOfColumns; ++i )
      this.adjustColumnWidthToContents( i );
}

Let me know if this isn't what you need, and we'll try to find a solution.

One more thing. On Win would it be possible in the future to use different version numbers in the PixInsight64.ini file name? Running multiple versions concurrently and not have to rename the .ini would ease development.

The configuration file could be user-selectable via preferences. I'll implement this on all platforms. Anyway, right now there's no reason to continue development on PI 1.7.x. PI 1.8 is now stable and we only have a few issues on Mac OS X, which the incoming RC5 version will hopefully fix.

[mschuster]

Hi Juan,
RC6 Win7 no longer requires the gc(true) keywords bugfix. Thank you. This is a relief not having to worry about.
Mike

[Juan Conejero]

Hi Mike,

The only change has been SpiderMonkey 17. That confirms that this was a problem with the previous JS engine (the unofficial---but stable---1.8.7 version of SM). Glad to know we have one less pitfall!