Jump to content

horst

PW-Moderators
  • Posts

    4,085
  • Joined

  • Last visited

  • Days Won

    87

Everything posted by horst

  1. thank you for the info. I will try it out.
  2. Hi teppo, thanks for the help and the useful link. I have tried with the explanation on that site, but I have solved it only 90% with this query: $q = 'SELECT t1.g_id, t1.g_title, t1.g_summary, t1.g_description FROM g2_Item t1 LEFT JOIN g2_CustomFieldMap t2 ON t1.g_id = t2.g_itemId WHERE t2.g_itemId is NULL AND t1.g_canContainChildren=1'; it returns all rows from t1 that have no matching row in t2. But I want to get all that do not have 3 matching rows in t2: sample data of t1: g_id = 1000, g_summary = 'my summary1' , etc. g_id = 2000, g_summary = 'my summary2' , etc. g_id = 3000, g_summary = 'my summary3' , etc. g_id = 4000, g_summary = 'my summary4' , etc. sample data of t2: g_itemId = 1000, g_field = 'custom_fn1', g_value = 'myValue1' g_itemId = 1000, g_field = 'custom_fn2', g_value = 'myValue2' g_itemId = 1000, g_field = 'custom_fn3', g_value = 'myValue3' g_itemId = 2000, g_field = 'custom_fn1', g_value = 'myValue1' g_itemId = 3000, g_field = 'custom_fn1', g_value = 'myValue1' g_itemId = 3000, g_field = 'custom_fn3', g_value = 'myValue3' The wanted select should return the rows for g_id: 2000, 3000, 4000, because only g_id 1000 has all 3 rows in table t2.
  3. Hi, I'm not sure if I can ask this here because it has nothing to do with PW, so - if is unwanted please tell me. I'm actually working on a old site of mine that runs with Gallery2. There I have added 3 userfields to albums and now have to update all data (300 albums). Because it is so very very slow with updating through its own admin interface, I want to write a short interactive update wizzard script but stuck with the mysql-select query. I need to query two tables in a (old) mysql 4 DB. From the first Table I need this: SELECT g_id,g_title,g_summary,g_description FROM g2_Item WHERE g_canContainChildren=1 But I want only get the rows in result where are not set all data in the second table: the second table (g2_CustomFieldMap) has fields: g_itemId,g_field,g_value g_field can contain: 'custom_fn1','custom_fn2','custom_fn3' for each g_itemId (g_itemId is g_id from first Query) Is it possible to call this all together as one query? Any help from mysql-specialists are welcome
  4. Hi Soma, can this be used in the frontend? I want to use DataTables with my MP3-DB in the frontend with AJAX-Pagination and -Sorting.
  5. Hey, is this new? Cool: mods.pw/3y EDIT: uhm, sorry for beeing OT! Just got excited.
  6. Oh, I haven't thought that one could do it with the standard 4S. But apart from technical details, this one is my favourite because of composition and light ;-)
  7. Hi Marty, good work! (site and photos) This one was shot with pure / native iphone 4S ? Or with an additional lens for close-up range?
  8. Maybe it is an option to search for specific camera that supports iOS? google: ipcamera video codecs for ios or is camera allready there?
  9. 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!
  10. 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
  11. 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.
  12. Yep (ich habs) : $options = wire('modules')->getModuleConfigData(wire('modules')->get('ImagesManager'));
  13. 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!
  14. 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)); } } }
  15. 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
  16. 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.
  17. 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'
  18. 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.
  19. ( ohne Worte - without words )
  20. 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!
  21. Hi Raymond, yes watermarking makes sense together with a CMS.
  22. 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).
  23. 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' )
  24. No, this isn't suspicious, it's me saying skoal.
  25. ( this is the community from Ryans point of view )
×
×
  • Create New...