mousing over Histogram transformation box, and other bugs

[eganz]

First of all, let me say that pix insight is an incredible astrophotography editing program.

However, when I move the mouse over the histogram transformation box, It draws incorrect material from other parts of the screen, or from behind the screen onto the two black boxes which are supposed to hold the dynamic histogram.
Therefore, in order to use this box properly, I need to very carefully avoid letting the mouse be over these black boxes.
The entire histogram box will redraw correctly if I move it slightly from the top.

I also have various problems with memory errors (similar to those in others have reported) such as PCL Win32 system exception -access violation: invalid memory read operation at address…
these seem to occur when I first load in .FIT files that I have downloaded from online telescopes. These also occur if I tried to do image registration from "views" of these files. So far, I found that if I'm very careful not to use the mouse wheel to zoom in on these files, and to immediately change to the local file format .xisf, then I'm able to avoid these errors. For image registration, I use "files" not views as the sources In the StarAlignment process.

I'm using Pix Insight Standard Edition 1.08.04.1195 Ripley X64, QT 5.5.1, Windows 10, 64 bit on a PC, Nvidia Quadro video card, 4K screen. I never have these kinds of errors in other applications, and am able to run prime 95 Etc. without problems.

[Juan Conejero]

when I move the mouse over the histogram transformation box, It draws incorrect material from other parts of the screen, or from behind the screen

Weird issue. Needless to say that we cannot reproduce it on any machine and operating system. This has not been reported before either, AFAIK.

I also have various problems with memory errors (similar to those in others have reported) such as PCL Win32 system exception -access violation: invalid memory read operation at address…

As you surely know by reading other reports on this forum, we are unable to reproduce these problems on any of our testing and working machines. However, from several detailed reports we have received lately, it seems there is a correlation between this issue and the use of touch screens and devices. Are you using a touch screen, or do you have any touch input device connected to your computer?

Even if the answer to these questions is no, please try the following:

- Select EDIT > Global Preferences from the main menu.

- On the Preferences tool window, select Miscellaneous Image Window Settings on the left column.

- Disable (uncheck) the Touch events option.

- Click the Apply Global button (blue, round) or press F6 to apply the changes.

Let's see if this solves the problem.

[eganz]

Juan,
Yes, I do typically use a small Adesso touchpad.
However, despite turning off the touch events as you suggested, and also unplugging my touchpad and using a mouse instead, there is no change to these problems.

Today, for example, when I tested a fit file, and then zoom in with the mouse scroll bar, I get endless divide by zero errors.

Eric

[eganz]

I'm also getting similar rendering problems with the curves transformation box in the live area when I mouse over the black box.

I'm also sometimes getting memory errors when using dynamic crop on zoomed images.

E

[Juan Conejero]

Today, for example, when I tested a fit file, and then zoom in with the mouse scroll bar, I get endless divide by zero errors.

Really strange. After analyzing the relevant source code in quest of a reason for this odd behavior, I have a theory. Please try the following:

- EDIT > Global Preferences

- On Preferences, select the Core UI Resources section.

- Disable the Automatic UI Scaling option.

- Set UI scaling factor equal to 1.5 (the nominal scaling factor for a 4K display).

- Press F6 to apply the changes.

- Exit PixInsight.

- Launch PixInsight.

Let me know if this makes any difference. It probably won't, but it's worth trying anyway. This is definitely a problem with your graphics driver and Qt 5.

I hope all of these problems will be fixed when we release a new version of PixInsight next Fall. If the above procedure does not fix the issue, then sorry but I'm completely out of ideas. As I've said we are unable to reproduce any of these things on any of our physical and virtual machines, running four different operating systems including Windows 10 and Windows 8.1, and including standard, 4K and 5K monitors. We also test PixInsight on a 5K iMac on Windows 10 with BootCamp and an Apple touch pad without any problem.

[eganz]

Juan,

This did not have any effect.
In fact, then the Windows were the wrong size (this is too big for the desktop), although the fonts were nicely larger.
Furthermore, the problems I'm having did not go away, or were perhaps even slightly worse.

I also tried turning off the readout options, but this also did not help.

It does seem to me that you might include more checks for divide by zero or out of bounds array conditions in the code. Also, perhaps one can have an option to turn off the live updates on the histogram window.

thanks for your help,

Eric

[Juan Conejero]

It does seem to me that you might include more checks for divide by zero or out of bounds array conditions in the code.

No division by zero or "out of bounds" condition can happen in our code. The problem you are experiencing is very weird. It is an anomaly, and as such it cannot be reproduced under normal working conditions.

As a last resort, you can try disabling OpenGL acceleration. Run the PixInsight.exe executable with the --opengl=raster argument. I don't have a Windows machine at hand right now, but you can open a command prompt on Windows 10 and enter these commands:

cd C:\Program Files\PixInsight\bin
PixInsight --opengl=raster

If the problem is being caused by a deficient OpenGL implementation (typical on Windows), this should fix it.

[eganz]

Juan,

After changing the scaling parameters as you suggested,

- On Preferences, select the Core UI Resources section.

- Disable the Automatic UI Scaling option.

- Set UI scaling factor equal to 1.5 (the nominal scaling factor for a 4K display).

- Press F6 to apply the changes.

the interface had larger fonts but did not fit on the screen as I mentioned earlier

Then after I changed it back to automatic scaling, now Large boxes such as the histogram don't fit on my screen anymore. Somehow the scaling did not go back to where I started. I use a lot of window scaling (350%), on my small 24 inch 4K screen, but even if I turn this down it's very hard for me to use the interface now. To fit the entire box on the screen the fonts come out very tiny.

What would be appropriate UI scaling factors that I should use to try to get the entire PI interface on the screen but with larger fonts?

E

[eganz]

Juan,

okay I tried starting the program using "PixInsight --opengl=raster"

this did not fix the memory or drawing errors that I've been discussing.
However, interestingly, When PixInsight is started in this way, then the histogram box comes out in normal proper size.

I still have the sizing problems when I start the program normally.

E

[Juan Conejero]

Perform a complete reset of settings by running:

PixInsight --uninstall

Answer yes to the confirmation dialog box. This will return everything to its default state the next time you launch the application.

I use a lot of window scaling (350%), on my small 24 inch 4K screen

This might be the root cause of the problem. Can you try with default screen settings on Windows?

[eganz]

Juan,

okay the -uninstall command worked to restore the histogram back to its original size.

If I run Windows with only 200% scaling, which is the recommended amount, then All fonts are very tiny on my 4K screen.

PixInsight now comes up probably with the correct size Working area but with tiny fonts.
Mousing over the histogram box still does not work properly and paints incorrect material.
In the brief time and I tried it, I was able to zoom and use the wheel mouse to zoom in to both fits files, and your new format files without any difficulty. So I did not see any memory errors and during this brief trial.

I can't really operate my computer at this scaling level so it is not a long-term solution for me.

Eric

[eganz]

By the way, I had a look at the QT website. I see that QT 5.5 is not listed as compatible with Windows 10. For that they list QT 5.6 or 5.7.

Will you be able to update your program to these new QT releases?
This should provide improved compatibility with Windows 10.

Eric

[eganz]

Juan,
by the way, if I turn off the grid lines and MTF curve, then the lower histogram box behaves better, although incorrect images are still copied here when I mouse over the upper box.
Eric

[eganz]

I find that the memory problems typically occur as the mouse moves over the image.
I've enclosed a screenshot to show you what I mean.
If the mouse avoids the image area, then no problem.

one hypothesis is that this is related to the readout function, but modifying the check boxes for the readout function in the options menu does not fix the problem. Perhaps if one could disable this entirely…

Oddly, there are days like yesterday when I can process entire sessions without as many problems, but today I'm plagued again with memory errors. It seems that the early stages like registration and integration are more prone to triggering these problems, while the later post-processing stages work more smoothly on my machine.

E

[eganz]

for what it's worth, here's a little more information on the memory errors.

They seem to occur when I first start pix insight. In particular, the first image that I load in almost always generates these errors now. once these memory errors have started, no work can be done and the program needs to be exited.

However, if I am persistent, then eventually the program will start and load in the first image without errors. Once this occurs, then the program seems to keep running well without memory errors, and I'm able to do my processing and get work done, as long as I leave the program open.
It seems that loading in color format RGB XISF files initially is more likely to be successful in this way, while black and white fits files almost always generate errors on the first load up.

E