The TIFF compression algorithm makes the files smaller
The files are readable by almost any image viewer.
The standard way is intended to be used for light, dark, flat and flat-darks. These files are normally written in large quantities and compression and viewability makes sense. Already some application developers are working on support. See the list at end of the specification in above webpage. For APP the only requirement would be to read TIFF and decode the tag description containing the header information in a string and decode information like date, exposure, gain, sensor temperature.The specification is not set up as a replacement of FITS. It just propose better of use of the existing TIFF file format.
OK, this may sound cynical. But I have always avoided TIFF as a file format.
I don't know why, but I seem to come across many applications that are supposed to support TIFF format images, but more often than not, when I try to open a TIFF file in these applications I have found that I get a message such as "format not recognised", "invalid file" and similar.
I don't know why this happens, it is just a vague anecdotal experience of mine, which has led me to avoid using the format for as long as I can remember.
However, I guess FITS files are just as unwieldy, and any non-lossy compression in a file format would be a good thing, I just hope that any implementation of the format is portable to other softwares.
It is only the filling of a standard TIFF description tag in a structured way with date, gain, exposure time, sensor temperature, used filter.....
Standard libraries like www.libtiff.org support the tag Description. The Description is just a string you could fill with the FITS header except that each line is ends with a LF or CR+LF as you like. LibbTiff has only LZW compression which performs a little less then Deflate. (LZW is used in GIF, Deflate in PNG)
Personally I'm using a Pascal library. Code for importing was simple since the FITS header is a simple structure. Filling the Description tag was only a few lines of code. For Ekos mainly writing Astro-TIFF is interesting. With the compression method Deflate (same like ZIP) achieves almost the standard FITS compression factor called RICE from the CFITSIO utilities FPACK and FUNPACK leaving about 60% of the file size.
TIFF is a super flexible format. I don't think there are any compatibility problems since it is already a few decennia’s available. Except for FITS it is the only generic format which allows 32 and 64 bit in floating point images. But the intended usage if for 16 bit lights, darks, flat and flat-darks. Astro imagers produce these files in the thousands. The file size reduces to about 60% (use grey level format) of the original size and you can use standard image managers to organise and view your images. So the intention is just to use the power of this existing and established TIFF format.
Siril version 1.0 to be released soon will accept Astro-TIFF for stacking. CCDCiel has fully implemented Astro-TIFF reading and writing in the code. The next ASTAP program to be released today or tomorrow will fully support it including batch conversion both ways.
Good. I looked it briefly up for somebody and could only find: Compression = 32946 PKZIP-style Deflate encoding (experimental)
which accordiing Wikpedia is different the compression type=8 Deflate. But the documentations for the coverage hasn't been updated since 2002.
Update, reading through the documentation it is explained. So the libtiff
is not updated:
Adobe Photoshop Technical Notes March 22, 2002
proprietary ZIP/Flate compression code (0x80b2) has been used by some software vendors. This code
should be considered obsolete. The compression used by the obsolete code is identical to that defined
above. We recommend that TIFF implementations recognize and read the obsolete code, but only write the
official compression code (.
I finally managed to pave the way for this in INDI v1.9.5 by defining INDI_TRANSFER_FORMAT and INDI_CAPTURE_FORMAT. We should have support for this in the next release. Now if anyone willing to submit a PR for this, it would be awesome!
I tried this last night because I use CCDCiel for capture and Siril for processing. I am impressed with the long-term storage savings, but something isn't right yet. I'm quite used to using the EXPTIME header variable within my scripts to name my stacked files. When processing in Siril 1.0.0 with Astro-TIFF files, the EXPTIME is not a sum of all exposures, instead it is the length of a single sub-exposure. This isn't right... I haven't looked to see what other values might also not be correct. I'm unsure if this problem is in Siril or a formatting problem in CCDCiel.
Within CCDCiel, it's worth noting that there's a significant processing hit for adding compression. This isn't a problem for long exposures because you can configure CCDCiel to start the next exposure before the previous exposure is done being saved. When shooting something quick like bias or flat frames, however, it will take extra time between images. I use a Raspberry Pi... so this time can add up.
It would be nice to continue to capture regular FITS files and then use a command line tool to convert and compress the files to Astro-TIFF. Does such a tool exist yet?