data.table class objects seem to conflict with the parallel ClusterApply loops. Providing regular data.frames to the cluster seems to work. Perhaps this is the easiest workaround and wont really influence speed.

e.g. worker.r file
Started this in the worker-r branch

Maybe not so important, as mostly frame rate should be the same among vids (I imagine).
Issue came up when dealing with some test dinolite usb microcam videos differing in resolution and therefore frame rate.

1. add information about the content and format of particle.RData, trajectory.RData and Master.RData
2. add section about trouble shooting tracking parameters
3. add a change log to the site to inform about recent changes and potential issues with previous versions

otherwise the function doesn't work when used without previous functions.

Tracking is the most time-consuming aspect of BEMOVI so far. To cut time down for tracking, pre-filtering on the raw coordinates may be helpful: for instance, morphologies far outside the range encountered could be filtered out (this already happens due to size limits in the locate_and_measure, but more morphology variables could be included).

This requires that the link_particles function is changed to work on the particle.RData instead of the raw text files output by locate_and_measure.

Probably useful to have a check in the merge_data function something like:

if(length(merged2[,1]) == 0)
stop("The merged data has no observations. Probably this is due to no match in filenames in the video description file, and in the video files supplied.")

It might be helpful to have a population level summary output including population densities (optimally in individuals per ml).

clean up old branches

We could use the median instead of the mean; probably good idea to check some of the within trajectory variation

It is quite easy to have mismatches between the output of the trajectory/morphology data and the video input text file.

This can occur for example if file names do not match or if there are differing lengths or simply because spaces are used instead of tabs to separate text input.

Perhaps a .csv file would avoid the spacing issues and some checks could also be made to inform the user that there video input metadata is inconsistent with the names of the raw files.

I will start the discussion the move from ImageJ to OpenCV.

An initial question in the OpenCV forum indicated that it would be possible to use OpenCV instead of ImageJ.

The process would involve the following steps:

Background identification and removal

• https://docs.opencv.org/3.4.15/d1/dc5/tutorial_background_subtraction.html

Blob detection

https://learnopencv.com/blob-detection-using-opencv-python-c/

binarisation

i.e. converting the moving particles to one colour (necessary?)

morphology

• identification of boundaries
• https://www.tutorialspoint.com/opencv/opencv_morphological_operations.htm

particle tracking

• https://learnopencv.com/object-tracking-using-opencv-cpp-python/
• https://www.pyimagesearch.com/2018/07/30/opencv-object-tracking/

particle measuring

• This could possibly done in R, when the boundaries of the particles are exported?
• This looks promising: https://docs.opencv.org/3.3.1/d3/dc0/group__imgproc__shape.html#ga107a78bf7cd25dec05fb4dfc5c9e765f
• https://docs.opencv.org/3.3.1/dd/d49/tutorial_py_contour_features.html

Java always want's to have access to X11, which causes problems in a docker image. The problem would be solved, if the argument -Djava.awt.headless=true would be added to the java calls. I don't think there would be any negative side effects?

Major axis / minor axis measured, rather than length and width.
Get length and width from the direction of movement?

I encountered an error in the link_particles function. Perhaps, as earlier, it has to do with an updated version 1.12.0 of data.table (13 jan, 2019). Here the error code:

Error in [<-.data.table(x, j = name, value = value) :
Cannot use := to add columns to a null data.table (no columns), currently. You can use := to add (empty) columns to a 0-row data.table (1 or more empty columns), though.

I'm a bit of a noob with scripting, but reinstalling data.table and bemovi did not work. :)

In the merge_data function

I'm not sure this syntax works: sub(".cxd | .avi", "", morphology.data$file)

Also, should also remove all of video.description.file, trajectory_data, and morphology_data.

Add this to the function check_video_file_names. Would show a message of "no videos in selected directory, or selected directory does not exist, please check the path to the project directory and folder name for raw videos are correct."

The output of the link_particles function (the trajectory.data object) sometimes contains NA values.
This doesn't seem to effect most things and I expect that it is related to movement variables such as step length being almost zero.

Replace existing lops with apply, fread and rbind_all from data.table

Here is the error message. I think it concerns the merging of ijout.txt files...

Error in [.data.table(data, !(diff(X) == 0 & diff(Y) == 0), ) :
i evaluates to a logical vector length 12336 but there are 12337 rows. Recycling of logical i is no longer allowed as it hides more bugs than is worth the rare convenience. Explicitly use rep(...,length=.N) if you really need to recycle.

The analysis of .cxd files is not working out-of-the box under Linux. This problem occurs because in the relevant functions the path to the ImageJ plugin directory (for using the required Bio-formats plugin) is hard coded to "/Applications/ImageJ" for all unix systems. However, this specific path is only correct for Mac OS. What we need here is a part of the "IJ.path" path (without "ij.jar"). Couldn't we use this information to make bemovi also work for .cxd files under Linux? NOTE: This will be really relevant if we want to use the MOSAIC plugin instead of the standalone particle tracker.

I've been following the tutorial found in bemovi.info/pages/analysis.html and I've run into what I think is a bug. The link_particles function has a line in it that calls the organise_link_data function, which attempts to create an object called files that stores all the .ijout.txt files that are found in the trajectory folder. However, this is an issue because if you're following the tutorial, there are no .ijout.txt files in the trajectory folder. The only .ijout.txt files created are the ones in the particle data folder as created by the locate_and_measure_particles function. Therefore, I can't get through link_particles without getting an error. Am I just missing something?

https: //www.dropbox.com/sh/i9u2opuc1l8y764/AADy-AWdNfMbu5DLsLhKaP0ja

In the link_particles function a hardcoded JAVA path needs to be changed so that different versions of Java may be used.