It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
[Solved] Bzero value in calibrated FITS changed between 1.0741 and 1.075
I am having some problems with files that have been calibrated in APP v 1.075 and i see some strange differences in the FITS headers. Both files have been calibrated with 16 bit masters for bias, darks, flats and BPM. What is going on here? (The main problem is that DSS (yes i know, but i want to stack with the max option and APP does not have the option for that) is not accepting the FITS calibrated with 1.075 when there are files calibrated with older versions also)
This topic was modified 6 years ago by Kees Scherer
Kees, there really is no problem here as far as I can see from the fits headers presented and also, I can't see anything strange here.
The first header shows clearly that it concerns datatype (BITPIX fits tag) of -32, which means 32bits floats (+32 would mean 32bit integers). Calibrated 32bits float frames will only be created in calibration when the light or, 1 or all masters were 32bits, then the original data, if 16bits, would be scaled from 16bits to 32bits in calibration. Otherwise, the data keeps the original datatype.
So the second fitsheader presented shows clearly that it concerns 16bits signed integers. In case of 16bits integers, the bzero value needs to be used, so any fits reader can properly read the data. The bzero value is responsible for correctly converting signed integers to unsigned integers.
Signed 16 bits integers have values between -32768 to + 32767
Unsigned 16bits integers have values between 0 - 65535.
This is all according to the well documented FITS specification.
So for 32bits float data, a bzero value is not used and not needed to be able to store the data properly in 32bits in the fits file. In 16bits integers, a bzero value is required however to be able to store the data correctly. That explains why both files show different things here.
I am not aware of DSS having issued with FITS files that are created by APP. Kees could you send us such a calibrated frame so we can check? Perhaps also useful to indicate which DSS version you are using.
Woops!.... Thank you for the answer Mabula! My bad, i looked at it the wrong way around. I made new masters, very carefully in 2 groups, 16 bit and 32 bit and compared calibrated lights with older calibrated lights and i ASSUMED that the older lights had been calibrated with 16 bit masters, because...well, why would i have used 32 bit masters? But it turns out i did use 32 bit masters during the last year. So that explains a lot (all my lights calibrated with the 32 masters are 65 mb in size and the lights calibrated with 16 bit masters are 32mb in size). But where APP has no problem with that DSS 3.3.2 does not accept the "mixed" calibrated files and gives an error that reads: "The checked pictures are not compatables......".
Woops!.... Thank you for the answer Mabula! My bad, i looked at it the wrong way around. I made new masters, very carefully in 2 groups, 16 bit and 32 bit and compared calibrated lights with older calibrated lights and i ASSUMED that the older lights had been calibrated with 16 bit masters, because...well, why would i have used 32 bit masters? But it turns out i did use 32 bit masters during the last year. So that explains a lot (all my lights calibrated with the 32 masters are 65 mb in size and the lights calibrated with 16 bit masters are 32mb in size). But where APP has no problem with that DSS 3.3.2 does not accept the "mixed" calibrated files and gives an error that reads: "The checked pictures are not compatables......".
Do you still want to see the calibrated frame(s)?
No problem @kees_scherer, i am glad that this makes it clear 😉
Hmm, i can only assume that DSS requires that you load data of the same datatype to be able to function properly, but I am not sure. What happens if you only load the 32bits calibrated frames or only the 16bits calibrated frames, does DSS work then? If so, the solution would be to convert the frames of 16bits to 32bits or vice versa I would think.
The warning about compatibility leads me to think that the fits loader of DSS and/or the internal data normalization engine can't handle data of different datatypes for correct processing.
Oh, for what would you need the MAX integration method? (besides average & median)
It will not be difficult to add this to APP. Perhaps other integration methods as well?
I use the max setting for images like my 14 october APOD. It was made using APP (calibration), DSS (Stack with max signal option) and PI (stretch and annotate) I like to check stacks for asteroids etc. and in the M31 case there was a striking framing of the Galaxy by all the trails so i submitted for APOD. I have tried the same with PI and come close, but in the DSS version the satellite trails come out much brighter (as there is no averaging i suppose)
DSS works fine with only the 16 bits calibrated lights or only the 32 bits calibrated lights so i will try to convert the 32 bits to 16 bits.
This post was modified 6 years ago 3 times by Kees Scherer
Hello Mabula, maybe it would be possible to add integration mode, which will stack the better images with different exposure times. Such a kind of HDR mode. With Photoshop there is a method called UDI. Maybe you've heard of it already. Or something like DSS see screenshot.
Converted all 32 bit subs to 16 bit and stacked together with the 16 bit subs in DSS with max setting. Worked perfectly, this is what i want to see in such a stack.
Hello Mabula, maybe it would be possible to add integration mode, which will stack the better images with different exposure times. Such a kind of HDR mode. With Photoshop there is a method called UDI. Maybe you've heard of it already. Or something like DSS see screenshot.
Please check the integration weights in 6) Integrate, there is the option to weight on exposure time already. The images with longer exposure time will get more weight. An image exposed twice longer as another, will have a weight which is the root of 2 relative to the other frame.
A HDR integration mode, is something completely different though... I will need to think about that.
Converted all 32 bit subs to 16 bit and stacked together with the 16 bit subs in DSS with max setting. Worked perfectly, this is what i want to see in such a stack.
An HDR mode would be really cool, this is how I made a lot of my images to get a really nice star-field with colors in the cores and then deep data for nebulae.
Thank you Mabula. Yes, i would use max stacking also for star trails, very happy that you will implement that!. (I almost do not dare to ask about LNC 2.0.......)
