Re: Package Proposal: Image_JPEG

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?! 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). 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. 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