Re: Recording in ADV format
Posted: Thu Jun 04, 2020 6:44 am
Robin,
first thank you for impressive program! I'm trying to tame it's Live Stack functionality and I'm very impressed about it's capabilities.
FITS format has indeed a nice default/standard possibility to store many frames - as a data cube (when number of axis, NAXIS = 3). Each frame (or extension) can have it's own unique header OR there can be one global header and a dedicated small(er) header for each individual slice in FITS data cube. A'la global for everything that goes for e.g. object, observatory, equipment, ... etc and very simple specific ones that cover filter and exposure/timing information. FITS as a data cube is commonly used in professional astronomy, both in optical and radio. FITS offers also (lossless) compression as a kind-of-standard feature (fpack/funpack), however I'm not sure if any of amateur astronomy programs support that out of the box.
And it is also trivial to get individual frames out from FITS datacube (astropy/pyfits/cfitsio) or even slice it along any axis (that's why it is popular e.g. in radio astronomy).
However, should you implement FITS datacube functionality, please ensure that NAXIS = 3 is used only for datacubes. Many programs tend to do the sanity check of the file by checking IF NAXIS = 2 - and if it is not, file is considered incorrect or broken. Which is not necessarily true, especially because a FITS datacube (NAXIS=3), containing just one frame is basically an ordinary FITS, expressed just very slightly differently (but correctly after the standard). Just the length of the third axis, NAXIS3 = 1 in that case. In principle, it would be easy to fit a RGB imaging session as a data cube, too: e.g. when there is a mono camera with filter wheel. A'la Jupiter.fits could contain R, G, and B (e.g. live stack) frames in one file instead of having many different ones. Probably it is not that useful for imaging planets but in system when there are many filters.
I'm keeping my thumbs for FITS datacube functionality, I could use it easily for photometry of very bright objects that require taking many frames per object.
Best wishes,
Tõnis
first thank you for impressive program! I'm trying to tame it's Live Stack functionality and I'm very impressed about it's capabilities.
FITS format has indeed a nice default/standard possibility to store many frames - as a data cube (when number of axis, NAXIS = 3). Each frame (or extension) can have it's own unique header OR there can be one global header and a dedicated small(er) header for each individual slice in FITS data cube. A'la global for everything that goes for e.g. object, observatory, equipment, ... etc and very simple specific ones that cover filter and exposure/timing information. FITS as a data cube is commonly used in professional astronomy, both in optical and radio. FITS offers also (lossless) compression as a kind-of-standard feature (fpack/funpack), however I'm not sure if any of amateur astronomy programs support that out of the box.
And it is also trivial to get individual frames out from FITS datacube (astropy/pyfits/cfitsio) or even slice it along any axis (that's why it is popular e.g. in radio astronomy).
However, should you implement FITS datacube functionality, please ensure that NAXIS = 3 is used only for datacubes. Many programs tend to do the sanity check of the file by checking IF NAXIS = 2 - and if it is not, file is considered incorrect or broken. Which is not necessarily true, especially because a FITS datacube (NAXIS=3), containing just one frame is basically an ordinary FITS, expressed just very slightly differently (but correctly after the standard). Just the length of the third axis, NAXIS3 = 1 in that case. In principle, it would be easy to fit a RGB imaging session as a data cube, too: e.g. when there is a mono camera with filter wheel. A'la Jupiter.fits could contain R, G, and B (e.g. live stack) frames in one file instead of having many different ones. Probably it is not that useful for imaging planets but in system when there are many filters.
I'm keeping my thumbs for FITS datacube functionality, I could use it easily for photometry of very bright objects that require taking many frames per object.
Best wishes,
Tõnis