How Interactive Can I Make Graphs and Functions?

PauseForUser is probably what you want to use in this situation. You've probably done this already, but make sure you read this section:

I don't think you're proposing anything that's particularly difficult to implement in Igor, though you have a rather complex workflow that is performance sensitive so you may need to put a decent amount of effort into this to get it working exactly how you want.

Even though I'm not sure that IP9 will be significantly better than IP8 for what you're doing, I do suggest that if you're going to spend a significant amount of your time on this that you use the latest version. IP9 does have quite a few performance improvements that could be useful to you. It's also maintained, so if you discover a bug (not unlikely with PauseForUser) it's something we'll possibly fix in the version you're using.

Regarding this one point:

• It would present a dialog box where I can enter a simple 1 or 0 (yes/no) that it did it right.

Consider using DoAlert with alertType=1. That will give you a true modal dialog with Yes and No buttons. You can press the Y key (or enter) to select Yes and the N key for No.

BTW, I should mention the ImageAnalyzeParticles operation to you in case you haven't already looked into that. Also, if you need help making your code run faster, let us know (best through emailing your experiment and/or code to support@wavemetrics.com).

Look at windows hook functions with the SetWindow command that will allow you to run a function just by clicking your mouse in an image without having to move the clunky cursors around. Maybe you could even click and drag to indicate the size of the crater using the mousedown and mouseup event codes.

For showing the location of already-identified craters you could use DrawArc which will allow you to draw circles using the coordinate system of the image. Another option if your images are black and white is to expand them to have red, green and blue channels and give the already identified craters a slight color.

aclight is right that this will take some effort to get right, but if you have another 15 years in you, then it's well worth it!

The main window might be the graph containing the image and a control panel subwindow with perhaps three buttons: Done, Start New Crater, Analyze. You might or might not want Erase Current Crater. Use a window hook to field mouse clicks; the window hook would presumably maintain an XY wave pair to display the clicks.

The Analyze button would do its thing, then put the result on the graph, and as aclight suggests, use DoAlert to ask if the result is good.

Actually, perhaps you don't need the Start New Crater button- that would simply be the starting state, and the Analyze button would simply do the analysis, wait for your answer, store the new crater or not, reinitialize and cycle around to waiting on the window hook again.

My recollection is that a while back I "helped" you with this project, and perhaps I suggested ImageAnalyzeParticles and it wasn't really appropriate. Correct me if I'm wrong! My fading recollection is that the craters tend to have only partial rims, so they don't really make good particles.

I'd use GraphWaveDraw/GraphWaveEdit to convert mouse click positions to wave entries. And continue from there.

> I fully understand Igor was not designed for this level of interactivity.

Designed or not, you can get anything interactively done.

Shameless plug: See https://youtu.be/Y3I-LDX-R2Q?t=465 for a demo of a program we are developing in Igor Pro. The dude explaining the program is me ;)

As you can tell, in Igor there's usually more than one way to get a task done! We pride ourselves on the programmability of Igor, including the control panels that allow "sophisticated UI programming". I think that's what's in the data sheet...

It all sounds very doable to me.

My inclination would be to create an interface with a graph window and a panel. I would try to avoid pauseforuser as much as possible and use a hook function to capture mouse clicks. You can also hook keyboard events if you want to build a very efficient interface.

Consider: mousedown, define and draw a circle centred at mouse position, set a flag for active drawing; mousemoved, redraw circle so that mouse position is on rim; mouseup, reset flag.

You could plot points as markers and allow the markers to be dragged for refining their positions. GraphWaveEdit can be helpful here: the UI for adjusting the points is provided, but comes with limitations. For an example of using GraphWaveEdit for interactively adjusting point positions, take a look at the spline drawing part of the baselines project.

I have also played around with using GraphWaveDraw to allow a user to draw a region of interest. The trick there was to create a panel with continue/cancel buttons, set a window hook to catch mouseup at end of GraphWaveDraw and bring panel to front, start GraphWaveDraw, then set pauseforuser and wait for the panel to be killed, then remove window hook.

I would say that Igor absolutely is designed for that level of interactivity, and the time investment for getting up to speed with UI design is not too bad compared with other options.

Here is an example I played with. It's just meant as an idea of what you can do.

If you run the MyCraters() function, it creates a fake image of some craters. In the left image where some of the craters are already colored, you can color more craters by clicking with the mouse anywhere in the image. Move the mouse and click again to indicate the size of the circle to be colored. The size of the circle will be updated as you move the mouse around in the image.

Updating the image on the fly as you move the mouse is a little dangerous because it can get very slow, but it seems to work OK here.

Wow! Thanks for all the suggestions.  It'll take me awhile to wade through them, though it's nice to see that there are a couple different options.  Other than it actually working, my main issue is it being fast.  If it's not faster than my current workflow, I won't use it, since I'm doing literally hundreds of thousands of these so a half-second extra per crater propagates to over a hundred hours extra time in the long-run.

As an example of a simple UI thing to speed stuff up, for the "UserDecides()" function I wrote where I grade the AI-based craters as true or false positives, it's pre-seeded with a "1" so I can just press the Enter key if it's a real feature; otherwise, type 0 and press Enter.  One less keystroke saves time!  And my AI-based initial pass is good enough that about 91–93% are true positives, so that's a lot fewer "1"s to type.

Technically, you shouldn't need the "enter". You could set it up so you only need to press "0" or "1" and automatically advance to the next crater.

How does your workflow work? Do you have a very large image with a slightly oversensitive AI so you are sure all craters are identified. Then all you have to do is weed out the 7-9% false positives? How does that work, do you get a small cropped image around each crater you cycle through and hit "0" or "1" for each image?

olelytken wrote:

Technically, you shouldn't need the "enter". You could set it up so you only need to press "0" or "1" and automatically advance to the next crater.

How does your workflow work? Do you have a very large image with a slightly oversensitive AI so you are sure all craters are identified. Then all you have to do is weed out the 7-9% false positives? How does that work, do you get a small cropped image around each crater you cycle through and hit "0" or "1" for each image?

I also allow a "-1" to go back if I went too quickly, so waiting for a single keystroke might not be best.

The AI is under-sensitive since I'd rather it get low-hanging fruit easily than struggle to get harder stuff and have a lot more false positives.  If I can speed up half of my crater mapping by 5x, then that's still a lot of savings.  The images I'm using are enormous mosaics (~260 GB in the equatorial region of Mars, ~340 GB for mid latitudes, each covering about 3% of the planet) that I've chopped into 600 parts with small overlaps that are each around 250 MB.  There is a bit of lag in Igor drawing/zooming to each new area because each snip is so large, but it's maybe half a second so noticeable but not horrible, and I have it also display the "upcoming" crater so my eye can already make a decision on that one while the UI is updating the main window.  Main feature in the attachment is on the left, upcoming on the right.

But, just to be clear, that's the "phase one" of this effort.  "Phase two" is the one where I go in and click and then I want the AI to use that as the seed for where to look, which is the subject of this post.  Just wanted to clarify since the screenshot is WAY zoomed in compared to what Phase 2 would be for the main UI window.

P.S. Related side-question for which I'll open up a different thread if the answer is at all "yes," does Igor offer any sort of built-in machine learning?  I haven't seen it but that doesn't mean it's not there, and I'm not good enough with Python to try ML in that.

As you can see in my code you can get the position of the mouse click with a combination of AxisValFromPixel, s.mouseLoc.h and s.mouseLoc.v.

For browsing your craters you could make 3 buttons "Previous", "Next" and a "Accept/Reject" toggle, and bind each button to a key, for instance page up, page down and spacebar.

If you want to speed up the process, you could display the craters as a 5 x 5 grind showing 25 craters at a time. A single mouse click on each of the 1-3 bad craters would toggle them off/on and page down would load the next 25 craters. It all depends on how good your resolution has to be to accept or reject a crater.

Reducing the resolution may also make your images load faster. Depending on exactly how you write your code you can get very large differences in speed when you are working with such large images.

So, first off, thanks all for the suggestions and ideas on how to tackle this.  Wish I asked earlier!

With all the suggestions, I opted to start from the bottom first with @olelytken's code block.  I spent three hours cannibalizing and integrating much of it last night (okay, one hour was a stupid bug on my part) and it seems to be working extremely well.  I've also integrated the keyboard listener for delete to delete the last mark, arrows to scroll across the image since even these 1/600th snippets are too large to display at once (~11.5k pixels on a side), and "n" to load up the next image.  I would actually say at this point that it's doing what I want and I'm satisfied to the point I don't need to try other solutions.

That said, I want to respond to others:

@tony: Yup, the hook function works well.  It's something I've never experimented with (didn't know about, either), so it's like when I discovered multi-threading for the first time and it completely changed my world.  Regarding refining positions/points, I don't want to get quite that far unless/until there's a machine-learning component for it to learn from.  While I'm one of the only people in my field who cares about the actual rim trace/shape as opposed to just a latitude/longitude/diameter for cataloging purposes, it would take way too long to do it manually so I wold only do it to train an AI.

@johnweeks:  Right, but if you don't know all the intricacies of what can be done and the kind of interactivity Igor offers, it's hard to think about how to use that.  Going back to when I had to learn that horrid language IDL, it was a situation of you have to know what you don't know in order to search for it to learn how to do it but if you already know it then you don't need to search for it.  Regarding helping me before, I've definitely posted here before for other crater work and your particle analyzer rings a bell, but it just won't work for complicated situations like this (and that would have been for a different project since I only started this about a year ago and haven't posted to the Igor forums in that time).  There is a reason why every planetary science conference for decades has someone(s) new showing off their latest AI crater detection code and then they disappear and no one in the field uses it: Despite seeming to be simple circles, craters and the terrain they're on is complicated!  The basics behind my "low-hanging-fruit" AI is a simple circular Hough transform with some post-processing to reject most false positives (and, of course, some true positives fall into that mix).

@thomas_braun: That's sort of what I was doing with the draw tools, but it was just slow and clunky.

@aclight: Thanks.  I'll just say that based on trying the hook function, I'm going with that!  The more "true" alert box I'd like to stay away from simply because it's really fast for me to type 0/1 on the numeric keypad, or -1 to go back a crater if needed.

Remaining Questions [related but unrelated to this exact problem]:

• Is Igor Pro 9 optimized for Apple's M# chips?  If not, I will probably skip this version until it is, since that will almost certainly be a faster speed increase for me.
• Does Igor have any back-end for machine learning?  That's the next step in this but I don't know enough Python to try there and love the interactivity of Igor more.