VOTable for Images

Thu Oct 17 16:35:28 CEST 2019

Thanks all,

This is pretty much what I thought..
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.
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.

Mark

On Thu, Oct 17, 2019 at 4:38 AM Mark Taylor <M.B.Taylor at bristol.ac.uk>
wrote:

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