<div dir="ltr">For reference, DS9 has supported the tiled image convention for years (since ~2008 according to release notes). It appears to do so using CFITSIO rather than a separate implementation. A DS9 developer would probably know better.<div><br></div><div>Rob<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 10:06 AM, van Nieuwenhoven, Richard <span dir="ltr"><<a href="mailto:Richard.vanNieuwenhoven@adesso.at" target="_blank">Richard.vanNieuwenhoven@adesso.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At nom-tam-fits we wan't to implement the compression's and have done so partly already. The<br>
biggest problem is that the standard does not provide test data, and in my opinion this is a  prerequisite for a standard like this.<br>
In fact a good standard delivers a reference implementation or a compliance test.<br>
<br>
I can see that a reference implementation is not possible in a community like this, but the delivery of<br>
test data would make the live of a developer 1000 fold easyer. Especially if it is available in levels, like separate data files for the different kinds of compression.<br>
<br>
Sure the compression makes fits more comple, but that's what access library's like ours are for. Especially when the fits files start to get as big as e few gigabytes...<br>
<br>
       Ritchie<br>
________________________________________<br>
From: fitsbits [<a href="mailto:fitsbits-bounces@listmgr.nrao.edu">fitsbits-bounces@listmgr.nrao.edu</a>] on behalf of Mark Taylor [<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>]<br>
Sent: Wednesday, June 24, 2015 5:45 PM<br>
To: FITS List<br>
Cc: Amit Kapadia<br>
Subject: Re: [fitsbits] start of Public Comment Period on compressed FITS image and tables<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, 24 Jun 2015, Lucio Chiappetti wrote:<br>
<br>
> On Wed, 24 Jun 2015, Mark Taylor wrote:<br>
><br>
> > but three weeks is not enough time to attempt an implementation to check it<br>
> > does actually provide all the description required to implement these<br>
> > conventions.<br>
><br>
> That statement reminds me interoperability testing is part of the criteria to<br>
> be considered by the EC when going to votes. I assumed the fact the registered<br>
> conventions (in general) have been around for quite a while could waive for<br>
> most of the interoperability demonstration.<br>
<br>
That does prove that it can be done and work well, but it doesn't prove<br>
that the way it's described in the text correctly and fully describes<br>
how it's done.<br>
<br>
> Nevertheless, while nobody is asking that topcat supports ZIMAGE and ZTABLE<br>
> now, in 3 weeks, 3 months or 3 years :-) it would be helpful if the original<br>
> authors and supporters of the convention may recall the status of<br>
> interoperability (multiple implementations), and also any other author of<br>
> popular s/w (e.g. ds9) may state whether they support it already.<br>
<br>
Yes, I'd be very interested to hear if there is more than one<br>
independent implementation out there.<br>
<br>
> > The text looks like what it presumably is, a post-hoc codification of a<br>
> > series of experiments in compression<br>
><br>
> This seems a bit unfair or un-kind, but ...<br>
<br>
I apologise if that is or appears to be true.  The text itself looks<br>
well written and complete, but my point was that there is quite a<br>
large number of algorithmic options described, and my suspicion<br>
is that some of them may be there because they got implemented<br>
and then superceded by a better idea rather than because they<br>
are all useful alternatives.<br>
<br>
> > is all there in CFITSIO, but that can't be used directly by non-C-friendly<br>
> > languages such as java, javascript, and who knows<br>
><br>
> is Fortran C-friendly ? or idl ?<br>
<br>
I would class IDL and FORTRAN as "C-friendly" on the grounds that<br>
they are (probably) implemented in C and can generally be linked<br>
cleanly to C routines.  Java is capable of interfacing with C<br>
via the Java Native Interface, but this breaks the 'pure java' model<br>
and greatly complicates distribution of java executables which<br>
are otherwise completely platform-independent, so I'd call it<br>
C-hostile.  In browser-based javascript I think it's generally<br>
impossible for security reasons to use C-based libraries or<br>
run C-based utilities.<br>
<br>
>                                  I would not engage myself in supporting<br>
> ZIMAGE or ZTABLE directly, not even in java ... I guess it won't be very<br>
> efficient.<br>
<br>
You might not, but I probably should.  If this becomes part of the<br>
standard (rather than an associated convention) I would hope to<br>
be able to support tile compressed tables in the java library STIL<br>
(hence STILTS/TOPCAT), though I'm not sure on what timescale.<br>
(There is no reason by the way that java cannot do this processing<br>
with comparable efficiency to C.)  At the moment this java software<br>
supports any table encoded according to the current FITS standard,<br>
and I'd like to be able to say the same about future versions.<br>
<br>
>            Although if somebody writes a class for a Rice (or PLIO or<br>
> HCOMPRESS) stream (gzip *is* supported) the problem can be nicely isolated.<br>
<br>
Yes, if they do.<br>
<br>
> (well javascript is not a serious language really suited to deal with binary<br>
> data, is it ?)<br>
<br>
I'm not a javascript/HTML5 expert, but there are increasingly complex<br>
web applications appearing for visualising and manipulating<br>
astronomical data within the browser.  Some of these do the data<br>
access on the server side, in which case use of CFITSIO can be used,<br>
but not all.  While investigating this, I found that the client-side<br>
javascript FITS I/O library fitsjs (<a href="https://github.com/astrojs/fitsjs" rel="noreferrer" target="_blank">https://github.com/astrojs/fitsjs</a>)<br>
actually already offers partial support for tile-compressed images -<br>
though it looks like only the Rice algorithm is supported.<br>
I have CC'd Amit Kapadia, the author of that package, in case he<br>
wants to comment on the difficulties or otherwise of implementation<br>
(and doesn't already read this list).<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> +44-117-9288776  <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</div></div></blockquote></div><br></div>