Question about physical coordinates

[javierggt]

I have a fits file with a 665x720 pixel image, and the following ds9 regions file:

# Region file format: DS9 version 3.0
global color=green select=1 highlite=1 edit=1 move=1 delete=1 include=1 fixed=0 source
physical;Polygon(4388.455,4088.196,4388.651,4091.190,3845.803,4126.580,3845.608,4123.586)

I have also created a WCS to transform from these physical coordinates to pixel coordinates.

Now... when I read the regions file using regions.Regions.read, it assumes the regions are in pixel coordinates, even though the DS9 parser correctly sets coordsys to 'physical'. The region then has a pol.to_sky method to transform it in exactly the opposite way I want: I want to transform it from physical to pixels.

How would you deal with this case?

I suppose one way would be to provide the WCS at the time the regions file is read, so it can provide a region in actual pixel coordinates. Is there another way? Can one register a WCS for coordinates that might appear when reading?

[keflavich]

What are the physical pixel coordinates? What frame are they in? I'm not sure we have any implementation for "physical" coordinates as I don't know how they're supposed to be interpreted.

[javierggt]

I am new to this thing, so whatever I say should be taken with a grain of salt.

"Physical" coordinates relate to the coordinates of the instrument, like coordinates on a CCD camera. After processing, the pixel coordinates might not correspond to the actual instrument pixels. In my particular case, the image is re-binned and cropped.

Because it is instrument-dependent, I don't think there is a general way to process them, but in my case I have a WCS I do the transform from physical to pixel coordinates.

[javierggt]

A question: the DS9 parser does set the coordsys data member, so what does regions.Regions.read do with it? If it is a known coordinate system, does it apply a transformation?

If the answer is yes, the followup question would be: should there be a warning or an error if it does not know how to handle that coordinate system?

[larrybradley]

We don't have an implementation for "physical" coordinates. This isn't possible with the current framework of the Regions classes because they are independent of any dataset or WCS. Coordinates that depend on a WCS (such as "physical", "linear", or "wcs[a-z]") aren't supported by this package. This a bug in the ds9 reader because all it does is assume "physical" = "image", which is not correct. Instead the ds9 reader should raise a warning message that "physical" is not supported.

As a workaround you could load your "physical" region file into ds9 and write it back out in another supported coordinate system (e.g. image, icrs, fk5, etc.) that can be loaded by this package.

[javierggt]

I agree the reader should give an error in this case, instead of assuming "physical" is "image".

It would be nice to have the option to pass a WCS to the read method. The question then is if this is something that might conceivably happen.

[taldcroft]

If it helps, in this particular case "physical" is local coordinates in detector pixels in a tangent-plane projection on the Sky for Chandra data. I.e. SKY coordinates in https://cxc.cfa.harvard.edu/ciao/ahelp/coords.html.

[javierggt]

If it helps...

I don't think it will help, because this coordinate system is attitude-dependent, so the only way to deal with it is to provide the WCS for the observation. Still, it would help if providing the WCS on reading was an option.

I can do the workaround proposed by Larry (or something similar)