Alpha channel of .png is taken into account
RomainSauvaire opened this issue · comments
Hello and congratulations for this nice piece of code !
I am trying to work with some .png files and this one particularly fails and returns me #000000 as the most vibrant color.
I guess it fetches it from the alpha channel.
Could you have a more in-depth look please ? Here is the image
Hi!
You're right I don't take alpha channel into account. I think I should blend transparent colors considering a white background.
But for some reason I can't reproduce the behavior you describe using the image above neither can I create such image =/
Hi Mat,
I guess GH transforms uploaded images. Here is a "raw" version.
My bet would be to count it as a "special" color that don't get mixed with the others : on this particular image I would like to retrieve a dark yellow rather than the transparent/white. Do you see what I mean ?
Let me know if you need something else.
What I do on my system is that when someone uploads an image, a small temporary duplicate is created as a sample, say 100px x 100px. That duplicate is used for the color extraction. That speeds the process up massively, but what you can do before the color extraction step, is add a background color, say white, to your small sample image. That way there will never be any alpha to worry about and color extractor will always return colors. Your full size image will still have alpha, but your script will now define that as white.
@RomainSauvaire this is what I get with your last image:
Maybe our GD version are differents? I've got 2.1.1-3.
@al35mm as resizing affect colors I prefer not to do that. However you can resize an image for yourself before building the palette.
@MatTheCat I have 2.1.1-dev. Doesn't look so far than yours. But I have complete different results (with the original file)
When I run sudo apt-get install php7.0-gd I get
php7.0-gd is already the newest version.I'm a little bit lost here :-/
This may seem dumb but are you sure it's the right image and the color-extractor version you're using is 0.2.0?
This doesn't seem dumb ;)
Here is the version filled in my composer.json
"league/color-extractor": "^0.2.0"
The image URL I use is filled in an image src to check it is the correct one so yeah, I guess it is :)
FYI here is the code I use
$url = 'whatever';
echo '<img src="'.$url.'">';
$palette = Palette::fromFilename($url);
$palette = $palette->getMostUsedColors(5);
foreach($palette as $color => $count) {
$c = Color::fromIntToHex($color);
echo '<div style="background-color:'.$c.'; display: inline-block;width: 2rem;height: 2rem;"></div>';
}Oh I assumed you used the ColorExtractor::extract but you just get the most used colors. Would it be correct to consider full transparency as white or just ignore it?
Ok I got the difference between mostUsed and extract. Thank you for the clarification.
IMHO, it is not correct to consider transparent as a color either white or whatever. It should not be counted at all.
I think I'll introduce two more parameters in Palette constructors: $ignoreTransparency, defaulting to true and $transparencyColor defaulting to 16777215 (white). The latter will be used to blend colors if transparency is taken into account.
Nice idea @MatTheCat.
I'm thinking of a way to rather define a $transparencyColor (or anything else) which will be defaulted to null and can be replaced by a color when we want it to be blended.
What do you think about that ?
It's simpler, I'll do that.
Maybe $backgroundColor would be better for such a variable?
Why not but there is no info about the fact that it will override transparency. I hesitate but I'm not sure to propose a better naming.
ps: ce serait plus simple en français ;)
Okay ^^
Si cette couleur "remplace" la transparence alors qu'advient-il des pixels semi-transparents ? Je pense que l'idée d'un "fond" est plus intuitive puisque tout se passera comme si le fond de l'image était de cette couleur.
Excellent argument : je n'avais pas pensé au semi-transparent ;)