Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #88348 > unrolled thread
| Started by | kai.peters@gmail.com |
|---|---|
| First post | 2015-03-30 14:22 -0700 |
| Last post | 2015-03-31 15:09 +1100 |
| Articles | 5 — 4 participants |
Back to article view | Back to comp.lang.python
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
| From | kai.peters@gmail.com |
|---|---|
| Date | 2015-03-30 14:22 -0700 |
| Subject | Image 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]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-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]
| From | high5storage@gmail.com |
|---|---|
| Date | 2015-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]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-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