Closed kunzaatko closed 9 months ago
Can you resolve the conflict and push again? I think it is OK to merge apart from this.
@RainerHeintzmann I think that your package is very useful! Atleast for me it was. I am working on a package TransferFunctions
, but it is on and off based on what functionality I need at the time. I wanted to ask you whether it would be OK for you if I adapt and refactor the code from this repo into it... I will of course cite you in the docs when I do that...
Would that be OK with you?
Can you tell me more about the goal of the package. I assume that you are aware of the PointSpreadFunctions.jl package? If you need the functionality of PSFDistiller.jl can you not just Import it instead? Copying code seems a bad choice for maintainability.
From some of your earlier commit messages, you were also implementing some kind of inversion based SIM reconstruction method... We are also working with SIM data and I am attempting to compare several models and PSF measurements and ultimately to attempt to get enhance the reconstruction that we are using. Also I am currently working on inverse modeling the OTF from the forward SIM model and for a generated ground truth model of a micro bead acquisition (using, I assume your colleges, code from DeconvOptim
. The particular function is called generic_invert
if I recall correctly). The main point of TransferFunctions
is to generalize these into a common type system where the reconstruction can be called with any of these to compare them and to further work with them. I am currently working with your PSFDistiller
package to estimate the PSF from different sections of the image and trying to incorporate this estimate through the MeasuredPSF
type from my package into the reconstruction.
I am aware of your PointSpreadFunctions.jl
, but to be completely frank with you, it is not well documented. I was going through the code but it is just hard to understand someone else's code without documentation, also since I am only just getting comfortable with image formation in microscopy. Sorry, but for the benefit of honesty I must say that it would be very hard to use the package, even though I assume (and from the code deduce) that it is actually very similar to what I want to achieve.
About the "code copying", I would like to use method you have implemented, but I would need to rewrite almost all of it to adhere with the type system that I want to achieve and some functions (such as gaussf
if I remember right) would be rewritten, so I can experiment with the method (similarly to the background estimation but much further). I would like to write the gaussf
function using ImageFiltering.jl
to tryout the straightforward convolution without going into the Fourier domain since this does bring the necessity of attenuation and edge tapering, if not done correctly, generates artifacts.
Sorry for the long response. Looking forward to reading your opinion :)
In PointSpreadFunction.jl
we tried to use a type system which makes sense, and I am trying to use that also for other things. In that sense it would be a pity to now start a new common type system instead. So can you maybe tell me a bit on the "type system" you had in mind, so that I can understand which aspects the current one (as generated by PSFParams
) is inappropriate.
I would be very happy to improve the documentation of PointSpreadFunction.jl``, maybe with your help. There is a actually a video, which describes it a bit. I use it quite regularly. The simplest way is to just copy the example code which is in the help file of the
psffunction. Also for SIM reconstruction, I would be more than happy to collaborate. As for
gaussf(which is now called
filter_gaussian, às far as I remember, it would be nice if one could choose between an efficient real-space and a Fourier-space implementation. It should belong into the package
SeparableFunctions.jlsince the Gaussian is separable and therefore its implementation (via
ImageFiltering.jl`?) should be done this way. I guess we should continue the discussion somewhere else? Maybe in your (to date still empty) SIM package?
Presently, I am in quite a time pressure, because my thesis is due at the beginning of January and I have a few topics that I want to expand and to work on further.
For the type system, I have to have some time to wrap my head around it, compare it with what I use in my package, and I need to go over the code to get a grasp of how the type system in PointSpreadFunctions.jl
is built.
As for the SIM reconstruction, I have the functionality locally currently, but it is in a very non-final way so I didn't yet get to pushing the initial version of the content. I am very open to collaboration.
The gaussf
/ filter_gaussian
is implemented with everything that is needed for the PSFDistiller
(I didn't go through the PointSpreadFunctions.jl
package yet) and with separability in ImageFiltering
. It is implemented via a KernelFactors
type similarly to how I presume your SeparableFunctions.jl
works. Here is the relevant documentation page.
Because of the time pressure, I am in as I said, would it be OK if we discussed this in the second week of January? Perhaps, this would be better for a videocall...? If you want to continue the discussion right now, I am afraid that I will not be able to give it my full attention, so I would highly prefer to defer it to January. But either way, lets continue the discussion either in the SIMReconstruction
package or in a new issue under one of our transfer function packages...
Thanks for the reply. Yes, sure, lets continue discussion starting second week of January.
Hello @RainerHeintzmann, I am ready to continue the discussion now. As for the SIM that we have discussed, I have implemented the Wiener filter reconstruction and a inversion/optimization reconstruction based on DeconvOptim
s invert
function. I did not include it in the package that I was writing at present time, because it depends on my implementations API of the transfer function, that may be subject to change on the basis of our discussion I presume. I think it would be best to schedule a video call meeting to talk about our respective ideas and visions for the API. Does that sound good to you? What time and day would work for you?