VOTable for Images

[Mark Taylor]

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/