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@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?
