Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: SUIT
-
Labels:None
-
Story Points:1
-
Sprint:SUIT Sprint 2016-8
-
Team:Science User Interface
Description
There are several region issues I have found when comparing old and new API:
(1, 2, 3, 7, 8 are implemented in DM-7147, 4, 5, 6 are implemented in DM-7190)
1. The default coordinate system when "pure numbers" are used should be pixel positions on the original image.
The [spec](http://ds9.si.edu/doc/ref/region.html) says the following:
"...the default system is implicitly assumed to be PHYSICAL. In practice this means that for IMAGE and PHYSICAL systems, pure numbers are pixels."
'If no coordinate system is specified, PHYSICAL is assumed.'
More explanation can be found [here](http://hea-www.harvard.edu/RD/funtools/regcoords.html)
2. PHYSICAL coordinate system does not mean screen pixels. The question is whether we can always use image pixels.
If wcs is "physical", WCS is the pixel coordinate system of the original image, which may be different from the pixel coordinate system of the current image, if the current image is the result of an imcopy or other geometric transformation operation. In the "physical" coordinate system the ltv, ltm and the axis attribute parameters wtype, axtype, units, label, and format may be edited, but the FITS parameters crval, crpix, and cd cannot. [reference](http://stsdas.stsci.edu/cgi-bin/gethelp.cgi?wcsedit)
3. When used in API, the actions are dispatched one after another. For example, dispatchCreateRegionLayer might be issued before image plot has finished loading. Can we make regionCreateLayerActionCreator wait for image with plotId to finish loading?
More details: If I create a region layer with a few regions in image coordinates right after firefly.showImage, two errors are loaded to console:
doOnAppReady: uncaught TypeError: Cannot read property 'getImageCoords' of null(…),
RegionFactory:602: Uncaught (in promise) TypeError: Cannot read property 'getImageCoords' of null(…)
4. When a region is selected, yellow dashed line appears around it. On zoom the line does not change color.
5. Can not add empty region. Line 124 of the test script.
6. Can not add or delete regions after the first one. (Load test script, click Show Regions, then Add Region, line 121 of the test script) When there is one region in the layer and you are adding another region with a different position but everything else the same, the added region is perceived to be the same.
7. It's possible to select regions only in in the first region layer added. In the other layer, you can sometimes see the selection blinking, but it does not stay.
8. If region format is wrong, for example
'image; box 40 400 72 72 # color=blue' instead of
'image; box 40 400 72 72 0 # color=blue',
the region is silently ignored, no warning or error is logged to console.
9. We need region selection action to support callbacks on region selection. (Currently the selected region is "calculated internally based on the distance between the region and mouse readout.)
Attachments
Issue Links
Activity
Hi Cindy,
Regarding PHYSICAL and IMAGE coordinate system in regions, we should probably consult Gregory Dubois-Felsmann or David Ciardi [X].
Regarding dispatchers, which rely on previously added data, I'd like to ask the opinion of the team.Trey Roby
When I add regions to an image in API, how would I make sure that the image with the given plot id finished loading before calling dispatchCreateRegionLayer? Similarly, when adding or removing regions, how would I ensure that region layer is already created? (Since all the calls are asynchronous.)
Should we handle it in action creators or in the code, which uses our API?
Tatiana
IMAGE coordinates are pixel coordinates in the current image. PHYSICAL coordinates are pixel coordinates from a parent image. For a 2-D image, the relationship between IMAGE and PHYSICAL coordinates are minimally specified by LTM keywords similar to CD-matrix keywords, and LTV keywords for an offset. This is often used when a CCD image contains a section (like a "bias voltage strip") that contains no science data. For most applications this will mean non-zero values for LTV1 and LTV2 keywords, and LTM1_1 and LTM2_2 set to 1. If flips are desired then the LTM keywords could be -1.
This convention is an IRAF/NOAO construction. Sample images can be retrieved from the NOAO Science Archive. I retrieved a Dark Energy Survey image but it is in a compressed format and I couldn't get it to read into Firefly. I did verify with this image that ds9 defaults to PHYSICAL coordinates when a region file does not specify the coordinate system.
A detailed specification is given in this description from Lick Observatory. For test purposed we could construct one of the examples given there.
David Shupe
added a comment - IMAGE coordinates are pixel coordinates in the current image. PHYSICAL coordinates are pixel coordinates from a parent image. For a 2-D image, the relationship between IMAGE and PHYSICAL coordinates are minimally specified by LTM keywords similar to CD-matrix keywords, and LTV keywords for an offset. This is often used when a CCD image contains a section (like a "bias voltage strip") that contains no science data. For most applications this will mean non-zero values for LTV1 and LTV2 keywords, and LTM1_1 and LTM2_2 set to 1. If flips are desired then the LTM keywords could be -1.
This convention is an IRAF/NOAO construction. Sample images can be retrieved from the NOAO Science Archive . I retrieved a Dark Energy Survey image but it is in a compressed format and I couldn't get it to read into Firefly. I did verify with this image that ds9 defaults to PHYSICAL coordinates when a region file does not specify the coordinate system.
A detailed specification is given in this description from Lick Observatory . For test purposed we could construct one of the examples given there.
To be a little more helpful, note that the equation (from section 1.6 of this long archived email is this matrix equation:
IMAGE = LTM*PHYSICAL + LTV
IMAGE coordinates are the usual FITS pixel coordinates, i.e. the first pixel center is (1.0, 1.0) and NAXIS1 is the 'fast' direction. To get the PHYSICAL coordinates, in general you have to invert the LTM matrix and subtract the LTV values. In practice the LTM keywords will only ever have values of (+1, 0, -1) and in most cases you just have the identify matrix where LTM1_1 = 1, LTM2_2=1, and LTM1_2 and LTM2_1 are unspecified and default to 0. Then the inverse is also the identity matrix. Then you just have to subtract LTV1 from the first IMAGE coordinate and LTV2 from the second IMAGE coordinate to get PHYSICAL.
David Shupe
added a comment - To be a little more helpful, note that the equation (from section 1.6 of this long archived email is this matrix equation:
IMAGE = LTM*PHYSICAL + LTV
IMAGE coordinates are the usual FITS pixel coordinates, i.e. the first pixel center is (1.0, 1.0) and NAXIS1 is the 'fast' direction. To get the PHYSICAL coordinates, in general you have to invert the LTM matrix and subtract the LTV values. In practice the LTM keywords will only ever have values of (+1, 0, -1) and in most cases you just have the identify matrix where LTM1_1 = 1, LTM2_2=1, and LTM1_2 and LTM2_1 are unspecified and default to 0. Then the inverse is also the identity matrix. Then you just have to subtract LTV1 from the first IMAGE coordinate and LTV2 from the second IMAGE coordinate to get PHYSICAL. Since the desired direction is from PHYSICAL to IMAGE:
IMAGE_x = LTM1_1*PHYSICAL_X + LTM1_2*PHYSICAL_Y + LTV1
IMAGE_y = LTM2_1*PHYSICAL_X + LTM2_2*PHYSICAL_Y + LTV2
If any of these keywords are not specified, the defaults are:
0 for LTV1, LTV2, LTM1_2, LTM2_1
1 for LTM1_1 and LTM2_2
David Shupe
added a comment - Since the desired direction is from PHYSICAL to IMAGE:
IMAGE_x = LTM1_1*PHYSICAL_X + LTM1_2*PHYSICAL_Y + LTV1
IMAGE_y = LTM2_1*PHYSICAL_X + LTM2_2*PHYSICAL_Y + LTV2
If any of these keywords are not specified, the defaults are:
0 for LTV1, LTV2, LTM1_2, LTM2_1
1 for LTM1_1 and LTM2_2 Comments on region issue,
1. .the default system is implicitly assumed to be PHYSICAL,
=> (modified) updated per DS9 definition with DM-5192, Python API support
2. PHYSICAL coordinate system does not mean screen pixels
=> need to find out the definition of PHYSICAL in DS9
3. Can we make regionCreateLayerActionCreator wait for image with plotId to finish loading
=> (modified) fixing the problem by moving region parsing after drawing layer is created. (the fixing will be with DM-5192)
4. When a region is selected, yellow dashed line appears around it. On zoom the line does not change color.
=> (to be modified) will check and fix
5. Can not add empty region. Line 124 of the test script.
=> (to be modified) function feature related.
will modify 'dispatchCereateRegionLayer' to create an empty drawing layer if empty region is passed. (the function didn't create the drawing layer if empty region is passed).
6. Can not add or delete regions after the first one?
=> there are dispatch functions for adding/removing the region entries, will check if those functions work and meet the needs.
7. It's possible to select regions only in ithe first region layer added
=> (to be modified) will check and fix
8. the region is silently ignored
=> (to be modified) will check and output error message to the console.
Will comply to the error handling of Firefly later.
9. We need region selection action to support callbacks
=> (to be added) A new feature to implement. Will be created once the spec. detail is set.
Hi Tatiana,
Thank you for raising the issues.
Currently, the JavaScript versions set the default as J2000, it is no problem to change the default coordinate system to be ‘PHYSICAL' as defined.
Yes, so far I couldn’t find the document which gives very clear definition about “PHYSICAL”. As I run several cases in ‘SAOImage ds9’, both PHYSICAL and IMAGE are treated the same.
DS9 document says, ‘PHYSICAL’ is ‘pixel coords of original file’ and ‘IMAGE’ is ‘pixel coords of current file’.
My question is
Please let me know any of your thoughts.
The similar situations may also happen to other dispatching functions. Should dispatch functions handle this problem or should the application handle the calling sequence (workflow) problem?
I need your thoughts for this issue, too.
Thanks,
Cindy