(from Joe Smerdon)
AFAICT, removing spots removes curves also, but doesn’t recalculate the average curve.

(from Joe Smerdon):
Changing the energy while in ‘pause’ breaks it, leading to a restart.

From @feranick on October 8, 2014 4:24

This will enable per-spot removal of individual curves. For example, by selecting and removing a spot the related IV gets removed as well (either directly or through the Plot UI).

Copied from original issue: feranick#33

Currently the saved spot locations are saved as binary data, but they use csv as the file extension. This should be changed to something else (pkl? or bin?) as csv has a clear meaning and it's confusing to the user

Right now they are saved in different files. Given the different format/shape between energy/Intensity and peak position, the current commented solution in gui.py (line 1328) based on numpy, won't work.

A better solution is to use pandas to make a dataframe where mixed formats can be combined and saving as a csv of intensity and peak positions trivial.

From Renee: "I’ve been playing around with EasyLEED and I can’t get it to track the spots properly. I think it’s probably a matter of getting the parameters set up properly, but I don’t know what are reasonable parameters, e.g. for the Kalman position and velocity. The default values seemed to be 0.1 and 0, but when I use those, the integration windows don’t move with energy. Do you know what are reasonable values to use? It keeps saying the fit failed."

After I made changes to the preference panel, when I push apply, the new settings are available as long as I remain in the same session. If I close EasyLEED and reopen it, those settings are lost, as the were never saved back into defaultconfig.py

From @feranick on October 4, 2014 20:48

The idea is to to just extract the intensity without caring to much about automation. One could combine the Kalman filter with some manual intervention. The idea would simply be to let the user correct the predicted positions from time to time. The user input could then be incorporated into updating the state model in the same way that the guesses from the fitted positions currently are.

From private communication with Andi.

Copied from original issue: feranick#22

Your method in gui.py clearPlot() is not actually connected to the QPuchButton titled Clear Plots

rather clearPlot() is only ever called from the method restart(). This is unintuitive.

Also:
OS X 11.4 El Capitan, Python 3.5, PyQt5 via easyleed --pyqt5: clicking restart in the menu bar does not clear the plots, neither does clicking the clear plots push button.

I have tested a fix for the second issue:

in your clearPlot() method, change self.axes.cla() to self.axes.clear().

it might be that matplotlib is not registering your PlotWidget's axes as the 'current' axis. The cla() function documentation says that it clears the 'current' axes, which is somewhat ambiguous.

As for addressing the first issue, that would seemingly require a bit of refactoring.

I have installed 'EasyLEED' in Linux. But when I'm trying to run, it shows
the error message...

shuva@shuva:~$ easyleed
Traceback (most recent call last):
File "/usr/local/bin/easyleed", line 33, in
sys.exit(load_entry_point('EasyLEED==2.5.2', 'gui_scripts',
'easyleed')())
File
"/home/shuva/.local/lib/python3.10/site-packages/easyleed/main.py",
line 9, in main
form = MainWindow()
File "/home/shuva/.local/lib/python3.10/site-packages/easyleed/gui.py",
line 798, in init
self.parametersettingwid = ParameterSettingWidget()
File "/home/shuva/.local/lib/python3.10/site-packages/easyleed/gui.py",
line 496, in init
self.initUI()
File "/home/shuva/.local/lib/python3.10/site-packages/easyleed/gui.py",
line 502, in initUI
self.inputPrecision.setValue(config.Tracking_inputPrecision)
TypeError: setValue(self, int): argument 1 has unexpected type 'float'

(from Joe Smerdon):
If you could group spots, (maybe just the circles a different colour), you could track several inequivalent beams at once.

Hi, I just realize that the last two commits in master were never released. Would you please push for another bug fix release (2.5.2?)

It would be nice if the UI for beam selections would color code the QGraphicsEllipseItems (or their subclass objects) to match the color used in the I(V) plot. If you select 4+ beams and all the circular selections are blue, it becomes difficult to distinguish which I(V) curve belongs to which beam since the curves are separated by colors.

Steps to reproduce:

1. Open Easyleed
2. Click "Open" from toolbar
3. In the File selection window, select cancel

Actual result:
Easyleed crashes

Expected result:
Nothing should happen

Currently, stopping at a specific energy during an IV extraction and starting again from that energy, initiates a new set of curves, that are not connected to the ones prior stopping the acquisition.

It would be great to have the ability to "pause" the extraction, for many reasons (for example, realigning the spots), to continue with it within the same set of curves.

The only one visible from the dropdown is the "Gaussian fit"...

Hello,
I am currently trying to get easyLEED to work for some analysis I am doing and I have the following error when I close the window to open an image:

modalSession has been exited prematurely - check for a reentrant call to endModalSession:

I did some reading and found that this type error has been seen before with Qt on Macs when a window is closed. Here are some similar issues which have been reported:
https://bugreports.qt.io/browse/QTBUG-37699
https://bugreports.qt.io/browse/QTBUG-32943

I am running OS X 10.11.6 and used homebrew to install the easyLEED dependencies, and did a pip install of easyLEED.

Thanks in advance for any help,

Drew

From @feranick on October 10, 2014 21:6

Either multiprocessing or multithreading. This should also help in solving issue feranick/issues/3

Copied from original issue: feranick#39

Currently, many acquisition parameters are given in absolute pixels and have limits.
Are there any reasons (i. e. stability of the prediction algorithm) to not remove the upper limits on parameters such as the upper limit of 99pixels for the default radius of a new spot?

Additionally, our camera resolution is quite high and some large spots do not even fit in the current maximum of the spot radius. Because I had no time yet to look into the problem, my quick and dirty solution was to scale down my input images. I assume, scaling the parameters relative to the image size could fix various similar problems with different resolutions of the input data.

What were your reasons for the standard parameters? Are they scaled relative to the size of your input data?
Probably, I will look into the problem in the next months. If the standard parameters are optimized for your input image resolution, assuming these parameters are proven to deliver good results, I would like to take the ratio of standard parameters to your input image size as a starting point to find good ratios and to let the user use a relative scale/factor to modify the ratio.

Greetings from Dortmund