[Feature Request] filter by color about pokemon-terminal HOT 20 OPEN

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

pokemon random dark
pokemon random-kanto orange

from pokemon-terminal.

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.

from pokemon-terminal.

from pokemon-terminal.

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

from pokemon-terminal.

from pokemon-terminal.

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.

from pokemon-terminal.

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.

from pokemon-terminal.

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.

from pokemon-terminal.

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

from pokemon-terminal.

from pokemon-terminal.

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.

from pokemon-terminal.

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

from pokemon-terminal.

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.

from pokemon-terminal.

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).

from pokemon-terminal.

from pokemon-terminal.

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.

from pokemon-terminal.

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.

from pokemon-terminal.

That could be separate I think.

from pokemon-terminal.

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.

from pokemon-terminal.

I could possibly get back into working on this.

from pokemon-terminal.