Hello everyone,
during a project in 2020 I wrote some logic to have a renderQueue for
ImageJ-Jobs. I needed this for several repetitive jobs on a large volume
project with slightly different configurations and I did not want to set
working paths again and again.
I think that these scripts might also be interesting for others and this
is also the reason for this mail. Right now I'm working on other topics,
but I would like to come back and refine this approach. It would be
great if there is interest in this and if some funding (or as part of
running projects) could be gathered. In case of the later, I would set
up a more detailed project-website on this and love to made an enhanced
(checked/documented) version public.
Since I'm currently not working with ImageJ, I hope you can understand
my question/idea. In any case it would be nice to get in contact with
people/institutions interested in this or to hear from other solutions
in this fashion.
What is possible (features):
- works with any macro (without changing internal logic)
- several input-, temp- and output-paths can be used (feeded)
- every dialog-parameter can be altered externally (not limited to),
hence logic of macro can be different for created jobs
- flexible method to create n-jobs over folders a.s.o.
- works with n-instances per machine and/or network nodes running IJ
- a common folder (shared) is used for managing jobs
- watch-folder logic (new jobs can be added on the go/anytime)
- ordering by name or mod-date (priority for processing)
- path-mapping (work on central jobs, with local copies of data)
- flush cache after each completed job on client IJ
- avoid collisions on groups of jobs (assignments)
Some testing/adjustments need to be done for..
- Mac/Linux (developed and used with Windows nodes so far)
Kind regards,
Rainer
--
Rainer M. Engel, Dipl. Digital Artist
scientific|Media imageLAB, Berlin
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html
Locked
