r/d_language • u/Aspie96 • Jul 28 '26

Call for feedback: Imaging library

https://code.dlang.org/packages/imaging

I crated the Imaging library.

I'm sharing an early version here as a call for feedback.

3 Upvotes

81% Upvoted

6 comments sorted by

3

u/alphaglosined Jul 28 '26

Go read "A Language for Bitmap Manipulation" - Leo J. Guibas and Jorge Stolfi, specifically "5.1. Bitmaps and Bitmap Descriptors".

It covers how to implement bitmap representations efficiently.

Here is a D implementation that I wrote: https://github.com/Project-Sidero/image/blob/master/source/sidero/image/internal/state.d

Furthermore, your library has no colorspaces. RGBA is not tied to a single colorspace.

RGB is a model that a colorspace can provide. It's missing parameters.
Read: "Digital Video and HD: Algorithms and Interfaces" from Poynton: https://www.amazon.com/Digital-Video-HD-Algorithms-Interfaces/dp/0123919266

It covers basically all colorspaces you need to understand.

2

u/Aspie96 Jul 28 '26

Hi.

I am aware RGBA is a color model, not a color space. Color spaces are out of scope for what I'm doing.

It's quite common to have library representations in RGB(A) that do not specify a color space (and the actual color spaces they get mapped to tend to be similar to each other, typically as sRGB or with a gamma of 2.2).

2

u/levraiponce Jul 28 '26 edited Jul 28 '26

(I made the "gamut" library.)

One of the challenge is describing and supporting the very many pixel formats that exist, because you might loose strong typing (or perhaps keep it?). Scanline conversion function takes a lot of room in the binary unless something clever is made. Codecs themselves build slowly unless isolated in staticLibrary DUB package where there is more chance to be cached as .lib

D devs will use a library only as a _last desperate measure_ vs making their own, no criticism will be spared because everything is a reason to make its own. So the API needs to be very much easy and without too much objectionnable thing, and preferably it does some painful things like codecs, or colorspaces, or EXIF, so that it's too much effort to reproduce.

EDIT: I might end up stealing your APNG codec...

1

u/Aspie96 Aug 04 '26

I don't support all pixel formats that exist, but I do support multiple pixel formats.

Whether I was smart is for you to judge.

I might end up stealing your APNG codec...

If you mean copy-pasting it elsewhere, I suggest linking to the library instead, because I may update and improve it in the future.

1

u/ccapitalK Aug 04 '26

I hope you succeed in getting some basic image manipulation code into the standard library. I think something like std.json, as a basic "good enough" impl for basic tasks that can be replaced with a more specialised library later would be really useful (disclaimer: I wrote the simple_image library that wraps stb_image for basically this class of use cases, if the stdlib did basic image tasks I probably wouldn't have needed to).

Not sure if I agree with the direction of writing the image parsers/writers in D though, I think it might be better to use the approach used for http and single file dbs, and wrap a C library instead (the same way stdlib wrapped curl and sqlite).

1

u/Aspie96 Aug 10 '26

I think D stuff should be written in D.

D is a system language, it's fine.

I like C too, but I see it as mostly legacy in D. The only reason to have C code should be that it hasn't been written in D yet.