Andres.Pozo
Well-known member
I can not reproduce this problem. To test it I would need at least two of the images that fail and a capture of the window of MosaicByCoordinates with all the panels expanded.ario said:
Andr?s.
PixInsight 1.8.7 Released
- Thread starter Juan Conejero
- Start date
Andr?s.
Ruediger
Well-known member
Juan Conejero said:
Hi Juan,
totally understanding your points. The empty work space previews are definitely not a show stopper, but the point that process icons get lost on multi screens is really tedious. I use 5x24" screens and it is almost not possible to work with, since you spent most of the time with searching process icons. It feels like watching a tennis game: left-right-left....
Maybe it is possible to have at least a look on this aspect only: Keeping the process icons somewhere defined would be great.
Thanks a lot - a great job anyway!
Cheers
Ruediger
Hi Andr?s,Andres.Pozo said:
I reinstalled the new version and tryed again:
in attachment you can see the start window of MosaicByCoordinates and the Error that follows using V1.8.7 (with 1.8.6 no problem)
the files xisf are 2.3MB each, from QHY9 in bin4. The restriction for attachment is 512KB. If you need a couple tell me how to send them to you.
it seems that when it start to save the keywords after image warping, it finds a string instead of a numeric value.
Armando
Attachments
Andres.Pozo
Well-known member
I need the images, without them I can't know what is happening.ario said:
You can use any file transfer service that you like (dropbox, wetransfer, ...) If you don't want to make public your images, you can send me the link by private message.
Andr?s.
Andres.Pozo
Well-known member
Thanks ario. I can now reproduce the failure. However, it fails due to changes I am not responsible for. I have reported this so Juan is aware of it.ario said:
JeffSeivert
Member
Thanks for the update to PI!
I'm having an issue when using the Batch Preprocessing Script in the new 1.8.7. The screen goes black after a few seconds and never recovers. Everything else seems to work fine.
I read the release notes and saw that there may be rendering issues on laptops with an Intel video card and I wonder if this is the problem.
My specs: Asus laptop, Core i7-4720 HQ CPU @ 2.6Ghz and 16GB RAM.
I also have Intel HD 4600 Graphics and NVIDIA GeForce GTX-950M (2GB) cards.
So my question, is there a way to force PI to use the GeForce card and hopefully avoid the rendering issue?
Otherwise, is my only option to go back to 1.8.6? And out of curiosity, what changed between 1.8.6 and .7 regarding the rendering?
I uninstalled 1.8.7 and installed 1.8.6 and it ran perfectly with the same files.
Thanks for an awesome platform and support!
Jeff
I'm having an issue when using the Batch Preprocessing Script in the new 1.8.7. The screen goes black after a few seconds and never recovers. Everything else seems to work fine.
I read the release notes and saw that there may be rendering issues on laptops with an Intel video card and I wonder if this is the problem.
My specs: Asus laptop, Core i7-4720 HQ CPU @ 2.6Ghz and 16GB RAM.
I also have Intel HD 4600 Graphics and NVIDIA GeForce GTX-950M (2GB) cards.
So my question, is there a way to force PI to use the GeForce card and hopefully avoid the rendering issue?
Otherwise, is my only option to go back to 1.8.6? And out of curiosity, what changed between 1.8.6 and .7 regarding the rendering?
I uninstalled 1.8.7 and installed 1.8.6 and it ran perfectly with the same files.
Thanks for an awesome platform and support!
Jeff
Barry-Wilson
Active member
Hi Juan
Like Brad I use an iMac with OS 10.14.6 Mojave and I too am noticing considerable delay in the real time preview window and, in general, a slower response time.
Is there anything I can do to help you diagnose if there is an issue?
Barry
Like Brad I use an iMac with OS 10.14.6 Mojave and I too am noticing considerable delay in the real time preview window and, in general, a slower response time.
Is there anything I can do to help you diagnose if there is an issue?
Barry
Hi Barry,
As I said in my answer to Brad's post, I cannot reproduce this problem. Version 1.8.7 works perfectly fine on all of our working Mac machines. All of them run macOS 10.14.6.
The only thing I can figure out here is a third-party application interfering with PixInsight. Do you have some virus protection application, or a similar utility?
As I said in my answer to Brad's post, I cannot reproduce this problem. Version 1.8.7 works perfectly fine on all of our working Mac machines. All of them run macOS 10.14.6.
The only thing I can figure out here is a third-party application interfering with PixInsight. Do you have some virus protection application, or a similar utility?
Hi Jeff,
We cannot reproduce this problem. BPP runs normally on all of our working and testing machines, on all platforms.
On Windows, the PixInsight core application already attempts to use the discrete GPU exclusively on machines with dual graphics. This should work for both nVidia and AMD graphics cards. However, whether or not this works on a particular machine is a different thing; one never knows for sure on Windows, especially on laptops, where the concept of standards is pretty fuzzy. There is nothing more I can do to fix these issues.
What is really strange is that it works with 1.8.6 and not with 1.8.7. There are no changes at all that could justify such a different, and problematic, behavior.
We cannot reproduce this problem. BPP runs normally on all of our working and testing machines, on all platforms.
On Windows, the PixInsight core application already attempts to use the discrete GPU exclusively on machines with dual graphics. This should work for both nVidia and AMD graphics cards. However, whether or not this works on a particular machine is a different thing; one never knows for sure on Windows, especially on laptops, where the concept of standards is pretty fuzzy. There is nothing more I can do to fix these issues.
What is really strange is that it works with 1.8.6 and not with 1.8.7. There are no changes at all that could justify such a different, and problematic, behavior.
Hi Julien,
We are working on a completely new INDI support module, based on the INDIGO platform. So please be patient, it will be available again soon, and it will be much better than the old version.
We are working on a completely new INDI support module, based on the INDIGO platform. So please be patient, it will be available again soon, and it will be much better than the old version.
Alfredo Beltran
Well-known member
Hi Juan
As always, thank you very much for all the work done to make new releases available for us.
I have made some calibration and integration processes for a 100 stack of dark and bias frames. I can notice a huge difference in the increase of time that it takes now (Windows 10 home), and also that PixInsight tries to use as much ram as it is available. I don?t know if that?s the cause to make the whole process slower.
Is this the expected behavior?
Regards,
Alfredo
As always, thank you very much for all the work done to make new releases available for us.
I have made some calibration and integration processes for a 100 stack of dark and bias frames. I can notice a huge difference in the increase of time that it takes now (Windows 10 home), and also that PixInsight tries to use as much ram as it is available. I don?t know if that?s the cause to make the whole process slower.
Is this the expected behavior?
Regards,
Alfredo
Hi Alfredo,
The new automatic buffer sizes parameter of ImageIntegration is enabled by default. It is starting to become obvious that this has been a mistake, which I'll fix as soon as possible.
As described in the tooltip for this parameter:
Usually this is the best option to optimize image integration performance, but be aware that for large data sets and low-memory machines (relative to the total size of the data) the process may use too many system resources. If you want finer control on system resources usage, disable this option and tweak the values of the buffer size and stack size parameters.
So if your machine does not have RAM enough to integrate 100 frames at once, please uncheck the automatic buffer sizes option. This will return to the previous behavior.
The new automatic buffer sizes parameter of ImageIntegration is enabled by default. It is starting to become obvious that this has been a mistake, which I'll fix as soon as possible.
As described in the tooltip for this parameter:
Usually this is the best option to optimize image integration performance, but be aware that for large data sets and low-memory machines (relative to the total size of the data) the process may use too many system resources. If you want finer control on system resources usage, disable this option and tweak the values of the buffer size and stack size parameters.
So if your machine does not have RAM enough to integrate 100 frames at once, please uncheck the automatic buffer sizes option. This will return to the previous behavior.
Alfredo Beltran
Well-known member
Juan Conejero said:
Thank you very much Juan
cplonski said:
This cannot be reproduced on any platform. You don't mention it so I assume you are a Windows user. The HistogramTransformation tool works without problems in real-time preview mode on Windows 10. It is as fast as it was in version 1.8.6, both for preview and for execution, and perfectly stable. I have just verified this again on two different machines running Windows 10 Professional.
This is a machine-specific issue, probably being caused by a wrong or defective graphics driver, or by conflicts with third-party applications. The behavior you are describing cannot be reproduced on any supported platform under normal working conditions.
Hi John,
No, of course I won't abandon it, since I agree this feature is very useful. My mistake has been enabling it by default without more 'protection' for users trying to integrate huge data sets on weak machines. I am going to add a new parameter to control the maximum fraction of the available memory that ImageIntegration is allowed to use. I hope this parameter, with a default value of 0.8 for example (so the machine will always have at least a 20% of free memory), will help prevent cases where the automatic buffer sizes feature is causing problems by exhausting resources.
johnpane said:
No, of course I won't abandon it, since I agree this feature is very useful. My mistake has been enabling it by default without more 'protection' for users trying to integrate huge data sets on weak machines. I am going to add a new parameter to control the maximum fraction of the available memory that ImageIntegration is allowed to use. I hope this parameter, with a default value of 0.8 for example (so the machine will always have at least a 20% of free memory), will help prevent cases where the automatic buffer sizes feature is causing problems by exhausting resources.