Large frame camera (Sony A7Riv about 62mpix, raw file size 119MB fits or arw either).
If I compress all the library files - master bias, master dark, Master flat -- that are used as input to calibration runs, is Pixinsight always smart about decompressing, and does it only once?
It's not a huge savings but every little bit helps.
So original lights -- a FITS file is about 119MB -- If I convert to xisf (still at 16bit) and compress it's less than half of that. If I'm doing that for archival purposes, worst case is a single decompression cost when I start over with calibration (I'd probably skip blink as already having been done and discarded those).
Aside: I was excited to see NINA would do the compression, and was thinking the one-time price during calibration was acceptable to start compressed and let NINA spend time while otherwise waiting during exposure, but then found out NINA waits between exposures while compressing. Sigh. So not doing that.
I'm assuming all the intermediate steps (which I do not keep), debayer, registered, approved, etc. should never be compressed.
And the zlib/max/byte shuffle compression is lossless. Very slow, but best compression lossless.
So do I have that right so far?
The final piece of the puzzle really isn't a pixinsight question but curious if anyone knows.
The uncompressed raw file from the camera is the same size as the FIT file captured from APT or NINA. The FIT file has the 14 bit camera raw in 16 bit integers. The ARW raw from the camera I WOULD HAVE ASSUMED was in 14 bit chunks inside the file. But the ARW is almost exactly the same size as the FIT file. Does that mean Sony is also stuffing 14 bit words inside 16 bit storage, wasting that space on the cards (etc)?
If I compress all the library files - master bias, master dark, Master flat -- that are used as input to calibration runs, is Pixinsight always smart about decompressing, and does it only once?
It's not a huge savings but every little bit helps.
So original lights -- a FITS file is about 119MB -- If I convert to xisf (still at 16bit) and compress it's less than half of that. If I'm doing that for archival purposes, worst case is a single decompression cost when I start over with calibration (I'd probably skip blink as already having been done and discarded those).
Aside: I was excited to see NINA would do the compression, and was thinking the one-time price during calibration was acceptable to start compressed and let NINA spend time while otherwise waiting during exposure, but then found out NINA waits between exposures while compressing. Sigh. So not doing that.
I'm assuming all the intermediate steps (which I do not keep), debayer, registered, approved, etc. should never be compressed.
And the zlib/max/byte shuffle compression is lossless. Very slow, but best compression lossless.
So do I have that right so far?
The final piece of the puzzle really isn't a pixinsight question but curious if anyone knows.
The uncompressed raw file from the camera is the same size as the FIT file captured from APT or NINA. The FIT file has the 14 bit camera raw in 16 bit integers. The ARW raw from the camera I WOULD HAVE ASSUMED was in 14 bit chunks inside the file. But the ARW is almost exactly the same size as the FIT file. Does that mean Sony is also stuffing 14 bit words inside 16 bit storage, wasting that space on the cards (etc)?