colour lib needs reviewers

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Mon Sep 12 15:55:01 PDT 2016


On 9/12/2016 8:06 AM, Manu via Digitalmars-d wrote:
> So, the main reason I wanted to push for this in phobos is because
> it's an enabler.
> There is no multimedia in phobos at all. I think that's a shame, and
> this is a starting point. Any conceivable image based work depends on
> this as foundation. If pixel format types are phobos-supplied, then D
> image libraries will naturally be compatible, as opposed to naturally
> incompatible since every image library will otherwise re-implement
> their own colour types (and almost always incorrectly).
> The thing about colours is, they're HARD to get right, but more
> importantly, most programmers have no idea that it's actually a hard
> problem and won't tend to go looking for a lib for a colour type (Ie,
> struct { ubyte r, g, b;}... simple! *cough*). They probably will use
> it if it's in phobos though for compatibility reasons.
> Image processing is super easy by contrast.
>
> One of my first port-of-calls after this work would be a graph/plot
> library... I'd use the hell out of that. I constantly want to output
> data visualisations!
>
> It also enables seamless interaction with realtime rendering api's.
> Ie, if OpenGL/D3D/Vulkan bindings support phobos supplied colour
> types, then image decoding libraries, and other sources of image data
> become easy to render without any requirement for adaptation.
> Rendering libs and image/video data source libs are almost always
> separate, independent libraries. We need to maximise probability that
> they are compatible out of the gate.
>
> I didn't want to touch 'images' in this work, because there are
> countless subjective designs to present those API's, but I don't think
> there's many competing designs for a colour library, so it felt it was
> the best and most bang-for-buck starting place overall.
>
> Also, I think this has very high synergy with ndslice. I think ndslice
> +  color is the foundation for image processing, or at least image
> data transport.

Thanks for the rationale. I'm glad to see you're planning follow-on libraries! 
I'd use a graph/plot library myself. Some of the rationale above should go into 
the documentation for the library.



More information about the Digitalmars-d mailing list