Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projection mode changer #73

Merged
merged 12 commits into from
Jan 21, 2020
Merged

Projection mode changer #73

merged 12 commits into from
Jan 21, 2020

Conversation

tischi
Copy link
Collaborator

@tischi tischi commented Jan 18, 2020

No description provided.

@tischi tischi requested a review from NicoKiaru January 18, 2020 18:18
@tischi
Copy link
Collaborator Author

tischi commented Jan 18, 2020

Hi @NicoKiaru ,

I mainly implemented methods to make the ProjectionModeChanger work: https://github.com/bigdataviewer/bigdataviewer-playground/blob/projectionModeChanger/src/test/src/sc/fiji/bdvpg/bdv/ProjectionModeChangerDemo.java#L14

Along the way, as discussed, several other things were touched, e.g. one interface was removed.

The naming conventions are not consistent, see here: #72

I suggest, we fix this with another PR.

@tischi tischi mentioned this pull request Jan 19, 2020
@@ -96,6 +96,6 @@
/**
* Finds the corresponding registered sac for a source.
*/
SourceAndConverter getSourceAndConverter( Source source );
SourceAndConverter getSourceAndConverterFromSource( Source source );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this function new ? I don't remember where it comes from, but since you can have multiple SourceAndConverter for an identical Source, we should remove it and keep only the function getSourceAndConvertersOfSource.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf COmment, this should return a List

@NicoKiaru
Copy link
Collaborator

Should I review it ? Is it ready ?

@tischi
Copy link
Collaborator Author

tischi commented Jan 19, 2020

Should I review it ? Is it ready ?

Yes, please. I think we could merge it.

@NicoKiaru
Copy link
Collaborator

OK, I start the review now

Copy link
Collaborator

@NicoKiaru NicoKiaru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should address the problem between linking Source and SourceAndConverter

if ( source instanceof TransformedSource )
source = ( ( TransformedSource ) source ).getWrappedSource();

SourceAndConverter sac = SourceAndConverterServices.getSourceAndConverterService().getSourceAndConverterFromSource( source );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could fail because a Source can have different converters and thus exists in different flavors. One Source -> 2 SourceAndConverters, one with a gray LUT and one with a completely different LUT, for instance.

We have to think about that, but that's a major issue. I had to deal with this in the remove(SourceAndConverter, BdvHandle) function from the display service, you should have a look at it and then let's rediscuss this. Maybe there's no better way...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed! See conversations below.

Comment on lines 3 to 10
public class ProjectionTypes
public class Projection
{
public static final String PROJECTION_MODE = "Projection Mode";
public static final String PROJECTION_MODE_SUM = "Sum";
public static final String PROJECTION_MODE_AVG = "Avg";

public static final String MIXED_PROJECTOR = "Mixed Projector";
public static final String SUM_PROJECTOR = "Sum Projector";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf comment above, maybe change this to int to fasten the computation

Copy link
Collaborator Author

@tischi tischi Jan 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I could do this, but long term I think an enum would be the cleanest.
The only reason I was choosing String constants was because this is the only thing that works in Command choices. Thus, using ints not would make it more complicated because we have to implement the constants twice.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll investigate the performance and report back

Comment on lines 243 to 262
@Override
public SourceAndConverter getSourceAndConverterFromSource( Source source )
{
final List< SourceAndConverter > sacs = getSourceAndConverters();

for ( SourceAndConverter sac : sacs )
if ( sac.getSpimSource().equals( source ) )
return sac;

// Try again, with unwrapping; (TODO: do we need this?)
if ( source instanceof TransformedSource )
source = ( ( TransformedSource ) source ).getWrappedSource();


for ( SourceAndConverter sac : sacs )
if ( sac.getSpimSource().equals( source ) )
return sac;

return null;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part I have major concerns. First part :

  • a Source can have muliply linked SourceAndConverter
  • a TransformedSource is different from a Source, so we should be able to set different projectors and properties if we deal with a Source or one of its transformations

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I had the same problem. I wrote a some text about it below, which you probably did not see. I paste it here again:


The AccumulateProjectorFactory in bdv work on a list of Source and not SourceAndConverter, which is quite unfortunate for us, because I need to get the metadata (projectionMode) for each Source. I thus added a function to our SourceAndConverterService that returns the SourceAndConverter for a Source. I am now very confused, because in our framework (e.g. due to SourceAndConverterDuplicator) there could be multiple SourceAndConverter for the same Source java object, in principle with different metadata. Currently the function I added (i.e., getSourceAndConverterFromSource) simply returns the first matching SourceAndConverter.

I am not sure how to handle this properly, i.e. how to figure out to which SourceAndConverter the Source belongs.

Do you have some ideas?

Question that come to my mind is:

Do we really need the SourceAndConverterDuplicator or can we avoid having this? I checked for its usages and it is only used by the SourcesDuplicatorCommand. As the code does not need it, do your users need it or could you provide similar functionality differently?
If we really need the SourceAndConverterDuplicator, could we wrap the Source that we put into the new SourceAndConverter such that it becomes a different and unique java object? E.g., make a DuplicatedSource( source )?
What are the other places where we wrap a Source into a SourceAndConverter? Could we also there wrap the Source into a unique object?
Could/Should we enforce that the metadata for a Source is unique? That is, we would not allow different SourceAndConverter for the same Source to have different metadata?
If you do not know a solution I would ask on gitter.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's how I dealt with this issue in the remove from display :

/**
* A reflection forced access to ViewerState.removeSource(int index)
* protected void removeSource( final int index )
* is necessary because the SpimSource is not precise enough as a key : it can be displayed multiple times with different converters
* all following calls fail:
* bdvh.getViewerPanel().getState().removeSource();//.removeGroup(sg);//remove(index);//.removeSource(source.getSpimSource()); // TODO : Check!!
*/
removeSourceViaReflection(bdvh, index);

@@ -96,6 +96,6 @@
/**
* Finds the corresponding registered sac for a source.
*/
SourceAndConverter getSourceAndConverter( Source source );
SourceAndConverter getSourceAndConverterFromSource( Source source );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf COmment, this should return a List

@NicoKiaru
Copy link
Collaborator

NicoKiaru commented Jan 20, 2020

The link between Sourceand SourceAndConverter is done in the method createProjector of the class MultiResolutionRenderer.

With:

  • the function: bdvHandle.getViewerPanel().getState().getVisibleSourceIndices()
  • a reference to BdvHandle being used by the factory
  • an access to BdvHandleReferences of the display service

We should be able to reconstitute the sequence that led to the projector factory call, and retrieve from which SourceAndConverter a Source comes from.

Another option would is to get the first SourceAndConverter that comes (as it is currently but it will fail sometimes). But we could make this assumption for now and see if the new BigDataViewer state in bigdataviewer/bigdataviewer-core#68 allows us to find more easily the link between Source and SourceAndConverter

Copy link
Collaborator

@NicoKiaru NicoKiaru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks all ok

@NicoKiaru NicoKiaru merged commit 10463f3 into master Jan 21, 2020
@NicoKiaru NicoKiaru deleted the projectionModeChanger branch January 21, 2020 07:53
@tischi
Copy link
Collaborator Author

tischi commented Jan 21, 2020

Great work!
Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants