Color-arithmetic should _probably_ be done in linear-color space and not sRGB

[Wunkolo]

I believe right now all image-arithmetic is operating upon image color values that are within the non-linear sRGB color-space. So operations upon them like sums and averages and conversions may not be indicative to the actual underlying linear color values and may have to be converted from sRGB into linear color space before producing the DCT, and then back into sRGB when intended to be presented to the user.

Ex, sections of code like here should probably be converting the sRGB pixel data into linear before converting into LPQA:

thumbhash/rust/src/lib.rs

Lines 41 to 51 in df761ae

	// Convert the image from RGBA to LPQA (composite atop the average color)
	for rgba in rgba.chunks_exact(4) {
	let alpha = rgba[3] as f32 / 255.0;
	let r = avg_r * (1.0 - alpha) + alpha / 255.0 * rgba[0] as f32;
	let g = avg_g * (1.0 - alpha) + alpha / 255.0 * rgba[1] as f32;
	let b = avg_b * (1.0 - alpha) + alpha / 255.0 * rgba[2] as f32;
	l.push((r + g + b) / 3.0);
	p.push((r + g) / 2.0 - b);
	q.push(r - g);
	a.push(alpha);
	}

The default behavior for many image-loading libraries is to provide image-data in the sRGB color-space with no conversions as well.