Incorrect image size returned by SubBlockStatistics about libczi HOT 4 CLOSED

Please see the discussion here - this seems to be the same topic.

from libczi.

Thank you for the detailed answer. Although I can understand why the reported size is reported as such I would consider that a bug. There is only one image size in pixels independent of how data storage is organized. When pyramidal levels are computed from this original size there's no ambiguity on their sizes nor to what the original size is. Moreover, the correct size is reported by the Zen software as well as embedded meta-data.

I can submit a fix pull-request if you decide this is an issue. Otherwise I'll be using my own block enumeration and image statistics for now.

from libczi.

I chose to extend "SubBlockStatistics" in order to provide both size-definitions - because both are reasonable and both are in use. It is conceivable to have files without any layer0-subblocks at all, so relying only on layer0-subblocks is not sufficient.

from libczi.

That sounds like a great solution for the problem! Thank you!

I'm guessing the no layer 0 image is a degenerate case that is possible in format but unlikely to happen, do you have any situations when that is needed? I would feel that in that case the highest resolution available effectively is level-0 and should be stored as such, pixel resolution parameters should be adjusted along with objective magnification and other metadata and the image would be completely valid.

from libczi.