[Tutor] PIL's palette
denise.hartley at gmail.com
Thu Jul 14 19:58:19 CEST 2005
> Your palette is a LookUp Table (LUT) - it is also named like this in
> your prog ('lut') - which is a 768-long list (or as in this case, a list
> of 256 lists, every inner list has 3 elements - so again you have 768
> elements). So 3x256 or 1x768 is just an implementation detail. Let's see
> the 3x256 version:
Actually, it creates one list, of 768 values (numbers). Not a list of
lists, which could be indexed into. Just one lonnnnng list. So I
dont know how it indexes into it or does anything with it! But I
printed out "lut" and that's what it is, one long list. Anybody know
how that works, then?
> Now your picture looks like this:
Even if it *did* have indices - why would my picture look like this,
now? I dont think I understand what you're saying. Is this after I do
the putpalette? All I know is, I start with one image, I do
putpalette() and all of a sudden everything is a different color. And
I dont know why it changes which colors to which. The greyscale thing
makes a little more sense - it turns my color image into a black and
white one, but I dont know why it chooses which grey color for which
> And when it is rendered, PIL looks up the color (hence lookup table) at
> the given index. So the first pixel of the image will be the color held
> at index 8 in the lookup table (or palette).
Why would the first pixel be at index 8? What color is it looking up?
I'm starting with an image (say it's a red square with a blue square
inside it, that's more simple). What is it looking up? Pixel 1 already
*has* a color - (255,0,0). Putpalette() obviously ... picks some
other value. I don't know why, or how. All the pixels in the original
image start with a color value, and after putpalette() they end up
with a different color value. I just dont know how it decides that, or
why (and thus I dont know how I can control it to use it the way I
want - for instance if I wanted to make the square yellow on the
inside instead of blue).
> So basically the palette is the comupter abstraction of a real painter's
> palette - the real painter has x colors on his palette, and says (by
> looking at the palette): ah, i need this intelligent shade of cobalt
> blue. You do the same here - you have a palette (the look up table) and
> say: ah, i need this color - so you put the INDEX of that color into the
> image, and when the computer is 'painting' he looks up the color at that
Again - I dont know how I'm telling the palette what color I want. I
don't feel like I am telling it anything, at this point, ah ha. I just
have a list of 768 numbers, which python somehow uses to change all
the colors in my previous image.
> Yep, because the first produces a palette like this:
> index |
> 0 | [255,127,0] orange
> 1 | [254,127,1]
> 2 | [253,126,2]
> ... | (some kind of purple, magenta, red ...)
> ... |
> 255 | [0,0,0] black
> So i think the indices in your original blue image point to colors in
> the new palette which are 'red-like', hence the red-red combo.
This seems to make a little more sense, but... why are there indices
in my original image? What indices do you mean? And why do they point
to colors in the new palette which are red-like?
Also, if there is a different way to do the color-changing above, a
simpler way that makes more sense, feel free to point it out.
Originally, I was changing all (0,255,0) to (255,0,0) (for example)
with getpixel/putpixel. But that only works if it's a blocky shape,
no shading or anything like that. colorize() does what I want but you
have to start with black and white images. I was just wondering if I
could do something like colorize() but from red to blue for instance
instead of from black or white to blue. I *thought* putpalette would
do it - and it seems to, I just have no control (at this point) over
what colors it decides to change things to (because I dont know how
this long 768-item list is working).
More information about the Tutor