<div dir="ltr"><div><div><div><div>Thanks all,<br><br></div>This is pretty much what I thought..<br></div>I don't have a lot of requirements at this point, but am trying to look ahead to usage threads for the image portion of the Cube model.<br></div>The current annotation scheme(s) are directed to VOTable, so if I can't properly serialize an image dataset in VOTable, then it will have to do something else.<br><br></div>Mark<br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 4:38 AM Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk">M.B.Taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, you could put a tile compressed FITS image in there.<br>
In that case the FIELD metadata items would have to[*] describe<br>
the COMPRESSED_DATA (and optionally GZIP_COMPRESSED_DATA)<br>
columns defined in FITS 4.0 section 10.1.3 as well as any<br>
additional optional tiling-related columns that may be included.<br>
Current VOTable parsers would certainly see such referenced<br>
FITS files as tables rather than images, but downstream processing<br>
could be written to turn them back into images.<br>
That feels like a bit of a hack, but it may fit Mark's<br>
requirements for doing this (I don't know what those are).<br>
<br>
Mark T<br>
<br>
[*] that's not strictly true: VOTable 5.2 says<br>
<br>
"The VOTable specification does not define the behavior of parsers<br>
with respect to this doubling of the metadata. A parser may ignore<br>
the FITS metadata, or it may compare it with the VOTable metadata<br>
for consistency, or other possibilities."<br>
<br>
so it wouldn't actually violate the standard to e.g. supply<br>
column metadata in the VOTable that refers to the image rather<br>
than the tile compression; but it would at least lead to<br>
unpredictable parsing results.<br>
<br>
<br>
On Thu, 17 Oct 2019, Seaman, Robert Lewis - (rseaman) wrote:<br>
<br>
> Could this work with tile compressed FITS images, which are indeed bintables?<br>
> <br>
> Rob Seaman<br>
> Lunar and Planetary Laboratory<br>
> University of Arizona<br>
> --<br>
> <br>
> On 10/16/19, 4:27 PM, "<a href="mailto:apps-bounces@ivoa.net" target="_blank">apps-bounces@ivoa.net</a> on behalf of Mark Taylor" <<a href="mailto:apps-bounces@ivoa.net" target="_blank">apps-bounces@ivoa.net</a> on behalf of <a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>> wrote:<br>
> <br>
> Mark,<br>
> <br>
> I don't think this is going to work. The <FITS> element in VOTable<br>
> is only designed to point at a FITS Binary Table (BINTABLE extension),<br>
> not a FITS image (primary HDU or IMAGE extension). The reason that<br>
> the extnum has to be >0 is that you can't put a BINTABLE in the primary<br>
> HDU, only in one of the later extensions. If a VOTable parser gets<br>
> directed from the FITS element to an HDU that does not contain<br>
> a BINTABLE, it's going to fail to understand it; that's certainly<br>
> true of my parser, and I'd say it's the clear intention of the<br>
> standard, e.g. (VOTable 1.3 section 2.3):<br>
> <br>
> Henceforth, we shall abbreviate "FITS Binary Table and its Conventions"<br>
> simply by the word "FITS".<br>
> <br>
> If you wanted to insert the content of an image dataset into a VOTable<br>
> document, you'd have to do something like use a cell of a table<br>
> with multi-dimensional array type.<br>
> <br>
> Mark<br>
> <br>
> On Wed, 16 Oct 2019, CresitelloDittmar, Mark wrote:<br>
> <br>
> > All,<br>
> > <br>
> > In my presentation at the interop (DM session), I mentioned that the<br>
> > VOTable serializations of the 2D and 4D image fail validation.<br>
> > <br>
> > I'm not terribly surprised (it is VO*Table* after all), but I have some<br>
> > small hope of working up to some usage work on the Cube-Image in the near<br>
> > future and am not sure what the strategy is for serializing/annotating<br>
> > image datasets.<br>
> > <br>
> > Looking for suggestions..<br>
> > <br>
> > Basically, I'm currently using the same mode that I do with tabular<br>
> > datasets. Include the header metadata, describe the content, point to the<br>
> > FITS file.<br>
> > <br>
> > <FIELD ID="_col-image" name="image" datatype="int"/><br>
> > <DATA><br>
> > <FITS extnum="0"><br>
> > <STREAM<br>
> > href="file:///data/vao/staff/mcd/docs/models/dm/Cube/examples/src/chandra_2Dsky_image.fits"/><br>
> > </FITS><br>
> > </DATA><br>
> > <br>
> > 1) obviously, there is no field named "image" in the dataset, I could use<br>
> > the block name, but it's still a hack<br>
> > 2) extnum="0"<br>
> > The VOTable spec is pretty clear that the extensions are "numbered from 1<br>
> > up, the main header being numbered 0".<br>
> > So, it's no surprise that I get the following validation error on this:<br>
> > (using votlint in stilts_3.0-9)<br>
> > ERROR (l.293, c.26): cvc-minInclusive-valid: Value '0' is not<br>
> > facet-valid with respect to minInclusive '1' for type 'positiveInteger'.<br>
> > ERROR (l.293, c.26): cvc-attribute.3: The value '0' of attribute<br>
> > 'extnum' on element 'FITS' is not valid with respect to its type,<br>
> > 'positiveInteger'.<br>
> > ERROR (l.294, c.112): Non-positive extension number extnum=0<br>
> > WARNING (l.294, c.112): Read error for external stream<br>
> > uk.ac.starlink.table.TableFormatException: Can't read FITS header<br>
> > <br>
> > And, if I point it at a non-table HDU in later extensions...<br>
> > WARNING (l.294, c.93): Read error for external stream<br>
> > java.io.IOException: No table HDU at extension 2<br>
> > <br>
> > I suppose I could do it with the <BINARY> node, but it'd be nice for the<br>
> > redirect to work.<br>
> > <br>
> > Mark<br>
> > <br>
> <br>
> --<br>
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
> <a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/%7Embt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
> <br>
> <br>
> <br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/%7Embt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a></blockquote></div>