search

GiovanniSena / LiSM_Hardware_Control

Code to control LiSM setup and run scans. By Paolo Baesso and Todd Fallesen. Published
0 stars 1 forks source link

MIP visualization #3

Closed GiovanniSena closed 7 years ago

GiovanniSena commented 7 years ago

Between scans, we need to see the MIP of the previous time-point. At the moment, something is wrong with the range of pixel values used to render the image, and we always see it black...

PaoloGB commented 7 years ago

As far as I remember this used to be the case: after each stack, the code would estimate the MIP and show that in the preview window. In the meantime it would calculate the transformation matrix. I have no way to check what happened but I did notice that there is a new file called GUI_displayMIP_GS.m in the GUI folder which is identical to the original one GUI_displayMIP.m but is lacking the normalization part. The problem is that the two files have different names but the functions inside have the same GUI_displayMIP which means that one will override the other.

If the _GMS version is an attempt to fix the issue, than you should rename the old file to something different, including the function within. However, I suspect the _GS version is the one that was creating the issue, so it should now be fine because I have renamed the function in the _GS file to be consistent with the file name.

GiovanniSena commented 7 years ago

Thank you Paolo, that might have been my fault, then. I think Todd fixed the problem now. I will have him double-check that the GitHub version reflects his latest fixes, and post here the results.

GiovanniSena commented 7 years ago

Todd, can you please read the above and make sure the file on GitHub reflect your latest fix on this issue? Thanks

PaoloGB commented 7 years ago

No worries. Please be aware that I have already committed a few changes to the repository and cleaned up the GUI, FilterWheel, CFG, Camera and FileIO folders. So if you want to modify something use the commit process:

-checkout the current folder -branch it -modify the files -commit the changes and push them to the repository -create a merge request

This way we all work on the same files and we can avoid conflicts.

GiovanniSena commented 7 years ago

So, just to be clear, you can "push" yourself the commits because you are a Collaborator? Another viewer could branch/modify/commit but will have to request a "pull" before his/her changes are merged in the Master?

PaoloGB commented 7 years ago

I will close this issue as I think it is now solved (let me know if not clear).