mViewer is not the specific application I have built and documented here; it is the underlying toolkit. Bending mViewer to your will is a matter of either extending/evolving my code to do what you need or rejecting it altogether and building what you need. This section is not a cookbook, just some ideas on the kinds of thing that mViewer is good for and ways of getting there.
These are just some random examples, meant to stimulate creativity and in no way exhaustive.
Interactive actions like defining an area and selecting a point are currently tied to specific GUI functions, but there is nothing hard-coded about this. By replacing this code or adding a callback to you own code, you can support any action.
Suppose that you needed a set of points - say, a set of sources with suspected extended emission or a set of points for specialized background fitting, or the outline of a region. You could build a fancy GUI control for this if it is going to be used by many inexperienced people, or for your own personal convenience, and (remembering that our application leaves you in an interactive Python session connected to the mViewer data) you could define a set of python commands to start and stop collection (and probably to delete the just-collected point). Then all you have to do is append the area examination information (or a subset of it) to a Python data structure, which can be used (either when done or as you go) for any number of purposes both laudable and nefarious.
With Montage behind it, you have all sorts of image processing functionality at hand. Even mViewer by itself has more capabilities than we have used so far. For instance, suppose you have two images from different sources (and possibly different wavelengths) and you are not sure of the astrometry of one or the other (or both). Montage provides you with the ability to reproject either of them to match the other and mViewer can make a color composite with just the two (e.g. as red and blue planes). Relative offsets are then apparent and the reprojection of a single image is fast enough to make the whole process interactive.
Add to this a overlay of an astrometric catalog and you have absolute positioning as well.
You can put mViewer (or more accurately the Python session) in charge of whatever other processing you like. This might be simple quality control (mark or delete the images with bad data from a set) or even something as complex as telescope control, including other image sets and catalogs with your current instrument feed in the decision-making process.
Nothing is done without your involvement (or more accurately your Python code's involvement). If you do not want the image to zoom based on GUI actions, you need not allow it. We provide image processing tools, image rendering capability, and an example framework, but these can be organized any way you see fit.
The following is a real-world example. Some years ago a researcher was trying to validate a catalog they had generated and had a subset of sources that were somewhat ambiguous: pairs of sources in their catalog matched pairs of sources in the reference catalog closely enough that it was tricky for software to resolve.
Seeing both catalogs rendered (with scaled symbols) on top of a reference image was usually enough for a trained eye to resolve the ambiguity and the number of such points was small enough (tens of thousands) that with a fast enough way to step through the presentations the job was feasible for a small number of people to do in a reasonable time.
This exact confluence of circumstances is not common enough to warrant developing a custom tool, but this mViewer Python toolkit makes it easy to put together a tool that is, "good enough," for the temporary job.
In the previous examples, mViewer is more or less in control of processing. This does not have to be the case. mViewer, or even the Python instance, could easily be subservient to other processes.
For instance, a telescope system or processing pipeline might periodically have completed new images and you might want to have a window open on your desktop monitoring progress. If your processing is in Python, a variant of the code here can be folded in directly. Otherwise, a variant of this code could be fired up as a resident process, listening for messages that there is something new to display. Since the code here includes a web server as an intrinsic part of the processing, sending such messages is just accessing a specific URL.