[Cube/ImageDM] - WCS distribution with STCMod

Fri May 2 12:38:19 PDT 2014

Francois,

I'm attaching a diagram which I hope will help clarify the relationships.
It is my interpretation of a 2D image represented by the objects from the
Cube model diagrams.
Hopefully the resolution is sufficient to read it.

+ The AstroCoordSys holds the 2D Space Frame (standard spherical), and the
Frame for the Observable.
   - It would also have any Frames for non-data axes like Time, etc..
   - There can be >1 AstroCoordSys

+ PixelatedData is the 'data' container..
   - I has a PixelCoordSys holding the PixelFrames

+ PixelFrame is a 1:3D pixel axis set, here we just have the 2D set for the
spatial axes
   - It holds a refFrame which defines the Transform(s) to a Frame in
AstroCoordSys.  The 'destination' is
     specified by the reference to SpaceFrame (ref_frame_id).
   - It also holds the referencePixel and referencePos
   ** These objects are populated by the WCS information (or other source,
depending on the serialization).
   - IF there are multiple data arrays, there will be >1 PixelatedData.
     o each has their own PixelCoordSys with Transform definitions to the
destination AstroCoordSys frame.

+ The Voxel is a representation of the NDImage 'atom'
   - pixelAxes = pixel coordinate value with reference to corresponding
PixelFrame
   - independentAxes = spatial coordinate value with reference to
corresponding SpaceFrame
   - dependentAxis = 'observable' image value at those coordinates with
reference to corresponding frame.

I think the confusion comes when we consider WHEN/HOW the independentAxes
values are realized.
They are shown as Quantity, but clearly must be calculated.  What I'm
trying to show is that when these
values are served up, they are a 2D Vector Quantity.  When that happens,
will depend on the implementation.
How it happens is shown by the relationships.

The Voxel has both the PixelCoordinate and, therefore, access to the
Transform information held in
it's PixelFrame.Cart2DRefFrame.  With that information, it can calculate
the 2D Vector Quantity to
provide as the Space2DCoordinate value.

NOTE:  The STCMod portions of my diagrams are by no means to be considered
definitive.  The intent
is to illustrate the areas of the STC-1.33 recommendation which do not
quite serve the needs, and
provide a suggested alternative which does.  My expectation is that these
would be discussed, and either
be folded into a revision of STC (as is, or another solution which also
provides the needed functionality)
or not.. where we then either work around it, or keep it external from STC
as an extension.
  eg: STC-1.33 has insufficient support for non-linear transformations.
So, I defined the CustomRefFrame
        with modified structure which allows 1 linear + 1 non-linear
transform.. and added some examples
        Polynomial, Lookup, Stokes (a placeholder for handling polarization
)

MAPPING:
  As you see in the diagram, the Transform definitions (WCS) are
distributed to the PixelCoordSys object
  under 'data'.  What we decided from the earlier discussion is that this
is not what is desired to be distributed
  with an SIAP QueryResponse.
    + The SIAP QueryResponse requires 1 CoordSys defining the system all
metadata values are in.
    + It also wants to provide the full set of WCS information that the
corresponding image product contains.
       - this is given in the Mapping object.

  So, what thought we had settled on was that SIAP would define Mapping for
inclusion in the QueryResponse.
  We could provide a 'mapping' for populating Mapping from the distributed
objects.  This would essentially
  reverse the logic I used in the document showing the relation of Mapping
content with STC-1.33 earlier.

  The QueryResponse would, as usual, be comprised mostly of
ObservationDataset metadata (cut off 'data'
  from NDImageDataset), plus the Mapping, plus perhaps other summary
information about the 'data' section.
  I don't recall if things like Image.Nsubarrays, Naxes, Naxis, Pixtype
(which are all very serialization
  dependent) were needed for the QueryResponse.

Mark

In Response To:
============================================================================================================================================

   Suppose we are building a serialization of that. Will we have a computed
> value, error for each voxel stored in the serialization ? or is the
> aggregation there to show we can potentially COMPUTE these coordinates
> values using the mapping or WCS information ?
>

 This is a case where one would NOT serialize a direct translation of the
model.. too inefficient.
As a serialization, one could have 2 ND Image extensions, one for the
'value', one for the 'error'... or any number of other options.

>  As for the Mapping, which is, (if I follow previous discussion embedded)
> in the AstroCoordSys, why is that one not shown on the diagram ? Why isn't
> it attached to the Pixelated data Box like PixelCoordSys ? Is it supposed
> to be adressed through the AstroAxisCoordinate ? Or is alternativly all the
> Mapping information attached to the PixelCoordSys ?
>
>
 Yes.. the WCS information is distributed in the CoordSys.. via
CoordRefFrame, and stored in the PixelCoordSys.PixelFrames (transforms from
pixel -> astro).
 See STC:Overview

   So Now we can have all the WCS information under PixelFrame (via the
strucure in CustomRefFrame as far as I understand)  I Think it was not the
case in 2007 STC. There was an issue wis ReferencePosition in
WorldCoordinates or so. So you changed this on MOd STC ? That's what you
mean ?

   If we relate to earlier incarnations:
   - pixelatedData == storage of ND data array.  The PixelCoordSys is
associated with this object because it contains the PixelFrame descriptions
for that array and their Transforms to the broader world coordinate
system(s).  Different data arrays may have different transforms from their
pixel coordinates to the same world coordinate systems.  The AstroCoordSys
definitions are valid for, and owned by the Dataset as a whole, so it is
associated with the ObsDataset.   It may help to show that in this diagram.

  - voxel == I am using 'voxel' to represent the fundamental ND volume of
coordinate space.  It has associated with it, the various 'coordinates' of
the volume in the ND space (pixelAxes, independentAxes), and the
'observable' value AT that location (dependentAxis).  I am not positive the
composition relation is correct here, but I think it is.
    The actual values of the AstroAxisCoordinates may be defined (generally
would be), as a transform of the pixelAxisCoordinates (via WCS info), and
computed.

So we need a dynamic diagram to show that ? With methods and so ... ?

    This is shown in the STCMod:Coordinates diagram.  AstroAxisCoordinate
is an extension of Coordinate, and has a reference to the associated Frame
which holds the Transform information needed to compute the value. (STC:
Overview)

   But if we have all the mapping/WCS information under PixelCoordSys why
do we need this ? Is that a replication ? or a reference to the Frames
embedded in PixelCoordSys ? Or Am I totally wrong ?

  *Having all the mapping/WCS information in one single place seems very
important to me (we had a Mapping class in early versions of this model and
then we moved to reuse STC, actually a MOD STC for now)*

  *If everything is  under PixelCoordSys, that's fine *but I am a little
puzzled when I read "

*AstroAxisCoordinate is an extension of Coordinate, and has a reference to
the associated Frame which holds the Transform information needed to
compute the value. (STC: Overview) *
Because AstroAxisCoordinates are attached to Voxel in the NDImage diagram.

Do you see where I am lost ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140502/3e09cca8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImageExample.jpg
Type: image/jpeg
Size: 51691 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140502/3e09cca8/attachment-0001.jpg>