astropy / astrowidgets Goto Github PK

In Jupyter Lab, using our example notebook, I popped out the Output View for that print cell (to serve as log display). But I find that when the log gets too long, I cannot see the new stuff because it is hidden at the bottom (out of view) and there is no way to scroll. I can make the Output View bigger but if I keep doing it, eventually it has to cover up everything else; this is not desirable. If this needs to be moved to another repo (like Jupyter Lab or ipywidgets or something), please let me know.

Somewhere (README? Docs?) there should be a bit more on the installation. Don't have time to take care of it right now, but some bullet points I'm reminding myself to include because they tripped me up:

For jupyterlab:

• Needs an up-to-date jupyterlab
• Needs a reasonably up-to-date nodejs
• Need to have ipywidgets and ipyevents in the kernel of execution
• Need to do jupyter labextension install @jupyter-widgets/jupyterlab-manager in the kernel of jupyterlab
• Need to do jupyter labextension install @jupyter-widgets/jupyterlab-manager ipyevents (possible duplicate of the above, but I had to do them in order to get it to build properly...)

(I still haven't gotten ipyevents working though, so might have more to add)

Unless we plan to render them in Sphinx, there is no good reason for the notebooks to be buried inside docs. I propose move them to root level or inside astrowidgets package dir.

Although in the long run, when they are stable, should move them to Astropy tutorials.

Need to implement marking from input table in add_markers() so I can uncomment the following from example notebook using Ginga.

# TODO: Make this work
# Programmatically re-mark from table using SkyCoord
w.add_markers(markers_table, use_skycoord=True)

What is a viz tool without space cats?! Just sayin'.

ping @eteq

In the long run, they are optional when multiple toolkits are supported (Ginga, Glue, bqplot, etc).

xref #13

During Scipy 2018, we experimented with vectorized-drawing branch from https://github.com/ejeschke/aggdraw/ . @ejeschke, do you have plans to open a formal pull request from that branch against https://github.com/pytroll/aggdraw ?

In the example notebook, there is a cell to do w.cursor = 'top' to move X/Y/RA/DEC/Value display to the top of the image display. It used to work but no longer does (at least it has no effect when tested on Windows 10). Will have to check to see if it is also broken on *nix. Or maybe because I tested in on Firefox but now I am using Chrome? 🤔

Update: Also does not work on Windows 10 using Firefox.

Update: Also no longer works on RHEL 7 using Firefox.

As discussed during Scipy 2018.

As asked on Slack, "I notice that the notebook jumps up to show the entire viewer when I am a few cells down and I happen to mouse over the viewer. Is this a bug or feature? (Chrome on Windows 10)"

@mwcraig , "That is a bug I thought I had fixed....I noticed (and was irritated by it) a couple weeks ago too. I’ll look at this install of the install issue... It is a side effect of setting the focus to the image, which I needed to do to make keyboard events work in lab"

Thanks, Matt!

This would allow other widgets to execute callbacks when the image is changed.

This is forked from https://github.com/eteq/astrowidgets/pull/1#issuecomment-406811166 + related discussion in #10.

Specifically, about the select_points function from the API - it was replaced by w. is_marking = True.

My argument is that, while having marking be settable is tempting at first glance, I think it's better as a method because it's actually doing something. That is, the typical user (I think) isn't thinking about the act of marking stuff as a state machine, but rather a set of actions. Most workflows are either:

workflow 1:

1. show an image
2. mark some points/regions on it that are defined in a table or similar that requires no interaction
3. zoom around/look at what's marked
4. possibly repeat 2-3, or workflow 2

workflow 2:

1. show an image
2. interactively click on some objects in the image
3. do something in code with the marked locations
4. possibly repeat 2-3 for a different set of points, or workflow 1

To be very concrete one might select a subset of stars that are good PSF stars, and then use them to build a PSF (workflow 2), then the user wants to mark all the new locations of the stars after re-centroiding/fitting (workflow 1), then they want to mark a different set of stars from that set that turn out to look bad from the fitting (workflow 2 again).

So that sort of use case motivates select_points/mark_points. It's not modal per se (at least not to the user), but rather they start the action of selecting points, then they finish and are done. Then the next time they want a different set of points.

TL;DR: While I am fine with the name changes, I think select_points/mark_points is still useful, and it should retain the behavior of knowing which "session" the selections were made from. Perhaps get_markers returns all of them, but get_last_markers() or something like that returns only the most recent set? Or get_marker_sessions() returns a list of lists of markers?

While it is great that a table is an option, I often find myself creating a table just to use in add_markers. Accepting something like a Table or a numpy array would be convenient.

This is a follow-up for after #7 is merged. Also need to update setup.cfg to exclude warnings as needed.

Right now zoom_level can be get/set or one can call zoom which seems to do the same thing. Not sure that was the intent in the original API proposal at https://gist.github.com/eteq/bb625148969db51b2b03b71e92ca5231

I can get ginga_widget.ipynb to display the image but the widget is no longer responsive to mouse or keyboard. Tried it on Windows with both Firefox and Chrome. 😱

Is there something special I have to do for interaction with the widget?

Here is my conda list output. Am I missing some dependencies? 🤔
myenv.txt

Update: CI shows no failure against Ginga dev.

Today I spend some time to explore the possibility of using bqplot for implementation, image from FITS has to be convert to other standard format such as PNG, JPEG for it to work, my question is there better to convert FITS to these format?

My current way of converting it is using pillow.

Wiping the cache didn't help. I think switching to pip instead of conda would fix this, but not sure when I'll have time to do it, so feel free to update the RTD requirements, @mwcraig and @eteq .

https://readthedocs.org/projects/astrowidgets/builds/8806519/

Solving environment: ...working... failed

ResolvePackageNotFound: 
  - sphinx-astropy
  - sphinx-gallery

These differences are mostly name differences and in most cases the current names are, I think, fine.

ping @eteq

(Edit by @eteq: the proposed API in question is here: https://gist.github.com/eteq/bb625148969db51b2b03b71e92ca5231)

Currently, this works for "pixel locking", but what about "WCS locking"; i.e., ImageWidget A and ImageWidget B (both displayed in the same notebook) have similar pointing but different central RA and DEC and/or rotation, what does it mean to lock their WCS when one pan/zoom on one of them? How is it accomplished? Do we need to rotate one of them so they both have the same orientation?

import ipywidgets

mylink = ipywidgets.widgets.jslink((w._jup_img, 'value'), (w2._jup_img, 'value'))

UPDATE: jslink value does not really do what I want...

xref spacetelescope/dat_pyinthesky#7

I haven't had a chance to glance at the source code yet, but I'm guessing that in this case they maybe aren't added as a single compound object.

So slow...

It failed to import configparser but I don't have time to investigate, so I am opening this as a reminder.

https://readthedocs.org/projects/astrowidgets/builds/

I was working with some students today via an example notebook using astrowidgets running on binder. Some of them noticed very substantial lag when panning. I'm not sure whether that is because of limitations of binder, or network speed or what. If you have a couple minutes and can give it a spin and report back that would be great.

To get to the example go to this binder link, run the first cell to download a couple of images, then click into the first notebook.

It has a couple of vastly simplified mouse/keyboard bindings I wanted to run by the students today. It also supports right-click-and-drag to change contrast/cuts if you want to try that (shift-right-click to reset the contrast).

I know this is currently at hack-level so all is forgiven, but at some point if this design has legs we want to keep the top-level API (import astrowidgets limited to the API specific to here. That is, right now some ginga stuff (AstroImage, most notably) is in the top-level, which I think would confuse users.

Similarly (but more controversially): perhaps the core widget shouldn't be a subclass of a widget at all, but rather contain the widget? (but override _repr_html_ and so on to behave correctly). That way the tab-completion method of learning a tool isn't overwhelmed by all the widet details.

Not urgent, but just putting it here to keep track/discuss.

During a hack day project, in which @eteq and Matteo Correnti were a part of, I was given a non-interactive version of a photometry notebook. My task was to use astrowidgets to make some parts interactive. The non-interactive version leveraged astropy.visualization rather nicely. But I had a hard time trying to do exactly the same steps using astrowidgets with Ginga as a backend because ejeschke/ginga#560 is still unresolved. I have a feeling that other backends we would support in the future (e.g., bqplot or Aladdin Lite) might not use astropy.visualization as well. So, I guess that hook into astropy.visualization might have to happen here in the astrowidgets layer.

Relevant snippets:

import matplotlib.pyplot as plt
from astropy.visualization import (ZScaleInterval, SqrtStretch, ImageNormalize)
from astropy.visualization import simple_norm

norm = simple_norm(data, 'sqrt', percent=99.)

plt.figure(figsize=(14, 14))
plt.imshow(data, norm=norm, cmap='Greys')

norm = simple_norm(data, 'log', percent=99.)

plt.figure(figsize=(14, 14))
plt.imshow(data, norm=norm, origin='lower', cmap='viridis')
plt.colorbar()

xref spacetelescope/dat_pyinthesky#7

RIght now in some places you can specify whether you want pixel numbering to start at 0 or 1 (e.g. in add_markers) but in other places an offset of 1 is baked in, for example in the method that calculates the pixel location to display.

I'm thinking that setting that preference once when the object is created might be a better way to go.

Also in the other mouse callback.

These are my notes from the sprint Saturday night:

# Define a callback that shows the output of a print
out = ipyw.Output()

def show_event(viewer, event, datax, datay):
    with out:
       # print(dir(event))
        print(event.data_x, event.data_y)
display(out)

# This would work for adding markers with the appropriate callback
gvc = w._viewer.get_canvas()
gvc.add_callback('cursor-down', show_event)

# Changing binds for pan/zoom
bind_map = w._viewer.get_bindmap()

# ms is click-drag
# kp is keypress
# sc is scroll
# map_event args: mode, modifiers (usually empty), trigger, event_name (last two as strings)
bind_map.map_event(None, (), 'ms_left', 'pan')

# contrast with right mouse
bind_map.map_event(None, (), 'ms_right', 'contrast')

# zoom by scrolling
bind_map.map_event(None, (), 'pa_pan', 'zoom')

# pan by scrolling
bind_map.map_event(None, (), 'pa_pan', 'pan')

# restore contrast with ctrl-right-click... NOTE TUPLE FOR MODIFIER
bind_map.map_event(None, ('ctrl',), 'ms_right', 'contrast_restore')

# click to center
bind_map.map_event(None, ('shift',), 'ms_left', 'panset')

# to bind a custom event to a function of your choosing

bind_map.map_event(None, (), 'kp_w', 'my_custom_event')

# Signature of callback_function is
def callback_function(viewer, event, data_x, data_y, *args):
    with out:
        print('The magic key was pressed')
    pass

# prefix for keypress is keydown-
# suffix for ms_... is -down
# suffix for sc_... is -scroll
w._viewer.set_callback('keydown-my_custom_event', callback_function)

I started the key binding tables as a quick-look for myself. Not sure if the notebook is the best place for such a thing. It is already documented in Ginga but more spread out. I'll need to think about this... 🤔

It works without opencv, just slower when rendering image rotation and such.

• Make it truly optional in widget constructor.
• Remove it from CI dependencies and setup. (Removed from setup in #33)
• Make it optional in installation doc.

• Copy CoC from Astropy?
• BSD 3-clause license?

As reported in #59 (comment)

Right now if cuts is set to a string before the data has been set, then cuts has value (0, 0).

It seems like the user will expect that, once the user sets the data, the autocuts they wanted will be applied.

Alternatively, we could make it an error to set the value to a string before the data has been set.

While working on #35, I saw a note that says, "Initialize and display the slider right below the viewer." I don't remember adding that. Was it you, @mwcraig ? Opening an issue so we don't forget.

Currently, it does the following and displays the slider below the executed cell.

import ipywidgets as ipyw
from ipywidgets import interact

# Show the slider widget.
interact(
    show_circles,
    n=ipyw.IntSlider(min=0,max=len(t),step=1,value=0));

From Ginga there is additional shape that can be added to markdown, I am wondering which shapes is appropriate?
the following could be added:
rectangle, line, Point, Polygon, FreePolygon, RightTriangle, Triangle, Ellipse, Square, BezierCurve, Box, squarebox

I made an attempt at spacetelescope/dat_pyinthesky#7 during a "hack day" specifically for JWST but it can be generalized for just the generic ASDF format (https://asdf.readthedocs.io/en/latest/). Relevant snippet from the hack day:

    # TODO: Need to generalize this method before moving it
    #       to astrowidgets package.
    def load_jwst_asdf(self, filename):
        """Load ASDF extension from JWST Level 2 data.

        .. note::

            This needs to use ``'astropy_ape14'`` WCS module in Ginga.
            This also currently needs ``jwst`` pipeline to be installed.

        Parameters
        ----------
        filename : str
            Filename of JWST Level 2 file.
            It is a FITS file with ASDF-in-FITS extension.

        """
        import asdf

        image = AstroImage(logger=self.logger)

        with asdf.open(filename) as asdf_f:
            asdf_f['wcs'] = asdf_f['meta']['wcs']
            image.load_asdf(asdf_f, data_key='data')

        self._viewer.set_image(image)

Ginga's ASDF loader was implemented in ejeschke/ginga#719 and will be released with Ginga 3.0.

@mwcraig @pllim @astrofrog
As I reading up the ideas for Astrowidgets I noticed this idea
"Develop a method for identifying the nearest point source to a click on an image
(very preliminary work on this is available)"

I want to ask where I could find the preliminary work of this?
Thank you!

@jdavies-st asked how to overlay wcsaxes on a widget image display.

I see that there is an Appveyor YAML file in the repo. Do we plan to enable Appveyor at some point? Sooner than later?

I can see arguments both ways, opening to remember to come back to this....

I just ran into this problem on Windows 10 and jupyterlab/jupyterlab#5424 fixed it for me.

I have a notebook PR (spacetelescope/dat_pyinthesky#7) where I do not clear the output on purpose so people can see how things are supposed to appear without running the notebook. I noticed this when I view the notebook on GitHub:

Meanwhile, a separate notebook that does a similar thing but using non-interactive Matplotlib display renders the image fine.

If there is nothing we can do about this, you can slap a "won't fix" label and close this.

I am interested in exploring the development of a non-interactive version using Matplotlib as the backend, towards a non-interactive version which would implement as much of the API as possible in a non-interactive format. However, I have never done anything similar. Is there any suggestions as to some workflow or just simple guidelines I should follow?

Attempts to create an ImageWidget (from the Widget Example Using Ginga Jupiter notebook) result in the following error:

/Users/juan/anaconda3/lib/python3.7/site-packages/astrowidgets/core.py:72: UserWarning: install opencv or set use_opencv=False
  warnings.warn('install opencv or set use_opencv=False')

This is despite the fact that I have version 4.1.0 of the opencv python package installed. I confirmed when the offending line is run from th notebook separately it throws the following error:

ImportError                               Traceback (most recent call last)
<ipython-input-4-85398129f892> in <module>
      1 from ginga import trcalc
      2 
----> 3 trcalc.use('opencv')

~/anaconda3/lib/python3.7/site-packages/ginga/trcalc.py in use(pkgname)
     17 
     18     if pkgname == 'opencv':
---> 19         import cv2
     20         cv2_resize = {
     21             'nearest': cv2.INTER_NEAREST,

ImportError: dlopen(/Users/juan/anaconda3/lib/python3.7/site-packages/cv2.cpython-37m-darwin.so, 2): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Users/juan/anaconda3/lib/libopencv_freetype.4.1.dylib
  Reason: Incompatible library version: libopencv_freetype.4.1.dylib requires version 24.0.0 or later, but libfreetype.6.dylib provides version 23.0.0

This suggest to me the the opencv package installed via conda is NOT the correct prerequisite. Is there a way to force astrowidgets to install the proper opencv during pip installation?

It does not really use stginga, so the name is misleading. And some code and info there are outdated now.

A companion issue for #62 but for a simpler case of pixel locking without worrying about WCS. This would assume that Image A and Image B have the same pointing and rotation. This would be useful to compare, say, a science scene and its residual image, or a science scene and its uncertainties, etc.

I thought I got it figured out but turns out I was wrong. @mwcraig suggested using ipywidgets.link on zoom and pan traitlets tied to ImageWidget but I couldn't get that idea to work, given my inexperience with widgets and traitlets.

xref spacetelescope/dat_pyinthesky#7

I think this is a jupyterlab thing (i.e., it might not work this way in the notebook), but when I have the widget up and hit a number key to zoom, the event apparently gets passed onto the lab and it will change whatever cell I have selected into a header-level (the default Jupyter behavior). If it happens to be the cell containing the image widget, it hard-crashes the lab and I have to refresh the browser to get anything to work.

Sort of vaguely related to #39 since it might be the easiest way around it