Setting the corner color in rotated PIL images

[rzed]

"Anthra Norell" <anthra.norell at tiscalinet.ch> wrote in
news:mailman.90.1115377246.29826.python-list at python.org: 

> What do you mean 'is required'? I tend to think that getting
> ahead with a job is what is required. I don't sneer at
> work-arounds if they save time. 
> 
> Frederic
> 
> A somewhat craftier solution, if still pretty hackish, would be
> to go through your image pixel by pixel, look what color each
> one is (color = image.getpixel (here)) and change the ones with
> the wrong color (if color == wrong_color: putpixel (here,
> right_color)). 
>       If the color of  the corners does not occur inside your
>       picture, you 
> can go throught the entire image. Else you'd have to stop
> changing colors at the first occurrence of a pixel that does not
> have the wrong color, coming inward from each of the lateral
> edges. (Code below (untested)). 
>       If you have elements in your picture that not only have
>       the same color 
> as the corners, but also run into them, then you might have to
> refine your code further in order for the inner loop not stray
> into the image. 
> 

[Code snipped]

Yes, that is essentially similar to the slow flood-fill approach I 
used initially. I did in fact make use of your previous suggestion, 
which works but requires oversizing the image, calculating the crop 
rectangle and so on -- not overly difficult, just annoying -- and I 
also use another approach (outlined in another message) that 
involves pasting a rotated copy of the image back onto the original 
under control of a mask. It depends on what I want to see in the 
corners, essentially. And, having coded the workarounds, I get on 
with the process without worrying about it.

But ... it would be nice if I could specify a default solid color 
to replace the black in the corners, and have the rotation take 
place in one operation without resizing and recalculating and 
duplicating images and all. 

Somewhere down in the C code, the "corner" color is being set to 
black. I wouldn't think it would be terribly hard at that stage to 
set those bytes to other values instead, and exposing that color 
through PIL's interface. But I suppose it's more trouble than it's 
worth for Fredrik, or nobody else has been bothered by it, or by 
the lack of a flood-fill function. To me, these are 
uncharacteristically odd omissions from PIL.

-- 
rzed