More Surface Adjustment Methods

[itzpr3d4t0r]

trafficstars

Description

I propose adding three new methods to either the Surface class or the transform module (names aren't final since this is just a functionality suggestion):

• [ ] Surface.set_hue() / transform.hue()
• [ ] Surface.set_saturation() / tranform.saturation()
• [ ] Surface.set_brightness() / transform.brightness()

These methods would enable users to conveniently modify the brightness, hue, and saturation of surfaces, opening up possibilities for a variety of visual effects. They are present in basically any image editing software nowadays.

Motivation While there is a lot of functionality already implemented to fiddle with surface blending/modification, i believe that these new functions could be a very relevant addition mainly for two reasons:

• They would enable a greater variety of visual effects.
• They would avoid extra complexity of using separate libraries/programs/combinations of existing pygame functionality.

Some possible use cases of these new functions are:

• help create lighting effects, simulate day and night transitions, and dynamically adjust brightness in visual environments or objects.
• allowing for different moods and visual atmospheres, so recoloring foliage to from a green summer pallete to a fall one.
• achieve vivid or muted color palettes, for changes in visual impact, say an horror game with hard shifts from color to black and white or close to it.

For those who don't know what hue or saturation mean,

• hue basically defines the color tone, so that a surface that's mainly red can be shifted to mainly green.
• saturation defines the color intensity.

This is a simple example of the scales these three factors use:

[PurityLake]

Is this being worked on currently? If not, I'll give it a go. Is this to be written in C?

[itzpr3d4t0r]

Is this being worked on currently? If not, I'll give it a go. Is this to be written in C?

Yes this is being worked on and was targeted to be implemented in C. The main thing to address is whether we want to implement these as transform functions or Surface methods. I have a Surface implementation since it's simpler but it's in a local branch in my desktop PC and i'm on laptop on vacation for the next week.

[PurityLake]

In my opinion, a transform makes most sense to me. Looking at the API for a Surface it doesn't out of the box provide any mutation methods (excluding blitting) and I would be of a mind to preserve that.

Also, perhaps a transform.hsl(surf, h=None, s=None, l=None) function so there is an option to set any combination of the three.