Yes, and there are a few macros based off that:

https://www.libvips.org/API/current/VipsImage.html#VIPS-IMAGE-SIZEOF-ELEMENT:CAPS

element, pixel, line and image, plus a matching set for regions.

Thanks and sorry for taking your time for this question.

I only want to change the L-channel, not A or B and then back to sRGB.

That might look a bit odd -- most people would expect saturation to change with gamma. It would probably be best to just change gamma in sRGB.

LCh is 0-100 for L, 0-150 (or so, C can get a bit bigger even) for C, and h is in degrees, so 0-359.

I'm getting lost a little. For adjusting saturation I do something like (all operations in LABS colorspace):

img = img.linear({ 1 , 1 + dAmount, 1 + dAmount }, 0);

Code was borrowed from #825.

For brighten, the code is:

labs[0] = labs[0].gamma(vips::VImage::option()->set("exponent", 1 + dAmount / 100.0));
this->img = vips::VImage::bandjoin(labs)
	.copy(vips::VImage::option()->set("interpretation", VipsInterpretation::VIPS_INTERPRETATION_LABS));

I don't remember where this code was borrowed from. Is this code wrong?

If have time to comment, please let me know which methods are preferred to adjust saturation and brightness. I did some code changes at my side, and add enough, adjusting brightness (using gamma) now behaves differently (images get far too bright). Not sure why. I really appreciate to get additional information.

Also: I discovered that switching to LAB or LCH, that the underlying type is float, not uchar (as expected by me, based on the set in-max/out-max in #4036 (reply in thread)). But after even reading even more documentation, I found that it says (although not very explicit) that LAB and LCH use float. But then, why using 255 (uchar max) as in-max/out-max. I really got confused. Do I mix things in a wrong way?

Finally: I found with performance testing (similar to what you have showed in the blur example) that LAB is 'slow' compared to sRGB calculations, but I guess there is no faster method for uniform (to human eyes) adjustments of luminance. Can you please confirm (or preferred, deny and tell about the silver bullet)?

Please, can you give me an update. My last questions did not get an answer.

Ooop, sorry.

I think it depends what style of adjust you want to make, which in turn I guess depends on what your users expect and prefer.

You can attempt to make a perceptually uniform adjustments in CIELAB. In this space you can change L* to get uniform brightness changes, so (for example, in python again):

lab = image.colourspace("lab")
lab *= [1.1, 1, 1]

makes every pixel brighter by 10% of its current brightness, in "units", where a unit is a just-discerable-difference for a standard observer. Or you can change saturation with maybe:

lab = image.colourspace("lab")
lab *= [1, 1.1, 1.1]

Which would change a*b* in the same way. However, while this is perceptually correct, few users will ever have adjusted an image like this, and may not like the results.

Something like photoshop will do a "physical" rather than a perceptual change, so they will use a linear space to scale the number of "photons" in the light source:

scrgb = image.colourspace("scrgb")
scrgb *= 1.1

This will effectively increase the amount of light illuminating the scene, so brightness and saturation will both change.

There's no physically correct way to change saturation without changing brightness, so scaling a*b* would probably be your best bet. A poor second (imo) would be changing S in HSV.

Performance: you could use labs, but it seems to have little benefit in my tests on current x86 hardware, since they do float so quickly. You might as well stick with plain lab (ie. float pixels) for convenience.

You could try and use LUTs for speed, but I'd only bother if these operations start to seem expensive when you test. The obvious code above ^^^ should be pretty quick.

Many thanks for your always valuable feedback.