Gamma correctness

[theotherphil]

The code in this library assumes that the input intensities are encoded in a linear colour space, but in the majority of cases they won't be. What's the best way to handle this? In many cases the user might not care about the distinction, but we should arrange the types/traits so that you can't accidentally ignore the fact that you're treating non-linear inputs as if they were linear.

I've added examples/blend.rs showing how interpolate currently does the wrong thing for RGB images.

[Reisz]

Gamma correctness is actually more important, than most people think (see here).

In my opinion, every image processing API should work in linear space (as the algorithms expect) and convert from/to gamma-encoded on loading/storing. I would suggest the following API for loading/storing:

• load(path) Loads image and decodes from sRGB
• load_enc(path, encoding: Encoding) Loads image and decodes using various encodings. Options should include linear, as many non-color texture maps in 3d rendering are stored in linear space.

And the same for store of course.

Encoding example:

enum Encoding {
  Linear , sRGB, PlainGamma(f32)
}

[theotherphil]

I agree that it's important to get this correct. I don't have time to look at this myself at the moment. I suspect there's a bit of thinking to be done about how best to handle linear colour spaces - there's a lot of code in this crate that assumes that pixels have eight bits per channel, and just converting everything into 8bpp linear space and back might result in unacceptable loss of fidelity in the most distinguishable intensities. We could support working with f32 subpixels as well, but this will likely be less perfomant, and in any case will require changing a lot of code. I'm open to suggestions (or PRs!).