-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
integrateSingleImage indexing error #56
Comments
Image.energy is not strongly typed, is the problem. Within If you look at the analogous lines in the I'd also suggest copying the warning/guard I added over on |
I'll have to try the |
I also have an issue with this. Is there any temporary hack that I should know about or is it on its way to getting fixed? |
Actually I get this with the datatype being of numpy.float64. I can change the attribute energy to be a float though |
Try installing the latest pre-production release with 'pip install -i https://test.pypi.org/simple --pre --upgrade pyhyperscattering' and see if that fixes it? What loader is being used to generate the data -- SST1RSoXSDB or something else? |
I now get a different error. And yes this is SST1 RSoXS.
It seems like it is not handling the type numpy.float64 properly. It is assuming that the energy attribute is an xarray. |
Gotcha, yes, I agree with the diagnosis. Probably a change in the SST1 file format but we ought to handle this case anyway. I'm hoping to find a minute today to get a patch up for this. Just adding another try/except to the existing tree of possible types of energy... Can you point me to a dataset (scan number is fine) that I can test with? A copy of how you're invoking the load and integrating steps would also be a big help. Thanks! |
The scan id is 36950 I believe. Here is the code for invoking the load and integrating:
|
Additionally, I get this error:
Do you have any idea why this is? I am not giving my own mask to the integrator so maybe that is explaining it? |
So, Alternately, you could just try Basically, understanding your use case a little better might be helpful. That said, integration of freestanding images rather than just stacks is certainly within API scope for the package, so I would like to get this working, but understanding the context might yield a faster work-around. |
I am basically using loadSingleImage to load one image and then I try to integrate that. I tried using the loadFileSeries with regex to load one image and then integrate but it will throw an error if the regex only matches one file. I think the best workaround is to load two images with a regex OR pattern, integrate both, and display the one I want. |
I see! Good news: I think the 56-integratesingleimage-indexing-error branch has a complete fix for this. It was a matter of dealing with some of the scan stacking logic and adding a cut-out for single-image stacks with no indexes at all. Can you install this branch with, e.g., |
It seems to integrate a single image fine for my case. |
One other issue I discovered with loadSingleImage. It does not assign coords automatically to the data like loadFileSeries does.
Actually not sure if this is an issue. It seems inconsistent to me but there might be a reason for it. |
This is wrong on my part as well. |
This is an interesting one. The assignment of the Just to clarify, regex matching is working if it only matches one file, or failing? I tested this on my machine and it worked but it could be sensitive to the directory structure. |
It is working. I grabbed a file name at random to try and didn't realize that it excludes dark images. That's a few hours of my life I'll never get back lol. |
When trying to call integrateSingleImage directly, I run into an IndexError here. img.energy is of type xarray.core.dataarray.DataArray, not float, so the expression on line 41 will always evaluate to True. If you pass a single energy DataArray (e.g. imgstack.unstack('system').sel(energy=270)), the array is 0-dimensional and this is where the IndexError arises.
When PyHyper calls integrateSingleImage through integrateImageStack via groupby-progress_apply, img.energy is of length 1 (perhaps because it still has the system multi index?), so indexing its first value is no issue.
Long story short, I think we can get rid of the if-else statement on lines 41-44, and just replace it with
en = img.energy.values.ravel()[0]
The text was updated successfully, but these errors were encountered: