search

imagej / imagej-common

ImageJ core data model
https://imagej.net/libs/imagej-common
BSD 2-Clause "Simplified" License
10 stars 18 forks source link

Allow more flexible image input options #71

Open imagejan opened 7 years ago

imagejan commented 7 years ago

Currently, module inputs of type Img (and ImagePlus, Dataset, etc. via converters) are handled by ObjectWidget and SwingObjectWidget that offer a simple JComboBox with a list of convertible objects. It would be nice to offer more flexibility via a style attribute, to allow:

Another (maybe more elegant) option would be to create a singleton object that shows up as "Load from file..." option in any dropdown list for image inputs, thereby allowing to choose an open image or load from file at will.

See https://github.com/saalfeldlab/bigwarp/issues/42#issuecomment-340198033 for the discussion that triggered this issue.

tischi commented 6 years ago

I would like to weight in here! For using commands both from within the GUI and headless ("write once run everywhere") I would find it almost essential to have the style="file-or-image" option working. Because, within the GUI, you typically want to choose the image from the currently open images, but using the exact same command headless you always want to give the path to a file. My personal current solution is that also for running from within the GUI, I am asking for files, which is not ideal.

tischi commented 6 years ago

...for the headless use-case: would it also be possible that the Context realizes that the Command is called headless, thus knows that images cannot come from the GUI, and thus any Image parameter automatically would also take filepaths as a input?

imagejan commented 5 years ago

@tischi wrote:

would it also be possible that the Context realizes that the Command is called headless, thus knows that images cannot come from the GUI, and thus any Image parameter automatically would also take filepaths as a input?

I think it wouldn't even be necessary to detect we're running headless. The presence of a Converter<String, Img> or Converter<String, Dataset> (that internally call DatasetIOService#open to create a Dataset) could be sufficient.

The question is whether having such converters (from String to almost everything) would lead to issues somewhere else where such a conversion would not be desired.

imagesc-bot commented 3 years ago

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/new-colocalization-cross-correlation-plugin-looking-for-feedback/49492/2