lichtkind

Hai again, after a very productive three weeks I can announce the next major release of Graphics::Toolkit::Color (despite the rather small version number jump). In this post I explain what changed(+12 spaces, +1 method, +7 method args), why it is relevant and how I used LLMs to achieve that.

A lot more space to explore !

The 12 new color spaces are: LinearRGB, CIERGB, Adobe 98 RGB, Apple RGB, Pro Photo RGB, Wide Gamut RGB (Adobe), Rec.709, Rec.2020, Display P3, Display P3 Linear, DCI P3 and DCI P3 Linear. Most of them are or were relevant in (professional) photography, videography or for designers (This is what I meant by go pro). But almost none of these spaces have any CPAN support (until now). With the notable exception of PDL::Transform::Color which does know 7 of them. This makes GTC a "modern" color handling library, especially with GTC 2.3, when another such batch is supposed to land. And if you want to know more about all these spaces, just read our fine docs.

Are you good ?

The new spaces are more or less a variant of good old standard RGB. They have just slightly different white point or gamma value or transfer function. And many of them have a much wider gamut than SRGB. Gamut is just a fancy word meaning range - meaning there are colors you can normally describe in e.g. AdobeRGB, that would not be included (out of range) in standard RGB. When converting, GTC clamps just the values that stick out on an per axis basis. Because this is not ideal, it is planned for 2.4 to have professional gamut mapping (to the visually nearest color). All I can offer for now is the method: is_in_gamut. It allows you to know, if a color will be clamped just by the fact of being read or written by GTC. I also added the argument raw, which prevents such clamping (at your own risk of getting strange values or misbehaving operations). is_in_gamut is also available as standalone sub if you want to check values before creating an object.

Just trust me !

Another issue with these new spaces is that their values are in most cases normalized (0..1) but sometimes come as 16 or even 32 bit integer. Of course you should expect that GTC can read them all. For that scenario I extended the constructor with the option to have named arguments too:

my $color = Graphics::Toolkit::Color->new( color => ['ProPhotoRGB' => 523, 1000, 27 ], range => 2**16, raw => 1);

Output such values works the same way:

 $color->values( in => 'WideGamutRGB', range => 2**32, as => 'named_string', raw => 1);

Space Names

Another topic brought up by the new spaces is color space names. Take for instance linear Display P3. You might want to write Display-P3 Linear or linear_display_p3. Now you have such flexibility with all space names. It was always case insensitive but now you can insert or remove the 4 chars: ' ', '_', '-', '.'; Same is true for the equally valid alias name of a color space. That would be 'BT.2020' for the 'Rec.2020' or XYZ for the CIEXYZ space.

Adapt to the current Sun !

Then we got the new method apply to do gamma correction. The math behind it is trivial but it's there for convenience. And as always GTC tries to give you a little extra by being able to apply to each axis a different gamma value, if you want to. The method name is a bit vague on purpose so it can do more in the future.

Space inversion

Last but not least I expanded the possibilities of the invert method. You can now specify which axis to invert, which makes this tool much more powerful and perlish (TIMTOWTDI), since inverting 'hue' (in HSL, OKSL, LCH ...) is the same as computing the complement with the method of the same name.

Talking Machines

Of course nothing is written by an LLM. I tried it once for test rewrites, but I didn't like it and it wasn't even that much of a productivity boost. It's awful if you lose haptic contact with your mental model of the software. But I did use an LLM in two areas which made me a much better and faster developer.

First is planning. Research and evaluating possible features, grouping them, crafting a roadmap, are things that LLMs speed up. If you have concrete questions with answers that you can evaluate then it's not only a speedup but also a form of QA. If I have a well thought out roadmap much earlier in my head I can make much smarter decisions during development.

The second area where LLMs are very helpful are concrete calculations combined with research. Most helpful was being able to throw a conversion matrix at Claude and ask it how many decimals of precision this thing had and which white point it used. And my ProPhotoRGB conversion matrix needed a CAT Bradford adaptation. Claude reminded me of that fact on its own and computed after I asked for it a combined CAT and conversion matrix and told me the white point of it. It already knew it should use only values from the standard, colour-science or Lindbloom. All things I could potentially do too, but that would take me an extra half an hour at least. Of course I wrote the tests for that matrix by hand, but this was the real eye-opener to me.