8000 API discussion · Issue #4 · amspath/libisyntax · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
API discussion #4
Open
Open
@Falcury

Description

@Falcury

BGRA vs RGBA

Right now we are returning pixels in BGRA format, but we could just as easily return them in RGBA. Should we allow specifying a desired pixel format in the API? And maybe for grayscale too (i.e. returning the Y channel without further color space conversion)?

Role of wsi_image_t

Currently we are exposing wsi_image_t handles in the API. Can we get away with hiding this structure as an implementation detail, or is that a bad idea?
And probably we should add accessors for the label and macro images (maybe mapping to the OpenSlide counterparts)?

Role of isyntax_cache_t

Can this also be set as part of the internal state of isyntax_t? I can see why separating it could be useful because the cache might be shared across multiple isyntaxes. But there is also some messiness (which I am not yet sure is necessary). For example, right now internally I end up needi 5378 ng to pass in the isyntax_t's own ll_coeff_block_allocator in isyntax_load_tile(), which seems a bit superfluous:
u32* tile_pixels = isyntax_load_tile(isyntax, wsi, scale, tile_x, tile_y, isyntax->ll_coeff_block_allocator, true);
Another thing: I guess that right now resources associated with a WSI are not freed upon calling isyntax_destroy(), as long as the cache is still alive?

'reader' vs. 'streamer' mode

Should we provide ways to 'hint' how the WSI will be accessed, in order to give optimal performance in each scenario? In a 'streaming' / interactive viewing situation you would might want to proactively/greedily precache substantial parts of the WSI (like is being done in Slidescape), in order to counteract the high latency that may result from needing to multiple successive idwts. Also in that case it might make sense to not evict caches too aggressively (as RAM or VRAM allows). However if you are only interested in getting the pixels of a single specific region, this is probably overkill and not what you want.

read_region() implementation

I would like for libisyntax to (eventually) supply its own read_region() implementation, also correcting for the offset shift in successive levels. (Maybe this is homework for me to do.)

Custom I/O functions

Allowing for custom file access procedures, as mentioned by @bgilbert.

Custom allocators

Should we allow custom allocators, also e.g. for libisyntax_tile_read/ libisyntax_tile_free_pixels?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0