Description
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
?