DigitalSlideArchive / HistomicsTK

A Python toolkit for pathology image analysis algorithms.
https://digitalslidearchive.github.io/HistomicsTK/
Apache License 2.0
393 stars 117 forks source link

Boundary and feature formats #35

Open cooperlab opened 8 years ago

cooperlab commented 8 years ago

Define the formats to be produced by object segmentation and feature extraction.

Boundaries - will need a function to convert a list of 2 x N arrays (x,y) to some format for consumption into Girder.

Features - how to link the feature names to the rows of a K x N array. Would these be consumed into Girder or kept as arrays on disk?

cdeepakroy commented 8 years ago

We can use the pandas dataframe for the features.

cdeepakroy commented 8 years ago

For boundaries, could we use a label map instead?

cooperlab commented 8 years ago

@cdeepakroy Label maps are fine. Great for supporting additional processing but not ingestion friendly. It looks like we are going to have programmatic commits of the boundary polylines so an intermediate ingestion-friendly format is probably not needed.

cooperlab commented 8 years ago

Compression will be important to keep the label image sizes down. LZW should work great for this.

cdeepakroy commented 8 years ago

For label maps something like run-length encoding will save a lot of space since i would exprect these label maps to be quite sparse in number of non-zero valued pixels.

cooperlab commented 8 years ago

They will compress very nicely. Still may want to go with single or uint32 types here for when they are in memory.

cooperlab commented 8 years ago

@slee172 - please test performance for reading / writing features to HDF5. Let's get some insights from @cdeepakroy on how the features will stream out of the pipeline. Tiles are processed in parallel - so will each tile generate a unique HDF5? Should we try to aggregate the features from multiple tiles into 1 file per slide?

HDF5 provides internal structure to provide random access, so if we aggregate tiles we should organize the features for efficient random access.

slee172 commented 8 years ago

@cooperlab I've got the same issue when writing features to HDF5. For 3 slides, it took about 30 min on python, but it took about less than 1 min on c++. I just used c++ instead of python when writing. @cdeepakroy could you inform me a way of processing features when using HDF5 as @cooperlab mentioned?

cooperlab commented 8 years ago

@slee172 that is a significant difference.

Is the interface for writing HDF5 clear, or is it possible we are misusing it and writing 1 record/row at a time?

slee172 commented 8 years ago

@cooperlab The python version I used directly writes the features into HDF5s using h5py package, but c++ version uses thread when processing slides. This is one different between them. I would say we can improve the python version when using multithread on it, but we could find another way if there is.

cdeepakroy commented 8 years ago

@cooperlab What kind of query operations would be doing mostly?

Any other common query use cases?

cooperlab commented 8 years ago

I think that covers the spatial query cases nicely. It's mostly about 1. serving up or analyzing data relevant to the field of view or 2. tile-based parallelization of analyses that are downstream of feature extraction.