[fitsbits] reopening of Public Comment Period on the compression conventions

[van Nieuwenhoven, Richard]

You can do all that with cfitsio routines (all compression algorithms
are included) and or use the command line fpack/funpack. (it will use
zlib only for GZIP and GZIP2 compression)

In nom-tam-fits it goes this way:
-----------------------------
compressedHdu =
        CompressedImageHDU.fromImageHDU(imageHdu, 100, 15);
compressedHdu.setCompressAlgorithm(ZCMPTYPE_RICE_1);
compressedHdu.compress();
-----------------------------
Will result in compressing the image in tiles 100x15 using the RICE
compression.
-----------------------------
compressedHdu = CompressedImageHDU.fromImageHDU(imageHdu, 100, 15);
compressedHdu.setCompressAlgorithm(ZCMPTYPE_HCOMPRESS_1)//
        .setQuantAlgorithm(ZQUANTIZ_SUBTRACTIVE_DITHER_2)//
        .getCompressOption(HCompressorOption.class)//
        /**/.setScale(4);
compressedHdu//
        .getCompressOption(QuantizeOption.class)//
        /**/.setQlevel(1.0)
        /**/.setCheckNull(true);
compressedHdu.compress();
-----------------------------
Will result in compressing the image in tiles 100x15
- use H-Compress with scale 4
- use Quantification with SUBTRACTIVE_DITHER_2, q-level 1.0 and use
check for NaN's

Nom-tam-fits has no external dependencies at all (zlib is included in
core java)

For examples how to do that with cfitsio, it is better to ask Bill directly.

    Ritchie





Am 2016-01-15 um 21:52 schrieb Demitri Muna:
> Hi,
> 
> Thanks for the replies; it’s good to see different ways how people are
> using data. I’m not inherently opposed to lossy compression - it’s up to
> the data provider to decide how to provide the data, and that can mean
> providing compressed data as the archival or reduced data. My concern is
> tying the format to a particular compression scheme, particularly given
> how often the format is updated. Will the decompression software be part
> of the monolithic cfitsio, or will (can) FITS have dependencies (e.g.
> zlib)? I did note the ZCMPTYPE keyword.
> 
> I assume that in the case of a compressed table or image that one could
> still seek to the byte offset of the data start, know from the header
> where the byte offset to the end of the data is, read that chunk and
> decompress it in memory?
> 
> Finally, can there be a routine (which could be wrapped by but not
> strictly written as a command line program) that will take a FITS file
> and rewrite it into an compressed/uncompressed format, either by
> specifying the HDUs or for all applicable HDUs?
> 
> Cheers,
> Demitri
> 
> _________________________________________
> Demitri Muna
> 
> Department of Astronomy
> Il Ohio State University
> 
> Home page: http://muna.com
> 
> My Projects:
> http://nightlightapp.io
> http://trillianverse.org
> http://scicoder.org
> 
> 
> 
> 
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>