Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #88348 > unrolled thread

Image rotation issue

Started bykai.peters@gmail.com
First post2015-03-30 14:22 -0700
Last post2015-03-31 15:09 +1100
Articles 5 — 4 participants

Back to article view | Back to comp.lang.python


Contents

  Image rotation issue kai.peters@gmail.com - 2015-03-30 14:22 -0700
    Re: Image rotation issue Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-30 15:32 -0600
    Re: Image rotation issue Chris Angelico <rosuav@gmail.com> - 2015-03-31 10:47 +1100
      Re: Image rotation issue high5storage@gmail.com - 2015-03-30 21:04 -0700
        Re: Image rotation issue Chris Angelico <rosuav@gmail.com> - 2015-03-31 15:09 +1100

#88348 — Image rotation issue

Fromkai.peters@gmail.com
Date2015-03-30 14:22 -0700
SubjectImage rotation issue
Message-ID<baa02843-6a54-440d-a404-552af28c5816@googlegroups.com>
Last week some readers have kindly supplied ideas and code for a question I had asked around a form of image data compression required for specialized display hardware.

I was able to solve my issues for all but one:

The black & white only device (1024 (X) x 1280 (Y)) expects the compressed data based on portrait mode, i.e. 8 pixels combined into one bytes for 1280 rows of 128 bytes. 

This was working well until the desire came up to be able to tilt the display and use it in landscape mode - now I needed to rotate the text, as Pillow does not seem to support drawing at angles.

No big deal - or so I thought after discovering rotate:

from PIL import Image, ImageFont, ImageDraw

white = 1
black = 0
img   = Image.new('1', (1280, 1024), white)  # start in landscape mode since we need to calc. based on that
draw  = ImageDraw.Draw(img)
fontname = 'FreeSansBold.ttf'
    
# in real life, x and y are calculated to center or align text both vertically and horizontally
x = 10
y = 500

dfont = ImageFont.truetype(fontname, 96)

draw.text((x, y), 'Hallo world', black, font = dfont)
draw   = ImageDraw.Draw(img)
    
rotimg = img.rotate(270) # rotation is counterclockwise
    
# i can almost make it work by resizing rotimg here, but the aspect ratio is then screwed
#rotimg = rotimg.resize((1024, 1280))
    
rotimg.show()
imagedata = list(rotimg.getdata())
    
But grabbing data from the rotimg does not work as it does not seem to return an image with swapped dimensions...

What am I missing? 

[toc] | [next] | [standalone]


#88350

FromIan Kelly <ian.g.kelly@gmail.com>
Date2015-03-30 15:32 -0600
Message-ID<mailman.350.1427751181.10327.python-list@python.org>
In reply to#88348
On Mon, Mar 30, 2015 at 3:22 PM,  <kai.peters@gmail.com> wrote:
> rotimg = img.rotate(270) # rotation is counterclockwise
>
> # i can almost make it work by resizing rotimg here, but the aspect ratio is then screwed
> #rotimg = rotimg.resize((1024, 1280))
>
> rotimg.show()
> imagedata = list(rotimg.getdata())
>
> But grabbing data from the rotimg does not work as it does not seem to return an image with swapped dimensions...
>
> What am I missing?

Have you tried passing the expand flag to rotate?

http://pillow.readthedocs.org/en/latest/reference/Image.html#PIL.Image.Image.rotate

I'm not sure if that will result in an image sized (1280, 1024) or
(1280, 1280). If the latter, you should be able to fix it using
Image.crop.

[toc] | [prev] | [next] | [standalone]


#88355

FromChris Angelico <rosuav@gmail.com>
Date2015-03-31 10:47 +1100
Message-ID<mailman.355.1427759276.10327.python-list@python.org>
In reply to#88348
On Tue, Mar 31, 2015 at 8:22 AM,  <kai.peters@gmail.com> wrote:
> rotimg = img.rotate(270) # rotation is counterclockwise

Unless the 90 and 270 cases are documented as being handled specially,
I'd look for a dedicated function for doing those changes. A quick
perusal of the docs showed up this:

http://pillow.readthedocs.org/en/latest/reference/Image.html#PIL.Image.Image.transpose

Is that any better, or is that doing the exact same thing as rotate()?

By the way:

> The black & white only device (1024 (X) x 1280 (Y)) expects the compressed data based on portrait mode, i.e. 8 pixels combined into one bytes for 1280 rows of 128 bytes.
>

This sounds to me like the fax standard. I wonder, can you make use of
a TIFF library to do some of your work for you?

ChrisA

[toc] | [prev] | [next] | [standalone]


#88359

Fromhigh5storage@gmail.com
Date2015-03-30 21:04 -0700
Message-ID<71574a15-7686-4c41-891c-631f2a32987b@googlegroups.com>
In reply to#88355
On Monday, 30 March 2015 16:48:08 UTC-7, Chris Angelico  wrote:
> On Tue, Mar 31, 2015 at 8:22 AM,  <duderino> wrote:
> > rotimg = img.rotate(270) # rotation is counterclockwise
> 
> Unless the 90 and 270 cases are documented as being handled specially,
> I'd look for a dedicated function for doing those changes. A quick
> perusal of the docs showed up this:
> 
> http://pillow.readthedocs.org/en/latest/reference/Image.html#PIL.Image.Image.transpose
> 
> Is that any better, or is that doing the exact same thing as rotate()?
> 
> By the way:
> 
> > The black & white only device (1024 (X) x 1280 (Y)) expects the compressed data based on portrait mode, i.e. 8 pixels combined into one bytes for 1280 rows of 128 bytes.
> >
> 
> This sounds to me like the fax standard. I wonder, can you make use of
> a TIFF library to do some of your work for you?
> 
> ChrisA

According to the docs rotate & transform can both be used and should do the same in my case - but they are not.

rotimg = img.transpose(Image.ROTATE_270) 
print img.getbbox()
print rotimg.getbbox()

gives

(0, 0, 1280, 1024)
(0, 0, 1024, 1280)

while

rotimg = img.rotate(270, 0, 1)
print img.getbbox()
print rotimg.getbbox()

gives

(0, 0, 1280, 1024)
(1, 1, 1025, 1281)

Neither one produces good output when the compression is applied. 

Don't think it's related to fax standards - it's proprietary (E-Ink Tile)

[toc] | [prev] | [next] | [standalone]


#88360

FromChris Angelico <rosuav@gmail.com>
Date2015-03-31 15:09 +1100
Message-ID<mailman.357.1427774965.10327.python-list@python.org>
In reply to#88359
On Tue, Mar 31, 2015 at 3:04 PM,  <high5storage@gmail.com> wrote:
> Neither one produces good output when the compression is applied.

Oh well, was worth a try.

> Don't think it's related to fax standards - it's proprietary (E-Ink Tile)

Doesn't need to be specifically _related_, but it's looking similar.
If you could do 90% of your work by pretending that this is a fax
you're sending, you could possibly do the other 10% by snagging a byte
stream from somewhere. But maybe not worth hunting down. Just a
thought.

ChrisA

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web