Commit Graph

20 Commits

Author SHA1 Message Date
artscoop
7b657f6887 Fix for all good_tests
Fixed loading of all types of provided images (+rgba). Added edge case where the header is reported as 40 bytes long with BITFIELDS (they start past the 40 bytes of the header). Loading fails for RLE, but IIRC, they're unsupported so it's normal.
2015-03-04 22:05:32 +01:00
artscoop
c8551770eb Quickfix number 4
Until tests pass.
2015-03-04 19:55:08 +01:00
artscoop
497ddf9c68 Remember correct image offset if bitfields+palette
Use the provided image offset if there is palette data while the image is bitfielded.
2015-03-04 19:50:52 +01:00
artscoop
877c138e21 1bpp BMP fix
It appears that
{{{
  The handling of 1bpp bitmaps is a little complicated.
  When reading 1bpp bitmaps, the palette is ignored.
  1's are considered foreground, and they are considered black.
  0's are considered background, and they are considered white.
}}}
so the raw mode has to be `1;I`
2015-03-04 19:26:15 +01:00
artscoop
c0ce8d0ae8 Removed debug print
Debug print left in _save. Removed.
2015-03-04 18:29:28 +01:00
artscoop
456bd96565 Fix 32-bit BMP loading (RGBA or RGBX)
PIL choked on perfectly valid BMP files (32 bits with Alpha). It could not handle valid RGBA masks to determine the raw format.
To clarify things, I:
- Rewrote the `BmpImagePlugin.BmpImageFile` class to be far more readable
- Made error messages more explicit (e.g. say that RLE bitmaps are unsupported)
- Made a readable dict to contain BMP header information
- Kept the existing security checks
- Instead of reading palette info by chunks of 3/4 bytes, read the whole palette info at once and parse the data.
- Now works with BMPv4/5 with Alpha (and can be exported to alpha PNG for example)
- Tested load and save with RGB24, RGB8, RGB8L, RGB32 and RGBA32.
- Tested with one bogus file. File not accepted, as expected.

I wanted to test more BMP formats, but I could not find that many images.
But for all the types I tested, it worked flawlessly.
2015-03-04 18:15:56 +01:00
hugovk
8de95676e0 flake8 2014-08-26 16:47:10 +03:00
gcq
61be1d8b19 dpi key should only be present when there is resolution info in the BMP header. 2014-06-28 23:59:01 +02:00
gcq
9318755a18 Adds dpi to the Image info dictinoary. 2014-06-28 23:21:22 +02:00
gcq
103354facc BMP now uses a reasonable resolution, and customizable using the "dpi" option. 2014-06-28 22:18:47 +02:00
wiredfool
88d0e6080a Fixed DOS with invalid BMP size entries 2014-01-31 21:33:24 -08:00
wiredfool
6de70524f7 108 and 124 bit header fields are a superset of the 64 bit header 2014-01-26 20:43:21 -08:00
wiredfool
046a226f34 Don't use gigs of memory with invalid palette sizes 2014-01-23 20:11:05 -08:00
Alex Clark
3020c16eaa Fix imports 2013-03-07 11:20:28 -05:00
Brian Crowell
254f0cf674 py3k: FIX: Bad upside-down check in BmpImagePlugin 2013-01-10 08:46:58 -06:00
Brian Crowell
a7e3b2e47b py3k: The big push
There are two main issues fixed with this commit:

* bytes vs. str: All file, image, and palette data are now handled as
  bytes. A new _binary module consolidates the hacks needed to do this
  across Python versions. tostring/fromstring methods have been renamed to
  tobytes/frombytes, but the Python 2.6/2.7 versions alias them to the old
  names for compatibility. Users should move to tobytes/frombytes.

  One other potentially-breaking change is that text data in image files
  (such as tags, comments) are now explicitly handled with a specific
  character encoding in mind. This works well with the Unicode str in
  Python 3, but may trip up old code expecting a straight byte-for-byte
  translation to a Python string. This also required a change to Gohlke's
  tags tests (in Tests/test_file_png.py) to expect Unicode strings from
  the code.

* True div vs. floor div: Many division operations used the "/" operator
  to do floor division, which is now the "//" operator in Python 3. These
  were fixed.

As of this commit, on the first pass, I have one failing test (improper
handling of a slice object in a C module, test_imagepath.py) in Python 3,
and three that that I haven't tried running yet (test_imagegl,
test_imagegrab, and test_imageqt). I also haven't tested anything on
Windows. All but the three skipped tests run flawlessly against Pythons
2.6 and 2.7.
2013-01-10 08:46:56 -06:00
Brian Crowell
83ff0b3b31 py3k: Use relative imports
In py3k, imports are absolute unless using the "from . import" syntax.

This commit also solves a recursive import between Image, ImageColor, and
ImagePalette by delay-importing ImagePalette in Image.

I'm not too keen on this commit because the syntax is ugly. I might go back
and prefer the prettier "from PIL import".
2013-01-10 08:46:48 -06:00
Brian Crowell
09f1081c95 py3k: Fix up uses of dictionary views, ranges, and has_key()
y.has_key(x) is gone (use x in y), and keys(), values(), items(), and
range() all return views.

Some iterables needed to be packed into lists, either because the code
expected a list (such as "range(256) * 3") or because the original
collection was being modified (automatic global declarations).

The Tiff ImageFileDictionary is a special case and will be dealt with in
another commit.
2013-01-10 08:46:42 -06:00
Brian Crowell
37f22ebfcd py3k: Use string methods instead of string module
First, we go for the obvious stuff. The string module methods are gone in
3.0, so we translate them to the appropriate methods on the string class.
2013-01-10 08:42:49 -06:00
Alex Clark
9a640e3157 Forking PIL 2010-07-30 22:52:47 -04:00