- This topic has 10 replies, 4 voices, and was last updated 9 years ago by
.
-
Posts
-
I would like to request an RfC for (a release far in the future):
Xisf fileformat support
XISF stands for Extensible Image Serialization Format, and as you probably know, is the native file format of the PixInsight platform for storage, management and interchange of digital images and associated data. XISF is a free, open format, where we welcome the contributions of anyone interested, including users of PixInsight and other applications, as well as individuals and groups from other development teams, institutions and companies involved or interested in image processing software.
http://pixinsight.com/doc/docs/XISF-1.0-spec/XISF-1.0-spec.html
Hi @mth75,
Thank you for your request.
I will put this on the RFC list, but it will be completely at the bottom for now.
What would be the use case of supporting Xisf for you since you request this?
Maybe I am not up-to-date, but as long as no camera manufacturers or any capture application uses xisf I can’t see a real use-case for supporting xisf. If camera manufacturers start to use xisf, I’ll move this quickly to the top of the RFC list, since the use case becomes very clear then.
To my knowledge, xisf is created by PI and only used by PI. They have made FITS redundant, which is obviously very strange to state since the whole astronomical scientific community is working with FITS and not with xisf. But maybe I have missed something so please let me know if others are transitioning to xisf as well.
(FITS is perfectly able to store all kinds of data formats (unlike the statements made by the main PI developer) and so called problems with the FITS format are the result of bad API libraries or misunderstanding of the FITS conventions, at least that is my opinion.
Be aware that NASA actually still is putting money and effort in the further development of the FITS standard and APP is using their latest library.)
I will put this on the RFC list, but it will be completely at the bottom for now.
Yes, of course.
What would be the use case of supporting Xisf for you since you request this?
The case would be working with both applications (in both directions). For starters, anyone with XISF libraries would be able to use his/her subs without prior converting. Furthermore, I think it’s very plausible that power users will use both APP and PI. My RfC will lower the threshold for doing so.
I save all Pixinsight files in Xisf format and it is a bit of a bummer when i want to work with a file in APP and i can not find it in the “load files” menu because oh yes, i forgot that APP does not support this format…..
Which I can understand as it takes yet more time to develop and there are just so many things a developer can do in a first release. However, as many use PI, it does indeed automatically provide a “problem” as you have to convert everything.
Thank you for sharing.
If you have xisf files, this means you have PI, and with PI you can convert them to FITS files easily. Even better, let PI save your files automatically in FITS. I consider this much more a PI issue, than an APP issue to be honest and the solution for a PI user is very easy as you all know.
So I would hardly consider this a priority from an “APP” perspective or a “problem”.
If someone can make the case that xisf is essential due to some special capability (which I haven’t found or seen sofar) or if someone knows that certain camera manufacturers are going to adopt xisf, or capture programs that will only use xisf, then it’s clear xisf should be implemented sooner rather than later off course. (For now, xisf only exists in the PI sphere and I honestly suspect it will stay there)
Yes agreed. It’s just that PI users who have all xifs files, just need to perform an extra step which can take ages if your whole library is in that format. Problem with PI is/was that they pushed the format a bit to save files in that format as standard. But yes, it still is a thing of PI. We’re just thinking about what users who switch will see this extra thing.
I totally understand @supernov ;-)
So I would hardly consider this a priority from an “APP” perspective or a “problem”.
You don’t think it is a problem because it is only a problem for PI users. With 90% of the future users being PI users it would only be a problem for 90% of APP users.
My RfC was intented as a convenience feature (not to adres a problem). I wouldn’t be surprised if WIP files are processed in both applications. That’s the reason I suggested this feature (for later in the future indeed).
So I would hardly consider this a priority from an “APP” perspective or a “problem”. You don’t think it is a problem because it is only a problem for PI users. With 90% of the future users being PI users it would only be a problem for 90% of APP users.
Kees, indeed, I couldn’t state it more cleary, the problem starts in PI and luckily it is very easily resolved by either
1) saving all files in fits in PI (which isn’t harmfull in any way ? to your data )
2) convert your existing xisf to fits, which is also very easy in PI.
- You must be logged in to reply to this topic.