Can anyone suggest a better way to set the color of the corners?
All I really need in this case is that they be a solid color, the
same color they were before being rotated.
--
rzed
Frederic
[in response to:
>> I'm using PIL to generate some images which may be rotated at
>> the user's option. When they are rotated, the original image is
>> cropped in the new image (which is fine), and the corners are
>> black (which is not, in this case). I can't find any documented
>> way to change the default fill color (if that's what it is) for
>> the corners, and PIL also doesn't seem to support a flood fill.
>> I have created a flood fill in Python, which works but which
>> markedly slows image generation.]
> I just had the same problem the other day. I solved it by
> starting out with an image large enough to retain enough white
> area following the rotation.
Well, that's a workaround I could try, but I'm half-hearted about
it. I don't like to think that it's *required*. Another possible
solution is to make the outer portion black, so the rotation seems
to do the right things, but in the cases I'm dealing with, that's
either out or more trouble than it's worth. I can haul the rotated
images into a paint program and manually touch up the corners, too,
but I don't like to have to do that either.
It seems strange that there wouldn't be some way to change the
black to another color, or (maybe just as good) to transparent. PIL
is so useful that it strikes me as an aberrant oversight. More
likely, there *is* a better way, but I just don't know it and can't
find it in the docs.
--
rzed
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.
# Left edge
for y in range (image.size [1]):
for x in range (image.size [0]):
color = image.getpixel ((x,y))
if color != WRONG_COLOR:
break
image.putpixel ((x,y), RIGHT_COLOR)
# Right edge
for y in range (image.size [1]):
for x in range (image.size [0]-1), -1, -1):
color = image.getpixel ((x,y))
if color != WRONG_COLOR:
break
image.putpixel ((x,y), RIGHT_COLOR)
----- Original Message -----
From: "rzed" <je...@comics.com>
Newsgroups: comp.lang.python
To: <pytho...@python.org>
> ----- Original Message -----
> From: "rzed" <je...@comics.com>
> Newsgroups: comp.lang.python
> To: <pytho...@python.org>
> Sent: Sunday, May 01, 2005 1:17 PM
> Subject: Setting the corner color in rotated PIL images
>
>
>> I'm using PIL to generate some images which may be rotated at
>> the user's option. When they are rotated, the original image is
>> cropped in the new image (which is fine), and the corners are
>> black (which is not, in this case). I can't find any documented
>> way to change the default fill color (if that's what it is) for
>> the corners, and PIL also doesn't seem to support a flood fill.
>> I have created a flood fill in Python, which works but which
>> markedly slows image generation.
>>
"Anthra Norell" <anthra...@tiscalinet.ch> wrote in
news:mailman.91.11151178...@python.org:
> I just had the same problem the other day. I solved it by
> starting out with an image large enough to retain enough white
> area following the rotation.
>
> Frederic
>
I found another method that doesn't require the larger size and
cropping :) but does require two copies of the original image :(
(sort of).
I copy the image and rotate the copy, then I create an all-white
image of the same size as the original and rotate it by the same
amount. Then I use ImageChops composite() to combine the rotated
copy, the original copy, and the black-and-white version
(parameters in that order). The black corners of the b/w version
serve as a mask to paste the original corners onto the copy.
It still seems like a lot of trouble to go to, but I don't think
there is a ready solution otherwise. I think there's a C-code
memset of all zeroes that underlies the black corners thing, and
that's not likely to change.
--
rzed
> I'm using PIL to generate some images which may be rotated at the
> user's option. When they are rotated, the original image is cropped
> in the new image (which is fine), and the corners are black (which
> is not, in this case). I can't find any documented way to change
> the default fill color (if that's what it is) for the corners, and
> PIL also doesn't seem to support a flood fill. I have created a
> flood fill in Python, which works but which markedly slows image
> generation.
>
> Can anyone suggest a better way to set the color of the corners?
if you're doing this on RGB images, the quickest way to do this is:
def rotate(image, angle, color):
bg = Image.new("RGB", image.size, color)
im = image.convert("RGBA").rotate(angle)
bg.paste(im, im)
return bg
here's a more general solution:
def rotate(image, angle, color, filter=Image.NEAREST):
if image.mode == "P" or filter == Image.NEAREST:
matte = Image.new("1", image.size, 1) # mask
else:
matte = Image.new("L", image.size, 255) # true matte
bg = Image.new(image.mode, image.size, color)
bg.paste(
image.rotate(angle, filter),
matte.rotate(angle, filter)
)
return bg
</F>
> 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
Fredrik:
Thank you for the reply. It just showed up on my server, and, of
course, it works perfectly.
--
rzed