Kitware / dive

Media annotation and analysis tools for web and desktop. Get started at https://viame.kitware.com
https://kitware.github.io/dive
Apache License 2.0
80 stars 21 forks source link

[FEATURE] Increase control/transparency over which annotations are visualized #673

Open russelldj opened 3 years ago

russelldj commented 3 years ago

Is your feature request related to a problem? If so, Please describe. It's challenging to visualize multiple annotations for the same dataset. As far as I understand, you have to ensure that file you want to visualize is the most recent one with the correct detection metadata tag, which I find cumbersome. It's also frustrating to not have a clear indication which file is being currently visualized because this could lead to confusion if you're switching datasets frequently.

Describe the solution you'd like A selection menu to control which annotations are used. For example, a radio button with all the valid datasets.

Describe alternatives you've considered A simpler solution, which only addresses the second part of my request, would be to display the filename that's being used somewhere in the DIVE interface. Alternatively, within girder maybe a boolean visualize metadata tag or a numerical priority tag could be less cumbersome than hacking with the detection tag.

Additional context As a concrete example, I am trying to visualize the results of two different box->polygon refiner strategies. I think my ideal solution would allow me to have both results open in different windows simultaneously and pan/zoom around each individually to compare. However, even being able to quickly toggle between the two annotations would be really useful.

subdavis commented 3 years ago

Thanks for the report. We never really intended for people to hack around this, so what you're doing right now is sort of unsupported.

The problem you're describing (difference between different pipelines) is definitely a real use case. @BryonLewis and I were talking about wanting to add this solution earlier today.

As a concrete example, I am trying to visualize the results of two different box->polygon refiner strategies. I think my ideal solution would allow me to have both results open in different windows simultaneously and pan/zoom around each individually to compare.

I think PR #672 will be another solution for this use case. In order to look at multiple results on the same data, you could upload the data once, create a few clones, and run different pipelines on each clone. So you can have "dedicated" datasets for each set of results, but they'll all just be shallow copies of the same source media with their own annotations overlaid. The benefit here would be that you can name each dataset after the pipe you intend to run rather than having to remember which result_timestamp.json file corresponds to which pipe.

672 will be ready shortly. Some way of choosing historical data from a list is also a great idea.

russelldj commented 3 years ago

Cool, the cloning mechanism sounds really nice. However, even once that lands, I think a selection mechanism could be useful. If you want to run a bunch of different pipeline variations, it seems a bit annoying to create and name all those clones. Also, in my particular case I'm producing the results in my local viame so it feels a bit weird to clone a dataset just for visualization, but I don't think this workflow would be super common.

russelldj commented 3 years ago

I hit a variant of this issue running DIVE locally. I had a folder of image folders, each with an associated annotation file. Then I wanted to visualize a processed result from box->poly for each of those datasets. Because DIVE seems to only work with one .csv, and I wanted to preserve the original annotations for further experiments, the fastest solution I could think of was simply to duplicate all the image data. Which is a bit cumbersome, especially for large datasets.

If supporting local DIVE isn't a large priority, I don't think this issue adds much new information.

waxlamp commented 2 years ago

@subdavis, is there a plausible way forward on this? I think the DIVE interface is designed with the assumption of a single set of annotations, but perhaps a design review can identify a way to support more than one.