Upper Range cannot be above 9923 in FITTS Format Preference

[bitli]

In FITS format preference, I can enter values in Upper Range up to 9223. When entering any value from 9224 or above it sets the value to -9223.372036854776500.

This happens on Windows 7 64 bits.

[ADDED:]
Screen capture.
Sorry, but the problem persists when I restart PI and do it in the first operation.

-- bitli

[Niall Saunders]

Hi Bitli,

Are you using a 'wireless' keyboard?

Cheers,

[Juan Conejero]

Niall, you aren't alone!

Jokes apart, this extremely odd thing must be identified and fixed once and for all. Let me build a test core application and I'll be asking you to be your TeamViewer guest.

Yes, I bet he is also using a wireless keyboard. Are you bitli? Can you check if this behavior stops when you use a wired keyboard?

[Niall Saunders]

Hi Juan,

The next few days may be an ideal opportunity for you - I am 'home alone' during the next three weekday evenings, and the entire weekend. My PC will be available to you.

Cheers,

[bitli]

I am really sorry Juan, but the keyboard is a cable only, 1 month old, high quality logitec keyboard, and worked perfectly wit any other applications.

I know it looks strange. In fact the negative value you have seems to be exactly the limiting value.

Maybe a side effect of some array overflow or errant pointer to put that value over your high limit? Before restarting the program, I need to find a way to make a 'movie' from the error, otherwise JUan will believe that we do a practical joke on him  . Then I will restart the program to see if the effect disappear. 

But is is extremely annoying. I am stuck with LightBucket that do not want to consider format issue and PixInsight that refuse to load any image with data  out of 0.0 - 1.0 range....

-- bitli

[NKV]

Yes, I bet he is also using a wireless keyboard.

I'm using a wireless keyboard Logitech diNovo. I confirm the bug.
Win7-64 / PI1.6-64

[Juan Conejero]

Okay. So we have a "hardcore" problem here. While I try to figure out what this stuff is all about, here is a solution to let you specify the FITS input range without resorting to the FITS Preferences dialog.

- Exit PixInsight.

- With Windows Explorer, locate PixInsight's configuration file:

  %APPDATA%\Pleiades\PixInsight.ini

where %APPDATA% should be on Windows Vista and Windows 7:

  C:\Users\<your-user-name>\AppData\Roaming

- Open PixInsight.ini with a good plain text editor. This excludes Notepad. You can use PixInsight's script editor if you make a copy of PixInsight.ini on a different folder, edit and save it with PixInsight, exit PixInsight, then replace the original with the edited version.

- On your text editor --for example on PI's script editor--, look for the following two lines of text:

ModuleData\FITS\FITSLowerRange=0
ModuleData\FITS\FITSUpperRange=1

They should be together or very close in PixInsight.ini. They may have other values different from 0 and 1 if you changed them. Just write the values you need for FITSLowerRange and FITSUpperRange, and save the file.

- Now restart PixInsight and the new FITSLowerRange/FITSUpperRange values will be in effect.

Ugly, but works.

Oh and, Niall, please don't laugh so loudly, I can hear you!

[Niall Saunders]

Juan, believe me - I am NOT laughing. I do not envy you the task of hunting this bug down. And my offer of my time and PC, via Teamviewer, still stands. I will send you an off-group email with my mobile number, you can send me an SMS Text message and I will do my best to 'appear' for you.

And another tip for those troubled with this 'bug'. With one 'instance' of PixInsight running, start a SECOND instance of PI at the same time. Then close both instances down.

What you will now have will be the PixInsight.ini configuration file (as described earlier by Juan), but it will have two (identical, at this stage) 'sections' within it. Now, the way I work things is that I edite the SECOND half of the config file, and make my [0.0, 65535] change to the SECOND INSTANCE ONLY.

This allows me to load my Meade Envisage 32-bit Float images into the SECOND instance, and to then convert them (with an ImageContainer and the SampleFormatConversion process) to 16-bit Unsigned Integer format - for use whilst I calibrate the data.

The actual 'calibration' steps are still carried out in the 'first instance' of PI - because all the data is, by then, in 16-bit UI format, which is perfectly 'OK' for PI, as it meets all 'common sense' FITS standards.

Once I have converted my data into 16-bit UI, I can close PI(2) down until the next session of data needs to be converted (a process which takes, in the grand scheme of things, almost 'no time at all')

Hope this helps.

Cheers,

[Juan Conejero]

Yes guys, bug fixed!!!  8) 

Please see this announcement.

Fortunately, this time I've been able to reproduce it on my main Windows development machine (and with a wired keyboard and all!). It has been relatively easy.

The floating point input range controls on the FITS and TIFF preferences dialogs have 15 digits of decimal precision. This is just to provide enough accuracy for 64-bit floating point values. When you enter a new value in these controls, they have to round the value to 15 decimal digits, which implies a multiplication by 10¹⁵, an integer rounding of the multiplied result, and a division by the same factor. For some odd reason, the MSVC++ compiler is doing this very wrongly above the 9923.... value in question. The same routines work perfectly on Linux and Mac OS X compiled with GNU's g++.

So I've reduced the precision to 14 decimal digits in the Windows versions (no big deal), and this has fixed the bug. After this bug however I'm going to check several core math routines in the PCL because something doesn't smell well here. I'll keep you informed.

Thank you for your patience, and for helping me to make PixInsight better.

[bitli]

I can confirm that the corrections works perfectly on 7 64 bits (at least with a wired keyboard - sorry, I could not resist). Thank you very much for the prompt correction. BTW I had to restart the computer (maybe loggin-off on would have been enough), otherwise it seems the old DLL are still used (probably still loaded).

Now I can read the LB FITS files, they look better, but there is indeed something completely wrong with the levels. I will try to guess the processing that was done from the FITS keywords and see if there is a bias to remove or something.  And get back to LB to see if they can help. After all, Juan did  half of the road to meet them, so they could do something to (they are generally pretty helpful too).

-- bitli

[Niall Saunders]

Thanks Juan - I am REAL happy that it wasn't just me going crazy

(and, more importantly, I don't have to spend the rest of the evening trying to find that ancient 'wired' keyboard that is somewhere in the attic )

Cheers,

[bitli]

Sorry to spoil the party, but it is fixed in the FITS preferences. But if you set the preferences to ASK IF OUT OF RANGE, the error still occur in the popup window that appear when loading the file.  The work around is easy, but I though you may want to know this to fix it for a future release.

But thee way, I am still looking for a way to set these paramters by PJSR. My idea is to read the FITS keywords (using your script) and then adapt the parameters before reading the fits file in the script.

-- bitli

[Juan Conejero]

This bug is now identified and fixed. It is actually very simple and quite stupid on my part.

The following information can be of interest for those of you with programming knowledge. The Round() function has been implemented in this way in the pcl/Math.h header file:

Code: [Select]

inline double Round( double x )
{
#  ifdef _MSC_VER
#    ifdef _M_X64
   return double( _mm_cvtsd_si64( _mm_load_sd( &x ) ) );
#    else
   __asm fld      x
   __asm frndint
#    endif
#  else
   double r;
   __asm__( "frndint;": "=t" (r) : "0" (x) );
   return r;
#  endif
}

The reason to use a SSE2 implementation for Windows x64 is in one of the limitations of the MSVC++ compiler: inline assembler code is not supported on x64 platforms. For this reason, we can't issue the fld and frndint instructions unless the whole routine is rewritten in assembler and compiled separately with MASM, which seems really excessive for such a small routine —which isn't performance-critical either—, and would prevent inlining anyway.

The _mm_cvtsd_si64() intrinsic function works nicely, but it has one problem: the result is a signed 64-bit integer (__int64). This means that it can't be used to round a 64-bit floating point number outside the range of int64. In this case, the FITS Format Preferences dialog was trying to round 65535 with 15 digits precision, which clearly exceed the int64 range. The result when _mm_cvtsd_si64() overflows is either 9223372036854775807 or -9223372036854775808, which are the largest positive and negative integer values representable with 64 bits. Multiply them by 10^-15, apply them a bit of roundoff error, and you get the infamous magic numbers...

The fix consists of avoiding _mm_cvtsd_si64(), obviously. Another fix would be avoiding MSVC++ completely, but this is not feasible, unfortunately.

[Carlos Milovic]

Oh those forgotten days when we used mingw...