Closed tischi closed 3 years ago
Not sure I can help...
Maybe it's obvious, there's no need to always write a serializer (in gson terms an Adapater implements both the serializer and deserializer). That's only needed when you want to control how it is created. This link about control of object type can be useful : https://github.com/google/gson/blob/master/extras/src/main/java/com/google/gson/typeadapters/RuntimeTypeAdapterFactory.java
Maybe few considerations, taking the coloringModel
as an example:
{ "segmentationDisplay":
{ "coloring" : {
"lut" : "glasbey",
"alpha" : 1.0
},
"selection" : {
"selectedSegments": [...]
}
}
}
vs.
{ "segmentationDisplay":
{
"lut" : "glasbey",
"alpha" : 1.0,
"selectedSegments": [...]
}
}
coloringModel
is in fact not much more than a Converter< RealType, ARGBType >
and could potentially be serialized as such. @NicoKiaru do you have a way of serialization for this already? We would need support for special LUTs and also an alpha (blending) value. If @NicoKiaru needs to serialize such objects also for the playground then for compatibility reasons maybe we should try to use the same code, if possible.So there's an extensibility mechanism for serialization in bdv playground. Maybe the serializer can live in mobie, and just be caught in bdv playground. We can discuss this. That leaves you the flexibility of putting the converter that you'd like, serialiazing it the way you want, and still being compatible with bdv playground.
Some feedback from my side:
there will be a lot (if not all) of the MoBIE code being called from within those Serializers, because MoBIE is all about generating these views. Thus I am a bit confused about the best practice for doing this...
I think this depends on the context of how you are using the objects that are deserialized. Is there a value of having a "not fully build" version of the object? As an example, let's take a segmentation that has a table directory. We currently have different "levels" of building the object representing this:
default.tsv
This represents different degrees of lazyness/eagerness. I think it's clear that 3 does not make sense, because you would load tables that might never be selected by the user. 1 and 2 would both make sense, and the choice depends on whether there is some advantage of having the intermediate state 1, maybe to do some validation of the view.
Personally I would like to avoid nesting with just a single element, e.g.
{"selection": {"selectedSegmentIds": [...]}}`
for more complex objects with more than one associated field nesting is fine and in some cases even preferable, e.g.
{
"scatterPlot": {"show": true, "axes": [...]}
}
is I think better than
{
"showScatterPlot": false,
"scatterPlotAxes": [...]
}
As a general comment I would very much like to avoid serializing java class names in order to keep the spec language independent.
@K-Meech The serialization can be done in many ways and I am still not sure what is the best. I thus suggest that we do the bookmark creation as the very last thing after we have all other things sort of stable in the new version.
No worries @tischi - makes sense! Also, if there are other refactoring parts I can help with, then let me know. I'll have some time after the easter holidays.
I think all of this is outdated and was solved by the new view concept. Reopen if something here is still relevant.
@constantinpape (cc @NicoKiaru)
I know, in the end it's my job, but I would be grateful for some input. Below is one important MoBIE class that contains all the information that is needed to visualize label mask images.
I don't know how complex it will be but I have a feeling now that we should get rid of the JSON fields and instead implement
Serializers
for all the classes; this would also naturally structure the JSON by adding fields likecoloringModel
a.s.o.However(?), since some of those objects are quite heavy to instantiate this could mean that there will be a lot (if not all) of the MoBIE code being called from within those Serializers, because MoBIE is all about generating these views. Thus I am a bit confused about the best practice for doing this...