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...
Fix for UnicodeDecodeError: ascii codec cannot decode byte while saving a TIFF image
Problem occured while saving TIFF images that contain non-ascii characters in metadata
Manually merged with master by wiredfool
cf. #1191.
Only TiffImagePlugin and OLEFileIO still rely on (their own) DEBUG flag.
I left TiffImagePlugin as it is because I hope #1059 gets merged in
first, and OLEFileIO because it uses its own logic.
Untested, as usual.
