horst

@Stefan: unfortunately I don't know the AIOM well. It was just a thought. I would think one mostly need the $config->urls->something if one have to provide a link to the clients browser and need the $config->paths->something mostly to tell a php-script / function where to grap the file(s) in filesystem for preprocessing something.

EDIT: Ah, you have it in the first line: // _init.php $jsPath = $config->urls->templates . 'styles/js/'; try it with changed this to: // _init.php $jsPath = $config->paths->templates . 'styles/js/'; ------------- I don't know if it needs the fullpath or only a url, but you are definietly provide the url and not the fullpath: $fullPath = $jsPath . $file; // = /proseeswire/site/assets/... I would do a quick try with: $_SERVER['DOCUMENT_ROOT'] . $jsPath . $file; If this succeeds, I would change the "$_SERVER['DOCUMENT_ROOT'] . $jsPath" to some PW $config-var (e.g. $config->paths ...)

Uploaded version 0.1.7 to github - added handling for gamma correction when gamma reading seems to be not available. With some versions of Imagick the function getImageGamma() returns 0 for all images. Don't know why, but have changed the code to asume a Gamma of 2.2 in those cases.

Uploaded a new Siteprofile, including the latest ProcessWire 2.4.2 from todays dev branch. The profile include tests for ImageSizer and ImagickResizer for the following categories: cms crop formats gamma scale sharpen others The module for extending the images naming scheme (PageimageNamingScheme) is included too.

No, I'm currently not using Images Manager with this. I'm working with the pure basics (ImagesSizer, ImagickResizer, Pageimage, PageimageNamingScheme) and try to test against all issues that was reported in the past I can remember. And if it isn't allready fixed, provide a fix or report it to Ryan.

@robinc: I have added the code with get and set gamma to the module. But it doesn't work every time. I have had it in the code before and than have removed it again, because it seems not to work consistent over different IM-versions and I have read that going into 16bit depth mode will do that internally. But now with coming to test it, I must see it doesn't do it as promised. So, on my local machine (ImageMagick 6.8.8-4 Q16) applying gamma correction works as expected, but on a live account (ImageMagick 6.6.9-7 Q16) it do not! I have played around with the point where to call it, but nothing changes. We need to do more testing, - if it gets a value from the image or not and that like. --- In a post above you have said that you are interested in interpolation methods for upscaling, so if I personally would try to avoid this, it sounds interesting for others. If you like, we can put a check into the code just before it comes to resizing. When it detects that it should and is allowed to upscale, we can use other methods for it. Can you provide some lines to this. PS: If I find the time I will update the site profile this evening. --- EDIT: I have found out that on my online account (ImageMagick 6.6.9-7 Q16) the function getImageGamma() returns 0 for all images. Don't know why, but have changed the code to asume a Gamma of 2.2 in those cases. We have to observe these further.

@soma: it is right that this should be called only once, regardless if it need to correct one or both dimensions. I have send a pull request for it. But I think this has nothing to do with the issues I have encountered that the ImagickResizer is called two times, because I have not had set any max-dimensions and also fileAdded isn't invoked when calling size, width, height on pageimages. It is invoked by file adding / uploading, as you have to deal with with your fantastic Images Manager. (yep, have read about the break with the newest dev branch)

@robinc: which version of ImagickResizer do you use? Above in a code comment from you I have seen v 0.0.5 which is a very early version. regarding to gamma correction with GD in imagesizer: Out there in the wild you can find images with gamma 2.2 and gamma 1.8, (mostly), therefor I have set it to 2.0, because there is no way to detect it with GD. Normally with IMagick using the 16bit colordepth should linearize the gamma setting internally. Manually doing this shouldn't be needed. But I will test this. I have updated my testset and already found some interesting behave. And the gamma test will be the next --- @adrian: I have updated it to version 0.1.5 - And yes, you has set it to singular at the beginning of the project. This was right, but stupid me has changed it.

@robinc: Great! Thank you. That was it. Now it is called only once. I have updated it on Github. And now it is open for regular testing. Actual version is 0.1.4

Actually the ImagickResizer seems to work well with: resizing cropping sharpening but there is an issue I have encountered on two different machines: It is called / processed two times for every image call. I have uploaded the module together with some debugging code to github. Following are a result without skipping the second process. The images get not cropped well: With skipping the second call, all works as expected: But why is it called two times? We hook into imagesizer::resize before, we set $event->replace to true and set $event->return to the right value (false | true). So why is it like it is?

While testing with ImageSizer and ImagickResizer I have encountered that there are some glitches in the dimension calculations. A simple testcase I have used is to downsize an image to the half of a dimension and -1, -2, -3, +1, +2, +3 pixels. This results in 5 failures: After wrapping a ceil() here and here, there were only 2 failures and 5 succeeds: Therefor I have changed this floor to round, and this one too. This results in 7 succeeds: I send a pull request and refer to this post here, (because I do not know how to embedd images in a github pull-request or comment. --- PS: only changing the floors to rounds and not wrapping the ceils results in 5 succeeds and 2 failures

Good work. Very nice site. Also they have good and many images. Works well together: layout, design, images. One minor thing: personally I would automatically select and display the first item when coming to http://www.tierarzt-partale.de/leistungen/ or I would add some useful content to that parent page. Without you have a big header "Unsere Leistungen im Überblick" and after that a blank area.

Uhm, now after not sleeping for a week and buying all coffee from Belgium and the Netherlands too, I have managed it: I choose "Keep going" => But seriously, - yesterday I have played the whole evening (5 hours) and have reached the 1024 every time. (I have played until my eyes became square). This morning after a good breakfast and a little walk in the sunshine (rethinking my strategy for 2048) I have tried ttwo times and it succeeded. Now I am redeemed!

Hi Alan, I would go with a bootstraped script that checks session settings (URL like: http://example.com/yourpdf.php). You need to keep security entry and the infos which pdf / page regards to this session. If it can create pdf on the fly you only need to secure your session settings (limited to a browser / fingerprint or somethnig that like for a limited timeperiod)

That with the coffee could be totoff?

Yes, sure: I have had sleep for 7 hours last night, have done some photographs and some digital retouching. I only have played ca. 2 hours / day = 6 hours (I swear!)

I have reached my personal goal!

We are looking with which Imagick / ImageMagick versions the icc conversion is available. We haven't found any valid answers in the net and also doesn't got one at a imagick forum. So far we have noticed that the lcms lib needs to be compiled into ImageMagick, but there is no way to check if it is or not via the Imagick-php-extension. (you can read more here in that thread) If you look at Adrians results, they are both the same, with and without icc conversion. Both doesn't work correct with grayscales and cmyk because tere isn't the lcms extension available. At least we do not need support for cmyk, but for grayscales. --- EDIT: The Siteprofile is updated! Have changed the require_once - path issue and embedded the Pageimage Naming Scheme and the latest Dev-branch into it. (see in the first post)

@Pete: I have worked with a A3 intuous for long time. Than I have changed to a power mouse with some additional buttons and the big tablet tooks to much space on the table. Now I use the power mouse and a little Bamboo tablet. I use two desktops, one for the main app and one for the palettes (photoshop). The Bamboo is active for the first desktop, this way it has a reasonable size for masking and retouching. They also have a shop for "Gebrauchtes": http://de.shop.wacom.eu/Produkte/Sonstige/Gebrauchtgeraete

sorry! Have found it yesterday and managed 512, or a highscore of around 6800. But I swear, if I get a 1024, I stop playing.

a real disease: https://github.com/gabrielecirulli/2048 http://gabrielecirulli.github.io/2048/

It is updated to version 0.0.3 and now has a cleaning routine that can be called manually in the config screen. Would be nice if a few user can test it in none production sites.

Martijn, no problem! Every one of us has max. 24 hours per day. And all of us need some time to sleep, some time for the family, some time for other things and some time for ProcessWire. I think - in this order.

Yes, Adrian is right, it isn't ready yet. Actually there are a few things that need to discussed / solved / changed with the ImageSizer and image handling generally. After that is done, I will implement the same solution into ImagickResizer. Currently it does not recognize settings for upscaling / cropping / etc. But it would be good if you can test it and send a feedback. Or if you can explain how to set up Imagick locally on Mac (if you are on a Mac) in that thread Adrian has linked to. Additional to that we are working on the naming scheme. If I remember right you has asked about that too: https://processwire.com/talk/topic/6205-module-pageimage-naming-scheme/

Pageimage Naming Scheme I have created a module that extends the naming scheme for images. It reflects more options within the filename. An example is here: http://images.pw.nogajski.de/new-naming-convention/ The module is on github (zip)- additionally you need PW version 2.4.2 or newer (while writing this, the latest dev version from today) The module is in alpha state, so yet do not use in production sites. To install and start using it works very smooth: It doesn't force to recreate your already cached images, only uses the extended naming scheme when need to create new image variations. Also recognizes both naming schemes when collecting imageVariations. Recognizes PageImageManipulator-files too per update to 0.1.3. If you want to uninstall it, you can run a cleaning script from the configuration screen that removes imagevariations to avoid orphaned files when switching back to the core naming scheme. Running the cleaning script as simulation is supported too. --- There are a new thing to mention: You can send a new option together with your images $options array: "forcenew" => true! This results in recreating these single variation of the image, without dropping all other variations. Now that you can have a lot more variations per image, this should be the preffered way to drop / recreate cached image versions. Questions, suggestions are welcome.