Phobos colour module?

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 6 01:19:45 PST 2015


On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:
> On 6 January 2015 at 04:11, via Digitalmars-d
> <digitalmars-d at puremagic.com> 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.

What's wrong with old-fashioned `Fast` postfixes on entry points 
where a faster but less precise method is available? Or template 
arguments like std.algorithm.SortStrategy?


More information about the Digitalmars-d mailing list