Consolidate and generalize saturation/luminosity adjusters

[dunkeroni]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Community Node Submission

Have you discussed this change with the InvokeAI team?

• Yes
• No, because:

Have you updated all relevant documentation?

• Yes
• No

Description

Now allows increasing values (previous versions could only multiply by values <= 1)
Now allows inverting.
Now allows offsets in addition to multiplication.
Accepts any color PIL format and channel designation.
Now operates in PIL formats, does not need to convert to OpenCV and back.

This can be used to affect Hue (HSV channel 0) since PIL represents it as 8-bit, but it does not replace the Hue adjust node since Hue is a degree rotation and uses different math.

Update: Split into two nodes with human-readable inputs. Also applied more stringent type-casting in the code to avoid some oddities that were appearing with uint8 clipping.

Related Tickets & Documents

QA Instructions, Screenshots, Recordings

Example node view:

Channel options list:

Added/updated tests?

• Yes
• No : node update only

[hipsterusername]

@dunkeroni - This is technically elegant, but functionally less user friendly. I don't think the average user would know how to use this

What are your thoughts on how we could make it more accessible?

[dunkeroni]

What are your thoughts on how we could make it more accessible?

We can combine mode and channel to a single dropdown list. It would get a bit more wordy, but "Red (RGB)" and "Magenta (CMYK)" are at least clear in their effects. "Luminance (YCbCr)" is obscure but recognizable to the people who would have need of it.

Method could also be split off to a separate node, so there would be an "Offset Image Channel" and a "Scale Image Channel" node. That would let the offset version accept an integer [-255, 255], which is a bit more correct.

[dunkeroni]

@hipsterusername take a look at the updated formats and let me know what you think.

[hipsterusername]

This seems incredibly useful. @psychedelicious - Do you have any ideas for node version patterns when a node (or set of nodes) is superseded by a new set?

Just have the new nodes start at v1, and not worry about it?

[psychedelicious]

@hipsterusername Yes, just start with 1.0.0 and delete the old nodes. Ensure the new nodes have a different unique type so there's no collision. That's been done in this PR (which I just updated and which now has versions for the new nodes).

[psychedelicious]

Thanks @dunkeroni !