GNU Astronomy Utilities - Tasks: task #14191, Enable FITS input and output using...
You are not allowed to post comments on this tracker with your current authentication level.
task #14191: Enable FITS input and output using Lzip
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Wed 26 Oct 2016 11:50:50 AM UTC | ||
Should Start On: | Tue 25 Oct 2016 03:00:00 PM UTC | Should be Finished on: | Tue 25 Oct 2016 03:00:00 PM UTC |
Category: | All Gnuastro | Priority: | 5 - Normal |
Item Group: | Enhancement | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Percent Complete: | 40% | Open/Closed: | Open |
Effort: | 0.00 |
Mon 06 Feb 2017 04:18:32 PM UTC, comment #5: |
Antonio Diaz Diaz <antonio> |
Fri 03 Feb 2017 02:06:14 PM UTC, comment #4: Thank you very much Antonio for the very nice review. It was very interesting.
|
Mohammad Akhlaghi <makhlaghi> |
Thu 02 Feb 2017 10:33:50 PM UTC, comment #3: Mohammad has found an article that explains why using gzip (and by extension bzip2 and lzip) to compress images is in general a bad idea. Gzip, bzip2 and lzip see the data as strings of bytes, not as pixels:
|
Antonio Diaz Diaz <antonio> |
Sun 29 Jan 2017 06:49:31 PM UTC, comment #2: Hello to all.
|
Antonio Diaz Diaz <antonio> |
Thu 17 Nov 2016 05:29:09 PM UTC, comment #1: Antonio Diaz Diaz (creator of the Lzip program and library) has kindly offered to help in this task.
|
Mohammad Akhlaghi <makhlaghi> |
Wed 26 Oct 2016 11:50:50 AM UTC, original submission:
Lzip is a compression format that has both a high compression ratio and archival capabilities (can detect corruption in the data with high completeness).
|
Mohammad Akhlaghi <makhlaghi> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-01-29 | antonio | Attached File | - | Added cfitsio3410_lzip-1.diff.lz, #39608 | |
2016-11-17 | makhlaghi | Attached File | - | Added cfitsio3390_lzip.diff.lz, #39006 | |
Attached File | - | Added sample.fits.lz, #39007 | |||
Percent Complete | 0% | 40% | |||
Carbon-Copy | - | Added -email is unavailable- |
Powered by Savane 3.13-f8d8.
Corresponding source code
There are (among others) two very different kinds of data to be considered here. Lets call them "text" and "continuous functions". The main feature of "text" compression algorithms like gzip is not that the size of its compressing element is fixed at 8 bits, but the fact that they search for exact matches in the data. For gzip a miss is as good as a kilometer; 'foo' is as different from 'for' as it is from 'fox'.
OTOH, algorithms designed to compress data of the "continuous function" type, usually take advantage of the fact that differences between consecutive data elements tend to be smaller than the values of the elements, and therefore easier to compress efficiently. This is the case of the rice algorithm.
IMO, the two kinds of algorithms are so fundamentally different that it does not make sense to mix them.
Regarding the use of gzip/lzip to compress binary tables in fits files, the first attempt does not seem promising. The table seems to compress much better if it is in text (ASCII) format than in fits format: