horst

Do you want use image functions or do want not? If you want use image functions, I suggest to use an images field, that's what they are built for.

size() is bound to images, not files you need to get the page then get the imagesfield then select the desired image (not: file!) do the resize

you need to get the page then get the imagesfield then select the desired image do the resize Will say, it is done as always. Where is your page that holds the imagesfield? Do you have a path, a name or a id of it? // within a modules method you will do something like 1) $p = $this->pages->get(YOURPAGESELECTOR); 2) $images = $p->yourImagesField; 3) $image = $images->first(); // or whatever you like 4) $image->size(x, y); PS: Please do not send me PMs with something like: "how can I do xy, please help its urgent." Use the forums support thread or the job section!

@OllieMackJames: Are you able to use PW 3.0.10 for your site, or do you need to stick with PW 2.7 ? If you can use PW 3, you simply may copy one of the ImageSizerEngines into your site modules directory, change the classname, and add the optimization functionality. To add the functionality, I highly would suggest to use an API image option, e.g. array("optimize" => true). This way you are able to control which variation should be passed to the optimisation service and which one not. At the end of the image manipulation, you can ask if optimize is set: if($this->optimize) { $optimus = new Optimus('<your_license_key>'); $result = $optimus->optimize($dstFilename); file_put_contents($dstFilename, $result); } That's all you need. You also may set the optimize default to true in site/config.php $config->imageSizerOptions = array(..., ..., ..., "optimize" => true)); and then explicitly disable it via individual API option settings in your template files. Just choose what fits best for your site.

Yes, it prevent memory errors. The sizer is invoked in here in Pageimage. If it returns false, for what ever reason, but also for a memorcheck, the error is handled here in Pageimage starting from line 434. It writes a text line into the variation file: "This is intentionally invalid image data.\n"; And it logs that error. But it will not interrupt your page render / page load. It will proceed further content, just the image what would exceed your available memory isn't created, is missing. But this only belongs to the GD-lib, not to IMagick. IMagick can process image manipulation by lines or by chunks, what let it successful work with less memory too.

The GD now has complete memory checking before loading images into memory. It has had memory checking since some time already, but I have overseen two points in the code for this, what is now fixed with PW 3.0.10 too. In regard of the IMagick bug with PNG8 with transparency, we only can and will change this if we are able to detect if IMagick can handle this correct. Otherwise it will be handed over to GD.

Fieldname BaseStyle has Uppercase letters. Try to rename / use only lowercase letters. Check the fieldname in DB, (field_BaseStyle or field_basestyle)

Here is a better comparision, including all 4 sharpening modes and with 280px images output. I only post the link of an PNG screenshot here, because it is 8MB: http://images.pw.nogajski.de/assets/screen_255.png Here are the values, without the thumbnail images:

A first comparision in filesize & processing time among the first 4 engines with different qualities. Sharpening is set to soft here. Without sharpening, the Netpbm is much faster, but also more blurry than IMagick without sharpening. In regard of filesize and visual quality, Netpbm is better than IMagick. For the overall usage, IMagick as PHP extension is best optimized for speed with a very good visual quality. It is also faster than the IMagick-CLI engine in most cases.

Recent Netpbm binaries for Windows are compiled and served by Terry Ron Vantreese. They can be found here: https://onedrive.live.com/?id=9E7DB242359A93F0!28283&cid=9E7DB242359A93F0 To use them, unpack them and put them into a subfolder. Enter the path to that directory into the designated inputfield in the modules config page. Save it, done!

Ah, sorry, don't got this fully. With the everywhere available GD lib it is not possible to do any sort of colorspace detection / prevention / conversion. With ImageMagick, as CLI or PHP-Extension, it is only possible with compiled-in lcms to proceed colorspace operations. And only then, it would make sense to keep an ICC profile. To clarify my understanding of a colorspace workflow: detect the colorspace (ICC profile) of the incoming image transform it into a workflow colorspace (e.g. AdobeRGB or ECI-RGB) do all manipulations transform it into sRGB colorspace just before output optionally embedd sRGB profile I never would use the incoming profile as the output-profile, I ever would transform into sRGB. (Browsers and CMS's are not Photoshop, ;-)) Embedding an output profile into an imagevariation requires lcms. Processing it in the above workflow will increase the processing time up to 4 times for every variation. We have tested a lot on this two years ago.

The first thing is, if you do not have the PHP-IMagick Extension available on a server, but are able to use the PHP exec() function for CLI operations. Than this and the NETPBM module are useful. A quick and short comparision of the current state of all currently available modules is: The core implemented PHP-Extension Imagick module lacks of support / detection of PNG 8bit transparency files and correct GIF support. Therefor it only processes JPEG and PNG24 images. GIF and PNG8 images are handed over to the GD engine. If the ImageMagick-CLI can handle PNG8 bit images with transparency is not inspected before image processing. It may or may not, but with a recent, and fully functional ImageMagick installation it should be able to process all sort of image formats and subformats. The NETPBM-CLI is currently work in progress. With Version 0.1.0, It supports JPEG only. But the other formats will be added as soon as I get time for it. There are no known downsides, I just need time to test and implement this. The difference in quality is minimal between those three modules. They are all better than the GD lib. To choose one before the other ATM only depends on what is supported on a webserver, or may be on personal preferences. When the modules are finished, so that they support all kind of formats and subformats, I will publsh a comparision table of the most useful aspects. Until then, it will be helpful if people can test one or more of them and report back how it goes.

NOt an easy one, but maybe easier for you now: https://processwire.com/talk/topic/6096-imagick-resizer-need-to-be-tested-2/#entry59711

@jugibur: just to clarify: PW doesn't alter the original image per default. There is only one situation where the original image will be altered: If you have settings for max-image-width or height set with an imagefield and an uploaded image exeed those limits, then PW creates a resized variation and stores that as the original! Otherwise, the original image will not get touched in any way! So, in short, ;-) The common denomination for colorspaces is sRGB! Browsers (and all other PC devices in a colorspace chain) per default do assume the sRGB profile, at least, if a profile is missing. Therefore, no ICC profile is needed. If you want to use more advanced features, should this be done automated by a webbrowser? We all know that different webbrowsers has done and do interpret features in different implementations, regardless of W3C standards. This is for different reasons: product- / company- political, simply missunderstood things or bugs, or what ever. If you want to publish images, do you really want to go that far, that you want use/try browser- or feature-sniffing, and than serve different imagevariations (with and without ICC) on assumed browsertypes? Using sRGB is the fastest (and a painless) way to serve homogenious results to different browsers. But what I meant with homogenious, was not how the images will look like in browsers of different vendors. I meant, that the way how PW handles the manipulations should be nearly independend of the used or available engine(s). So, per default, we use the lowest denominator, what is GD or everything else without ICC conversion possibilties. Also, for the average user and in most cases ( > 99% ?), the images will be in sRGB colorspace. Hopefully, most people who uses other colorspaces, also have a bit knowledge about imagehandling and therefor will know what they do. So, for those people, it may be an optional comfort feature to have ICC, but I'm not 100% sure, if this is really a comfort, despite all downside aspects. Long story / short saying: The default and core in PW only will have features that are used and or available for more than 30% of (assumed) PW installations. All other things belong into third party tools / modules.

You also may setup a more comfortable own template only for the options, using a slider for quality, select or radio or asm for sharpening, etc. And then embedd this template via a pagetable, limited to only one item, into your gallery template. (and reuse it on other templates too.) This way you give your user a comfortable UI and also minimize wrong values, typos, etc. For example, you can setup a slider for medium quality with a range only from 50-70, a slider for high quality with a range from 60 - 90, etc. ---- checking if you need drop / recreate variations can be done by hooking into after page save: check if it is a page with your gallery template, check if the field with options has changed, if true, A) removeVariations() of the images field, or B) recreate specified images by onetime passing an additional option "forceNew" => true to the API call.

what do you get if you echo out or var_dump() $p->viewable() // and / or $p->url // and / or $p->id right after $p->save() ?

ImageSizerEngine NETPBM CLI Version 0.1.0 beta (requires PW 3.0.10+) Get it from the modules directory or from github. https://github.com/horst-n/ImageSizerEngineNetpbmCLI For information what it is and how to use and install, please read this Blogpost. Currently supported by Version 0.1.0: only JPEG, - no PNG, - no GIF GIF and PNG will fallback and handled by GD currently. This will be changed when I have a bit more time.

ImageSizerEngine ImageMagick CLI Version 0.1.1 beta (requires PW 3.0.10+) Get it from the modules directory or from github. For information what it is and how to use and install, please read this Blogpost.

// maybe ? $projects = $pages->get("/projecten/")->children("sort=sort"); $prev2 = 0 < $page->prev($projects)->prev()->id ? $page->prev($projects)->prev() : $page->first($projects); $prev1 = 0 < $page->prev($projects)->id ? $page->prev($projects) : $page->first($projects); $next1 = 0 < $page->next($projects)->id ? $page->next($projects) : $page->last($projects); $next2 = 0 < $page->next($projects)->next()->id ? $page->next($projects)->next() : $page->last($projects); // or, if the above do not work as expected, maybe: $prev2 = 0 < $page->prev($projects)->prev($projects)->id ? $page->prev($projects)->prev($projects) : $page->first($projects); $prev1 = 0 < $page->prev($projects)->id ? $page->prev($projects) : $page->first($projects); $next1 = 0 < $page->next($projects)->id ? $page->next($projects) : $page->last($projects); $next2 = 0 < $page->next($projects)->next($projects)->id ? $page->next($projects)->next($projects) : $page->last($projects); But what do you want to show for prev2 and prev1, if the current page is the first? // simply use ? $selector = "limit=2"; $prevAll = $page->prevAll($selector); $nextAll = $page->nextAll($selector); // and then foreach($prevAll as $prev) { ... } foreach($nextAll as $next) { ... } This only will render items if there are any. Means, if the current page is the first one, you will not get previous-links. (what makes sense, as there are no ones).

@Jugibur: that's all right what you are saying. - But, ... the -strip param is only available in the CLI version of ImageMagick, not with the PHP extension. But the PHP extension can handle embedded image markers as well, if, and only if: needed dependencies are compiled in. For ICC conversion, the lcms lib needs to be compiled in, what seems not by default or not with all extensions. Other cons are: with the PHP extension of Imagick, you cannot determine if it is supported / compiled in or not! And if it is supported, it will expand the processing time up to 3-4 times, compared to the processing time without ICC conversion. Therefore, and to have a homogenuous behave across all engines, we strip all image markers by default, but excluding IPTC. (stripped ones are: ICC, EXIF, XMP, JPEG-Comments, and others) Here are two more modules for the new ImageSizerEngine System: ImageMagick CLI Netpbm CLI

The famous jquery DataTables have a Dynamic search / filter inputfield embedded what do a great job. Not exactly what you are looking for, but maybe worth a look into the code. Maybe they use an embedded sub library for that?

OMG. How many users will upload images to this site? Multiple / different users, or only you? I personally use max size = 2500px for the largest dimension of an (original) image. I create those with Photoshop in max quality before uploading.

I suggest to read https://www.littlebizzy.com/blog/ttfb-meaningless, and especially look for TTLB (Time To Last Byte). IMO, TTFB is completly meaningless,the only thingthat matters is: how fast can a user read / see the content of a page. And if you read on Wikipedia TTFB_vs_Load_Time or the more in depth article why it is meaningless, you may see that this doesn't matter. One thing, what is described there for example, is, that if you use gzip compression for your html / js / css content, you get a higher TTFB, but the TTLB is 20-30% lower! But besides that, using ProCache is the fastest way to serve your content. It also includes a part that assist you to setup the server for gzip, caching etc, it can collect and minify your JS, CSS, and HTML files, and you completly ommit invoking the PHP engine and connecting to a DB.

(https://en.wikipedia.org/wiki/Time_To_First_Byte) ProCache does serve static HTML files! PS: TTFB is meaningless

Exactly as @Craig said: for example, if you want import two templates that have a parent / children family relation, it cannot be imported in one go, as for both the other referenced family template isn't known in the system. But it works fine, if you first let out the family settings. Click / select YES for "Create this template?" for both templates and commit the form. In the next screen, you simply click on ok and in the next step you paste in the data again and click peview. Now you will see both templates with the opened settings. One shows the new property "parentTemplates" and the other a new property "childTemplates". Lastly click commit changes and you are done.