On Wed, 18 Nov 2015 11:16:56 +0100
Stefan Mark <mark_AT_unserver.de> wrote:
> What i meant, instead of having RGBA and only RGBA, it could have a flag
> that says either which color model is used, (like rgb, rgba, lab,
> monochrome, ...) or define how many color channels the image has, either
> named or by giving the channels wavelength.
you don't need a specialized format for RGB-data. If the alpha-channel
is always 65535 (maximum), the compression will take care of it.
I already went down the LAB-path. It may be the superior colorspace, but
nobody uses it anyway. and it's painful to work with.
monochrome data is a special-case of paletted images, and farbfeld in
its current state is _superior_ in handling this.
If you only have black, green and pink pixels in your image, the
compression algorithm will handle this perfectly. same applies to
greyscale images.
> That would allow for example scientific images to be stored (eg, r,g,b
> channels as well as a few infrared ranges and a bit of uv, maybe imaging
> radar, ...), or arbitrary image-like data (eg pressure, temperature,
> tensile stress, ...), or special colors for printing (eg cmyk and
> metallic color, glow-in-the-dark-color, transparent coating, ...).
The point you are missing here is that RGB is not a color model based on
the true physical perception of color.
LAB gets closer, but you can't really "easily" mix LAB color-data with
IR-data, because we can't see infrared light, and the three axes of the
LAB-color-space only take in regard those color-ranges perceived by our
eyes. I guess you could encode Infrared data, given the axes are
unlimited, but how does this help?
It all boils down to assigning infrared-data to color-data we can
perceive, and there's no reason not just to use Farbfeld RGBA for that.
For instance, when you have an IR-camera from your military drone, you
just map it smartly onto a greyscale 16-Bit range and be done with it.
> For common image purposes, the format would be only a very small bit
> more complex, although it would be much more versatile.
No, it wouldn't be more versatile. It would just suck more and be less
transparent.
> Providing a method to define the amount of dimension used would be nice too.
Yeah, because your proposal isn't complex enough already.
> I dont think so. The changes compared to the original format are pretty
> small.
It's still too complex for someone to keep it in one's head without
having to consult the manual.
It's easy to keep the current farbfeld-format in your head (and I'm not
planning to change it anyway, it already reached 0K on the
Kelvin-software- stability-scale).
"farbfeld" is the magic, followed by width and height in 32-Bit BE
integers, then width*height [RGBA]-chunks, each channel as 16-Bit BE
integers. That's it, nothing more.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Wed Nov 18 2015 - 11:49:26 CET