19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.
31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!
Suppport for XISF format
First let me thank your for your work, I really enjoy working with APP! I have switched from preprocessing in PixInsight to APP which for me gave much better results, and also made mosaics much more convenient to create, great work!
I would like, however, to request for XISF format. As I explained, I'm using APP for preprocessing, but I still prefer PI for final touches. I'm acquiring data with N.I.N.A which supports saving to the XISF format out of the box. There are several advantages in using XISF which are listed in https://pixinsight.com/xisf/#Why_XISF. The problem with APP not supporting this format is that you either have to give up on those improvements, or you have to convert everything back to FITS before processing, which is lossy.
Long story short, would be great to have APP support this OOTB, so that I don't have to scratch my head wondering if my FITS are in the right orientation, for example, which has caused me a lot of headaches (with darks oriented differently than the light, for example).
Ah yes, I do know that Mabula is not supporting it at the moment, because the XISF format is not a standard in the astronomy community and as far as I know not used much outside of PI. Fits, according to Mabula, can accomodate everything that is needed for a lossless workflow. But I'll also ask Mabula to chime in on this, maybe he has more insight now.
Thanks for the kind comments!
Thanks for the answer Vincent. As for XISF not being a standard, of course it's not, but not a good reason for me not to support it, or we'd all still be using FAT16 🙂 As I highlighted, N.I.N.A is already supporting this file format. Despite not being a standard, it's actually an open format.
Yes I do get your point. I think Mabula will have more insight into it. 🙂
Hi Cédric @melix,
Thank you very much for your nice compliment, I am happy that APP is working nicely for you 🙂
Support for XISF is on our todo list, but it is not very high on the list at the moment. And I have put it that low, because many other things on our todo list are definitely more important at the moment.
"There are several advantages in using XISF which are listed in https://pixinsight.com/xisf/#Why_XISF. /a> The problem with APP not supporting this format is that you either have to give up on those improvements, or you have to convert everything back to FITS before processing, which is lossy."
Okay... , first of all, when it concerns the data (which is probably everything and the most important thing, right?) :
FITS stores the data without any loss and with 100% data integrity. Saying or claiming that is does not, is simply not true. Almost all Fits files from all capture software don't compress the data, so it can never be lossy. A very few data capture packages use lossless compression in FITS, not lossy. And APP can read the lossless compressed data in FITS as well, that data has 100% integrity when decompressed as well.
The whole scientific astronomy world uses FITS to store image data, but also spectral data and graphs etcetera...., so if there was a problem with data reliability in FITS files, then for sure, FITS was abandoned many years ago already, but it was not.
So if you capture in FITS and process in APP your data is 100% conserved. The other mentioned possible downsides of FITS are there (data range too flexible in FITS?, character encoding to deal with non-standard characters) but their influence does not affect data processing so they don't make your data lossy, and there are in fact FITS keywords to deal with some of the issues mentioned in the list... so from my perspective and from a technical perspective the XISF standard does not add enough to give it a high place on our ToDo list. I do understand that for users that use both APP and Pixinsight it would be welcomed. But still then, Pixinsight still reads and processes FITS without any data loss, so it does not and should not harm your workflow or your data. For me that is the most important thing here to consider the priority of implementing XISF support. If you can show that data is in fact compromised by using FITS, I would certainly reconsider here 😉
well, I am, like Cedric @melix a big fan of APP.
What I see is, regarding N.I.N.A., those guys with that "monster" full frame cams like the ASI6200 (not me, I am happy with my 1600 and it's 32MB fits) are using the compression feature of XISF in order to reduce file sizes at some degree. They simply can't use APP for stacking atm. Of course, you could say, they can afford a 5k€ cam, so, they should afford some additional hard drives...
I personally would like to see XISF support, because I use PI's subframe selector and it only saves XISF, so I have to convert everything back to FITS (losing all the fits header data) in an additional step for reimport to APP.
It's true, FITS is standard, but standards evolve besides beeing under the risk of extinction, and XISF could be the new standard sometime. Well you could also say, CR2 is the standard in Canon DSLR and now there is that CR3.
So, I don't think XISF support is that much of a low importancy 😎