[Feature Request] filter by color

[IamCarbonMan]

Can we get something like a color parameter? I really really really love this project you have no idea. My xinitrc spawns a random Pokemon on my wallpaper every boot and my config.fish gives a random Pokemon to each terminal. Maybe it's just a phase but this never ceases to bring me joy. My eyes, however, do not appreciate the sudden burst of yellow Pikachu or white Arceus when they've adjusted to Giratina or Skuntank. At the very least, a parameter to specify "light" or "dark" would be greatly appreciated.

[LazoCoder]

Would you like this parameter to be on the random function or somewhere else? Example:

pokemon random dark
pokemon random-kanto orange

[IamCarbonMan]

Random would probably make most sense. On Jun 20, 2017 6:36 AM, "Lazo" <notifications@github.com> wrote: Would you like this parameter to be on the random function or somewhere else? Example: pokemon random dark pokemon random-kanto orange — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APgjsOe8QZYd0OhFAAZS73A58WJpJq7vks5sF8rkgaJpZM4N_K8X> .

[samuelhnrq]

The obvious way would be to make a hard-coded list of all 'dark' colored pokemon, gengar, ghastly, kyogre, etc, etc.

That would be a unnecessary huge amount of work, and dark is also subjective. Unless we use a 'color palete generator'-ish kinda of library that can detect on runtime how 'dark' a random picked pokemon is and try again if not dark enough and vice versa (for light), but that would be another dependency and @LazoCoder seems very conservative about dependencies. The thing is, with such 'color palete generator' lib we could also implement a pokemon-sensitive color palete setter feature which would be a great great improvement IMO

[IamCarbonMan]

Imagemagick is a common dependency for these types of projects. It's not very heavy to include either. Your might consider that as just about anything you could ever want to do to an image or a set of colors, Magick can do.

…

On Jun 22, 2017 4:38 AM, "Samuel Henrique" ***@***.***> wrote: The obvious way would be to make a hard-coded list of all 'dark' colored pokemon, gengar, ghastly, kyogre, etc, etc. That would be a unnecessary huge amount, and dark is also subjective, unless we use a 'color palete generator'-ish kinda of library that can detect on runtime how 'dark' a random picked pokemon is and try again if not dark enough and vice versa (for light), but that would be another dependency and @LazoCoder <https://github.com/lazocoder> seems very conservative about dependencies. The thing is, with such 'color palete generator' lib we could also implement a pokemon-sensitive color palete setter feature which would be a great great improvement IMO — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APgjsKwGr31pzUALGTjR7vJBs0eTy2-Qks5sGlJLgaJpZM4N_K8X> .

[samuelhnrq]

I agree completely, not only that i also just remembered issue #6 with could also be implemented with a image magick dependency, IMO we already have more than enough reasons to justify a image magick dependency.

[IamCarbonMan]

What would be really cool would be to pick a Pokemon that matches your current wallpaper or Xresources. This would also be fairly easy to acheive using Magick.

[IamCarbonMan]

As far as getting a relative "light/dark" value for an image, I found this command: convert -colorspace Gray -format "%[fx:quantumrange*image.mean]" info:

I looped this command over every image currently in the repo, so you can see how different Pokemon compare. Here's a gist.

There's a couple options as to how we could use those numbers. We could pick an arbitrary threshold and designate anything below it "dark", and above it "light". We could, say, divide all the numbers by 10 and have people do something like pokemon random --brightness 4. Or another option (kind of letting my imagination run wild here) would be something like pokemon random --lighter-than giratina. That last one would probably be a bit more complex than you want to get into. Although with a lot of different feature requests, if you're looking to make your codebase more flexible to allow for new features, this would probably be a great place to start.

[IamCarbonMan]

Concerning that table though, it may be a bit naive still. For example, Entei is apparently darker than Houndour. Looking around Stack Overflow leads to some formulas like such:

L = (0.299*R + 0.587*G + 0.114*B)

which gives "perceived luminance"/"contrast" according to the W3C accessibility spec. These might be worth looking into for comparison.

Update: Sorry, none of these are needed. Magick already applies these values with the option -colorspace gray. As such, I've added another gist based on a plain average of all the pixel values.

[samuelhnrq]

Well just using image magick to generate a table like you did would solve the issue without a new dependency. I agree that image magick doesn't hurts, but the less the better. Is your git the latest version of the database? I might give it a shot BTW we don't need the pokemon numbers, they increase one by line. so line number == pokemon number

[IamCarbonMan]

Either version of the table there should work. However you should keep the Pokemon numbers, because at the end of the list are the special mons that have names instead of numbers.

…

On Jun 23, 2017 8:31 AM, "Samuel Henrique" ***@***.***> wrote: Well just using image magick to generate a table like you did would solve the issue without a new dependency. I agree that image magick doesn't hurts, but the less the better. Is your git the latest version of the database? I might give it a shot BTW we don't need the pokemon numbers, they increase one by line. so line number == pokemon number — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APgjsDRo5WgBGHtoqE0bWhyII4inAm-Hks5sG9oygaJpZM4N_K8X> .

[LazoCoder]

On second thought, I think that adding in randomization by color might be more complicated than it seems. What if some of the colors are purplish-blue or bluish-green? Those will be hard to label and it can get very subjective even if an algorithm is used. I bet people will open up issues where they believe a certain Pokemon should actually be labelled under another color than what we have labelled it as. Furthermore I can imagine that somebody will want to extend this and request a feature for selecting from multiple colors and more:

$ pokemon random red or yellow or orange
$ pokemon (random-johto red or yellow) or (random-sinnoh green or blue)
$ pokemon random red-low-saturation
$ pokemon random red-high-saturation

This seems like it could get messy to code. Its probably best not to climb down this hole unless we really think this is going to provide immense value to the project.

Also, if we do brightness by intensity (pokemon --brightness 3) then somebody will inevitably ask for ranges (ie. pokemon --brightness < 3). Again, multiple command line parameters have many edge cases and can be hard to code.

Filtering by light and dark seems like a good, feasible feature though. Generating a pre-computed table seems like the best way to go. Its also best to leave out the custom images from the Extra folder. Since its a pre-computed table, custom images won't be supported for the light/dark functionality. If you do attempt this @samosaara, try to put it in its own class like ColorDatabase.py and have methods like:

get_dark_pokemon()
get_light_pokemon()

This way if we actually do decide to add support for colors it will be easier to put them in.

[IamCarbonMan]

The gist above is effectively a pre-compiled table of light/darkness values. If you'd like I can convert it into CSV or JSON or some other format. The only thing left is to decide what the threshold of light or dark is. Some examples:

Entei: 15
Murkrow: 20
Stunky: 25
Lumineon: 30
Glalie: 35
Porygon: 40
Ho-oh: 45
Solrock: 50
Anorith: 55
Charizard: 60
Spheal: 65
Manaphy: 70
Ampharos: 75
Sharpedo: 80
Pikachu: 85
Leafeon: 90
Zangoose: 95

[IamCarbonMan]

My suggestion for now would be just two lists, light_pokemon and dark_pokemon. Pokemon under 40 would be considered dark, Pokemon above 60 are light, and Pokemon 40-60 are in both lists.

[LazoCoder]

Sounds good to me.

Just so you know, I've updated the images with a different compression algorithm. You may want to run your script on the new images (I don't know if it will make a difference, but just in case).

[IamCarbonMan]

Alright. I've forked the repo to make changes, I should have this feature implemented in a few hours when I get home.

…

On Jun 24, 2017 1:08 PM, "Lazo" ***@***.***> wrote: Sounds good to me. Just so you know, I've updated the images with a different compression algorithm. You may want to run your script on the new images (I don't know if it will make a difference, but just in case). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APgjsIj1jUqWlfKH4EwryyRIzGdvWRJYks5sHWy0gaJpZM4N_K8X> .

[IamCarbonMan]

With the work that I'm now doing on #6 I think I've got a general idea for how we might do generic color filtering in the future. The simplest way would just be to list one or two primary colors for each Pokemon and use imagemagick to find the primary color of the users wallpaper or current terminal background color, and just pick the closest image.

[samuelhnrq]

I just had an epiphany, how about, instead of simply random color filtering... Pokemon type filtering?! Which in turn also has colors?! 😃 And we don't even need image magick?!?

But there are obvious drawbacks, first type isn't really a synonym of color, e.g. mudkip is also ground type, and it's blue, and like in my first example, some pokemon have multiple types, and third, some pokemon break the convention coff-coff, arceus, coff-coff

But I still think is a reliable ruler anyway! Mostly electric are yellow, mostly grass type are green, so on and so forth. But i'm not saying the ideas are mutually exclusive, I just thought it was a better alternative, but if you think it is not reliable enough as a color filter I will implement it anyway.

[IamCarbonMan]

That could be separate I think.

[samuelhnrq]

Okay so if anyone still wants to implement this, we could do basically the same we did with the lightness index, just generate the main color for all pokemon with some external tool, and keep the main colors in the database, it's also static data anyway. But since colors are just a hex code I was thinking to set some named color ranges, like a range of blue-ish hex codes and every pokemon that should fall in that range would be labeled 'blue', so on and so forth. And don't bother with lightness, that would be redundant, every blue dark or light should just be blue, then if he wants dark blue, he will just mix with the darkness filter.

Something to keep in mind is, is pretty much a consensus that we will change the database from plain text to JSON soon, so such change should wait for that.

[IamCarbonMan]

I could possibly get back into working on this.