mastrof / particletracking.jl Goto Github PK

Current LoG filtering uses the same scale σ for all the dimensions.
detect_blobs should accept a kwarg (e.g. spherical, defaulting to true) which allows to test all possible combinations of scales along each axis, this could provide better detection for elongated objects, and maybe even discrimination between objects of different shapes in the same dataset.

E.g.: detect_blobs(video, 2:3; spherical=false) would test LoG filtering with scales [(2,2), (2,3), (3,2), (3,3)] instead of only [(2,2), (3,3)].
Will need to check what is the proper normalization for the LoG kernel then.

The blob detection algorithm should support arbitrary dimensions, but due to the current implementation of the subpixel localization (offsets) it is limited to 2D.
offsets must be generalized to deal with arbitrary dimensions; should be relatively straightforward to generalize just by using CartesianIndices for iteration

times is limited to end-1 because for each t, the algorithm is then looking at t+1 onwards for the linking; but in practice this removes the last blob from the stored trajectory. Instead everything seems to work if times = eachindex(blobs).
Bug somewhere?

What we now define as Blob is only used internally and never touched by the user, which instead only interacts with the BlobRefined since subpixel localization is applied automatically. Changing the names would make more sense.

Currently. length(traj::Trajectory) returns the number of blobs measured along the trajectory; instead it should return the total effective length, i.e. the time difference between the end and start points.
The current behavior could be reassigned to a different function e.g. length_raw

Currently, evaluate_costs! imposes the limit distance for creation / annihilation by assuming the cost function to be quadratic in the distance.
This means that:

• the current implementation of PCost is wrong
• any other cost function must be implemented to return a cost that is quadratic in the distance

Assuming that the cost is always quadratic in the distance is convenient, but moves the burden on the definition of the cost functions. For instance, with this approach the correct return from PCost should be (dx^p + g0*dm0^p + d2*dm2^p)^(2/p), where the 2/p exponent makes calculations much slower than they could be.

At the same time though, the cost function should not deal with maxdist and creation / annihilation itself, these must be managed internally (as done now) to ensure proper behavior of the linking algorithm.

Could this be solved by adding another indirection layer? E.g. instead of hardcoding (dt*maxdist)^2 as the maximum cost, it may be possible to evaluate the maximum cost as follows:

• generate two dummy blobs a distance maxdist apart
• evaluate their linking cost according to the provided cost function and store it as maxcost
• use maxcost instead of (dt*maxdist)^2