Image: Request: Simple Decoding / Encoding Progress

[johannesvollmer]

I want to display how far the image has been loaded so far, probably in a progress bar. Currently, I'm using open<P: Into<Path>>(path: P).

I could imagine passing a callback to the decoder. Maybe we don't even need to modify decoders at all, if we update progress based on how many scanlines have been scanned?

[johannesvollmer]

Please correct me if I am wrong and there already is an easy way to have a progress bar.

[fintelia]

It isn't perfect (and I think support might be missing/buggy for some image types), but you can use the read_scanline function on an ImageDecoder to read an image one row at a time.

[johannesvollmer]

Is a row of jpeg macro blocks considered a scanline, being 8px high? Or do scanlines always have a height of one Pixel?

How can I dynamically determine if a decoder supports scanlines?

[fintelia]

Decoders that don't support scanlines have their ImageDecoder::read_scanline function panic with unimplemented!(). I don't think there is currently any other way to tell. To my knowledge, all image types currently have scanlines with a height of one pixel, though that is probably related to why certain types don't currently implement read_scanline at all. There is definitely room for improvement in the API...

[oyvindln]

Yeah that function as it is now doesn't really make sense on a jpeg image, or other images that use macroblocks like jpeg, as you would need to decode a full row of macroblocks. I suppose one could decode a whole row buffer the data in the decoder, though that does mean extra complexity/memory usage.

I think having a decoder struct that implements Read (and maybe Write as well) would be helpful for this use case, like how flate2 does with zlib data.

[HeroicKatora]

I would try supporting this in any subset of the individual decoders first, for mainly three reasons

• As mentioned above, not all decoders have sensible concept of scanlines. As far as I have understood from the comments, the read_scanline was due to be replaced sooner or later. There are other image formats for which pixels are encoded as square blocks, in a spacial tree or even as additional operations on other image regions. None conform to scanlines.
• We don't break the main API until we have established a usable interface. We also get knowledge about what notions are sensible as we try implementing it individually. @oyvindln I like the idea of using one of the generic interfaces, with better established usability, but many decoders need to allocate large buffers for good efficieny afaik.
• Is scanline even the best final goal? Imagine knowing you will load a very wide but not very high picture (for example a special sprite sheet). In that case, scanline will give you poor progress information. Instead, you'd ideally want to be notified even within a scanline.

[fintelia]

I'd be in favor of an into_reader function on decoders, as an eventual replacement for read_scanlines. That would provide the desired functionality and also avoid the weirdness we currently have between load_rect and read_scanlines (specifically load_rect uses read_scanlines but doesn't have a way to seek backwards if some of the needed scanlines have already been read).

Edit: that or perhaps having the decoder also implement Seek

[johannesvollmer]

I agree, using scanlines for displaying progress would have just been a simple and dirty solution. Some codecs require non-trivial buffer-processing after loading all scanlines, which can only be accounted for by using an individual progress implementation for every decoder / encoder. Otherwise, there would be an incorrect 100% progress, event though the image cannot be considered 'loaded' yet

[HeroicKatora]

This should have been fixed in #819 by providing a read_image_with_progress and released in 0.21.0, can you confirm?

[johannesvollmer]

Yes that's exactly what I was looking for. Thanks so much to everyone who contributed! :)