[ImageDM] Mapping

[François Bonnarel]

Hi all,
    after reading Mark's document I will have a few comments on the 
final step (but I went through all the steps before)

      - Information needed for Mapping transformation is dispersed in 
several different objects. I think Mark himself pointed that "limitation"
      - The Axis Frames and Pixel FRAMES are customized frames 
(basically because they imply reference  Positions) They are not the 
nativestanadr  Coordiabet systems you could associate "a priori" to the 
datasets. We probably need different Coordinate systems elsewhere in the 
ImageDM
      - The current STC projections (as Mark said also) is limted to 
trigonometric projections and  doens't allow something like lookup 
tables and even not polynomial transformations such as the one required 
for Schmidt plates or some other wide field images. So If we use STC for 
storing mapping Mappinf information we need to EXTEND STC first to these 
kind of "projections".

Best regards
François

Le 11/12/2013 08:36, David Berry a écrit :
> To state the obvious, it should be possible to convert from FITS-WCS
> to a richer WCS formalism, but may not always be possible to convert
> from the richer WCS  back to FITS-WCS. That's the case with AST, which
> uses a radically different formalism to FITS-WCS, based on stackable
> mappings and a complete separation between mappings and frames.
>
> Modernising AST's support for STC-X may be an option for implementation.
>
> David
>
> On 10 December 2013 23:42, Douglas Tody<dtody at nrao.edu>  wrote:
>> Hi Mark -
>>
>> The issue is that all the WCS-related computation we need to do for
>> image analysis is currently dealing with FITS WCS instances, e.g., in
>> archive data, and the class libraries used in most current applications
>> implement the FITS WCS data model as well (WCS instances in archive data
>> may or may not involve actual FITS files).  Most of these applications
>> are based upon one of the same small collection of WCS libraries, all of
>> which implement the FITS WCS model - possibly some other WCS models as
>> well, but FITS WCS is what is common.  So far I am not aware of any
>> current WCS libraries that support a STC WCS representation.  We have
>> some flexibility in how we represent a WCS instance within the ImageDM,
>> but we are almost always dealing with a FITS WCS instance or class
>> library outside of our VO middleware.
>>
>> So long as we have a simple mapping to/from a FITS WCS instance and our
>> internal VO representation it can work.  Mapping obviously provides this
>> since it is merely representing the FITS WCS data model directly using
>> VO data model technology, independent of the external serialization.
>> Whether or not a simple mapping to/from FITS WCS and the STC data model
>> is possible is less clear, especially if we are flexibile in terms of
>> representation, e.g., using VOTable and Utypes for the VO serialization.
>> We are making progress answering that question - your analysis looks
>> like it comes closer to answering the question than anything we have
>> done thus far.  It may or may not be possible, however using the VO data
>> model technology to leverage widely implemented FITS semantics such as
>> WCS is quite an interesting thing to explore as well.  It is essential
>> that current WCS-based image processing and analysis applications be
>> usable with VO interfaces with modest effort.
>>
>> In any case, specifying an automated mapping from FITS WCS to/from STC
>> would be a good place to start.  It would also be good to have some
>> tools (software) to demonstrate such a mapping with real data.  If we
>> had that then what you suggest would be a lot more practical to
>> consider.
>>
>>          - Doug
>>
>>
>>
>> On Tue, 10 Dec 2013, CresitelloDittmar, Mark wrote:
>>
>>> Doug,
>>>
>>> What I believe the document shows is that
>>>   - the FITS WCS Serialization ( as encapsulated by the Mapping object ) is
>>> compatible with the STC Model.
>>>
>>> Given that FITS-WCS serialization is a widely used standard, it is
>>> important to illustrate that the STC model is compatible with it.
>>> I would expect that to have happened before it became a recommendation.
>>> It
>>> may be useful to have a reference document showing the various FITS-WCS
>>> serialization options and their representations in STC objects.  A lot of
>>> that information is in the document I just put out, but is not directly
>>> shown.
>>>
>>> But I don't understand the concern behind the questions below.
>>>
>>> It reads like you are asking how many tools/libraries understand the
>>> STC-S/STC-X serializations before considering use of the Model within
>>> ImageDM.
>>> I don't see the relevance.  All we should need to show is that it is
>>> compatible with whatever existing standard serializations are required
>>> (FITS-WCS is all I've heard).
>>> Is there another Ascii/XML representation of WCS that existing tools do
>>> understand?
>>>
>>> If the concern is that STC may allow additional options not representable
>>> by FITS-WCS, I don't think that is a constraint.
>>>
>>> I feel like we've been around this barn before, so maybe someone else can
>>> help illustrate the issue from another angle to help clarify things for
>>> me?
>>>
>>> Mark
>>>
>>>
>>>
>>> On Tue, Dec 10, 2013 at 12:34 PM, Douglas Tody<dtody at nrao.edu>  wrote:
>>>
>>>> Hi Mark -
>>>>
>>>> The document at the link below does not load, at least for me.  I also
>>>> went into Volute and poked around, but could not bring it up, so I was
>>>> not able to review the comparision of capabilties.
>>>>
>>>> This looks like the most in-depth analysis yet of WCS vs STC, which is
>>>> good.  It will be good to have such a comparison to inform thoughts
>>>> about future applications or directions, in particular what capabilities
>>>> are missing or added by each WCS formalism.  In the meantime it would be
>>>> good to know the following:
>>>>
>>>>      o   What libraries are currently available that implement STC-WCS,
>>>>          and in what languages?  (I know that there is something at least
>>>>          STC-related in Starlink AST, for example, but do not know how
>>>>          complete it is).  Do these libraries support capabilities such
>>>>          as forward and inverse transforms for supported WCS functions?
>>>>
>>>>      o   Has the mapping (no pun intended) from FITS WCS to STC WCS and
>>>>          vice versa been worked out and implemented in any libraries?  So
>>>>          for example if we have data with a FITS WCS, can this be easily
>>>>          converted to STC?  How complete is the mapping?  Such easy to
>>>>          use load/save WCS tools would be necessary to enable use the STC
>>>>          formalism with data or applications currently implementing FITS
>>>>          WCS.
>>>>
>>>>      o   Do we know of any current science applications or tools that
>>>>          implement STC for its WCS capabilities?  To what extent is this
>>>>          supported in CIAO or DS9 for example, or other software?
>>>>
>>>>      o   What is the extent of STC WCS support in current archive data
>>>>          collections?  We know that FITS WCS is very widely implemented
>>>>          in current archives (hence supporting it is mandatory), but if
>>>>          STC is becoming more broadly used to describe WCS in archive
>>>>          data, this would increase the priority for supporting it.
>>>>
>>>> Regardless of the technical merits of these two technologies, we need to
>>>> know the answers to the above questions before deciding to favor, or
>>>> possibly even support, STC-WCS for image access and analysis, at least
>>>> in the short term for cube project development over the next 6-12
>>>> months.
>>>>
>>>>          - Doug
>>>>