Might be a good idea to have a list of wishes for PI as we have for PfE ;)
I will start:
Could we have in the event log the date as well as the time for acquired images? It would be useful to know how long it was running, say over a weekend.
Quote from: Gareth D Hatton on April 23, 2014, 05:07:33 AM
Might be a good idea to have a list of wishes for PI as we have for PfE ;)
I will start:
Could we have in the event log the date as well as the time for acquired images? It would be useful to know how long it was running, say over a weekend.
Hi Gareth,
I think this is an excellent idea. :-*
You already have access to our Mantis bug reporting site, and as you know, we've been using that for new features, but that site isn't accessible to all, so this will be very helpful I think. In fact, I'll make it sticky.
As for your specific request, just FYI, this before and after date-time information is already stored in the ProbeImage .PrbImg files, but it makes sense to me to have it in the Conditions tab as you suggest, maybe along with a total acquisition time field for the "subtraction".
Here is the date-time info in one PrbImg file (along with the before and after beam current):
[Measured/BeamCurrent]
Start=9.995e-009
End=9.999e-009
[Measured/Time]
Start=2013-12-03T14:53:10
End=2013-12-03T15:02:13
I would like to have PI doing a stage backlash when it is going to a new map position, just like PfE also does.
Quote from: Philipp Poeml on November 13, 2015, 01:18:57 AM
I would like to have PI doing a stage backlash when it is going to a new map position, just like PfE also does.
We could do that. Or you could get your stage properly repaired as we've been telling you for over a year now...
Please stop blaming the software for your stage problems. I know we are a very responsive company, but we sell software, not hardware!
Please note that there are zero errors in the PI log file you sent us. You do know that once we start a scan on the instrument, we no longer control the instrument, we just store the data returned? That is all we can do; that or halt the scan.
If the instrument firmware macro stops moving the stage or the beam during a scan and doesn't send back any errors, what exactly are we supposed to do?
In the meantime I will add a request for a stage backlash in Probe Image. It's a good idea, though not needed for JEOL instruments that have a firmware backlash and Cameca stages equipped with linear encoders.
John, I am not talking about stage problems here and that your software does not work, I was just asking for this. The thread is called: "Wish list for PI features". So, I just put a line in, a simple wish.
Quote from: Philipp Poeml on November 13, 2015, 09:09:00 AM
John, I am not talking about stage problems here and that your software does not work, I was just asking for this. The thread is called: "Wish list for PI features". So, I just put a line in, a simple wish.
I am pleased to hear that the software is running well. I am working this weekend on a new feature in PFE that I am calling a "Stage Reproducibility Correction". It is similar to what Cameca and JEOL do in their "stage drift correction" features, in that in PFE the user will acquire an image, and then digitize points on it using the mouse. Then during automation, after the software drives to the stage position of the digitized area and just before the "Use Beam Deflection for Acquisition" begins, the software takes another image using the same scan parameters as previously, compares that to the original image used for digitizing the points, and calculates the amount the stage is off by, and adjusts the column image shift to compensate.
I added your stage backlash wish to the PI request list.
Just for my own curiosity, if one does not perform a stage backlash correction on your SX100R stage (which is apparently very heavy and does not have linear encoders), roughly how much is the stage off from the intended stage position? On average?
I'd like to see an easier way/interface to import a 2nd or 3rd set of elements for a 6+ element map. There does not appear to be an easy way to set this up currently. Using PFE to move to a new element peak position in the MOVE window results in default peak settings, NOT the peaked element position. Is there an easier way than typing in the peak and pha settings for a second set OR creating a whole new unknown setup in PFE?
-Dan
Quote from: Dan Ruscitto on February 01, 2016, 07:54:29 AM
I'd like to see an easier way/interface to import a 2nd or 3rd set of elements for a 6+ element map. There does not appear to be an easy way to set this up currently. Using PFE to move to a new element peak position in the MOVE window results in default peak settings, NOT the peaked element position. Is there an easier way than typing in the peak and pha settings for a second set OR creating a whole new unknown setup in PFE?
-Dan
Hi Dan,
Not a problem. See this post from Karsten Goemann (about halfway down):
http://smf.probesoftware.com/index.php?topic=141.msg570#msg570
QuoteIn PFE, create a new unknown sample and load the Sample Setup for the second five elements. Again go to Acquire! | Peaking Options and click "Move To On Peak (start analysis) Positions". Wait until the move is completed then click "Read ELM" again for the WDS channels in Probe Image
The above method works for the first element on each spectrometer. For subsequent order elements, use the same dialog (from the Probe for EPMA Acquire! Peaking Options button), and follow the steps shown below to select the spectrometer order or simply <ctrl> click the elements for custom selections and then click the Move Selected Elements To On-Peak Positions button
(https://smf.probesoftware.com/oldpics/i63.tinypic.com/opqkav.jpg)
I would like to be able to ONLY acquire off peak maps.
I usually run MAPS with MAN anyway (before you ask) but I had now a situation where making the maps was an afterthought and then for the necessary interference corrections to be applied I realized I also needed background maps. So for future moments of poorly thought out workflow, being able to add off peak maps to the mix after the peak maps have been already acquired would be great.
Thanks!
Quote from: Anette von der Handt on March 08, 2016, 12:59:01 PM
I would like to be able to ONLY acquire off peak maps.
I usually run MAPS with MAN anyway (before you ask) but I had now a situation where making the maps was an afterthought and then for the necessary interference corrections to be applied I realized I also needed background maps. So for future moments of poorly thought out workflow, being able to add off peak maps to the mix after the peak maps have been already acquired would be great.
Hey, we can deal with who-man error! ;)
I would just set the on-peak acquisition time for a minimum dwell time per pixel and acquire the off-peak maps for the desired off-peak dwell time. Note that you will need to delete the new (low precision) on-peak maps and rename the off-peak maps to match the acquisition numbers of your original on-peak maps before loading them into CalcImage for quant.
Hi,
would it be possible to add a feature to PictureSnap to define and evaluate map dimensions in ProbeImage? For large maps, it can be a little bit trial and error when figuring out the absolute positions, dimensions and dwell times for a map and their costs/benefit.
I understand that there is already the two point set-up option in ProbeImage and so it is not really a pressing need. However I could see it being a very nice visual feature in aiding setting up X-ray maps (and I think the other programs don't offer a comparable feature but I may be wrong here).
What I envision is a dialog very similar to the "calibrate image" dialog in picture snap that can be launched out of ProbeImage. We can load in a calibrated SE/BSE image of the to-be-mapped region and either
(1) draw an area (square/rectangle) on the image by hand. The dialog would then give the center point of this area plus either the #pixels or pixel sizes (comparable to the traverse options dialog). Maybe also the calculated acquisition times if a dwell time is defined
and/or
2) I define a center point for my map. Depending on the entered pixels and pixel sizes, the mapped area will be shown on the image. Again bonus points if the total time for map acquisitions is shown.
A feature like this would have the added benefit that it make offline strategic planning of overnight maps easier (when I already have calibrated images from a previous PFE run and just want to see how long maps would run me).
Thanks for listening :)
Anette
Quote from: Anette von der Handt on September 19, 2016, 04:22:03 PM
would it be possible to add a feature to PictureSnap to define and evaluate map dimensions in ProbeImage? For large maps, it can be a little bit trial and error when figuring out the absolute positions, dimensions and dwell times for a map and their costs/benefit.
Hi Anette,
I think this is a great idea and I think I can do this by adding a dialog in PictureSnap that loops on a read of the current acquisition setup in Probe Image. I'll have to have Brian add a timer event that triggers a save of the current acquisition setup to a static name such as ProbeImage.acq or something, and then this new "Mapping Assistant" (or whatever we call it) in PictureSnap, reads that file and displays the current mapping setups currently loaded in Probe Image.
It's a bit of work, so let me think about it a little more, but I think it's entirely doable (and a great idea!).
john
Hi John,
I have a suggestion - when you click ok on the message that says the maps are complete -
at present it drives to the map (presumably the center)
In my experience of using it - I would would prefer it not to drive anywhere. For often I don't click ok until I'm half way through a different job in PFE and it catches me out by moving the stage
Thanks
Ben
ps I'm really liking probe image now - last week i was setting up batches of 9 maps and the Read XYZ and read z for each of the corners is very easy to use.
One thing I did wonder - but this would be complex and for the future. Sometimes when putting in the coordinates for a map and running the map 20 hours later - i.e. for the 9th map the z has gone slightly out of focus presumably as the vacuum has improved. I wondered if we could do something clever with the autofocus. So when it drives to a sample - there is a position which it autofocuses on and corrects all the corners by the same amount. The complexity is this would not be the center - as when the corners are set the center is not always in sharp focus. Nor would it always be the same corner - for if you have a step from the sample onto expoxy - and you have set the focus for the sample height - when it drove to the corner it would autofocus on the expoxy. I'm not sure it's worth doing - it would only be worth doing for quant mapping and I have not checked the effect on totals - is it significant - I guess that's the thing to check - how much it has to be out of focus to be a problem.
Quote from: Ben Buse on January 29, 2017, 02:20:54 AM
I have a suggestion - when you click ok on the message that says the maps are complete - at present it drives to the map (presumably the center)
In my experience of using it - I would would prefer it not to drive anywhere. For often I don't click ok until I'm half way through a different job in PFE and it catches me out by moving the stage
Hi Ben,
Note that the position PI drives to after mapping is complete, is wherever the stage was when you started the automated map acquisitions. So one solution would be to put up the modal dialog (that the maps are complete), *after* it moves the stage back to this start position?
Quote from: Ben Buse on January 29, 2017, 02:20:54 AM
ps I'm really liking probe image now - last week i was setting up batches of 9 maps and the Read XYZ and read z for each of the corners is very easy to use.
One thing I did wonder - but this would be complex and for the future. Sometimes when putting in the coordinates for a map and running the map 20 hours later - i.e. for the 9th map the z has gone slightly out of focus presumably as the vacuum has improved. I wondered if we could do something clever with the autofocus. So when it drives to a sample - there is a position which it autofocuses on and corrects all the corners by the same amount. The complexity is this would not be the center - as when the corners are set the center is not always in sharp focus. Nor would it always be the same corner - for if you have a step from the sample onto expoxy - and you have set the focus for the sample height - when it drove to the corner it would autofocus on the expoxy. I'm not sure it's worth doing - it would only be worth doing for quant mapping and I have not checked the effect on totals - is it significant - I guess that's the thing to check - how much it has to be out of focus to be a problem.
Would it be ok, to have an option for PI to perform an autofocus on each map, just before it starts the map acquisition? Perhaps it should just utilize the center of the map for this optional auto-focus? In other words, (if an auto-focus option is specified), drive to the center of the current automated map, based on a fit to the corner Z positions, perform the auto-focus, then adjust the corner Z positions based on the auto-focus offset, then start the map acquisition using the newly adjusted corner positions. How does that sound?
john
Hi John,
Quote from: John Donovan on January 29, 2017, 09:04:29 AM
Note that the position PI drives to after mapping is complete, is wherever the stage was when you started the automated map acquisitions. So one solution would be to put up the modal dialog (that the maps are complete), *after* it moves the stage back to this start position?
Yes that would work well.
Quote from: John Donovan on January 29, 2017, 09:04:29 AM
Would it be ok, to have an option for PI to perform an autofocus on each map, just before it starts the map acquisition? Perhaps it should just utilize the center of the map for this optional auto-focus? In other words, (if an auto-focus option is specified), drive to the center of the current automated map, based on a fit to the corner Z positions, perform the auto-focus, then adjust the corner Z positions based on the auto-focus offset, then start the map acquisition using the newly adjusted corner positions. How does that sound?
john
I don't think this would work - because sometimes when the corners are in focus - the center is not in focus - it could be on a spot of epoxy. I'm not sure how important this is - I need to check on acquired data to see the effect on intensity of it being slightly out of focus
Thanks
Ben
Quote from: John Donovan on January 29, 2017, 09:04:29 AM
Would it be ok, to have an option for PI to perform an autofocus on each map, just before it starts the map acquisition? Perhaps it should just utilize the center of the map for this optional auto-focus? In other words, (if an auto-focus option is specified), drive to the center of the current automated map, based on a fit to the corner Z positions, perform the auto-focus, then adjust the corner Z positions based on the auto-focus offset, then start the map acquisition using the newly adjusted corner positions. How does that sound?
john
Quote from: Ben Buse on January 30, 2017, 01:35:33 AM
I don't think this would work - because sometimes when the corners are in focus - the center is not in focus - it could be on a spot of epoxy. I'm not sure how important this is - I need to check on acquired data to see the effect on intensity of it being slightly out of focus
Ah, yes, OK.
Intensity loss as a function of stage Z has been documented previously by many investigators- including yours truly. Here's an excerpt from an old study I did many years ago at UC Berkeley:
(https://smf.probesoftware.com/gallery/1_30_01_17_8_16_02.png)
We should try to minimize the Z focus error to get the most quantitative results. This would be another advantage to synchronized WDS and EDS stage mapping. That is, major elements, which are most sensitive to Bragg defocusing effects (because of their high precision), could be performed using EDS which doesn't have these defocus effects, while trace elements could be done using WDS. Since the precision of trace elements is significantly lower, these defocus effects would be less evident.
One other idea I had is that along with an optional auto-focus checkbox, we could designate a particular stage position as the "auto focus position". Then when the auto-focus is performed, the resulting correction is applied to all 4 corners before the scan is started.
john
Quote from: John Donovan on January 30, 2017, 08:27:40 AM
One other idea I had is that along with an optional auto-focus checkbox, we could designate a particular stage position as the "auto focus position". Then when the auto-focus is performed, the resulting correction is applied to all 4 corners before the scan is started.
john
That is a very good idea.
Ben
Quote from: Ben Buse on January 31, 2017, 06:56:44 AM
Quote from: John Donovan on January 30, 2017, 08:27:40 AM
One other idea I had is that along with an optional auto-focus checkbox, we could designate a particular stage position as the "auto focus position". Then when the auto-focus is performed, the resulting correction is applied to all 4 corners before the scan is started.
john
That is a very good idea.
Ben
Or another option would be to simply add an auto-focus checkbox and another control for the user to specify which of the 4 corner positions is the "auto-focus position". The adjustment would then be based on that Z position offset.
john
Quote from: John Donovan on January 31, 2017, 07:58:20 AM
Or another option would be to simply add an auto-focus checkbox and another control for the user to specify which of the 4 corner positions is the "auto-focus position". The adjustment would then be based on that Z position offset.
john
Yes that would work well - specifying which ever of the 4 corners to use. Allowing user to avoid those corners which step off the material of interest. And not requiring an additional position
Ben
Quote from: Ben Buse on February 02, 2017, 12:56:53 PM
Quote from: John Donovan on January 31, 2017, 07:58:20 AM
Or another option would be to simply add an auto-focus checkbox and another control for the user to specify which of the 4 corner positions is the "auto-focus position". The adjustment would then be based on that Z position offset.
john
Yes that would work well - specifying which ever of the 4 corners to use. Allowing user to avoid those corners which step off the material of interest. And not requiring an additional position
Ben
I'll see if Brian can add this auto-focus option to PI. It should be relatively easy to implement for the Cameca and 8230/8530 instruments which have integrated auto-focus systems.
john
Hi,
I have another suggestion - if its easy to do - for the list of samples (where you have multiple maps) - a clear list button
Thanks
Ben
I'm sure I'm not alone in wanting to set up multi-run maps (i.e. more elements than spectrometers) on multiple samples. This would be soooo much easier if it was possible to copy more than one set of spectrometer settings at a time and/or if their order in the list could be re-arranged. Any chance of this being added? Pleeeease ::)
Quote from: Mike Matthews on July 24, 2018, 11:10:20 AM
I'm sure I'm not alone in wanting to set up multi-run maps (i.e. more elements than spectrometers) on multiple samples. This would be soooo much easier if it was possible to copy more than one set of spectrometer settings at a time and/or if their order in the list could be re-arranged. Any chance of this being added? Pleeeease ::)
Hi Mike,
Yes, we do need to improve the sample list options in Probe Image. One thing we are thinking of is adding a button so the user can copy or duplicate a set of samples which could then be assigned to a different stage position.
Also adding a button to move a set of samples to change their acquisition order is also a good idea. I will speak to Brian about this.
john
Hi John,
my new JEOL software on the 8530F+ now supports maps up to the size of 5120 to 5120 pixel while my maximum map size in PI is capped at 2096 x 2096 pixel. Is this larger map size already on your radar (as you don't have a JEOL) and planned to be implemented in PI?
The mapping specifications for my software are
Number of measurement points:
Stage scan: 8 x 8 to 5120 to 5120
Beam scan: 22 x 16 to 5120 to 3840 (Aspect ratio 4:3) and 16 x 16 to 5120 to 5120 (Aspect ratio 1:1)
X-ray measurement time per pixel:
Stage scan: 2 to 100 000 ms
Beam scan: 0.1 to 100 000 ms
Thanks!
Quote from: Anette von der Handt on September 24, 2018, 12:08:38 PM
my new JEOL software on the 8530F+ now supports maps up to the size of 5120 to 5120 pixel while my maximum map size in PI is capped at 2096 x 2096 pixel. Is this larger map size already on your radar (as you don't have a JEOL) and planned to be implemented in PI?
The mapping specifications for my software are
Number of measurement points:
Stage scan: 8 x 8 to 5120 to 5120
Beam scan: 22 x 16 to 5120 to 3840 (Aspect ratio 4:3) and 16 x 16 to 5120 to 5120 (Aspect ratio 1:1)
X-ray measurement time per pixel:
Stage scan: 2 to 100 000 ms
Beam scan: 0.1 to 100 000 ms
Hi Anette,
We could certainly do that. In the meantime you can use the conversion app in Probe Image to convert the large maps for subsequent quantification in CalcImage.
john
John, absolutely. The conversion app is great. I just really, really prefer to work with PI ;)
I think it would be pretty cool if PI could utilize the 'bidirectional scan' stage mapping mode that I just learned about in my JEOL UNIX software! It might not make much of a difference for normal mapping, but it would probably make the maps that I run at essentially the carriage return speed even faster! Probably almost twice as fast.
Quote from: orlandin on November 25, 2019, 02:16:19 PM
I think it would be pretty cool if PI could utilize the 'bidirectional scan' stage mapping mode that I just learned about in my JEOL UNIX software! It might not make much of a difference for normal mapping, but it would probably make the maps that I run at essentially the carriage return speed even faster! Probably almost twice as fast.
This is an older post but I just wanted to mention that I would avoid the bidirectional scan mode in JEOL at all costs if you want nice looking maps. You will get a small offset between the two directions and all grain boundaries and other sharp features will look jagged.
Would it be possible to add a "Total run time" counter to the map setup window? That would be very helpful in keeping track of time when setting up many maps.
Thanks!
Would it be possible to have the map file conversion tool use the original map comment as the folder name?
I still use the JEOL mapping software occasionally, especially for free shape maps. All the JEOL files already only have their map number "01, 02 etc" (how helpful). The converted files all go into a folder called "ProbeImage". Now if the converted files were in a folder using the map comment name, then I would not have to spend hours renaming folders to have a resemblance of organization. Pretty, pretty please?
It is this keyword in the map condition file: $XM_AP_COMMENT%0
Quote from: Anette von der Handt on March 09, 2023, 01:15:47 PM
Would it be possible to have the map file conversion tool use the original map comment as the folder name?
I still use the JEOL mapping software occasionally, especially for free shape maps. All the JEOL files already only have their map number "01, 02 etc" (how helpful). The converted files all go into a folder called "ProbeImage". Now if the converted files were in a folder using the map comment name, then I would not have to spend hours renaming folders to have a resemblance of organization. Pretty, pretty please?
It is this keyword in the map condition file: $XM_AP_COMMENT%0
Yes, it is possible, but we should make sure we get this right. By the way, the folder is named PrbImg, because the files are converted from JEOL format to PrbImg format.
For example, what if the comment is blank? We could just fall back to PrbImg I guess. But if the comment is not blank, then maybe we should actually create subfolders under the PrbImg folder?
Also I note that there is also a sample name meta data, e.g.,
$XM_CP_PROJECT_NAME 2019-04-15_Py_HR_mapping
Should this be used instead, if the comment is blank?
Quote from: John Donovan on March 09, 2023, 04:13:45 PM
Quote from: Anette von der Handt on March 09, 2023, 01:15:47 PM
Would it be possible to have the map file conversion tool use the original map comment as the folder name?
I still use the JEOL mapping software occasionally, especially for free shape maps. All the JEOL files already only have their map number "01, 02 etc" (how helpful). The converted files all go into a folder called "ProbeImage". Now if the converted files were in a folder using the map comment name, then I would not have to spend hours renaming folders to have a resemblance of organization. Pretty, pretty please?
It is this keyword in the map condition file: $XM_AP_COMMENT%0
Yes, it is possible, but we should make sure we get this right. By the way, the folder is named PrbImg, because the files are converted from JEOL format to PrbImg format.
For example, what if the comment is blank? We could just fall back to PrbImg I guess. But if the comment is not blank, then maybe we should actually create subfolders under the PrbImg folder?
Also I note that there is also a sample name meta data, e.g.,
$XM_CP_PROJECT_NAME 2019-04-15_Py_HR_mapping
Should this be used instead, if the comment is blank?
That is to say, how do people utilize these sample name and comment fields when performing x-ray mapping in the JEOL software?
For example, would it make sense to create a sub folder for each converted JEOL map dataset as follows:
..\PrbImg\<sample name>_<comment>
?
So the project name ($XM_CP_PROJECT_NAME) creates a folder under which all the individual map files are stored. Theoretically, someone would be able to use more than one project name through the "serial analysis" function but I am not sure if anyone actually does this. As the JEOL map files are all already in the folder that bears the project name and Probe Image then saves them within each map folder, I don't think that it needs another folder with the project name generated by Probeimage.
The comment name ($XM_AP_COMMENT%0) is what I would want to see associated with my exported map files. I am not sure why anyone would leave this field one empty, especially as the software usually autofills it but I guess it could happen. In that case using the project name might make the most sense but PrbImg would work just as well.
Let me know if a screen shot of the JEOL interface and folder structure would make it easier. Thanks for entertaining my request!
Quote from: John Donovan on February 02, 2017, 12:59:55 PM
Quote from: Ben Buse on February 02, 2017, 12:56:53 PM
Quote from: John Donovan on January 31, 2017, 07:58:20 AM
Or another option would be to simply add an auto-focus checkbox and another control for the user to specify which of the 4 corner positions is the "auto-focus position". The adjustment would then be based on that Z position offset.
john
Yes that would work well - specifying which ever of the 4 corners to use. Allowing user to avoid those corners which step off the material of interest. And not requiring an additional position
Ben
I'll see if Brian can add this auto-focus option to PI. It should be relatively easy to implement for the Cameca and 8230/8530 instruments which have integrated auto-focus systems.
john
Did the autofocus feature ever get added to PI (of PfE for automation)? Would be nice to have an autofocus between map acquisitions. Thanks.
Now that Aurelien Moy is the developer for Probe Image we could certainly add this feature for Cameca and JEOL 8230/8530 instruments (we are still waiting for Japan to provide auto-focus API calls for their latest iSP100/iHP200F instruments).
And rather than base the autofocus position on any particular scan corner it seems reasonable to utilize the center of the corners.
Yup, sounds good. Thanks for looking into this.
Oh, and FYI, Aurelien and Mike Jercinovic got the video imaging interface working for the Cameca SXFive tactis (USB) interface now in Probe for EPMA.
Contact me directly at Probe Software if you're interested in adding this capability to an existing tactis installation.