From Endrov

Public editable page, add questions if you think they fit here.



The disk crunches long after the daemon has converted a recording

Spotlight is probably indexing your files. Disable this for all directories that contain recordings.

Reading OST over AFP is slow/consumes a lot of memory

This is a bug in MacOSX. Install and use SSHFS instead.


Any OS

Endrov gets stuck with the splash screen

This might be a race condition. Just try and start it again. Due to the nature of this bug it has not been solved yet.

Endrov gets stuck when new windows are opening

If this happens during startup all the time, you have no choice but to edit or delete the configuration file. See separate section.

Do you need some other software to use Endrov?

If you're serious then I recommend getting Matlab as an option to perform some of the data analysis. While you can write utilities and new plugins with Java, Matlab still gives a productivity boost once you need to make graphs and do statistics. Statistics and Image toolbox are also recommended.

Can performance be improved?

Make sure that you run the server version of the JVM. Start-up is a bit slower, memory usage higher, but heavier algorithms will perform better. Check with the command java -version. It should say server and not client. If you run Mac OS X, consider upgrading to Linux (especially if you are low on main memory).

Endrov runs out of memory

The JVM is a bit restrictive with the amount of memory reserved for the program. You can for example feed -Xmx1000M to let the JVM use up to 1Gb memory. This is set in different locations for different platforms. On Mac, edit run.sh. (this instruction might be out of date)

3D rendering doesn't work/voxels do not show

Your graphics card might be too old. In the model window, change from 3D texture to 2D texture. The 2D texture has some graphical artifacts however, which is why it is not the default.

When will my favourite OS be supported?

If Java is supported, then all you have to do is locate system libraries corresponding to all .jnilib and plug them in. Please let us know if you collect a set for another platform so we can put them in the main distribution.

When will X be implemented?

See the Road map. If your feature has low priority but is really needed then we can consider doing it earlier; contact us in that case.

Loading OST imagesets is very slow the first time they are loaded

All images located and stored in an image cache. This requires plenty of disk traversal which is rather slow (it depends on disk latency); there are several ways to make this operation faster:

  • Try to load OST imagesets from local disk first time they are loaded (this takes some seconds on our hardware.
  • Batch-index imagesets after they have been created, see EV util/IndexImagesets.java.
  • Create an index while doing the recording. This is rather messy, indexing is easier.

Images added to an OST imageset does not show up

Did you update the image cache? Use the "reload" for the imageset in EV or manually delete the cache-file in the imageset directory

On what media are recordings best stored?

This is a tricky issue but for accessibility reasons, avoid tapes, CDs or DVDs. These medias also silently degrade which means you might be tricked that your data is safe while it is not. Hard drive storage is the best storage; accessibility is high, volume is high, price is low (lower than DVDs last time I checked). Disks do not degrade easily but they can crash and you should expect that it will happen. Therefore you need to store your data on redundant disks (NOTE: do not buy Lacie drives; their quality is crap).

If you already have a large volume of images (more than 500GB) then consider a raid-3+ (preferably raid-5+) as you will not need to span multiple disks and the hardware will give you simple but proven redundancy.

If you don't yet have a lot of data or wish to save money then incrementally adding disks might be a more efficient solution. Here you have to do backups manually so you will likely but pairs of disks and keep one for backup. As time goes, disks will become cheaper and cheaper and the final total cost will be less. Unlike a RAID-system, a manual backup will also prevent user mistakes such as batch jobs that might destroy all your data.

Consider extra safety precautions such as UPS, surge protection etc to prevent natural disasters. Keeping backup physically separate (another building or something) will keep your data safe from fire and other similar events.

Should a lossy or non-lossy storage scheme be used?

See Comments on compression.

Where does the name Endrov come from?

Endrov started out as a very application specific software (worm lineaging). It was at this time called VWB. As we wanted to bring along a standard image format, we decided to produce a plain viewer for neutral use which came to be known as the EViewer. After some experimental work, we figured out how to use Java for really fast imaging (fast enough for playback) - there was no longer to mess around with C++ and QT. EViewer grew to be a plugin framework and soon enough replaced the old VWB. However, EViewer was not a viewer anymore; the name was shortened to EV. Once we wanted to spread it, we figured the name was really poor (151 000 000 hits on Google). We still liked the name but wanted something easier to locate. The compromise was a new unique name (Endrov) that can be googled, but still be abbreviated EV. So, naming things can clearly be tricky.

What are these strange icons?

In lack of imagination, and to point out the gross icon resolution on Mac, the icons depict various lab members. The icon for the main application is also a pun on the ImageJ icon.