Open Zirafnik opened 2 months ago
The simplest solution here is probably to always return an RGB Object in metadata.background
regardless of the number of input channels.
Happy to accept a PR for this, if you're able. We should add a test case for this too as it doesn't appear to be covered by any of the scenarios in test/unit/metadata.js at the moment.
Removing greyscale number return type from .metadata()
would be a breaking change for anybody that confidently relies on receiving just the number.
Adding additional parameter type for .flatten()
background to include a number, is not a breaking change.
I'm OK with this being a breaking change, as part of a future possible v0.34.0, as it simplifies the API so that the background
metadata can always be parsed by the color
package and therefore operations that use it such as flatten()
.
Perhaps a single-channel input could return something like { grey: value }
instead? The color
package accepts values in the range 0-100 so we would need to scale from libvips' 0-255 range.
When using
sharp(input).metadata()
an object with properties, which includesbackground
is returned.It can return RGB Object or greyscale number.
When using
sharp(input).flatten()
we can pass in an options object which includes the background color property. This option expects an RGB Object or a CSS type color string (e.g. 'white').What I did, was use the background color returned by
.metadata()
, directly as an option in.flatten()
. This however, produced an error in cases where the metadata returned a greyscale number, which is not a valid input for flatten background option.Current workaround is simple: just repeat the greyscale number value for all the RGB Object fields.
However, while the "fix" is simple, it is not the expected behavior and should be adjusted. I propose that the
.flatten()
background
option accepts a greyscale number as possible input.