On 6 January 2015 at 04:11, via Digitalmars-d <[email protected]> wrote: > On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote: >> >> Yeah, in my misc repo, there used to be stand along image.d and >> simpledisplay.d. Now, they both depend on color.d. Even just a basic >> definition we can use elsewhere is nice to have so other libs can interop on >> that level without annoying casts or pointless conversions just to please >> the type system when the contents are identical. > > > Yes, that too. I was more thinking about the ability to create an adapter > that extracts colour information from an existing data structure and adds > context information such as gamma. Then let you build a function that say > reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit > RGB pixel with gamma correction and the residue in a specified format > suitable for dithering... ;-] > > It is quite common error to do computations on colours that are ignorant of > gamma (or do it wrong) which results in less accurate imaging. E.g. When > dithering you need to make sure that the residue that is left when doing bit > truncation is added to the neighbouring pixels in a "linear addition" > (without gamma). Making stuff like that less tedious would make it a very > useful library.
I have thought about how to handle residue from lossy-encoding, but I haven't thought of an API I like for that yet. Dithering operates on neighbourhoods of pixels, so in some ways I feel it is beyond the scope of colour.d, but residue is an important detail to enable dithering that should probably be expressed while encoding. Currently, I have a colour template which can be arbitrarily typed and components defined in some user-specified order. It binds the colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is defined and performs arbitrary conversions between colours. I'm finding myself at a constant struggle between speed and maximizing-precision. I feel like a lib should maximise precision, but the trouble then is that it's not actually useful to me... Very few applications care about colour precision beyond ubyte, so I feel like using double for much of the processing is overkill :/ I'm not sure what the right balance would look like exactly. I can make fast-paths for common formats, like ubyte conversions between sRGB/Linear, etc use tables. Performing colourspace conversions in fixed point (where both sides of conversion are integer types) might be possible without significant loss of precision, but it's tricky... I just pipe through double now, and that's way overkill. I'll make a PR tonight some time for criticism.
