On Wed, 18 Nov 2015 11:16:56 +0100 Stefan Mark <m...@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 <d...@frign.de>
