PictureSnapApp version 1.8.8

[neko]

WOOOOOOOOOOOO

It works! With Cameca! Folks are gonna be so happy to not have to stab around in the dark anymore! I mean, with 7 years of practice like me you can hit exact grains a lot of the time but that's not a skill anyone should need. And now I can accurately target the smallest of grains without effort.

My only feature request would maybe be a way to to modify the text overlay slightly (black outlined in white or yellow, or maybe a transparent background highlight or something) just to make it slightly easier to read on complex, light colored thin sections (like, on top of unpolarized plagioclase grains that are next to voids, which I was recently working on) - but I mean, I can live happily forever without that; and if it's that necessary I'll figure out how to do it in MatLab.

Cheers,
Nick
P.S. WOOOOOOOOOO

[Probeman]

Hi Nick,
Cool.

I too used to try and guess for specific grains in a mount (when it actually worked I'd say to myself "nice shootin' Tex!"), but since we've had PictureSnap (in Probe for EPMA) and now the standalone PictureSnapApp on our EPMA, FIBs and SEMs, we are no longer "shooting in the dark"!   

On your suggestion about the annotation text color, I'm sure John(!) can easily do something like that.  In the meantime, simply use the Display menu and click the Use Black Scale Bar and Annotations menu:



So use the white (default) color for dark colored images, the black color for light colored images, and for in between colored images, I guess use either color!   

For your own edification, note that annotations are stored in an ASCII file with a name the same as the image, but with the extension .ACQ. It's basically a normal INI file format with a different extension. The coordinates for the point and FOV annotations are always in native stage coordinates...

[neko]

Thanks Probeman! I saw that when I first used the program and totally forgot. That'll help for the time being, we can just switch back and forth when it's one of those sections with dark/light areas.

We tried using this upstairs with one of the laser ablation stages. It almost worked in text mode buuuuuuuuut (and, I stress, this is really dumb) it's half anti-cartesian.

As in, the X-axis runs in the normal cartesian plane, but the Y axis runs anti-cartesian. (+/+ in the lower right, -/- in the top left).

"We changed things up to differentiate ourselves from the competition!"

"Does it work better?"

"Worse, actually. But it's different!"

Dunno if that's a problem you've run into yet, but I thought you'd be interested in this oddity. We tried reversing the stage limits in PSA but... yeah, that didn't work, as expected. If you're planning on making this a laser ablation stage program you might run into this issue in the future, or maybe not, we might have the only one. I'm predisposed to finding everything weird and unusual in the world.

If you are interested, I can get more information on the stage/program makers, but... it's not a priority for us, the laser actually has quite a nice built in optical mosaic program that uses the snake pattern to save travel time, and you can see the section with the naked eye to help orient yourself.

[John Donovan]

We tried using this upstairs with one of the laser ablation stages. It almost worked in text mode buuuuuuuuut (and, I stress, this is really dumb) it's half anti-cartesian.

As in, the X-axis runs in the normal cartesian plane, but the Y axis runs anti-cartesian. (+/+ in the lower right, -/- in the top left).

"We changed things up to differentiate ourselves from the competition!"

"Does it work better?"

"Worse, actually. But it's different!"

Dunno if that's a problem you've run into yet, but I thought you'd be interested in this oddity. We tried reversing the stage limits in PSA but... yeah, that didn't work, as expected. If you're planning on making this a laser ablation stage program you might run into this issue in the future, or maybe not, we might have the only one. I'm predisposed to finding everything weird and unusual in the world.

If you are interested, I can get more information on the stage/program makers, but... it's not a priority for us, the laser actually has quite a nice built in optical mosaic program that uses the snake pattern to save travel time, and you can see the section with the naked eye to help orient yourself.

Oh god...  who was it that said the perversity of the universe tends to a maximum? 

This "half anti-cartesian" stage orientation was also the case for the first microprobe I ever used, an ARL SEMQ.  On that instrument, the explanation for the reversed Y axis was simple: they used an inverting microscope optics (as in a petrographic optical microscope), so it sorta-kinda made a little sense.

But then just to be different, they used stage units of 0.1 mm!       What the heck is a hundredth of a meter?  I called them humimeters. As in hundred micron units. So now you know!   And you'll never be able to forget either.   

Just so you know, I do have the X and Y polarities specified separately in the code, so in theory it's possible that PictureSnapApp could handle this "half-anti-cartesian" (or is it half cartesian?) situation.  In practice?  Maybe someday.  Also, if you look at the .ACQ file in a text editor, you'll notice that the X and Y stage "polarities" are specified separately, so we've left this option open for future development. 

Right now we're deep into implementing a new feature in PictureSnapApp that will make it like a lab notebook for images.  Possibly after this is implemented I will look into messing with these oddball stage cases.

But I would be interested in knowing if there are any other instruments that have these, let's called them "half cartesian", stages...

[John Donovan]

I'll answer my own question:

https://en.wikipedia.org/wiki/Finagle%27s_law

I probably read it in one of Larry Niven's novels, most likely one of his Ring World series novels. And if you haven't, you should.

Here's the part of the Wiki page I enjoyed the most:

A related concept, the "Finagle factor", is an ad hoc multiplicative or additive term in an equation, which can only be justified by the fact that it gives more correct results.

And who's to say that we are correct, and the optical microscope is wrong?     

[neko]

I'll answer my own question:

https://en.wikipedia.org/wiki/Finagle%27s_law

I probably read it in one of Larry Niven's novels, most likely one of his Ring World series novels. And if you haven't, you should.

Here's the part of the Wiki page I enjoyed the most:

A related concept, the "Finagle factor", is an ad hoc multiplicative or additive term in an equation, which can only be justified by the fact that it gives more correct results.

And who's to say that we are correct, and the optical microscope is wrong?     

Maybe they microscope they're using is inverted, but why on earth people don't just click the "invert * axis" button in the framegrabber software is well beyond my ken. Even the cheap software included with my $50 usb microscope could do that.

No one is worried that it doesn't work - I thought you would enjoy a good laugh, but it turns out I just surfaced youthful nightmares for you Just having features annotated on a printout helps enough with their system.

Finagle Factor really sounds like what Einstein thought the universal constant was (which he spent his later years fruitlessly attempting to disprove). Turns out he was so smart, he was wrong about being wrong, and he had accidentally discovered what we now refer to as dark energy.

Humimeter? Why not HectoMicron, as in why the hecto you do this? Was the stage accurate to the centihumimeters range?

[John Donovan]

Hi Nick,
Well I woke up this morning thinking of an easy way to do all this transformation stuff "on the fly"!

So now PictureSnapApp supports cartesian, anti-cartesian and now "half-cartesian" stages!   



I also modified the transformation menu dialog to support transforming images from and to different units and stage orientations (I've been a busy bee) as seen here:



But the best part is that I modified the open image file code so that PictureSnapApp now *automatically* detects the stage units and orientation of the image being loaded, and then converts it to the current PictureSnapApp stage units and orientation.  So the above transform dialog isn't really necessary any longer, but I left it there just in case someone can find a use for it.  This new auto-detect code should make it essentially effortless to move your images and annotations from one instrument to another.

And of course PictureSnapApp also converts all the point and FOV annotations to the new stage units and orientations, but remember you'll still need to re-calibrate the image to the new stage coordinates, even if no unit or orientation conversions were necessary. That is to say, just because two instrument stages have the same units and orientation, that doesn't mean that the sample was mounted exactly the same in both instruments. 

Of course, re-calibrating the image is also required if you remove the sample from the sample holder, and then remount it in the same instrument. Although in this case the image calibration will probably be very close to the saved calibration making it really easy to do (unless you mounted the sample in a different place in your sample holder).  But this is all normal and expected.

This new version also supports nm (nanometer) units (I'm thinking of TEMs, but maybe they all use mm and um units?).   Anyway, nm are now supported.

When you install this new version, it might force you to re-specify the stage parameters.  I don't think it will but I had to modify the installer slightly so it's possible.  Anyway, I will be very interested to see what you think of the recent changes... just update from the Help menu and all should be good to go.

Oh, I should also mention that if the software detects that it needs to transform the stage units and/or orientation, it automatically appends some text on the image name to make it clear what things were modified.  For example if the image was converted to um, it appends a "_to_um" to the original image file name.  In a similar manner, if the stage orientation was converted from cartesian orientation to anti-cartesian orientation, it would also append a "_to_anti-cartesian" string to the original image file name.  That way the original image is not modified.

[neko]

It works! I'm pleased to report it even handles 0 correctly for stage limits. This stage is weird, it's 0-50mm in both directions. But as you said, the image opened up, converted itself properly, and after we figured out what we were looking at, calibrate correctly and even in text mode with not so great scans, is within 50-100um of where it should be. We didn't calibrate that carefully, and we're also using a second computer and typing the coordinates in by hand. but hey, it works as advertised!

Next up: the ability to draw a box and have it auto-calculate your xmap/mosaic settings for you (just kidding, but this will help us figure out crystal extents more quickly with polarized optical scans).

In fact, this app is going to be *really* handy on those few rare folk who have basalt and plag that you can barely distinguish separately - using high gain BE mode helps, but a scan that shows crystal orientation & glass extinguishing via polarization will probably be way better. I just take a look at the samples and tell the poor researchers "good luck!"

[John Donovan]

We added the keyboard and mouse annotation documentation to the Stage Config dialog, and also it will pop up after you click the Calibrate button in the Window | Calibrate Image To Stage Coordinates menu window (the first time only!).

Here is what it looks like in the Stage Config dialog (which pops up the first time you run PictureSnapApp!).



We also added a feature that allows the user to capture the exact current position by typing <shift> p as seen here:



Of course one can right click anywhere on the image to add a random annotation, but this allows one to capture the current position precisely.

[John Donovan]

Next up: the ability to draw a box and have it auto-calculate your xmap/mosaic settings for you (just kidding, but this will help us figure out crystal extents more quickly with polarized optical scans).

Hi Nick,
We just added a feature tonight that does at least the first half of your request!  It was already in the PictureSnap feature in PFE, so we "just" moved the code over.   

You turn it on/off using a new Misc menu, and here we choose the draw rectangle mode:



Basically it just draws a (red) rectangle between the current position and the last position double-clicked to as seen here:



The blue square is of course the current field of view.

[John Donovan]

We made a separate web page for PictureSnapApp:

http://probesoftware.com/PictureSnapApp.html

[neko]

We just added a feature tonight that does at least the first half of your request!  It was already in the PictureSnap feature in PFE, so we "just" moved the code over.   

"just"  I've coded relatively little but dang, even on the simple, fun things I've done there's not "just" in programming.

I have an excel sheet with all the necessary calculations baked to calculate the mosaic center and number of cells (both for square xmaps and 3/4 height video scan maps, once I realized why they were coming out weird) in the X and Y directions, as well as just the number of cells you can expect from the map. It does this based on the FOV you input however, and due to that extends outside the nominal limits of the area.

The only inputs needed are X1, X2, Y1 and Y2 (negative, positive and the order they're specified in don't matter as long as you have the right axis) and FOV - I built the sheet as I was using it and ideas came to me, so it's not so well organized but it gets the job done way better than guessing. Xc and Yc are the center points of the mosaic, Width X/Y are the dimensions based on the input coordinates, "cells wide" is however many cells are needed in the X direction to cover at least the area of the mosaic, "Cells Tall Xmap" is how many in the Y direction are needed for square cells, and "Cells Tall Video" is how many cells are needed when you're doing image capture mosaics, to compensate for the 4/3 ratio of video scan acquisition. The numbers are all rounded to whole numbers for easy of copy/paste into programs that don't take floating points, all units in microns except for the cells.

Julian built something similar in his De-MA, but that only does single cell maps as far as I can tell; my spreadsheet can do that and also calculate your mosaic values. It doesn't tell you how long things will take, but I figured that wasn't a big deal as Peaksight tells you (inaccurately) how long it'll take.

Feel free to rob my IP blind if you find it useful - I'm sure there's a better way to do it, but as I said, this gets the job done, and it's really nice when you don't accidentally run maps that don't acquire the whole area or are offset. hashtag peaksight4probs

[John Donovan]

I have an excel sheet with all the necessary calculations baked to calculate the mosaic center and number of cells (both for square xmaps and 3/4 height video scan maps, once I realized why they were coming out weird) in the X and Y directions, as well as just the number of cells you can expect from the map. It does this based on the FOV you input however, and due to that extends outside the nominal limits of the area.

Hi Nick,
Nice.  I appreciate what you've done.  My mosaic efforts are here:

http://probesoftware.com/smf/index.php?topic=324.msg6078#msg6078

for creating stage/beam mosaics using an analog signal (BSE, SE, etc.) in our Stage app.  We also have a % overlap parameter which is nice for eliminating gaps when your beam to stage and/or scan rotation calibration isn't perfect.

[neko]

Hi Nick,
Nice.  I appreciate what you've done.  My mosaic efforts are here:

http://probesoftware.com/smf/index.php?topic=324.msg6078#msg6078

for creating stage/beam mosaics using an analog signal (BSE, SE, etc.) in our Stage app.  We also have a % overlap parameter which is nice for eliminating gaps when your beam to stage and/or scan rotation calibration isn't perfect.

That's great to know, and exactly solves every problem I currently have with mapping (which I kinda assumed you'd already have solved). Now to just convince people that these problems should be fixed...

[John Donovan]

Dang, this was harder than I thought it would be but we added the ability to rotate an image +/- 90 or 180 degrees to deal with samples mounted in different orientations in different instruments.  Or perhaps you loaded the sample in the same instrument, but upside down, as is sometimes the case!

To utilize this feature please update to the latest PictureSnapApp from the Help menu, then click on the Transform | Rotate Image/Stage Orientation menu as seen here:



Then use the Select button to load an image, and then click one of the Rotate buttons to rotate the image appropriately.



When you click the OK button the app will save the rotated image and also rotate the screen calibration coordinates. Here is an example of the original thin section and the two screen calibration points:



And here is the image rotated 90 degrees clockwise:



Please note that the stage calibration coordinates will not be modified, but since you'll have to re-calibrate the image to the new stage, that really doesn't matter.  But at least the location of the original calibration points will be preserved, though of course one can choose different calibration points if they prefer.