On 14 September 2016 at 04:10, Random D user via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
>
> In general, I think basics should be dead simple (even over simplified for
> the very basic case)
I think they are:
import std.experimental.color;
RGB8 color("red");
I don't think i's possible to make it simpler than that?
> but the API and the docs should provide me layers of
> increasing detail and sophistication, which I can study if (or when) I
> really need control and care about the details.
I'll work on the docs some more.
> Deprecated by who? Shouldn't phobos grade lib include all reasonable
> platforms?
They're all comprehensively supported, I just didn't pre-instantiate
every possible format imaginable. That would be devastating to compile
times, and have absolutely no value.
BGR really just exists because WINAPI. Microsoft haven't recommended
people write GDI based software for decades.
Look at DX10(,11,12), BGR isn't even supported in modern DirectX.
Microsoft left BGR to die years ago (and good riddance).
That said, there is an instantiation for BGR in package.d... the
reversed versions (ie, alpha first) are completely unusual; just some
big-endian games consoles.
Modern formats have the channels in order; RGB, this is true for all
data types, ubyte, short, float, etc.
> I agree that you probably don't see too much variation within windows APIs,
> images (BMP etc.) or with D3D GPU textures (they're compressed anyway and
> asset pipelines to do the conversions beforehand), but I was more of
> thinking image libraries and the numerous, sometimes old and quirky, image
> formats. Or perhaps someone wants to implement a software blitter for their
> favorite toy device/embedded project.
"favorite toy device/embedded project" <- this is the definition of
specialist task. I don't mind if that person has to type 'alias' at
the top of their app.
>>> For 16 bits fairly common are:
>>> RGB565 and RGBA5551, also sometimes you see one of RGBA4444 permutations
>>> (like RGBA8 above).
>>
>>
>> Nobody uses 16bit textures anymore. Compressed textures are both MUCH
>> smaller, and generally higher quality.
>
>
> Sure, agreed. These are not too useful as GPU textures these days (even on
> mobile), but if you do software 2d, load older image formats (image viewer
> etc.) or something even more specialized, these are pretty useful.
>
> I guess I was going for comprehensive (within reason), where as you were
> going for "90% of 2016 colors/image data", which is fine.
There is comprehensive support for all these formats... I just didn't
pre-instantiate the templates.
It's not hard to do at the top of your program:
alias MyRGBType = RGB!(...details...);
> Anyways, it would be nice to see color (and hopefully image + simple
> blitter) in phobos.
I think that'll come. This is a pre-requisite.
> There's no need to write the same convert/copy/stretch/blend loop over and
> over again. And cpu-side code is nice to have for quick prototyping and
> small-scale work.
Sure.
>>> Just as a completely random idea - How about aliases for HDR formats like
>>> HDR10 and Dolby Vision? Kind of looks like they're just combinations what
>>> you already have.
>>
>>
>> This is very specialist. Instantiations are expensive. If they're not
>> used, it's a waste of compiler effort.
>
>
> HDR TVs and displays are coming fast and with that I'm sure HDR editing and
> photography will be common, which of course means HDR color formats and
> apps. But these can be added later.
There is already support for HDR.
Use a floating point RGB with UHDTV colour space: alias HDR =
RGB!("rgb", float, linear(?), RGBColorSpace.UHDTV);
CompressedRGB also has comprehensive support for all the HDR formats
I've ever encountered.
My point was, I don't want to provide instantiations for these
types... most people don't need it. People writing HDR rendering
software will instantiate the types they need themselves. It's very
specialist work.
