Seb, sorry for being naive, but what else *exactly* does it do? if its not metadata, and its not the images image data.... what is it?!
It does provide access to the image data... just not as a bitmap you can easily change. JPEGs use 3 different compression mechanisms one on top of the other. My class gives you access (for now) to the compressed data. It doesn't decompress it, but it lets you read it and even change it. It also provides access to every component (or block if you wish) inside a JPEG file... some of them are integral to the file, some are optional. Some are data and some are metadata.
The current implementation also provides higher level encoding and decoding for some of those components, including EXIF and IPTC blocks. You could say that this is where some overlap exists with other PEAR packages and PHP extensions. And this is what you would call the "metadata" aspect of this package.
The package also lets you add and remove blocks, so you could use it to strip any non-mandatory block, or to add comments, color profiles, an IPTC block, thumbnails, etc.
The reason I say Image_Metadata means you could write a 'frontend' class, which Image_Metadata_JPEG can extend, or Image_Metadata_TIFF or whatever, this makes using the group of packages a lot easier when you are dealing with multiple image types (say, a stock art gallery script which accepts JPEG for previews and TIFF/PSD for he downloadable version).
Having a frontend class sounds like a good idea, but it is harder than it looks.
Different graphic formats have different kinds of metadata. Some formats, like JPEG and TIFF can have IPTC blocks, but not GIF files, on the other hand, Animated GIF files can have several images in them, something that's not present on a TIFF file.
So creating a single interface that can cover all those posibilities is, while not impossible, a very hard thing.
However... in the future that class, or set of classes, could be implemented using my package and others that will come later... it's just that I don't think it's a good idea to hold all image related packages until we have that "universal" interface.
You could even just (I'm sure people will kill me for saying this, but meh) write Image_Metadata as a class with only a single public method (the constructor) which simply checks if the file wanting to be manipulated, can be, and if the extension package needed to do that is present, and then it includes the extension package and returns an object of said extension package which is then used by the user.
I say one public method because I think doing all that in one method might make it too messy, placing the checks and such in different method means nicer code :)
I would be willing to write this 'frontend' package if this way is decided as the way to go. It would require little maintaining (just adding checks as new formats are added), and we just need to ensure all other Image_Metadata_* packages have the same method names for those which are publically called to do the same thing.
If you were thinking of extending your package to do rotations or whatever, I would suggest placing those in a *seperate* package, after all you can call on the methods in your current package from in it if need be, but there really (IMO) isn't a name that could cover the metadata stuff and manipulation except something like:
Image_Metadata_and_Manipulation_JPEG
Image_Metadata_and_Manipulation_TIFF
etc
which are ugly.
With JPEGs in particular, you can perform *some* changes in a lossless manner just by *massaging* the data. It doesn't involve any kind of pixel manipulation. They are very useful, since they don't involve loss of quality due to recompression. But they can only be performed if you can partially decompress the data. Which can only be done if you really know the file format. The GD libraries don't provide that feature. And I doubt any other file format can have a similar feature...
That's exactly why I originally proposed just Image_JPEG. At some point, those would be the modules to "anything" with a JPEG (or TIFF, etc) file.
I think Image_Format_JPEG might be even beter... because that's what the module does... it provides access to the "file format". If with that access you can do some other things, then so be it...
Instead you could have Image_Manipulation, or Image_Rotate and in the same fashion as Image_Metadata have Image_Rotate_JPEG or Image_Rotate_TIFF.
- Davey
Sebastian Delmont wrote:
Calling it Image_Metadata would be putting too much pressure on me :-)
And File_Metadata would be even worse.
I rather call it Image_Format_JPEG, and later create a separate Image_Format_TIFF.
Internally, they might share code, but users don't need to know about that. And if we later want to add Image_Format_GIF, which wouldn't share a single line of code, it would also fit in just fine.
Not all Metadata formats are the same. Not all image formats are the same. Trying to provide a single useful interface to encompass them all would be too much work. At least it is not something I would be willing to do.
And it's not just "metadata". I don't want to use the word "Metadata" because it is too limiting. This module (and the ones that might follow) allow for full control of the file... not just the metadata... it's just that it is data oriented rather than image oriented... that's why I think the word "Format" or "File" is appropiate. But it still is an "Image" file, not just any kind of file.
I didn't said I wanted to do TIFF, PSD, GIF, MP3 and DOC... I just said that, if they were developed, they could use package names like Image_Format_PSD, Audio_Format_MP3 and Office_Format_DOC.
Davey wrote:
Pierre-Alain Joye wrote:
On Wed, 07 May 2003 11:56:57 -0400
Sebastian Delmont <sdelmont@zonageek.com> wrote:
What about:
Image_Format_JPEG
and later, Image_Format_TIFF, Image_Format_PSD, Image_Format_GIF,
etc...
Do you allow modification and or access to the image data itselft (I
looked the code, but no phpdoc comments)?
If not, this is not usefull names. IPTC/EXIF/Metadata should be in one
and single package. I understand you will not like to work more than
required. Consider my point of view as a pov about PEAR and PHP.
Working a lot on imaging functions in php since a few months, many
packages for the same goals (I talk about the userview of the package,
regardless to the implementation) are definitively not the way to
choose.
pierre
I think its obvious that names with IPTC in them will not work, as it also parses EXIF and more.
Why not name it Image_Metadata - and say that at present it only supports JPEG/JFIF/JPG but you plan to write TIFF, PSD, etc into it.
That way we don't end up with Image_TIFF, Image_PSD or whatever.
Or what about File_Metadata if you plan to extend it for MP3 (would be that be ID3?) and DOC etc?
- Davey