horst

Hhhm, not enough time to go much further these days, but interesting stuff this ImageMagick. Imagick can be setup as CMS (Color Management System). I have created a little colorTargetfile and a Testcase with files of different colorspaces, colordepth, with and without embedded ICC-profiles, including Adobe-RGB, ECI-RGB, sRGB, different CMYK and different Grayscale. The RGBs and CMYKs it seems I have covered already, grayscales are on the todo.

try { paste https://www.youtube.com/watch?v=Wf68FTYoGKQ#t=134 . "\n"; } catch (Exception $e) { echo 'Exception: ', $e->getMessage(), "\n"; // doesn't work with this URL } http://www.youtube.com/watch?v=Wf68FTYoGKQ#t=134

$input->urlSegment[n] property (not array!) replacing [n] with 1, 2 or 3 (not replacing n with 1, 2 or 3) $input->urlSegment1, $input->urlSegment2 or $input->urlSegment3

Glad to hear it gives better results for you now. But want to clarify that resizing with PiM is 100% identical with resizing from the build in ImageSizer. You have used another sharpening method with PiM. You used USM-sharpening which produces better results but is very slow as PHP-implementation for GD. But supports identical values for all three params as photoshop does.

I found this good explanations for git in english and german, a complete book: Pro GIT from Scott Chacon. Also (at least on windows) with sourcetree app there is a button that opens a console (cygwin) that lets type in git commands as alternative for using the gui. Have installed it two days ago and not sure if it is useful or not. Would think that there are not much commands needed for a use with CLI.

@WillyC: does that mean one can, for example, create a new field, add it to the basic_page template and only need to update the tables fields and templates and add the new table field_myNewField to the live server?

Hi Etling, actually there is no prefered way to do this. Here is a module that may help: https://processwire.com/talk/topic/4420-page-list-migrator/ I haven't used it until now but have bookmarked it for the future. Adrian states it still alpha, but has done a lot of work to it allready. So more than worth a look.

Don't use it for the original source image. Simply save as PNG (not with the SaveForWeb-Plugin). Would assume you get 800-1600k filesize then. Upload it to site assets and do a test for the best quality / filesize: // you first need to install the PageImageManipulator $width = 680; $qualities = array(10,20,30,40,50,60,70,75,80,85,90,95,100); $options = array('sharpening'=>'none', 'cropping'=>false, 'upscaling'=>false, 'quality'=>100); // options for the image sizeing: max quality without sharpening $amount = 100; // unsharpMask default values $radius = 0.5; // " $threshold = 3; // " $image = $page->images->first(); $image->removeVariations(); foreach($qualities as $quality) { ini_set('max_execution_time', 15); $img = $image->pimLoad("{$width}_q{$quality}", true)->setOptions($options)->width($width, 'none')->unsharpMask($amount, $radius, $threshold)->setQuality($quality)->pimSave(); echo "<p>Quality: {$quality} :: Filesize: " . filesize($img->filename) . "<br /><img src='{$img->url}' width='{$img->width}' height='{$img->height}' alt='{$img->name}' title='' /></p>\n"; } If you have found the best quality value for your images you may try different values with USM-sharpening. (it is the same like with photoshop)

that makes no sense. The original must be greater than the resized version. And even with jpeg format, the original source should be 100% quality (and therefor greater than resized versions) and only the outputted / resized versions should be degradated to lesser quality (70 - 90). If you use a lossy compressed source, you multiple times add artefacts to the outputs. And PNG can be compressed too. -------- Workflow 1 could be: local source format TIFF, 16bit colordepth (ECI-RGB_v2 or Adobe-RGB) (regardless of with or without lossless compression) convert to sRGB colorspace, optionally scale down to max 1600px, reduce colordepth to 8bit and save it as JPEG with quality 12 (photoshop) or 100% (other software) upload this JPEG as original source try resizing and sharpening with unsharpMask($amount, $radius, $threshold) from PageImageManipulator Workflow 2 could be: local source format TIFF, 16bit colordepth (ECI-RGB_v2 or Adobe-RGB) (regardless of with or without lossless compression) convert to sRGB colorspace, optionally scale down to max 1600px, reduce colordepth to 8bit and save it as PNG without compression upload this PNG as original source try resizing and sharpening with unsharpMask($amount, $radius, $threshold) from PageImageManipulator and test different quality settings for the output (results in smaller filesizes) And once the imagick-module is ready change to it but above workflows may be worth a try.

@robert: I want to clarify here for following readers: This is definitely wrong! The artefacts has nothing to do with gamma correction. If you personally want to comment this out, please do so. But please do not give this advice to others, because you yourself have said: If you don't know what it is good for and on the other hand only guessing on something is not enough to give advice to other people that may also do not know for what it is good for. Gamma correction do exactly the opposite of what you say: it does not destroy colors - it saves the original colors. @all: Please read on in the other thread here: https://processwire.com/talk/topic/5889-image-quality-problem-on-resize/#entry57548 or just here: https://processwire.com/talk/topic/5889-image-quality-problem-on-resize/#entry57559

@renobird: Tom, to comment it out is nonsense. It just do the opposite: it save the original colors when resizing, whereas not using it it wash out (some) colors (makes them darker). A very helpful article with tests, examples and explanations is here: http://www.4p8.com/eric.brasseur/gamma.html This article also provides solutions for IMagick and Adobe Photoshop that have the same gamma error in resizing 8bit images! The advantage from Imagick and photoshop over GD-lib is their support for 16bit colordepth. Transfering images into 16bit colordepth do exactly a gamma linearization at first and after that a numbered colortransfer! One way to improve it is to use gamma correction!

Currently I'm not knowing IM, but I'm in!

@adrian: this is a very good starting point! An IM alternative may be good for all that can use it on their hosts. But for all users that cannot, we have to improve the usage of GD.

Hi @humanafterall. additionally to that what I have replied to @robert, it has nothing to do with linearization (gamma correction). The artefacts comes from sharpening the images. Attached is a test with sharpening set to 'none', the default 'soft' and the third image is a rezied version where I have added some noise to yout original image with photoshop. This is common usage: if you have technical gradients with pixel formats use the filter "add noise". How much and if monochrome or colored you may test, but that's the only way I know to avoid these artefacts. You can set / send options in your template like this: $img = $page->images->first(); $img->removeVariations(); $options = array( 'cropping' => true, 'sharpening' => 'none', ); $img = $img->size(768, 436, $options); EDIT: added more clearly that I have added noise to the original image and resized it in PW with GD-lib.

@robert: if you are interested in what it does, you may read the link that is posted in the thread you linked to: http://www.4p8.com/eric.brasseur/gamma.html#introduction In fact with first linearizing to 1 and after resizing linearizing back result in correct images. They are brigther in comparision to the ones resized with gamma errors. These ones results in to darkened images. If you want try it on your own images, you may incorporate a grayscale and / or other colortargets and check the results by the histograms or with the colorchecker in photoshop. But the explanation with examples from Eric Brasseur are really good and detailed I think. Could it be that the posterization is allready in the original images? At a very low scale, but allready there? And yes if you then darken the images together with resizing you end up not seeing it that strong. Sounds possible, right? But I'm not sure. If you have a look to the original image from chrizz in the other thread, you see that it has allready some artefacts, so visually tolerable, but they are allready there. Maybe there are better solutions available then disabling gamma correction. I really would have a closer look to that and test with other sharpening methods. Would you be so kind and send me one of your original images where you get better results without gamma correction? Also usefull a resized one with and one without linearizing and the information what sharpening mode you have used. (I can pm you my emailadress if you want) It is not good that exactly people who do a lot work on their images run in this problems whereas the overall common cases gets better results with it.

Ok, please check with wich charset your template file is stored! (It needs to be UTF-8, what is _not_ the default on Win!) And also you have two charset headers in your code example. The second one overrides the first! EDIT: please, if you want to show code examples, please can you post it as text, using the "<>" - code formatter button? You can simply test if your template file is UTF-8 encoded: try your example with $p->title = utf8_encode("smorebrod"); If this works, than your file isn't utf-8 encoded.

The only thing I can think of is the admin theme. This has changed, but you can still work with the old way, (needs to uninstall the default theme first, under modules)

In Short because on mobile: try to convert your csv file to UTF-8 and Set all other to UTF-8 too

@Ryan: what do you think of adding a method to the WireMail class that tells the user if the currently active Module can send attachments? if(wireMail()->canSendAttachments()) { wireMail()->attachment($file)->to($to)->send(); }

There was a thread about this here: http://processwire.com/talk/topic/5417-using-git-with-a-cms-for-version-control-and-deployment-on-multiple-machines/#entry53501

thanks diogo, you are right. If using it with only one UrlSegment it should work the basic way, but with several UrlSegments it could let into trouble.

Yes, looks like a perfect way!

Ok, I have read in the cheatSheet: So, this is all the same! And therefor I will use $page->fields in future. (It's more close for me. Ok, for Ryan it is more close to use $template->fieldgroup because in his thinking it is obvious that that is the part what gets invoked at the end)

@soma: I have found this here in a script from Ryan and therefor thought it is save to use.

uuh, 20:14 time for crime scene and soup. See you later!