tinevez on master
resolves #187 LogPanel Logger o… Merge pull request #188 from ka… (compare)
ctrueden on parsington-2.0.1
[maven-release-plugin] prepare … (compare)
ctrueden on parsington-2.0.1
BdvFunctions.show( SourceAndConverter )? I think that would be very useful to, e.g., give users the possibility to use own
LUTsfor displaying data in the Bdv. Currently, to achieve this, one needs to construct oneself a
Source<ARGBType>and then call
BdvFunctions.show( Source<ARGBType> ). This works fine in principle, but the actual pixel values in Bdv are then from 0 to 255 and do not reflect the real data anymore, which I think is not ideal.
WeakHashMapin order to be always able to retrieve the source and the volatile source (and potentially the RGBified source), one form another. But I don't know if it's a good idea. If you think it is, I'll go for it. If you plan to implement extra stuff in
BdvFunctionsor in the new BigDataViewer UI which will make my efforts obsolete very fast, I'd rather not do it.
interface DataSource<T, V> extends Source<V>that provides both the data and volatile voxels. (As it
extends Source, you could just pass it into a regular BDV if you wanted to)
when you perform processing, you want to act on the 'real' source, but when you want to display it, you want a 'volatile source' (or a converter (Volatile)ARGBType
This was partly my point of suggesting to work more with
SourceAndConverter objects, because you would have the
Source holding the actual data together with the
Converter< R, VolatileARGBType > that can be used for rendering. The job of actually applying the
Converter to the
Source could then be delegated to be done inside
Bdv, because outside
Bdv it anyway isn't useful?!
However, one limitation with this idea is here: https://forum.image.sc/t/bigdataviewer-blending-modes/28568/8
For my applications, I seem to need to also specify a special
VolatileARGBType out-of-bounds value, which is currently not part of the
Converter but of the
getDataSource(int t, int level);returning a RandomAccessibleInterval ? Why not a
Volatilepixels types within the Bdv for rendering, such that you can rotate a volume quickly, even is the data is not yet loaded (i.e. not
valid). For any sort of computation one typically wants to have the actual
validdata. Thus, I think, one way of seeing the issue is that we would never have to care about
Volatiledata outside Bdv, but upon saying
BdvFuntion.show( source ), Bdv would internally
VolatileViews.wrapAsVolatile( ... )for you. Currently however there are some limitations, e.g.
VolatileViews.wrapAsVolatile( )is only implemented for
RandomAccessibleand not for a
VolatileViews.wrapAsVolatile( )does not always work, e.g. if the
RAIis internally derived from too complicated
Converters. With the help of @hanslovsky I added some functionality to
VolatileViews.wrapAsVolatile( )to make it cover more scenarios, see e.g. https://github.com/tischi/fiji-plugin-bigDataProcessor2/blob/master/src/main/java/de/embl/cba/bdp2/volatiles/VolatileViews.java#L186 but there are still cases where it cannot handle it.
BdvFunctions, it seems that a
SetupLoaderwhich extends an
AbstractViewerSetupImgLoadershould also provide a Volatile source. As a consequence the source volatile wrapping has to be done internally to the repository anyway.
it seems that a
SetupLoaderwhich extends an
AbstractViewerSetupImgLoadershould also provide a
This is exactly the kind of stuff I was also just thinking about. To me, right now it seems as if there are two ways to provide
Volatile pixels: (a) via the
SetupLoader logic and (b) via this kind of logic: https://github.com/tischi/fiji-plugin-bigDataProcessor2/blob/master/src/main/java/de/embl/cba/bdp2/volatiles/VolatileViews.java#L118 where a
CachedCellImg can be made to return
Volatile pixel values. Honestly, I think I would need a Skype, probably with someone like @tpietzsch or @hanslovsky and a white-board to draw how all these things are connected :-)
SetupLoader existed before the
CachedCellImg. I use
CachedCellImgs exclusively because it is extremely convenient. There may be benefits of
SetupLoader that I am not aware of.
VolatileViews.wrapAsVolatile should be sufficient for any/most standard ImgLib2 native types. It gets a little more tricky when more complex types are being used, e.g.
LabelMultisetType in Paintera, or
Composite<T> vector-like types.
extends BasicMultiResolutionSetupImgLoaderand adds methods
on top of the existing
RandomAccessibleInterval<V> getVolatileImage( final int timepointId, final int level, ImgLoaderHint... hints ); V getVolatileImageType();
RandomAccessibleInterval< T > getImage( final int timepointId, final int level, ImgLoaderHint... hints ); T getImageType();
SourceAndConverterhas a method
SourceAndConverter< ? extends Volatile< T > > asVolatile();
asVolatile()version, and, if it exists, use that.
VolatileViews.wrapAsVolatilethis idea was a bit weakened, because now you effectively add a volatile source directly (with nothing non-volatile on top of it)
SourceAndConverterin the vistools
VolatileViews.wrapAsVolatilethat constructs a volatile view, creates appropriate RGBA converters, and then wraps it with the original RandomAccessible into a non-volatile/volatile
SourceAndConverterpair. The code for all of these steps is there, it just needs to be reorganized and exposed...
Thanks @tpietzsch ! It seems that the method
BdvFunctions.show(Source src); has also two limitations: (3) - the source is not wrapped into a volatile one; (4) - We cannot specify the number of timepoints.
(5) Another feature which would be nice is also the capability to create a viewer without any Source.
Do you think working on these three extra points would make sense ?
Exception in thread "main" java.lang.NoSuchMethodError: net.imglib2.cache.queue.BlockingFetchQueues.<init>(I)V at bdv.img.hdf5.Hdf5ImageLoader.open(Hdf5ImageLoader.java:215) at bdv.img.hdf5.Hdf5ImageLoader.<init>(Hdf5ImageLoader.java:166) at bdv.img.hdf5.Hdf5ImageLoader.<init>(Hdf5ImageLoader.java:152) at bdv.img.hdf5.Hdf5ImageLoader.<init>(Hdf5ImageLoader.java:147) at bdv.img.hdf5.XmlIoHdf5ImageLoader.fromXml(XmlIoHdf5ImageLoader.java:71) at bdv.img.hdf5.XmlIoHdf5ImageLoader.fromXml(XmlIoHdf5ImageLoader.java:50) at mpicbg.spim.data.generic.sequence.XmlIoAbstractSequenceDescription.fromXml(XmlIoAbstractSequenceDescription.java:111) at mpicbg.spim.data.generic.XmlIoAbstractSpimData.fromXml(XmlIoAbstractSpimData.java:153) at bdv.spimdata.XmlIoSpimDataMinimal.load(XmlIoSpimDataMinimal.java:86) at bdv.util.ExampleSpimData.main(ExampleSpimData.java:15)