Error drawing circles when coord="wcs"

[pllim]

While developing for eteq/astrowidgets#1 , I encountered error when drawing circles in in coord='wcs' mode. Circle radius is set to 20 (I assume it is in pixels but I have no idea if its unit secretly changes when I switch from "data" to "wcs" mode).

Here are the four points I attempted to draw:

RA (deg)	DEC (deg)
3.609821370156458	-30.378452205494682
3.589858963715532	-30.368501816764578
3.5872920549742506	-30.371258703333265
3.58680555297819	-30.366805584777612

What I did was attempting to create a CompoundObject from four individual Circle, each one constructed like this:

Circle(x=ra, y=dec, radius=20, coord='wcs', color='cyan')

This is the error I got from Ginga:

...\ginga\canvas\CanvasObject.py:193: RuntimeWarning: invalid value encountered in sqrt
  radius = np.sqrt(abs(y2 - y1)**2 + abs(x2 - x1)**2)
2018-07-21 12:13:54,733 | E | ImageView.py:1272 (redraw_now) | Error redrawing image: cannot convert float NaN to integer
2018-07-21 12:13:54,747 | E | ImageView.py:1277 (redraw_now) | Traceback:
  File "...\ginga\ImageView.py", line 1258, in redraw_now
    self.redraw_data(whence=whence)
  File "...\ginga\ImageView.py", line 1303, in redraw_data
    self.private_canvas.draw(self)
  File "...\ginga\canvas\DrawingMixin.py", line 723, in draw
    super(DrawingMixin, self).draw(viewer)
  File "...\ginga\canvas\CompoundMixin.py", line 143, in draw
    obj.draw(viewer)
  File "...\ginga\canvas\CompoundMixin.py", line 143, in draw
    obj.draw(viewer)
  File "...\ginga\canvas\types\basic.py", line 1044, in draw
    cr.draw_circle(cx, cy, cradius)
  File "...\ginga\pilw\CanvasRenderPil.py", line 110, in draw_circle
    self.cr.circle((cx, cy), cradius, self.pen, self.brush)
  File "...\ginga\pilw\PilHelp.py", line 124, in circle
    radius = int(radius)

I am using Ginga 2.7.1.dev1944 on Windows 7 64-bit with ipyevents on Jupyter Lab. In case it matters, Astropy is 3.1.dev22186.

I attempted to code dive a bit but got lost at viewer.renderer calls. What am I doing wrong here? Any help would be appreciated. Thanks!

[ejeschke]

I fixed that bug, but haven't pushed the code yet. Just wait a little and it will show up in the PR.

BTW,when coord='wcs' the radius is specified in degrees as well.

[pllim]

when coord='wcs' the radius is specified in degrees as well

Hmmm. Personally, I prefer radius to be in number of pixels regardless. As a user, I usually envision circle size in pixels and don't want to bother with "how big such-and-such degrees would actually appear on the display". However, I'll let @eteq and @mwcraig chime in as well.

[ejeschke]

Its not an uncommon use case (at our observatory) to want to visualize a point on the sky and its radius in degrees. Such calculations are handled more easily and accurately if all the coordinates are in the same units.

There is only one coord parameter to any object, which determines the coordinate mapper object that is assigned to the shape. I don't think it would be difficult to subclass one of the existing coordinate mappers and make it offset the radius as a data space value--you'd only need to override one method--but you'd need to manually assign the mapper object to the circles object just before you add it to the canvas.

[ejeschke]

Of course, you could then subclass Circles to make it do that automatically.

[ejeschke]

Thinking about that just a bit further, it's probably not too much more work to subclass the shape to make it take an astropy coordinate object and the radius as a value with a units attached. Am I correct in assuming that if you have a SkyCoord and you add a unit that is in pixels it does the right conversions?

[pllim]

Am I correct in assuming that if you have a SkyCoord and you add a unit that is in pixels it does the right conversions?

Currently, for coord='wcs', I pass SkyCoord.ra.deg and SkyCoord.dec.deg into Ginga.

To convert radius from degree to pixels, I would need to know the detector pixel scale (which might or might not be available as metadata in the image). How does Ginga compute this conversion internally?

[mwcraig]

How does Ginga compute this conversion internally?

I'm guessing it is derived from the WCS.

Thinking about that just a bit further, it's probably not too much more work to subclass the shape to make it take an astropy coordinate object and the radius as a value with a units attached.

This might be nice; I can imagine cases where I want to specify the location in world coordinates but I want the mark to have a fixed pixel size (e.g. for aperture photometry).

An alternative might be to allow radius to have a unit (even if x, y are still separate unitless arguments).