Move from rgba8 internally to rgba32f

[Quackdoc]

Currently oculante uses rgba8 internally. this is fine for a general purpose image viewer, but oculante has a lot of features that make it suitable for use in professional environments. however for a lot of those environments the internal 8bit handling makes this unusable. migrating to rgba32f will open the doors for a lot of workloads, Currently you can already use oculante to for getting specific RGB values. these values are always limited to 0-255.

one such workload is when verifying HDR mapping it's useful to be able to view the images RGB values, however for HDR 10bit+ is needed, and often working with 16bit images (thanks to uint16) which have the ranges of 0-1023 and 0-65535 respectively. and the rounding error can be quite significant. It is useful for many users to be working with 0-255. so it would be optimal to have a way to balance both of course.

working with high bitdepths internally opens the doors for a lot of use cases, from being necessary to HDR support to image verification.

[woelper]

Thanks! This is really high up on my wishlist too. Here are a couple of thoughts:

• The editing operations are already in float and are only reduced to 8 bit in the end. There should be almost no code change necessary in that area.
• rgba32 needs much more texture memory and system memory. Not sure if this is really problematic for the average user, but it could be significant for very large images.
• Relating to above, I've thought about adding two modes, 8 and 32 bit. This would of course make matters more complicated.
• This would potentially gamma issues like Incorrect gamma scaling #91

[Quackdoc]

I could certainly see 32 being an issue on some very low end users, or for very large images like the one I posted with the black loading issue.

at the very least, I do have a machine or two that can be used for preformance testing, an old N3050 laptop, it's pretty low end all things considered, it's no RPI but it should give a decent test once the black screen issue is sorted.

[woelper]

I started this on a branch, but I was not super satisfied as I was searching for a way to keep 8 bit as it is and only use higher bit depth where actually needed. As a next step, I will refactor every RgbaImage to a GenericImage, which should make the float transition easier in the future.

[BitCourier]

From a performance standpoint, even using rgba8 instead of the native image file format seems to be a performance degradation. This hits especially hard when dealing with huge grayscale images (as I do).

What about using "polymorphism" to get the best of all worlds? If the loaded image is 8 Bit, there is no need to use float32 over uint8, or do I get it wrong? If the image is grayscale, only convert to rgb(a) if any operation used needs it. Of course there is a big downside: code complexity.

At least this would be the way I would go.

[woelper]

I've indeed started to use a GenericImage instead of Rgba8 on a branch. Exactly as you say, this comes with code complexity as you have to match/test the image for it's contents everywhere you use it, and implement different operators for it or use different hardware texture formats to make use of the speed gains or memory improvements.

My strategy would be to make the container generic at first and convert to Rgba8 earlt, then gradually change code to accept the generic image and use optimisations.