<div dir="ltr"><div><div><div>Thanks a lot Erik for your detailed reply.<br></div><div><br></div>Your answer allows me to focus my questions/concerns about astropy.io.fits and <a href="http://heasarc.nasa.gov/fitsio/fpack/" target="_blank">fpack</a> in my initial message:<br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">In other words, the convention states how compressed FITS files should be read and written, while fpack is simply a program that knows how to write files with that convention.  There's no sense (I can think of) in which it makes sense for
a general purpose FITS library (like astropy.io.fits) to support fpack itself.
It does however support the same compression scheme and can read files
compressed by fpack.  And likewise can write compressed files that can be read
by funpack.<br></blockquote><br>1-by "it supports the same compression scheme" do you mean that astropy.io.fits reads/writes tile compressed FITS images in the same *exact* way (in terms of compression ratio and checksum file) as fpack does from command line (of course using the same set of parameters)?<br><br></div><div><br>2-my other concern is speed when reading/writing tiled-compressed FITS images. <br>Is astropy.io.fits performance comparable to fpack command line one?<br></div><div>Our example is 6576x4384pix images, with tiles size of 100x100pix.<br><br></div><div><br>3-one of our pipeline most intensive I/O operations is to extract small (500x500pix) subimages from the big ones (6576x4384pix) upon ~10^3 targets (RA,DEC) x ~10^6 exposures = ~10^9 requests.<br><br>In the <a href="http://heasarc.nasa.gov/fitsio/fpack/">fpack website</a> I've seen these two features:<br><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">-Each
 HDU of a multi-extension FITS file is compressed separately, so it is 
not necessary to uncompress the entire file to read a single image in a 
multi-extension file.<br></blockquote><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">-Dividing the image into tiles before compression enables faster access to 
small subsections of the image. 
<br></blockquote></div><br>I know it's a basic question, but...: are the compressed tiles stored into separate HDUs?<br><br>In other words, if my big (6576x4384pix) images are tile-compressed with fpack (or with astropy.io.fits if possible) and properly multi-extension HDU arranged, could astropy.io.fits (or pyfits) support the first of the two fpack features mentioned above?<br></div><div><br>That would really improve the reading performance for subimage extraction process.<br></div><div><br><br></div><div>Thanks in advance,<br><br></div><div>Octavi.<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 4:24 PM, Erik Bray <span dir="ltr"><<a href="mailto:embray@stsci.edu" target="_blank">embray@stsci.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Octavi,<br>
<span class=""><br>
On 10/08/2014 11:06 PM, Octavi Fors wrote:<br>
> Hello everyone,<br>
><br>
> this might sounds like a newbie question, but do you know if fpack compression<br>
> package is supported by astropy.io.fits version 0.4.2?<br>
<br>
</span>It depends on what you mean, exactly.  It would help to add some clarification<br>
about what *fpack* is--apologies if this isn't new to you but it's worth<br>
mentioning for anyone else reading.<br>
<br>
fpack itself (and its counterpart funpack (which I always enjoy reading "fun<br>
pack")) are just command-line programs that write new FITS files with one or<br>
more of the HDUs compressed according the FITS Tile Compression convention--or<br>
decompress them as the case may be.<br>
<br>
In other words, the convention states how compressed FITS files should be read<br>
and written, while fpack is simply a program that knows how to write files with<br>
that convention.  There's no sense (I can think of) in which it makes sense for<br>
a general purpose FITS library (like astropy.io.fits) to support fpack itself.<br>
It does however support the same compression scheme and can read files<br>
compressed by fpack.  And likewise can write compressed files that can be read<br>
by funpack.<br>
<span class=""><br>
> In<br>
> <a href="http://docs.astropy.org/en/stable/io/fits/usage/unfamiliar.html#compressed-image-data" target="_blank">http://docs.astropy.org/en/stable/io/fits/usage/unfamiliar.html#compressed-image-data</a><br>
> the module "astropy.io.fits.compression" is mentioned to access compressed HDUs,<br>
> but it doesn't say if fpack is supported and how should this package be<br>
> specified in fits.open method.<br>
<br>
</span>The docs you linked to at<br>
<br>
<a href="http://astropy.readthedocs.org/en/stable/io/fits/usage/unfamiliar.html#compressed-image-data" target="_blank">http://astropy.readthedocs.org/en/stable/io/fits/usage/unfamiliar.html#compressed-image-data</a><br>
<br>
could probably be expanded on with more examples, but as they indicate files<br>
containing compressed HDUs are handled transparently.  The compressed HDUs are<br>
accessed the same way as normal uncompressed IMAGE HDUs.  The data is<br>
automatically decompressed when it is read.  fpack has no role to play in that.<br>
<span class=""><br>
<br>
> My images images are 16 and -32bit. and I would like to make use of tiling<br>
> pattern (FZTILE='(n,m)', see fpack manual<br>
</span>> <<a href="http://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/docs/fpackguide.pdf" target="_blank">http://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/docs/fpackguide.pdf</a>>).<br>
<span class="">> For the -32bit images, any advise about noise-sensitive scaling (SCALE_FACTOR?)<br>
> and subtractive dithering to achieve high compression ratios while preserving<br>
> the scientific content of data, would be most than welcome.<br>
<br>
</span>The FZTILE keyword, as well as the other "Fpack compression directive keywords"<br>
listed in section 3.3 of the fpack guide are not standard FITS keywords and are<br>
only understood by the fpack program itself.<br>
<br>
These can be used, for example, in a pipeline where raw data is written out<br>
uncompressed in a FITS file.  The file is later processed through fpack which<br>
will compress any HDUs marked with these keywords according to the indicated<br>
settings.  The end result of that is a new HDU compatible with the tile<br>
compression convention, and keywords like FZTILE become ZTILEn, or for example<br>
FZALGOR becomes ZCMPTYPE.<br>
<br>
In other words, those FZ keywords indicate how the HDU *should* be compressed<br>
when passed through fpack.  The keywords on the actually compressed HDU<br>
(ZCMPTYPE, ZTILEn, etc.) indicate how the HDU *was* compressed.<br>
<br>
The FZ* keywords have no effect in astropy.io.fits (though it might not be a bad<br>
idea to create a facility that understands them, for creating compressed HDUs<br>
from existing uncompressed HDUs).  Instead, to create a compressed HDU you just<br>
create a CompImageHDU object as demonstrated here:<br>
<br>
<a href="http://astropy.readthedocs.org/en/stable/io/fits/usage/unfamiliar.html#creating-a-compressed-image-hdu" target="_blank">http://astropy.readthedocs.org/en/stable/io/fits/usage/unfamiliar.html#creating-a-compressed-image-hdu</a><br>
<br>
This works the same as other HDU types in the library.  Though it does take<br>
several optional keywords that are described in more detail in the API docs:<br>
<br>
<a href="http://astropy.readthedocs.org/en/stable/io/fits/api/images.html#astropy.io.fits.CompImageHDU" target="_blank">http://astropy.readthedocs.org/en/stable/io/fits/api/images.html#astropy.io.fits.CompImageHDU</a><br>
<br>
For example to specify a tiling use<br>
<br>
 >>> hdu = fits.CompImageHDU(data=data, header=header, tile_size=(n, m))<br>
<br>
Subtractive dithering is used by default where applicable.  It otherwise<br>
supports all the features of the convention except perhaps the ZMASKCMP option<br>
(not for any particular technical reason--it's definitely something that can and<br>
should be done, though I haven't had any requests for it either...)<br>
<br>
As to how to find a balance between compression quality and data quality I think<br>
others with more experience may wish to weigh in on that, though I will point<br>
out that documentation for the tiled image convention has some useful tips on that:<br>
<br>
<a href="http://fits.gsfc.nasa.gov/registry/tilecompression/tilecompression2.3.pdf" target="_blank">http://fits.gsfc.nasa.gov/registry/tilecompression/tilecompression2.3.pdf</a><br>
<br>
<br>
Hope that helps,<br>
Erik<br>
_______________________________________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/astropy" target="_blank">http://mail.scipy.org/mailman/listinfo/astropy</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Octavi Fors<br>Postdoctoral Research Associate<br>Department of Physics and Astronomy<br>The University of North Carolina at Chapel Hill<br>CB #3255, #157 Phillips Hall<br>Chapel Hill, NC 27599<br>Office: (919) 962-3606<br>Fax:    (919) 962-0480<br></div>
</div></div>