Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrew Champion
    @aschampion
    The issue is that there are cases where because of floating point epsilon going to the next section will floor back to the same section in stack coordinates, which drags the stack viewer back to the same section, which drags nav back to the same section
    I think 4c52ce7 may no longer be relevant anyway, because we do now query a fat bounding box for the node query
    Plus rounding stack coordinates would be more consistent with nearest neighbor interpretation
    Tom Kazimiers
    @tomka
    Great to see N5 data directly in the browser! Regarding 4c52ce7, my main problem with round() was that it would often lead to orthoviews with tracing data where you wouldn't see the same node in one view that is selected in another. I am happy to consider alternatives though, as long as they don't break the user expectation of visible tracing data in orthoviews. Wouldn't it maybe work to floor(( (x - x_translation) / res_x) + epsilon) in each dimension? I agree though that rounding stack coordinates would be more consistent. Maybe the current goal that an active node is visible in all orthoviews at the same time isn't reasonable in the first place. I remember though users were confused when this wasn't the case (before 4c52ce7) and they traced in one view, pressed a to center and continued in another view and not seeing a new edge linked to the centered node in the orthoviews.
    Andrew Champion
    @aschampion
    Oh, I see what you mean, since the node query bounding box is from (stack viewer's primary stack) [z, z+1)
    Will see if epsilon padding can fix
    Andrew Champion
    @aschampion
    @tomka I think floor((x - x_translation) / res_x + x * epsilon) works for most cases, seem fine?
    Philipp Hanslovsky
    @hanslovsky
    Aparrently I never use scalar label types, discovering a few bugs on the way.
    Andrew Champion
    @aschampion
    No worries, still haven't had a chance to run the WTA paintera conversion on Ella's data yet. Just abusing the float bits as integer labels has been enough for getting the label visualization working so far.
    Philipp Hanslovsky
    @hanslovsky
    Luckily the fixes are easy, so it should be quick
    Philipp Hanslovsky
    @hanslovsky
    I will merge saalfeldlab/paintera#164 once travisCI checks complete/succeed, then Paintera should be good to go for scalar label types. I will also release paintera-conversion-helper with winner-takes-all downsampling to create the appropriate datasets.
    Philipp Hanslovsky
    @hanslovsky
    conda update -c hanslovsky paintera
    This should install paintera-0.8.1. It will also install paintera-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-downsampling option:
    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
    Please make sure that
    paintera --version
    [JavaFX Application Thread] INFO org.janelia.saalfeldlab.paintera.PainteraCommandLineArgs - Paintera version: 0.8.1
    Andrew Champion
    @aschampion
    Video uploads in gitter? I guess not.
    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.
    Tom Kazimiers
    @tomka
    Awesome!
    Did you end up using a proxy stack to share the cache?
    Andrew Champion
    @aschampion
    Yeah, it ended up being a pretty elegant solution.
    Ella Bahry
    @bellonet
    nice!!
    @tomka @aschampion, do i have a way of getting the pixel value of the label layer when clicking?
    Andrew Champion
    @aschampion
    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')
    Ella Bahry
    @bellonet
    thanks!! will try it tonight.
    Ella Bahry
    @bellonet
    hi andrew, im here with tom, and will try to see if we can upload labels to catmaid. should the n5 format be exactly in the format i've sent you for the previous data?
    Ella Bahry
    @bellonet
    when we're specifying image mirrors in "image base" path - what do we need to specify for a local path?
    Tom Kazimiers
    @tomka
    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>.
    Andrew Champion
    @aschampion
    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.
    Tom Kazimiers
    @tomka
    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.
    Andrew Champion
    @aschampion
    What dtype is the dataset?
    Tom Kazimiers
    @tomka
    We are not entirely sure, is there a way we can check?
    Andrew Champion
    @aschampion
    Look at the dataType key in labels/unique-labels/s0/attributes.json
    err `n5gest ls <n5_directory.n5>
    Tom Kazimiers
    @tomka
    Okay, thanks. It is uint64
    Ella Bahry
    @bellonet
    thread 'arbiter:4ea5f3ed-0373-40cf-9ad8-14bd1042bc07:actix-net-worker-43' panicked at 'TODO: block ndarray failed: ShapeError/IncompatibleShape: incompatible shapes', libcore/result.rs:1009:5
    Tom Kazimiers
    @tomka
    This is what h2n5 logs on requests
    Andrew Champion
    @aschampion
    uint64 labels don't work yet, see the tested/supported table here: https://github.com/catmaid/CATMAID/issues/1801#issuecomment-438747065
    Ella Bahry
    @bellonet
    what should they be?
    Andrew Champion
    @aschampion
    Further, that table is for the features/image-block-layer, which is accessing N5 directly, bypassing H2N5
    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
    Tom Kazimiers
    @tomka
    Oh okay. So we probably can't make it work with this dataset?
    Andrew Champion
    @aschampion
    And you'll need the features/channel-packing branch of H2N5, which will pack the 32bit values into the RGBA channels (with some changes to the URL)
    Actually the dev branch of h2n5 already includes the channel packing
    Tom Kazimiers
    @tomka
    Thanks! But I guess we can't use this (Paintera) dataset then, but would need a different one, correct?
    Andrew Champion
    @aschampion
    Philipp changed paintera so that it can export scalar labels
    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.