jpeg-decoder icon indicating copy to clipboard operation
jpeg-decoder copied to clipboard

Introduces functionality for optionally returning incomplete pixel data

Open quilan1 opened this issue 3 years ago • 1 comments

Thought I might start the conversation around a manner in which one could recover partially rendered image pixel data from a corrupt or partially invalid jpeg file.

Still to do / discuss:

  • [ ] Add a test image, but I'm not 100% sure where to put it, and/or write a test for it.
  • [ ] Decide on the error format: Should only one error be stored? If multiple errors are recoverable, should this be a vector of Errors? Or just the first one?
  • [ ] Should the TryRecover trait be externally visible, or rather a new decode function made? (and pull the recovery machinery inside)

Just wanted to throw out a minimally invasive rough draft, perhaps to start some thinking about things.

======================

Currently, this library is rather rigid, with respect to the specification. If an error occurs while decoding the stream, the error is returned and recovery of the partially decoded image is impossible.

However, there are some occasions where it may be possible, to return the potentially incomplete image data. In this case, the try_recover function may be used on the result of the decode function. If the data supports recovery, the incomplete pixels are returned, but if not, it simply returns the error.

Added the TryRecover trait, the Error::Recoverable condition and implemented a simple example usage -- if an image does not have an EOI segment, it yields a recoverable error.

Usage of the functionality is straightforward:

use jpeg_decoder::TryRecover;

let mut decoder = Decoder::new(File::open("missing-eoi.jpg")?);

// Bails with an IO error about UnexpectedEof
// let pixels = decoder.decode()?;

// Returns the incomplete pixel data of the image
let pixels = decoder.decode().try_recover()?;

quilan1 avatar Jul 10 '22 16:07 quilan1

I've added my thoughts on idiomatic code style above but in terms of functionality, I do believe this is already decently covers a few cases. We clearly signal when a result is not standard compliant (except for implementation bugs) but have an interface to return the main decoding result as far as possible nevertheless.

Finding a non-license encumbered test is always a hassle. However, as a guidance you can add a subfolder tests/recover structured similar to reftest. I'm not sure which properties we even want to test for these images, though. Maybe start with asserting that a recoverable error is returned without checking the exact contents?

197g avatar Jul 10 '22 22:07 197g