On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:
> Is there general interest in UI within the D community? And is there enough to have our own toolkit, or would we be better placed to contribute to the likes of gtk-d?

There is lots of UI or UI parts in development, and interest too, but it's the hardest type of library to build (and most valuable).

Two that haven't been mentionned:

* DlangUI: https://github.com/buggins/dlangui, recently revived
  I think there was another fork too with radical changes.

* the new libsoba is planned to replace immediate-mode UI in Inochi2D: https://github.com/Inochi2D/libsoba with interstingly a WebGPU backend

On 27/03/2023 1:13 AM, Guillaume Piolat wrote:
> It's probably better to make really good libs for those before doing an UI, a whole UI is a bit above whan a single person could maintain and design.

I'm giving it a go anyway!



I am seeing a bit of a problem with gamut, its not handling color spaces correctly. It appears to currently ignore them, which means if you care about correctness or reproducibility its not suitable (and it does not mention it).

An example of this is in PNG, there is no gAMA or cHRM chunk handling. It would be ok if it would process it into a more expected form (like sRGB), but it doesn't do anything like that.

To do this properly means you can't make assumptions which of course is super expensive when doing processing. I.e. you need:

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/colorspace/rgb/model.d

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/colorspace/rgb/srgb.d#L88

Over all its the ideals of gamut are cool, its scope needs slightly enlarging tho ;)

On Sunday, 26 March 2023 at 12:13:34 UTC, Guillaume Piolat wrote:
> It's probably better to make really good libs for those before doing an UI, a whole UI is a bit above whan a single person could maintain and design.

I do like ten different things that I'm told are too much for a single person to do.

On Sunday, 26 March 2023 at 13:35:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I am seeing a bit of a problem with gamut, its not handling color spaces correctly.

Absolutely. Need to find a good design for it.

On 27/03/2023 5:39 AM, Guillaume Piolat wrote:
> On Sunday, 26 March 2023 at 13:35:27 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I am seeing a bit of a problem with gamut, its not handling color spaces correctly.
> 
> Absolutely. Need to find a good design for it.

You've got a real challenge on your hands. I have started again for less core changing things.

Here is an example of why I don't think you'll be able to slot it in as-is.

https://github.com/AuburnSounds/gamut/blob/main/source/gamut/image.d#L929

That should be taking in a target colorspace, not a channel specification (which is what PixelType is).

If every color space has an intermediary form it understands (i.e. CIE XYZ), you can convert it to that and back again easily. I.e.

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/pixel.d#L242

On Sunday, 26 March 2023 at 17:11:52 UTC, Richard (Rikki) Andrew Cattermole wrote:
> https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/pixel.d#L242

Yes, but you will recognize stb_image.h has that exact same semantic too. You can ask for 1/2/3/4 channel while loading. It is implicitely rgba8/rgb8/la8/l8, implicitely sRGB.
People care about value and that implicit conversion more than they do about colorspaces. So it's not a simple cut wrong vs true.

On 27/03/2023 9:36 AM, Guillaume Piolat wrote:
> People care about value and that implicit conversion more than they do about colorspaces. So it's not a simple cut wrong vs true.

Agreed. You're probably better off making it out of scope instead.

Its a lot of work, its slower and it kinda goes against the trade offs you have already picked.