PixInsight 1.8.8-8 Released
- Thread starter Juan Conejero
- Start date
Thank you for start tackling the documentation problem. I do enjoy the writing style of the available documentation and even if someone may say it is too math-heavy in some cases, I prefer that than vague and over-simplified descriptions of the available tools, even if I can't always follow the math. The experienced and more math-proficient members will have a solid documentation to refer while trying to explain concepts to newcomers. And of course this will definitely benefit myself when I want to answer forum questions?!
I have been unable to get this release to work on an Apple 2020 M1 Mini running macOS 11.4. Works fine on a 2015 MacBook Pro running macOS 11.4 and on a 2012 Mac Mini running Catalina macOS 10.15.7. I used the same downloaded file on the 2020 that was used on the 2012 and 2015, and even tried a new download on the 2020.
hi, please read the last paragraph of the first post in this thread and delete the starnet module as indicated.
rob
I tried another new download, and it is working now.
I'm aware of that. Thanks. And it is only needed for the M1 machines.
that's correct, sorry if it was the wrong solution but you said everything worked great on your intel machines but not the M1 machine so it was the most likely explanation...
rob
Dear All,
First of all, let me thank you for your work in developing PixInsight. I am using the new version 1.8.8-8 of PixInsight on Windows 10. I am a big user (maybe a little lazy?) of WBPP and especially WBPP 2.1.1 which is great. Indeed, I changed my setup and I am now obliged to redo my flats at each session. I was annoyed by not having the keywords. It solves a lot of problems.
Nevertheless, there are still some small problems with me or with the software, I'm not sure.
First of all, the default directory when we ask to save the "ProcessLogger" file is the installation directory of the application. The output file would make more sense.
Second, I usually use a hierarchy for masters and a hierarchy for images. If I choose for example the keyword "SESSION_1" for lights and flats, I normally choose a generic directory for Dark and Bias. However, WBPP did not use the Darks that were not associated with any session. If I copy the Master Darks in session 1, no problem. Except that logically, they should be associated by default to at least one session and not to any session.
Finally, thirdly, I have developed a method to remove the aircraft trails. I prepare an image with the trail to be removed, an average-weighted image with the same area without trail from a clean image as a replacement, and a mask of the trail. Then I take the image with the trail masked, and remove the trail and add the replacement. If I save this new file in FIT, either in Integer 32 or in Float 64, there is an error at runtime (see attached). On the other hand, if I use the new XISF file, everything is fine.
That's it. I thank you in advance for your next comments.
Sincerely
Christian Voirol
First of all, let me thank you for your work in developing PixInsight. I am using the new version 1.8.8-8 of PixInsight on Windows 10. I am a big user (maybe a little lazy?) of WBPP and especially WBPP 2.1.1 which is great. Indeed, I changed my setup and I am now obliged to redo my flats at each session. I was annoyed by not having the keywords. It solves a lot of problems.
Nevertheless, there are still some small problems with me or with the software, I'm not sure.
First of all, the default directory when we ask to save the "ProcessLogger" file is the installation directory of the application. The output file would make more sense.
Second, I usually use a hierarchy for masters and a hierarchy for images. If I choose for example the keyword "SESSION_1" for lights and flats, I normally choose a generic directory for Dark and Bias. However, WBPP did not use the Darks that were not associated with any session. If I copy the Master Darks in session 1, no problem. Except that logically, they should be associated by default to at least one session and not to any session.
Finally, thirdly, I have developed a method to remove the aircraft trails. I prepare an image with the trail to be removed, an average-weighted image with the same area without trail from a clean image as a replacement, and a mask of the trail. Then I take the image with the trail masked, and remove the trail and add the replacement. If I save this new file in FIT, either in Integer 32 or in Float 64, there is an error at runtime (see attached). On the other hand, if I use the new XISF file, everything is fine.
That's it. I thank you in advance for your next comments.
Sincerely
Christian Voirol
Hello again,
I have done the pre-processing of my images with WBPP 2.1.1. When I get to the ImageIntegration step, I get the message :
"** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
** Warning: Inconsistent Observation:Object:Name (OBJECT keyword) value(s) - metadata not"
I was able to correct the problem of the objects by changing the FITS header of each Master Light (Stellarmate had renamed M101 to NGC_5474 for the L images). On the other hand, for the filters, I did not succeed. And then ImageIntegration does not create an LRGB file, but a Gray file. The only thing I notice in the Header is that usually, the filter names are 8 characters long (if necessary, 7 spaces after the L, R, G or B) and that here, the filter name is a string of one character. I tried to change it manually, but it doesn't change. Where am I wrong? Thanks for your help.
By the way, using LRGBCombination with the same files, no problem: PI produces an RGB file. On the other hand, I still get the Warning message:
"LRGBCombination: Global context
Combining normalized LRGB channels: done
** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
** Warning: Inconsistent Instrument:Camera:XBinning (XBINNING keyword) value(s) - metadata not generated.
1.496 s"
Looking at the headers, the XBINNING of the Green channel does not exist. I manually added the XBINNING and the message becomes:
"FITSHeader: Processing view: MasterLight_G_Pre_TT1_Croped_ABE_M101_Filter
213.641 ms
LRGBCombination: Global context
Combining normalized LRGB channels: done
** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
1.477 s"
So, something is happening in the Header when WBPP 2.1.1 is released on filters. Or I'm making a mistake that I don't understand.
One last point: at the begining of the process, my ligths have the correct filter name and a correct binning.
But after the pre-processing, the treated file have a filter name changed:
Thank you for your comments.
Best regards
Christian
I have done the pre-processing of my images with WBPP 2.1.1. When I get to the ImageIntegration step, I get the message :
"** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
** Warning: Inconsistent Observation:Object:Name (OBJECT keyword) value(s) - metadata not"
I was able to correct the problem of the objects by changing the FITS header of each Master Light (Stellarmate had renamed M101 to NGC_5474 for the L images). On the other hand, for the filters, I did not succeed. And then ImageIntegration does not create an LRGB file, but a Gray file. The only thing I notice in the Header is that usually, the filter names are 8 characters long (if necessary, 7 spaces after the L, R, G or B) and that here, the filter name is a string of one character. I tried to change it manually, but it doesn't change. Where am I wrong? Thanks for your help.
By the way, using LRGBCombination with the same files, no problem: PI produces an RGB file. On the other hand, I still get the Warning message:
"LRGBCombination: Global context
Combining normalized LRGB channels: done
** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
** Warning: Inconsistent Instrument:Camera:XBinning (XBINNING keyword) value(s) - metadata not generated.
1.496 s"
Looking at the headers, the XBINNING of the Green channel does not exist. I manually added the XBINNING and the message becomes:
"FITSHeader: Processing view: MasterLight_G_Pre_TT1_Croped_ABE_M101_Filter
213.641 ms
LRGBCombination: Global context
Combining normalized LRGB channels: done
** Warning: Inconsistent Instrument:Filter:Name (FILTER keyword) value(s) - metadata not generated.
1.477 s"
So, something is happening in the Header when WBPP 2.1.1 is released on filters. Or I'm making a mistake that I don't understand.
One last point: at the begining of the process, my ligths have the correct filter name and a correct binning.
But after the pre-processing, the treated file have a filter name changed:
Thank you for your comments.
Best regards
Christian
Attachments
Last edited:
udeutermann
New member
Dear PI Team,
I ran into a severe problem with the new WBPP (which led me to reinstall the previous version since I do use WBPP heavily).
I have a set of 30 images taken with the ZWO ASI6200 at 1x1 (hence quite large). I tried it 3 times to integrate them (with a master Dark and Flat) and in all 3 trials PI went into a non-responsive state. I actually had to cold restart the computer to reset PI, even the End Task in the Task Manager did not kill it (running latest Windows 10 professional edition).
Maybe this is already a known issue, hence no further information for now. If you are interested I certainly can provide the image files for you to reproduce the problem.
Best regards,
Uwe
P.S.: I almost forgot: the previous version had no problems with this set!
I ran into a severe problem with the new WBPP (which led me to reinstall the previous version since I do use WBPP heavily).
I have a set of 30 images taken with the ZWO ASI6200 at 1x1 (hence quite large). I tried it 3 times to integrate them (with a master Dark and Flat) and in all 3 trials PI went into a non-responsive state. I actually had to cold restart the computer to reset PI, even the End Task in the Task Manager did not kill it (running latest Windows 10 professional edition).
Maybe this is already a known issue, hence no further information for now. If you are interested I certainly can provide the image files for you to reproduce the problem.
Best regards,
Uwe
P.S.: I almost forgot: the previous version had no problems with this set!
RBA
Well-known member
I noticed the bug I described (with a one-liner fix) in https://pixinsight.com/forum/index.php?threads/bug-in-clonestamp-and-fix.16284/ is still there...
I'm sure a bug in CloneStamp that has been there perhaps since the beginning of times with no one complaining all this time is not a concerning priority, but it should not be forgotten either ;-)
I'm sure a bug in CloneStamp that has been there perhaps since the beginning of times with no one complaining all this time is not a concerning priority, but it should not be forgotten either ;-)
Hi @udeutermann,
non-responsive state is uncommon for PI, would you be willing to share the data and let me/us to reproduce the issue locally? the main problem of this issue is that usually log files are written at the end of the processing so if PI is freeze and you have to kill it then we have no information to inspect.
Robyx
udeutermann
New member
Thanks Robyx! I certainly can, if I would know where to send them to. I have never done this before, can you please shortly explain to me how to do this or send me a link to the instructions?
Uwe
This is expected. The FITS format is supported by our ImageCalibration tool only to input raw data generated by external applications, but the rest of our image preprocessing tools and pipelines support the XISF format exclusively.
Hi @Psynergie,
Do you have a screenshot of the control panel showing the situatino you've mentioned?
Robyx
Yep, this makes sense. thx for the suggestion.
That's weird, there are no restrictions for darks with NO keywords to match any light frame, indeed I would expect your library's master darks to be matching.
Do you have a screenshot of the control panel showing the situatino you've mentioned?
Robyx
FlapAstro (aka rakla)
Well-known member
I assume this issue was machine/installation specific, as nobody else has reported it.
The solution is quite simple really. Just download the script from the GitLab repository and manually install it in the scripts folder.
/Ralf
Dear PI Team,
I have a problem with the new version 1.8.8-8.
With this new version I can no longer open the NEF files created by my Nikon D810a.
I had to uninstall it and reinstall the 1.8.8-7 version to be able to process my NEF files.
Does this new version support NEF files from Nikon camera ?
Sincerely
Valery
I have a problem with the new version 1.8.8-8.
With this new version I can no longer open the NEF files created by my Nikon D810a.
I had to uninstall it and reinstall the 1.8.8-7 version to be able to process my NEF files.
Does this new version support NEF files from Nikon camera ?
Sincerely
Valery
there are probably non-ASCII characters in your NEF files, like accents or degree marks. the latest libRAW (which is used by PI to open DSLR files) has problems with non-ASCII filenames.
rob
FlapAstro (aka rakla)
Well-known member
It works flawlessly with my D7200, so as Rob pointed out, it might be the file name and not the file content.
/Ralf
/Ralf