Copying TIFF tags with PIL

[dshimer]

I am doing some basic modification to existing TIFF files using PIL (1.6 in python 2.5). When I open the image there is quite a bit of info in the tags dict that I would like to save with the new image. Apparently (based on other forums I've seen) once you process the image all the TIFF specific data gets lost. I can copy the info but can't find an example of how to copy or re-assign it to the new image. For example

import Image,TiffImagePlugin
im=Image.open('oldname.tif','r')
tags=im.tag.tags
im.rotate(90,0).save('newname.tif')
 

would open an image named oldname.tif, save the tags, then save a new image that has been rotated by 90. How can I assign those tags back to the new image?

[bartonc]

I am doing some basic modification to existing TIFF files using PIL (1.6 in python 2.5). When I open the image there is quite a bit of info in the tags dict that I would like to save with the new image. Apparently (based on other forums I've seen) once you process the image all the TIFF specific data gets lost. I can copy the info but can't find an example of how to copy or re-assign it to the new image. For example

import Image,TiffImagePlugin
im=Image.open('oldname.tif','r')
tags=im.tag.tags
im.rotate(90,0).save('newname.tif')
 

would open an image named oldname.tif, save the tags, then save a new image that has been rotated by 90. How can I assign those tags back to the new image?

I don't see any reference to setting the tag attr in the docs, but have you tried
im2 = im.rotate(90,0)
im2.tag.tags = tags
to store the saved tags into the new image?

[dshimer]

That give me...

Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "C:\Python25\Lib\site-packages\PIL\Image.py", line 493, in __getattr__
raise AttributeError(name)
AttributeError: tag

I don't totally understand what is going on under the hood, but it seems (and I stress seems) that the tag attribute belongs to the TIFF image object, once you modify the image data in this case with the rotate command, it just becomes raw image data. When it is saved, the proper encoder is called based on the format provided, or the extension. This being the case im2 doesn't have a tag attribute that can be set. I have played with several ways of trying to have the save function do it as part of the re-encoding, but haven't had any luck with that either.

I don't see any reference to setting the tag attr in the docs, but have you tried
im2 = im.rotate(90,0)
im2.tag.tags = tags
to store the saved tags into the new image?

[bartonc]

That give me...

Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "C:\Python25\Lib\site-packages\PIL\Image.py", line 493, in __getattr__
raise AttributeError(name)
AttributeError: tag

I don't totally understand what is going on under the hood, but it seems (and I stress seems) that the tag attribute belongs to the TIFF image object, once you modify the image data in this case with the rotate command, it just becomes raw image data. When it is saved, the proper encoder is called based on the format provided, or the extension. This being the case im2 doesn't have a tag attribute that can be set. I have played with several ways of trying to have the save function do it as part of the re-encoding, but haven't had any luck with that either.

It looks like there is a get() and set() for tag data.
I hope this link proves useful. Google may have optimized itself for the searches that I do often; that link was at the top of the list for "python tiff tag attributes" search. I'll keep trying to get more documentation.

[dshimer]

I appreciate it, I had looked at that page, the underlying code has already been incorporated into PIL 1.1.6 which is probably where the core dpi support comes from. It would probably be a great place to start though for writing a complete tag copy function.

I really have two issues, image processing is a huge part of my work and if I open a file in 4 different programs (including PIL based) there is a lot of inconsistancy in whether or not the TIFF dpi parameters get transferred correctly. Couple this with the amount of stuff that different disciplines try to cram into a TIFF (for example GeoTiff) and it really gets unwieldy. Hence the thought that if I could just completely copy the complete set, most of the problems would decrease. I think your steering me in the right direction, I'll just need some time since programming is a side issue.

It looks like there is a get() and set() for tag data.
I hope this link proves useful. Google may have optimized itself for the searches that I do often; that link was at the top of the list for "python tiff tag attributes" search. I'll keep trying to get more documentation.

[bartonc]

I appreciate it, I had looked at that page, the underlying code has already been incorporated into PIL 1.1.6 which is probably where the core dpi support comes from. It would probably be a great place to start though for writing a complete tag copy function.

I really have two issues, image processing is a huge part of my work and if I open a file in 4 different programs (including PIL based) there is a lot of inconsistancy in whether or not the TIFF dpi parameters get transferred correctly. Couple this with the amount of stuff that different disciplines try to cram into a TIFF (for example GeoTiff) and it really gets unwieldy. Hence the thought that if I could just completely copy the complete set, most of the problems would decrease. I think your steering me in the right direction, I'll just need some time since programming is a side issue.

Some Gui Tool Kits have good graphics support. Here is a snippet from wxPython help:

wxImage
This class encapsulates a platform-independent image. An image can be created from data, or using wxBitmap::ConvertToImage. An image can be loaded from a file in a variety of formats, and is extensible to new formats via image format handlers. Functions are available to set and get image bits, so it can be used for basic image manipulation.
A wxImage cannot (currently) be drawn directly to a wxDC. Instead, a platform-specific wxBitmap object must be created from it using the wxBitmap::wxBitmap(wxImage,int depth) constructor. This bitmap can then be drawn in a device context, using wxDC::DrawBitmap.
One colour value of the image may be used as a mask colour which will lead to the automatic creation of a wxMask object associated to the bitmap object.
Alpha channel support
Starting from wxWidgets 2.5.0 wxImage supports alpha channel data, that is in addition to a byte for the red, green and blue colour components for each pixel it also stores a byte representing the pixel opacity. An alpha value of 0 corresponds to a transparent pixel (null opacity) while a value of 255 means that the pixel is 100% opaque.
Unlike RGB data, not all images have an alpha channel and before using GetAlpha you should check if this image contains an alpha channel with HasAlpha. Note that currently only images loaded from PNG files with transparency information will have an alpha channel but alpha support will be added to the other formats as well (as well as support for saving images with alpha channel which also isn't implemented).
Available image handlers
The following image handlers are available. wxBMPHandler is always installed by default. To use other image formats, install the appropriate handler with wxImage::AddHandler or wxInitAllImageHandlers.
wxBMPHandler 
For loading and saving, always installed. 
wxPNGHandler 
For loading (including alpha support) and saving. 
wxJPEGHandler 
For loading and saving. 
wxGIFHandler 
Only for loading, due to legal issues. 
wxPCXHandler 
For loading and saving (see below). 
wxPNMHandler 
For loading and saving (see below). 
!!!!!!!!!!!!!!!!!
wxTIFFHandler 
For loading and saving. 
!!!!!!!!!!!!!!!!
wxIFFHandler 
For loading only. 
wxXPMHandler 
For loading and saving. 
wxICOHandler 
For loading and saving. 
wxCURHandler 
For loading and saving. 
wxANIHandler 
For loading only. 
When saving in PCX format, wxPCXHandler will count the number of different colours in the image; if there are 256 or less colours, it will save as 8 bit, else it will save as 24 bit.
Loading PNMs only works for ASCII or raw RGB images. When saving in PNM format, wxPNMHandler will always save as raw RGB.

so maybe this is a good option.

[bartonc]

Here is a very interisting page.
I actually linked there from here.

[dshimer]

Here is a very interisting page.
I actually linked there from here.

Wow that looks like some neat stuff. Now all I need is for production to slow down a little so I can dive in.

This whole problem started with PIL 1.1.6 not setting dpi correctly. I really need to copy the entire tag of the original TIFF file but the real emergency came from not being able to properly manage the dpi. I did get a reply from the image-sig that points out a patch which at least corrects that problem.

The Tiff image plugin handles the RESOLUTION_UNIT field incorrectly,
see http://mail.python.org/pipermail/ima...ly/004011.html.

Markus Kemmerling
Medical University Vienna

I have applied and tested the indicated patch in 1.1.6 and all is now well as regards dpi! Hooray!

[bartonc]

Wow that looks like some neat stuff. Now all I need is for production to slow down a little so I can dive in.

This whole problem started with PIL 1.1.6 not setting dpi correctly. I really need to copy the entire tag of the original TIFF file but the real emergency came from not being able to properly manage the dpi. I did get a reply from the image-sig that points out a patch which at least corrects that problem.


I have applied and tested the indicated patch in 1.1.6 and all is now well as regards dpi! Hooray!

Glad to hear that you got it working. Thanks for the update, D!