Anyway, it's three orthoviews into an N5 volume, sharing the same cache, with a mutation to the cache at the end (blacking out a block) being immediately reflected in all three views, which is the basis for painting.
Did you end up using a proxy stack to share the cache?
@tomka @aschampion, do i have a way of getting the pixel value of the label layer when clicking?
Yes, in the
feature/label-stack-manager branch StackLayer has a method pixelValueInScaleLevel: https://github.com/catmaid/CATMAID/blob/features/label-stack-manager/django/applications/catmaid/static/js/layers/stack-layer.js#L520
it takes stack space coordinates
For the purposes of getting something working you can get a stack layer via
project.getStackViewers()[0].getLayer('StackLayer')
I only know about the h2n5 setup of the ortho-stacks for v14. If you could point us to an example with a label stack, we could use this as an example. The stack mirror path for the ortho views looks like this:
http://bocklab.hhmi.org/h2n5/tile/volumes/raw/%SCALE_DATASET%/0_2/256_26/%AXIS_0%/%AXIS_2%/%AXIS_1%. And we started h2n5 just in its most simple form: h2n5 <path-to-n5>.
Label stacks work the same. The H2N5 tile source path in CATMAID is just the relative path from the root of the n5 you're running h2n5 on. So
http://localhost:8088/group/dataset/etc/%SCALE_DATASET%/[slicing dimensions]/[tile size]/%AXIS_0%/%AXIS_1%/%AXIS_2%/, permuting the AXIS substitution parameter order as necessary for xyz, xzy, etc.
Copying from Slack: We made some progress. We could get
h2n5 to show the image data using this URL: http://127.0.0.1:8088/tile/raw/data/%SCALE_DATASET%/0_1/256_256/%AXIS_0%/%AXIS_1%/%AXIS_2%, but struggle to get the labels shown. With http://127.0.0.1:8088/tile/labels/unique-labels/%SCALE_DATASET%/0_1/256_256/%AXIS_0%/%AXIS_1%/%AXIS_2%`. We seem to get binary data back and the browser complains with code 501 (Data type does not have an image renderer implemented), which sounds promising. We tried to use the Randomised Label Color Map, but this doesn't seem to change anything.
The browser also only seems to attemt the first request which returns with 501, and after that all further requests are canceled.
err `n5gest ls <n5_directory.n5>
uint64 labels don't work yet, see the tested/supported table here: https://github.com/catmaid/CATMAID/issues/1801#issuecomment-438747065
And I think the
unique-labels dataset from Paintera is an index of labels, not a label map
Which is why the shapes are incompatible
If you're using H2N5, the only way is to still use float32 labels
Actually the
dev branch of h2n5 already includes the channel packing
So if you can figure that out, then truncate the labels to 32 bits, you could either try to use h2n5 with channel packing, or use the
features/image-block-layer CATMAID branch to access the N5 directly.
Both of those have been tested.
This should installconda update -c hanslovsky painterapaintera-0.8.1. It will also installpaintera-conversion-helper-0.4.0, I made a separate package for that tool for better versioning. I tested very briefly and as far as I can tell, scalar label support works now. Let me know if you encounter any issues.
This is how I created a data set with scalar labels, notice the--winner-takes-all-downsamplingoption:paintera-conversion-helper -r -d /home/hanslovskyp/Downloads/sample_A_padded_20160501.hdf,volumes/raw,raw -d /home/hanslovskyp/Downloads/sample_A_padded_20160501.hdf,volumes/labels/neuron_ids,label -o /data/hanslovskyp/sample_A_padded_20160501-bs=64-winner-takes-all-n5-lookup2.n5 -b 64,64,64 -s 2,2,1 2,2,1 2,2,1 2,2,2 2,2,2 2,2,2 --winner-takes-all-downsampling --label-block-lookup-backend-n5=10000
Those are his instructions for the scalar labels
For my own future reference: the next steps for 64 bit support were updating the
ObjectLabelColorMap shader to shader version 300, making shaders generic/specializable to the datatype of image stacks, and setting the right GL parameters in the image block layer
(I'm on dev branch and start the devserver): After a few seconds, I get an " File "....python3.7/site-packages/asgi_ipc/store.py", line 45, in mutate_value
raise self.deadlock_error
RuntimeError: Semaphore appears to be deadlocked. Kill all channels processes and remove files named like asgi-messages in /dev/shm
"
raise self.deadlock_error
RuntimeError: Semaphore appears to be deadlocked. Kill all channels processes and remove files named like asgi-messages in /dev/shm
"
What could be the problem here?
Nevermind. I removed the locks from /dev/shm and things seem to work again.
Yeah, unfortunately
runserver does start a minimal ASGI server as well that uses shared memory (/dev/shm) for inter-process communication. I typically run in therefore typically as runserver --noasgi and the deadlocks are gone. In production we use Daphne for our WebSockets/ASGI needs.