> FRIGN <dev_AT_frign.de> hat am 18. November 2015 um 11:49 geschrieben:
>
>
> 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.
An bold +1 written with a fat permanent marker!
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Norman Köhring
Web Engineer
https://koehr.in
Received on Wed Nov 18 2015 - 12:01:03 CET