2023-01-19: APP 2.0.0-beta13 has been released !
!!! Big performance increase due to optimizations in integration !!!
and upgraded development platform to GraalVM 22.3 based on openJDK19
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Java error during integration process
when trying to integrate a set of frames I'm experiencing the error in the image, always when arriving to the 10th frame.
I've tried to change the algorithm and to deselect the 10th frame, to verify that there wasn't something in the frame, but no way to proceed.
Is there anything I can try to solve?
Thank you in advance
Tried to reboot system but no effect.
@plicciar Hi! Can you tell us what data (lights and calibration frames) you have loaded? What camera, filter(s) etc. How many sessions? Are you doing an integration with the default values or did you change any settings in APP?
I have 2 session with around 200 lights, dark and bias specific for the sessions.
The files are FITS generated by an ASI 224 MC.
As the framing is not exactly equal between the two session (and the first one had some start stop as well) I've tried to use the "mosaic" registration mode.
Default settings for integration step
Ah! Svbony 31.8 UHC filter used
@plicciar OK thanks. You probably do not need to use the mosaic mode. So please just leave all settings to the default values and try again.
I've tried and it works...except for the fact that the process registers less than a half of the frames (from 95 to 44...)
Or better...it produces another error before integration but during registration
Is there any problem related to FITS file format? I don't have all these dumps when using raw frames from a DSLR
@plicciar Many people process FITS data in APP so the odds that something is wrong there in APP is very small. Could you upload your data to
using upload4 for both username and password? Please create a directory called plicciar_error and put the data in there. Then I'll have a look as soon as possible.
I've uploaded all the files from the two sessions, including MasterBias and MasterDark created in APP.
About the FITS support, I clicked missing part of the sentence. My concern was if there are, eventually, specific settings for ASI cameras required to have the files correctly generated for the best use in APP.
By the way, they are all interpreted as GREY only channel. I haven't seen the debayer function (sorry for silly questions but I'm a beginner...)
Thanks a lot for the support
@plicciar The debayer function is in tab 0.
Thanks for uploading the data. I’ll have a look as soon as possible.
@plicciar Can you explain the data to me please? I see files with names starting with an L and I assume those are lights. What are the files with names starting with Single? I also see that you have various master darks for different exposure times. That's not necessary when you use BIAS. Is your camera actively cooled? If yes, please try to stick to one temperature and shoot all your data at that. Anyway, please explain the filenames to me.
Well, the camera is not cooled.
Single_ and L_ are lights
The masters you see have been created by APP and are from Bias and Dark frames taken during the same sessions of the lights
@plicciar OK thanks. I have had a look at your data and there are several issues with it. First of all not all frames have been guided well. In some cases the stars are elongated and in some cases double. Also, an exposure time of a few seconds is not enough to image enough stars for APP to successfully do a registration of the frames. I am afraid that it is close to impossible to integrate these frames properly.
Do you use a guide camera? If not then please consider using one as soon as possible. If yes then please make sure that it works well since a lot needs to be improved in your guiding. Sorry to bring you this news.
Thank you for your answer.
I know that many light are discarded. But that's not the problem. The problem is the Java dump after analyze, register and normalize.
Why should the SW dump with frames that have been selected by the tool itself?
@plicciar If there is a lot of drift then things still may go wrong despite the frames having been registered properly. And it looks like APP is quanlifying some of the frames with double stars as good since the stars are sharp. In short, if the input data aren't good then the result is unreliable at best.
In any case, I am trying to process your data in mosaic mode. It requires tweaking of several parameters and I will post them here as soon as APP finishes successfully.
@plicciar I had another try but can't get the frames to register properly. I checked many of them and the data just are too diverse. I see the target (M51) move all over the FOV and this means that stars for instance to the upper left of the galaxy sometimes are visible and sometimes not. The same of course applies to the stars to the upper right, lower left and lower right. This makes it nearly impossible for APP to register the frames.
On top of that I see frames with sharp stars, frames with double stars, frames with elongated stars and frames with stars that are displayed as curved lines. I don't really know how this is possible with such short exposure times but you need to fix that before you can expect any results from APP. I am sorry but these data are unworkable and I will give up now. Please fix the guiding and try again.