A problem with releasing all of them in a JPEG package is that TIFF
files can also have IPTC headers.
That's a very good point...
TIFF and JPEG are the only Image formats that share a big chunk of structure. Actually, add Photoshop's PSD to that list. No other "popular" format uses IPTC (as far as I know).
The "exif" part of JPEG is actually a partial TIFF file. And "iptc" is actually a partial PSD file. So my Image_JPEG already has 99% of the code needed to parse TIFF and PSD files.
Creating a global Image_Metadata module would be too ambitious, and I don't want to spend time creating a single universal metadata abstraction that can cover PNG, GIF, BMP, etc... After all, there's a reason I'm using PHP instead of Java. And most of those formats don't have any metadata at all besides the image dimensions and perhaps some comments.
Creating a single Image_JPEGTIFFPSD module is actually rather simple. But naming that module might be an issue... JPEGTIFFPSD doesn't actually sounds right, at least not to me... Image_JPEG, Image_TIFF and Image_PSD sound better, and Image_TIFF and Image_PSD could be very simple classes inheriting everything from Image_JPEG. I don't really know how PEAR would handle something like this, but in the worst case it would mean indicating a dependency between the packages.
Another choice would be Image_IPTC + Image_EXIF, but that makes using the package much harder, since you might need two different objects to manipulate a single file. Two separate parsings, two separate saves, etc... And trying to hide those using a shared object or something like that would be a lot more complex.
I haven't worked on Image_TIFF or Image_PSD yet for lack of time and necessity, but again, they would be very simple to implement.
Anyway... that's just my opinion ;-)
Regards,
Sebastian