core: Add custom bit depth field

[feliwir]

This change allows specifying custom bit depths as specified in #351
By itself this change allows to encode 10bit & 12bit PPMs which is a requirement for testing changes proposed in #349

E.g. i can save the decoded 10bit & 12bit JPEG files now (PR will arrive after this one):

[etemesi254]

This has to be approached with care, the depth is important in other places especially in the imageprocs function, so will spend some few days checking that it works.

But appreciate the effort in starting it.

[feliwir]

I choose this approach to stay API compatible. I'd prefer not having an enum at all, but i think that would be a breaking change.

[etemesi254]

how would you represent different depths? disregarding apis?

[feliwir]

Well, the bit depth would just be an integer (u8) without an enum in my opinion. Because an amount of bits is always a variable number and there might be anything really from 0-32. Maybe we have 64bits depths in the future :)

Currently the API limits us to three possible presets (8, 16, 32). Additionally it also mixes in the scalar type (float or integer). This is not directly related to the bit depth in my opinion

[etemesi254]

And what datatype would represent them?

Because at the end of the day you need to tie it to a number a computer can manipulate.

[feliwir]

I totally agree that a datatype needs to be selected. However the current API is misleading, because there are also 8 & 16bit floats, and there are also 32-bit integers.
So in my imagination there should be a way to select the data type (signed integer, unsigned integer or float) and a function to select the bitdepth (a arbitary number). In case of an unsupported / invalid combination the encoder should notify the user by returning an error

[etemesi254]

ignore the encoding for now

how would you perform operations ?

a simple operation is like increasing exposure so its usually 'clamp(num*exposure_value,MAX_SIZE,VAL)'

depth of 'f32' represents floating type images which are between 0-1 generally not MIN_FLOAT-MAX_FLOAT

[feliwir]

I know that float image data is usually between 0-1. I am not sure how that is related to the API change proposal though

[etemesi254]

It is unrelated, just trying to pick your brain on what a better design would be, maybe one day could add it.