horst

here is the little module that adds auto population for single textfields with exif or iptc data: http://processwire.com/talk/topic/3398-working-with-processwire-getting-exif-data-from-images/#entry33552 Many thanks for your kind help Soma!

I have written a little module that extends Somas awesome Images Manager. Also it's written with Somas kind help, (thanks!) It adds auto filling of EXIF or IPTC fields where available on upload of new images through Images Manager. How to use it: You, of course have Images Manager installed and ready to run. Now you have to create some fields that should take your exif data: fieldname prefix is exif_ followed by the original exif-fieldname but lowercase! ( exif_author, exif_copyright, etc.) ALSO you have to create one TextArea field called (by default) image_exif, - this one and ... (not needed, only optional to get the full raw EXIF-data stored) all your exif_fields you have to add to the image-template that is used by Images Manager for creating the new Image Pages. then download and install the ImagesManagerMetadata module. here are a little screencast I've done with it: https://youtu.be/wjhJdT7Tf5Y this is alpha, version 0.0.2 ImagesManagerMetadata.zip

Hi Marc, @ 2) actually your original images are kept without manipulations, so all EXIF is kept with them. (at least this is if you not have set a max-width or max-height with your images, this I actually don't and have to check by myself). With all variations the EXIF is stripped! @ 1) I don't know what Marty does but I'm interested to hear about too. I actually try to auto-populate my page fields with EXIF-data and then do a manually correction where needed. After that there are only Pagefields that get outputted to the frontend. EXIF-data reading is done only once. I have written a little module with somas kind help that adds auto filling of EXIF-data to the Images Manager. I will post here in a few minutes when have uploaded a screencast.

Yep (ich habs) : $options = wire('modules')->getModuleConfigData(wire('modules')->get('ImagesManager'));

Allright , - but getting the ExifFieldname would be of great help if the user changes the default name: function ___setMetaData(Page $page, $file, $fieldnameExif) Many thanks!

Hi, it's me again. It would be really nice if we can have a field for IPTC as well: 'imagesIPTCField' => 'image_iptc', and if you can provide their fieldnames within the hookable method: $this->setMetaData($imagepage, $this->upload_path . $file, $this->options['imagesEXIFField'], $this->options['imagesIPTCField']); public function ___setMetaData(Page $page, $file, $fieldnameExif, $fieldnameIPTC) { If you want to populate IPTC data too: // write iptc data if field exists on page if($page->template->fieldgroup->hasField($this->options['imagesIPTCField'])) { $tmp = getimagesize($file, $info); if(isset($info['APP13'])) { $iptc = iptcparse($info['APP13']); if($iptc) { $page->set($this->options['imagesIPTCField'], json_encode($iptc)); } } }

Exif reading is perfect! We can retrieve the data with $myExifArray = wireDecodeJSON( $myImagePage->image_exif ); EDIT: Your solution is very elegant. The user who wants to get Exifdata may only add a TextareaField to his image-Template! --- But there is something with the Textfield not allright: I use Firefox on Windows

Hi Marty, I'm using that same 'lofi approach', - but waiting for Somas ImagesManager to become beta. Also I've posted a question to him.

Hey Soma, very cool Manager! (it's not the first time I say this, but it can't be said to often ) I want to ask if it is possible and if you find it useful, to include an optional userdefined callback-function that gets invoked in the public function executeUpload() method at line 517. After successful upload and the new ImagePage is saved calling it for example like this: if( ! empty($this->options['userCallbackUpload']) && function_exists($this->options['userCallbackUpload']) ) { ${$this->options['userCallbackUpload']}( $imagepage ); } With this, users may have a simple way to extend imagesPageTemplate with some more fields (e.g. for Exif-data). Yes, actually they allready have this option to extend the template or provide an own, but it would only allow to do a manually populating of fields. With a userCallbackFunction it could be done automatically. Is this not of interest for the ImagesManager himself? You may read Exif-description and IPTC-description fields and populate automatically the ImageDescriptionField. (IPTC has higher priority as EXIF). So, if a user uses IPTC-description the field is allready filled, if not, and Exif-Description is available, this is used. Downside: If there is unwanted text populated, the user has to change it manually. But with nothing populated automatically the user allways has to do it all manually. Maybe it could be an boolean option: 'Yes, do autopopulate the image description' or 'NO' ? EDIT: approved code for reading this I can provide, - as you've said elsewhere: i'm the 'metadata-man'

Hi Marty, Hi MarcC, I'm not sure if I understand the question/s right, but I can point out some things that come to my mind when reading it: The imagesfieldtype currently has only one description field what can collect data. This is a Textfield and can store data up to max 64kB. Depending on what EXifdata you need, it maybe a possible approach to store that with the description field (serialized?). Accompanying resize-methods to the imagesfield needs to create an own imagesfield with this extensions. (Like ThumbnailsModule) But I would prefer to store each image as a page and have all wanted single exif-data on that template as fields. To use images as pages is often discussed here, because it's flexible and scalable. Also Somas ImagesManager could be of interest. So, regardless on how you organize your images, I think it would be pretty usefull if the fields get populated automatically somehow, - at upload for example. Saying that, I actually don't really know how to do it. (I'm PW-newbie (somehow), - hook into upload with a module - ok, but what comes after hooking may be very individual on someones need) --- Note: when applying any Imagemanipulation with GD, every EXIF-data get stripped and is lost! You should not manipulate your original images! --- For reading and sorting Exifdata (and IPTC-data) I can provide some code if wanted.

( ohne Worte - without words )

EDIT: (deleted because of yellow card) EDIT 2: put backup in, - because referee was to quick with yellow card ------->> original postContent @Petsagouris: I think there is only one possible explanation: the libraries are baken by butchers ... and that's with the sharpening was meant as an example. Read the source of ImageSizer and you will see the other improvements from the community. Than look to the posts of that contributors and, for shure, you should get a clue of the quality level on which they [ work / act / post / contribute ]. U-Turn of the day: first I should go and take their lib, not write an own | U-Turn | now I should go and fix their's. Hey, you are joking!

Hi Raymond, yes watermarking makes sense together with a CMS.

Truth of the day: - WordPress is one of the most downloaded CMS so they must be doing something correctly. - specially for the germans: BILD-zeitung is the most selled Newspaper, so they must be doing something correctly. Yes of corse they will do something correctly, but what does it tell me about the quality / usability of it? --- Petsagouris, I have had two quick views to this lib, and it is like it is with most others of them: 1) sharpening - https://github.com/avalanche123/Imagine/blob/develop/lib/Imagine/Gd/Effects.php they have 1 pattern! That's that pattern that is into all libs that have sharpening and of corse you can find it all over the web. (php.net usernotes, stackoverflow, etc, etc). With the new addition to ImageSizer we now have 3 patterns (soft, medium, strong). (and they are well tested over a set of 30 images, from lowkey to highkey covering not only most common scenes). Maybe that in a year the other libs have them included too, because they have found them here in PW. who knows And, last but not least: sharpening isn't a _effect_, sharpening is essentially image processing. And there exists more than 20 different common methods to apply sharpening to an image. One of that is added to the ImageEditors sharpening method, it's called multistep-sharpening! So with it we now have 4 different patterns available, and you also may pass an array to the method with your own pattern, if the available do not suite your needs in some cases. (with this the advanced users have much more than 4 patterns that they can apply to an image) I don't know who are the people what have done all those libraries. They may be good or very good developers or enthusiats and they may have done really good work or awesome work, - but one thing is fact: I'm sure there are no photographers with them. ;-) (Don't go to a butcher when you want to buy a bread!) 2) there should be only the basics in it, in ImageSizer and in ImageEditor. But these should be robust and with a high comfort for users who don't know much about image-processing but may expect an equal behave like they know from PW. And with ImageSizer this is allready reached because of The only thing what was really needed and wasn't in there was a good sharpening. There is all in what is needed to do a perfect job with resizing, - regardless of image formats, filenames, transparencies, and what ever. But not more! And ImageEditor should be like that with what could be usefull for most users handling images in an CMS, and not more! At first it should be a tool for module authors who want to deal with images, so that they haven't to go and take a sharpening method from somewhere in the web without really knowing what it does / how it works. They should be able to simply resize an image, and sharpening is applied automatically. (They even have not to know about the fact that images could/should be sharpened when resized, - like I can store some Text into a PW-Page without have to know how a DB works on that).

When working on ImageEditor (formerly named ImageManipulation) I come across some points that I want to [ discuss | get advice | point out ] ----- 1) The ImageEditor now can be used like this: $myImage = $page->images->first; $imedit = new ImageEditor($myImage); if($imedit->imRotate(90)->imResize(300,0,false)->imSharpen('soft')->imSave()) { echo '<img src="'.$myImage->url.'" />'; } It needs a PageImage as source. This can be an original Image, but than it needs a targetFilename, because it doesn't allow to overwrite the original Image! When it gets an ImageVariation it can save to that filename (overwrite). You also may save to another image format, e.g. your source is JPEG and you apply some alpha masking vodoo to it, you want to save it as PNG. This can be done by define the optional option outputFormat. ----- 2) I think there is a need for a additional Image Method: $image->nameAppendix() or something like that because there is allready a naming convention for images ( originalimagename.300x0.jpg or originalimagename.0x300.jpg ) that could be extended to something like originalimagename . 300x0 (userdefinedAppendixWrappedBySpecialChars) .jpg The $image->nameAppendix('userDefinedAppendix') should set or exchange this filename part. This would be of great help to keep imagenames consistent across the site. I have read a thread where Ryan has said that when trying do delete all Variations of a site that cannot be done by iterating through $images and use ->removeVariations() for large sites. On the other hand when users or module authors can name the images without be restricted that may become a mess with imagenames. At least there should be defined a image naming convention with respect to UserNameAppendices, - than I can implement it into the ImageEditor. ----- 3) I need some advice on how to handle Errors & Warnings, e.g. when not all needed options are passed, or they aren't valid. Should we silently use defaultValues where available or should we use that and write to ErrorLogFile. Don't know how fast a Logfile can grow, or even more terrible, - when should I throw an Exception? When gets an admin email invoked? I can upload the code or provide otherwise more informations on that. Please ask / tell what is needed. ----- 4) Here are some examples / possibilities of usage: $myImage = $page->images->first; $imedit = new ImageEditor($myImage); output of $imedit->image : array(10) { ["type"] string(3) "jpg" ["imageType"] int(2) ["mimetype"] string(10) "image/jpeg" ["width"] int(1800) ["height"] int(1196) ["landscape"] bool(true) ["ratio"] float(1.505016722408) ["bits"] int(8) ["channels"] int(3) ["colspace"] string(9) "DeviceRGB" } $myImage = $page->images->first; $imedit = new ImageEditor($myImage, $options); //second param is optional $options array like with ImagesSizer /** * valid options, identical to that 5 from (new) ImageSizer, * width 3 additions: targetFilename and outputFormat * * - targetFilename is needed because we don't want to overwrite the original Imagefile * there are two exceptions: * 1) if you have allready created a variation and have passed that to the ImageEditor * than a targetFilename is not needed. * (we check reference '$image->original' to know about that) * 2) using the static function fileAutoRotation, because this is mainly implemented * for correcting an original imagefile on upload! So a file gets uploaded only one * time and only then we may apply rotation to the original image. * * - outputFormat is optional and only should give ability to * import for example a JPEG, do something with fancy masking and * save it to PNG-Format with alpha transparency. * * - bgcolor may be used when wrapping borders around an image or create Thumbnails like Slides * (squares with landscapes or portraits in it) * */ protected $optionNames = array( 'autoRotation', 'upscaling', 'cropping', 'quality', 'sharpening', 'bgcolor', 'targetFilename', 'outputFormat' ); // you may also at any point get out the memoryimage, apply your own stuff like a SepiaFilter and put it back: $myImage = $page->images->first; $imedit = new ImageEditor($myImage); $im = $imedit->imRotate(90)->imResize(300,0,false)->imSharpen('soft')->imGetIm(); imagefilter($im,IMG_FILTER_GRAYSCALE); imagefilter($im,IMG_FILTER_COLORIZE,100,50,0); $imedit->imSetIm($im)->imSave(); // the OneLiner // this one should get invoked when an image is uploaded public static function fileAutoRotation( $filename, $quality=95 ) // and this one is a present for apeisa, (but pssst, don't tell him) public static function fileThumbnailModule( $filename, $src_x, $src_y, $dst_w, $dst_h, $src_w, $src_h, $quality=95, $sharpening='medium' )

No, this isn't suspicious, it's me saying skoal.

( this is the community from Ryans point of view )

Thanks for looking to this Ryan. So may I go to the wishlist and add a 'FieldtypeTextUnique' to it, or is it allready on a list you have?

Thanks Ryan, - but I don't need it now with this module. It was just a to quick asked question. Anyway it's good to know for the future. I will go with the ConfigurableModule. But if one ask here on the forum it maybe that one get to much information for one's brain to handle / process / assimilate. But, just keep on with it guys!

Maybe, but as of Thumbnails is a visual Tool, I wish to have it like in my dirty Hack. plus one additional feature: If you have created a Thumb and quality isn't what you have expected, when you go back to recreate it, the CropRectangle should be placed automaticaly at its place, so you have only to select a different quality and / or sharpening pattern. (Just a dream, - but sometimes they become true)

Ryan, did you find out something about that with the use of the language pack? I'm fine with the default admin theme, but language pack would be fine.

Yes! That's really fun.

have had some hours last evening (exactly 8 'til now) I think I can finish the import next time I get 2-3 hours. So, don't know when now. There is some trouble with chars in filenames and ID3-Tags that want not get into the DB, so I have played around with sanitizer, but have to go deeper and change the current behave. Here are a screencast of the backend, starting with an empty DB (no mp3 data in it) set one or more pathes, do a quick filesystem scan (without parsing ID3 etc) envoke a command line script to perform scan with parsing mp3 files and pull data into DB: (please look fullscreen or otherwise enlarge Video) https://youtu.be/Re08fuNFRao

Hi Soma, I'm actually working on scanning filesystem and parse 5000 files for metadata. As I run into errors (e.g. not knowing to use $sanitizer->selectorValue()) I don't want to wait 3 minutes every loop, - so store a serialized array in cache-file (site/assets/cache/). I've asked to get a sense for the possibilities. Actually I only will use the ModuleConfigData-storage for some Path- and Extension-strings. Thanks, it only implements ConfigurableModule, so it must have Module allready. (will look into that closer) EDIT: have found this Post: http://processwire.com/talk/topic/1313-modules-process-and-the-difference/#entry11738

Can I also use it with extending Process instead of WireData? class MyModule extends Process implements Module, ConfigurableModule { That's awesome! I will change that after finishing some other parts Is there a limit on size to store? For example can I store a serialized array of 5MB or are any bads with that ? Many thanks!