Images in Qt show up incorrectly if each line is not aligned to 32 bits.
It is pretty common for an image's lines to be 32-bit alinged by chance.
Obviously any 32-bit image will not have any problem.
For the bug to manifest itself you'd need...
* a 1-bit image whose width is not a multiple of 32
* an 8-bit image who width is not a multiple of 4
Testing more images now and added a 7x13 png test image
By interleaving little and big-endian entries we make sure entries
exist for both cases. Some additional entries created when the
big-endian was missing. I am not sure of what entry to create for the
big-endian, 4-bit case (what is the order of the two entries within the
byte?).
Some programs generate SamplesPerPixel entries in ExtraSamples instead
of SamplesPerPixel-3, cf. #1227. This is a stopgap measure to support
them. One could also decide to add generic code to always support
having SamplesPerPixel entries (by dropping the first 3).
To have the old API that always returns tuples, and fractions as pairs,
set the `legacy_api` attribute of the IFD to True.
This should alleviate concerns about backwards compatibility.
Do not represent scalar tags as 1-element tuples. Keep tag
type and count information in TiffTags.TAGS. Normalize data in
ImageFileDirectory.__setitem__: wrap and unwrap tuples as needed,
convert rationals to floats. (To ensure consistency, make the "tags"
attribute private.) Interpret byte data as a series of integers rather
than a bytearray (which should only map to the "undefined" type). On
Python3, if a str is assigned to an "undefined" tag, encode it as ASCII.
Note that a large number of tags have been removed from TiffTags.TAGS
because I do not have time to figure out the type and count of each of
them. They should be restored before this gets merged in.
This obviously breaks backwards compatibility in a lot of ways...
