Hello,

I just wanted to share that Mia will have a platform presentation about ProbeLab ReImager in Symposium A08 at M&M2021. And because one presentation was not enough, he also has another presentation about data handling in general and a different software he is developing to handle, store and export JEOL SXES and wavescan data. So have a look if you are attending the virtual conference:

Symposium: A.08: Data Management, Version Control, and Multiformat Analysis in Electron Microscopy

8/3/2021 A08.1
12:30 PM - 1:30 PM EST: 351 - Probelab ReImager: A Multi-Platform, Open Source Software for Electron
Image and X-ray Map Visualization and Customization

8/3/2021 A08.2
3:00 PM - 4:00 PM EST: 444 - Compression and Access to Arbitrary Data: The Low-hanging Fruit

A quick update on Probe for EPMA remote training. We started our remote training services originally during Covid in 2020, but I have to say that it's been a very positive experience with unanticipated benefits.

In the beginning we felt that this remote training would be difficult, but now after providing dozens of remote training sessions over the last 18 months, and in discussions with our consultants also providing these remote training services, we have to say that in many ways, remote training has some significant benefits to on-site training.

Of course, avoiding travel restrictions is the big advantage to remote training right now, and yes we charge less for remote training since there are no travel expenses to reimburse.

But as for the remote training itself, we find that remote sessions are much more flexible for scheduling, as in the past we've had our consultants show up in a lab where the P-10 gas was empty, or the filament blows just as one is getting started.  Also we've found that shorter 4 or 5 hour sessions are better (less tiring) for everyone as the customer can then practice with the software on their own, and gather questions for the next session. And of course remote training really lowers the carbon footprint of Probe Software!

And in addition, the response from our customers has been very positive, many of them ordering additional training on advanced topics for example such as multi-point backgrounds and quantitative x-ray mapping. Finally we also try and arrange remote training with a consultant in as similar a time zone to the customer as we can.  Still, it's better than "jet lag"!  By the way, our consultants bios are here:

https://probesoftware.com/Support.html

And for those labs that cannot have an Internet connection directly to the instrument, we're even providing remote training in "simulation mode" using Probe for EPMA:

https://probesoftware.com/smf/index.php?topic=837.0

If you click on the link above, you might want to skip to the last few pages of the topic, as this "demo" or "simulation" mode is now fully implemented and works surprisingly well for training and teaching (of course we utilize the same instrument configuration as the actual instrument for these simulations).  I personally have been surprised at how effective the remote training can be in this "simulation mode".

Yes, there are some advantages to in-person on-site training and we continue to offer such training when it can be arranged, but we have been very impressed with how well these remote training sessions work for everyone.

Please contact Barbara (barbara@probesoftware.com) for more details on our remote training services.

Quote from: John Donovan on July 27, 2021, 09:03:09 AM

In the code I sent you there are indeed min and max fields for the intensity values stored in the MDB file for reading the BIM file!   See the DataImageGetImage procedure:

Code: [Select]

tImage.ImageZmin& = PrRs("ImageZmin")
tImage.ImageZmax& = PrRs("ImageZmax")

I never even thought that Z could relate to the intensities. That makes a lot more sense than what I was thinking before. I also didn't realize (somehow, must have been half asleep yesterday) that the BIM are actual intensity values. I was under the assumption that it was just actual pixel values of an image and was so confused why they were so large. This make so much sense and is better than I thought, thank you!

No worries.

It's probably derived from the Surfer GRD file format described here:

http://surferhelp.goldensoftware.com/topics/surfer_7_grid_file_format.htm

Where zlo and zhi are the grid data values.

Quote from: John Donovan on July 26, 2021, 04:53:16 PM

All values in the BIM file are signed 32 bit integers (long integers).

Also the pixel intensities should all be positive values from 0 to the max intensity values for that image

I think my issue is the second part of that quote, where the max value is semi-arbitrary, I found a few ways to fix it. It seems that manually reading it as a UIntLE does work because of the way it is structured in this instance. I'm not sure why it is a signed int32 because it will only ever be 0 or higher (Uint) so that also threw me off as I didn't expect the BIM to be in that format. I went through a lot of options to find what the format was because 32 is really big for B-W images but never actually tried signed.

Hi Mia,
The reason we use signed integers for the intensity values is because signed integers are the only integer data types VB allows!

https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/data-types/

Some image interfaces store intensities in 16 bit or 32 bit values so using 32 bits can accomodate them all.

I'm comfortable with the current method I have of reading out images from the BIM (though I will mess around with it further to make it more compatible). There doesn't seem to be a record in the MDB relating to the max intensity for any single image which makes it more difficult but obviously not impossible to work around. Is this supposed to be related to ImageAnalogAverages (I'll do more testing with this later on regardless)?

In the code I sent you there are indeed min and max fields for the intensity values stored in the MDB file for reading the BIM file!   See the DataImageGetImage procedure:

tImage.ImageZmin& = PrRs("ImageZmin")
tImage.ImageZmax& = PrRs("ImageZmax")
One could also call a min/max function to return the min/max values of the image intensity array after it is read from the BIM file.

The field "ImageAnalogAverages" is only utilized for image acquisition (pixel averaging).

Quote from: Mia Kraft on July 21, 2021, 02:45:25 PM

The next minor version update will likely include these assuming I don't go all in on Cameca specific support.

I released a bug fix addressing the issues brought up since 1.7.5. 1.7.6 should fix any bugs reported to me in the last several days. This includes several fixes for reading BIM file images correctly.

https://reimager.probelab.net/

tl;dr:
It seems like I was reading the images as UInt8 when I shouldn't have been which was causing errors but only on some machines' image outputs. I think it was a bit depth issue. This was causing issues on both JEOL and Cameca images but only on some hardware and caused different visual issues on each.

All values in the BIM file are signed 32 bit integers (long integers).  Obviously the first two long ints in the BIM file are positive because they are the X and Y pixels dimensions of the following image. Followed by the two long int pixel dimensions of the next image, etc., etc.

Also the pixel intensities should all be positive values from 0 to the max intensity values for that image (which depends on the image interface, but we choose to store in 32 bits since that should accomodate all (most?) analog signal  intensities).

The stage extents are of course stored in the MDB file in the Image table as 32 bit floats, and can be positive and negative values.