-
Notifications
You must be signed in to change notification settings - Fork 57
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
Label stack support #1816
Label stack support #1816
Conversation
This more cleanly separates functionality related to stack display from tile-specific display and is necessary for future layers that render stacks from volumetric blocks.
Remove useless float margin around layer control. Consequently it is not slightly wider by default.
This will enable support for non-premultiplied blend modes in future Pixi versions.
7bf0ae1
to
584083d
Compare
def stack_groups(request, project_id=None, stack_id=None): | ||
stackgroup_links = StackStackGroup.objects \ | ||
.filter(stack=stack_id) \ | ||
.select_related('group_relation') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is group_relation
joined here? It seems below only the stack group ID is needed and we could basically use .values_list('id', flat=True)
to get the result list of IDs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's vestigial from including the relation type with the group links, before I decided to just retrieve the groups explicitly anyway (thinking I might put the raw/label enum on groups). Will remove.
// Find if an existing manager for any of these stack groups exists. | ||
let managing_stack_id = ortho_sgs.find(sg => this.groupManagingStack.get(sg.id)); | ||
|
||
if (typeof managing_stack_id !== 'undefined') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity: Is there any benefit in using this over managing_stack_id !== undefined
(which seems easier to read to me)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since managing_stack_id
is declared in this scope, no benefit. Will fix.
// If this is a label stack, not a raw stack, create a label annotation | ||
// manager. | ||
// TODO: should eventually use a backend image label space instead. | ||
if (!!stack.labelMetadata()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, using the metadata
field of a stack is reasonable for now. Once the whole infrastructure is there and becomes clearer how everything works together, we can think about the label space implementation again.
Great! All the changes look good to me, except maybe for this one join of (how it looks like) unneeded information. |
This is the first block of changes from #1801.
The main new functionality of this branch is that stacks whose metadata has a special property,
catmaidLabelMeta
, will automatically be rendered as label stacks. Label stacks are rendered with a color map filter and with nearest neighbor interpolation. The selected label ID in these stacks is synchronized between stacks that are views of the same group.Note that in this PR, few of these features are available without using the console. For example, methods are added for retrieving pixel values from stack layers, and those could be used to select label IDs in the label annotation manager, but wiring this functionality is left for later PRs. Most of the changes here are refactorings to enable those PRs.
On a dev note, this is the first code making full use of ES6.