make the jpeg encoder work with non-memory and non RGB8 images

[lovasoa]

Change the JPEG encoder to work on a GenericImageView instead of a byte slice

This change allows users to encode jpeg images from other sources
than memory, thus finally allowing the encoding of images that
do not fit in memory.

This also allows users to make the encoder work in a streaming fashion.
(see #1219)

This also finally allows encoding images from other pixel formats than
8-bit RGB. The conversion to 8bit YCbCr (used in JPEG) is done on the fly
during encoding.

I need this change for dezoomify-rs.

I license past and future contributions under the dual MIT/Apache-2.0 license,
allowing licensees to chose either at their option.

[HeroicKatora]

I'm not sure how being generic over GenericImageView solves the problem of not holding all of the image in memory. It seems to me that loading from an external memory such as the file system is inherently fallible and the interface for accessing pixels can not properly express this. Can you expand on how the interface is intended to be used for this purpose?

[lovasoa]

Hi @HeroicKatora !

In dezoomify-rs, I handle missing image parts by writing black pixels in them. But this is up to the application developer to choose what to do. Anyway, I really don't think it's excessive to ask for image pixels to be infaillibly accessible when encoding an image. What do you think about the PR overall?

[fintelia]

Do we know whether this change leads to any performance regression?

[HeroicKatora]

Anyway, I really don't think it's excessive to ask for image pixels to be infaillibly accessible when encoding an image.

Any I/O operation is fallible be it disk failure, network failure, or data corruption. The strategy of using replacement pixels doesn't sound too bad for your application, it seems like a reasonable fallback. It only doesn't seem generically applicable.

On the PR itself I'm fine with the interface. It even seems to add support for bgr8 which is awesome. There's only the performance question raised by @fintelia, then you got a 👍 from my side.

[HeroicKatora]

The performance doesn't seem too bad overall, and we have a likely fix in the pipeline. Overall, this unlocks many interesting possibilities for the jpeg encoder. Besides images stored externally (for which I don't consider this interface perfect but for which it is better than nothing) this includes lazily computed images. That's definitely note-worthy.

This also only adds little additional API: a single method. The only problem is that of color conversion but we already require the methods from Pixel alone so it should not be the concern of this PR. Any replacement is likely to have an alternative trait bound available and requires a major version anyways.

[lovasoa]

Awesome! Thank you for merging. Would you be interested in a pull request adding the YCbCr pixel type to image-rs, allowing to avoid unnecessary back-and-forth colorspace conversions when the original image is already in YCbCr ?