ctrueden on master
Update mailmap So that "git sh… (compare)
elevans on master
Add gray version of 16x16-flat … (compare)
maarzt on edit-branch-label
Add BranchTrackSchemEditLabelAc… (compare)
IntervalView, see imagej-roi-course
@NicoKiaru I have the following workflow:
Source) and view it in BDV.
AffineTransformusing the manual transform UI of BDV
*.xmlfile that looks exactly as the original one that I opened, but I want a new
<affine>...</affine>content, reflecting the additional transform that I manually added in BDV.
Do you know how to do this most efficiently? Do I have to construct a new
SpimData object from the
TransformedSource and then use
XmlIoSpimData.save()? If so, would you have code already to construct
SpimData from a single
Source and the path to the corresponding .h5 file? Or are there other ways to save such an
myAffineTransformbeing the transform retrieved from the
TransformedSource. Then you can resave the dataset. FYI, I also found a trick to update the
spimDatawhen it's shown in the bdv (thanks to reflection to access a private method see https://github.com/BIOP/bigdataviewer_scijava/blob/master/src/main/java/ch/epfl/biop/bdv/scijava/command/spimdata/UpdateSpimDataDisplay.java)
AbstractSpimSourcewas made public, then it would be a bit easier. (https://github.com/bigdataviewer/bigdataviewer-core/blob/5be52618026c6734911d9c150a9e2ba1140799e0/src/main/java/bdv/AbstractSpimSource.java#L187)
@StephanPreibisch somehow I do not manage. It is not updating the image in BDV. Probably I am doing something wrong:
final Source< ? > source = bdv.getBdvHandle().getViewerPanel().getState().getSources().get( currentSource ).getSpimSource(); final SpimData spimData = sourceToSpimData.get( source ); spimData.getViewRegistrations().getViewRegistration( 0, 0 ).concatenateTransform( new ViewTransformAffine( "My transform", myTransfrom ) ); spimData.getViewRegistrations().getViewRegistration( 0, 0 ).updateModel(); bdv.getBdvHandle().getViewerPanel().requestRepaint();
sourceToSpimData is a
Map that I generate while adding new
SpimData to BDV in order to keep track of things.
updateModelfunction is useful for updating properly the SpimData object before saving it, but I'm nor sure..
SpimSource.loadTimepointsmethod through reflection
Thanks @NicoKiaru & @StephanPreibisch !
It looks like that both of your codes you are calling a method of the
Source that is wrapped by the
TransformedSource, which is the object BDV is using to display the source. What I did initially was simply:
final TransformedSource transformedSource = ( TransformedSource ) source; transformedSource.setFixedTransform( myTransform ); bdv.getBdvHandle().getViewerPanel().requestRepaint();
This updates the display of the
TransformedSource in the BDV and is much simpler code. I think the difference is that the
TransformedSource is something that only exists in BDV and is not talking back to the
SpimData object that was initially put into BDV for display. My feeling is that if one just wants to add additional transforms to
Sources and display those in BDV, using the
TransformedSource.setFixedTransform() approach might be cleaner?! In fact, the only reason I now also want to modify the
SpimData object is because I want to save a new xml with
myTransform appearing as additional
<affine>...<\affine> tags. What do you think?
BDV) and/or adding any kind of other transformation, e.g. as obtained by a phase-correlation algorithm. And they should play well together. E.g. a user might do a rough manual pre-alignment (using
T) and then press, e.g.,
Pto compute a fine phase-correlation alignment on top of the manual pre-alignment. I am a bit worried right now that the current
ManualTransformationin bdv-core relies on the
TransformedSource, while our solutions seem to rather work through
SpimData, and thus things might become messy, but I might be wrong as I am still not fully grasping everything...
SpimDataoption. Extra advantage of using SpimData is that the volatile view is taken care of also. It may not be the case fot the
TransformedSource? An alternative : every time you want to save the SpimData, check the transform of the
TransformedSource: if it's not identity, then push it to
SpimDataand also applied your reflection trick, in above example applying a simple translation along the x-axis. The result in
BDVis that the yellow box is shifted along the x-axis relative to the grey square (see screenshot). However the coordinates of the upper left corner of the image are still at x=0 and y=0 if you hover there with the mouse. If I would change the transformation via the
TransformedSource.setFixTransform()this would be different: the coordinates of the image would actually be shifted. Can someone explain me the meaning of the gray square and why the coordinates do not change using the
SpimDataapproach? (...for me, I think the coordinates really would need to change because I need to move around the relative location of multiple Sources in a physical coordinate system).
LoopBuilderbut that requires a lambda. I want to do this from Python and I'm concerned that writing the lambda will not be elegant and/or performant. My current approach is to use Ops (
ij.op().run("copy.rai", result, rai)) but @haesleinhuepf says in imagej/pyimagej#46 that it is too slow and must be fixed immediately.
Source< ? >and the
Source< ? extends <Volatile< ? >>. An alternative to twice calling the private
loadTimepoint()method via reflection seems to be to simply use
transformedSource.setFixedTransform( transform ). This also properly updates the BDV. I don't understand yet what the pros and cons are...
SourceAndConverter, you need to null check the volatile source and apply identical operations on both the volatile and non volatile source...
Could someone please help me? I have a BDV with only one source shown, and, correctly, below function returns me a list with one index:
However, when I let the user select a bounding box using (from bdv-core)
new TransformedRealBoxSelectionDialog( ... ).getResult()
above command (
bdv.getBdvHandle().getViewerPanel().getState().getVisibleSourceIndices();) returns me a list with two indices. My first guess is that the
TransformedRealBoxSelectionDialog maybe does not properly "clean up" the temporary overlay that it generates? Or am I doing something wrong?
IJ.wait( 100 );in-between it does show the correct number of sources. I think reason must be that the
TransformedRealBoxSelectionDialogreturns its results already before it cleans up. I'll try to fix it and submit a pull-request later.