horst

You only need to pass the filename first through a str_replace("\\", "/", $filename), then it is equal for all operatingsystems world wide, including windows. This is save for URLs and also is save for pathes that are handled within PHP. Only case that failes is, if you use it for calls in CLI on windows. (But we do not have any in PW core) I use this one in _functions.php NOTE: I was a bit confused by trying to find your changes from commit in my core file via the line numbers, until I noticed that you have commited your PR to the PW master branch instead of the dev branch. (That you used locally as I can see in your code screens above).

ImageMagick does use this too, but do produce correct results when it is setup to work in 16 bit colordepth mode. And thats the main difference: IMagick can do this and GD only supports 8 bit colordepth mode. When working in 8 bit colordepth mode like the GD, the workaround with gammacorrection applies good results for the middark to white parts, but the very dark parts get masacred. A very good explanation with examples can be found here: http://www.ericbrasseur.org/gamma.html ( One of my personal favorite quotes on Eric Brasseur site is down in Solutions/Conclusions, regarding Adobe Photoshop: ) It is a possible workaround to get overall better results with resizing/downsizing then it would be without it. But not for very dark parts! Let Ryan answer this: https://github.com/processwire/processwire-issues/issues/465#issuecomment-363045136 ?

@Robin S I have created a first shot for this. Maybe you have time to take at look at it and play around a bit. I'm very interested in your opinion and how we should finish this. image-histo-test.zip

Yep, but this is only with the GD lib. Unfortunatly the gamma correction brings some advantages for most the images, but is worse for images with very dark parts. Maybe I should check out if we can detect such candidates on upload and flag them for automatic disabling gamma correction (whit GD). But currently I have no clue if this can be done with reasonable accuracy.

Regarding compression and quality | webpQuality | lossy | lossless and how different the two rendering engines work, I want to show a little example, comparing two image motives with equal dimensions. I have created two master source images in the dimensions 3000 x 2000 px. The first one is a 24bit color jpeg, filled with noise in Photoshop. The second one is a checkerboard with 100x100 squares, only black and white, but also saved as 24bit color jpeg. I don't want to scare or confuse anybody. Look at the following tables with the file sizes for the different qualities, rendering engines and output formats. (Just let it sink, ...) Really interesting are the results of the IM files in 100% quality, compared to their jpegs and compared between both motives. ? EDIT: And here two more real world motives, but also with interesting IM 100 quality results:

I think it is independent from the source. The compression is set for the output format, that is webp, regardless what was the source format. It can be JPEG, PNG, GIF, TIFF, BMP or any other image file format that can be opened by the proceeding rendering engine. (For IMagick most often one out of 230+) In this context, we can use lossless for sources from JPEGs too. But because in my tests it seems to be exact or nearly the same like quality 100, I had not seen a valid reason to bloat our imageSizerOptions with another setting, what then would need to be checked for its existence and compared against webpQuality. Also: HINT: if one passes wrong values for webpQuality, out of range (1-100), the webp rendering method automatically falls back to lossless. So if you use 100 or anything above 100 for webpQuality, you get lossless. ?

@JFn I cannot confirm this. I tested with different newer PW versions up to 3.0.131. Everything is working as expected and like with older PW versions. Only thing from your examples that did not work, is to use the ->setOutputFormat(). How to handle this, please read my post directly above yours.

No, as written two posts above, we have different purpose images. There could be, for example, uncompressed master images that serves as source and should not be displayed on screen! Following I show some more image file purposes, but want to start with a brief introduction to image processing procedures. Within a web environments very limited support, our master source images have to be uncompressed JPGs with 8 bit color depth per channel. Far from optimal. In other environments TIFF or PSD in 16 or 32 bit color depth is used for that purpose. The destructive compression method of JPGs is responsible for most of the user errors that occur during the processing steps. Once you saved a JPG compressed within a workflow, as source or intermediate, you damaged it unrecoverable! And one also cannot detect this programmatic within a common web environment! This is one reason why we keep the master source, the original image untouched, "as is" in PW! (besides other aspects) So, for our use cases, the JPG format can have different purposes: uncompressed master source images, uncompressed intermediate variations, final optimized and compressed variations for screen output. Also, if one has a use case for it, one can optimize and finalize JPGs only for the purpose of printing in PW. Or for embedding them into PDFs, or for serving them as single files or as zipped archives for different purposes per downloads. So, it's not: "all get displayed on screen". Some never should be displayed on screen. (I maintain sites for photographers who keeps 60k+ images as original (pw master source) images in the site. They only publicly show watermarked images within limited dimensions. The original images are protected against web access. And they are used for all the different above listed output purposes.) Luckily with the WebP format it behaves different. Due to its intended purpose, (that is, highly compressed and optimized for screen output), it is unusable for all other purposes! Sure, if you want to or don't care about anything, you can use everything wrong, but it is not that subtle like with JPGs. In German we have a saying: "gefährliches Halbwissen" ("dangerous half-knowledge"). No idea whether one can translate the sense connected with it by DeepL? But it means something like: If you already know a good part, you quickly run the risk of drawing (wrong) conclusions about the unknown parts. Personally, I am always happy when I get explanations, help or advice from people who have more specialist knowledge. After all, I can't know everything myself, right? ? One of my most important life experiences & wisdoms to fight against my "gefährliches Halbwissen": "If there are many people who study and learn for years to get a vocational qualification before they can "really" get into the subject, then I know that a huge part of it is invisible to me, even if I think I already understand a lot of it.".

Because it is not a "normal" image format by its intended purpose! As far as I understood, you upload already compressed images that you don't want to proceed further? Note: 1) Already (not lossless) compressed images should not be used for any transformation, because the images are lacking lots of information due to the compression. (like the webp format!) 2) If you do not want to use the resize functionality, you have to provide the final webp by yourself too. PW only provides webp support for PW created variations for final output. This is due to the file formats nature or its intended purpose. Maybe you don't want or need a webp variation for admin thumbs. Maybe other users don't care. Maybe some users really like it when opening a editor page with 300 images displayed as admin thumbs. I cannot answer this other then: It may depend on a lot of different things? I really would like to discuss the general webp support first, and the less common use cases like this later on, in a following fine tuning phase. ----------- AFAIK the most common case is to use the pageimage system with uploaded uncompressed images that serves as master images. Those master images are never get served to the outside "as is". They every time get transformed into a variation file that is optimized and finalized for a specific purpose! At least this is the only correct way for an error-free workflow with maximum possible quality combined with smallest possible file size! Whether people understand this or not, my almost 30 years of expertise in the photographic industry has never shown me anything else. And all my work within the PW images system is (and only can be) based on this. ----------- I know that there also is a minor usage of the pageimage fields for simply displaying the original files to the frontend, but my best bet is that this is much lower then 10%. In my opinion this is not the intended use case for pageimages. The use of a file field would suffice, if it also could display an admin thumbnail in the backend. But because this functionality is missing in a file field, pageimage fields are used as "compromise solution" for this purpose.

I never have jpg and png files of the same variation name. So there will be only one type available. If you really create png and jpeg of the same variation, you have to work with suffixes. Webp is a (final) OUTPUTFORMAT only! You cannot use it as a pageimage. If you want to upload and use webp directly, you can use a file field. This one, maybe in site/config.php, is really usefull for conditional markup, as it can reduce it drastically. ?

@matjazp If sending webp first is not possible to you, you may use the initial htaccess solution, what already worked for you, but with the redirect in the rewrite rule (R=301): AddType image/webp .webp <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 ### Redirect regular PW JPEGs and PNGs to their WEBP image copies, ### if available and if the Browser supports WEBP: ## Does Browser accept WEBP images? RewriteCond %{HTTP_ACCEPT} image/webp ## Is it an existing file? RewriteCond %{REQUEST_FILENAME} -f ## Does a WEBP copy exist for it? RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.webp -f ## With an added GET var or GET value of skiprewrite we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch '*skiprewrite*'" ## With an added GET var or GET value from the PW Page Editor, we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch 'nc=*'" ## Is it a regular PW JPEG or PNG image, stored under site/assets/files? RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.(jpe?g|png)(.*)$ /$1$2$3/$4.webp [R=301,L] </IfModule>

The regular pw htaccess file is full of [OR] conditions. So I would expect that this must be possible. My example currently checks for jpg only. It must be completed to also check for png. And it serves the file that it (first) detects. You can read it in the htaccess comments.

This is old schooled from before PW 2.4, but it works fine for me. I use it until today, not only for modules that need backwards compatibility: /** * Default settings used by this module * * @return array */ static public function getDefaultData() { return array( 'myKey' => 'myValue', 'anotherKey' => 'anotherValue' ); } /** * Populate final merged data from default and DB * (use init or ready method for this, depending on your needs or preferences) */ public function ready() { $data = $this->wire('modules')->getConfig($this->className); // fetch the config data from DB for this module $data = array_merge(self::getDefaultData(), $data); // merge with default data foreach($data as $key => $value) $this->$key = $value; // populate final data to class properties } /** * the config screen: */ static public function getModuleConfigInputfields(array $data) { $data = array_merge(self::getDefaultData(), $data); // merge stored data from DB with default data // ... }

? Heya, success! This seems to be a reliable and resource-saving method to bring webp support to (existing) PW sites: .htaccess only 2.0 ? (subtitle: learning more about htaccess directives) When only calling webpUrl | webpSrc for all image sources, without any conditional markup, the whole site / page tries to get all images as webp files. $options = ["webpAdd" => true]; $img = $page->images->first()->size(120, 120, $options); echo "<img src='{$img->webpUrl}' alt='{$img->description}' />"; The new htaccess directives will check if the browser supports webp. If not, it redirects the webp requests to the jpeg or png variations. Also if the browser supports webp, but a webp file is not available (for what ever reason), the htaccess redirects to an existing jpeg or png file. So, it redirects, it does not only rewrite the URL. Look at this screenshot, the redirected request has the correct file extension: The new .htaccess directives: To support png too, we need to copy the block and change .jpg to .png, or there is a way to implement both types into one block. We will see. ?

As i know it and do it: having an array with the default values in the module that gets merged with the db stored data on ready, for example. No need to store it into db on install. Also think about an update of a module that has a new option implemented. With array_merge everything is up to date with the new module files. EDIT: also I‘m not sure if the system is ready to store configdata during install, or if this is only possible after the installation (registration) process.

My favourite atm is to serve webp format in webp files and use the htaccess solution to detect missing browser support and then, as fallback, serve jpeg format in webp files. This false file types automatically will go away by time, as browser support becomes complete.

Yes, its the default. Weird!

Hmm, but it should. What priority settings do you have set?

@AndZyk I have sent a new commit to github to cover this. Please can you download the 3 new files: core/Pageimage.php core/ImageSizerEngineGD.php modules/Image/ImageSizerEngineIMagick.module If you want to test / debug the webp functionality of both engines in one call, please use code like this in a template file: $options = [ 'forceEngine' => 'ImageSizerEngineGD', 'suffix' => 'gd', 'forceNew' => true, 'webpAdd' => true, 'webpQuality' => 90, ]; $img = $page->images->first->size(150, 150, $options); echo $img->getDebugInfo(); $options = [ 'forceEngine' => 'ImageSizerEngineIMagick', 'suffix' => 'im', 'forceNew' => true, 'webpAdd' => true, 'webpQuality' => 90, ]; $img = $page->images->first->size(150, 150, $options); echo $img->getDebugInfo(); A) it now should run without errors when you request a webp copy and the engine doesn't support it, and B) you can see it in the debug info if the selected engine supports webp.

Hi Andreas, my first idea is that your local IMagick installation lacks webp support. Can you check this in phpinfo().

http://www.colororacle.org/

Added Support for Servers|Connections without Authentication, currently in a dev-branch: https://github.com/horst-n/WireMailSmtp/tree/allow_without_authentication Please, if someone uses SMTP without authentication, can you try it out with enabling the new option in modules config screen and check the "Test Connection" feature with it?

This looks very interesting: https://cloudblogs.microsoft.com/opensource/2019/03/12/microsoft-open-sources-accessibility-insights/ You can find 2 tools: 1 chrome extension for Web, and 1 Windows App for WinProgs: https://accessibilityinsights.io/ And the GitHub Repo: https://github.com/Microsoft/accessibility-insights-web

@Noboru I now have changed it to work with all regular use cases in PW. But this includes to have a regular file and optionally a webp file. But this is/was the behave before the core webp addition too. Please try if it now works for you, or report back. If not, we can define a custom hook or a custom function to suite your setup.

It only loads the defined .htaccess.local files. The regular .htaccess files are completly ignored. Yes, you may need to copy all locally required parts from regular to local AccessFiles. But I locally work with the pw distri htaccess file. I don‘t want to have settings included for caching or for ProCache. Also rewrites for different domain names to one final domain etc. only stays in the online file. Nothing of that is needed or explicitly must be avoided locally. Maintaining the .htaccess for online deploy exclusivly and add .htaccess.local to the .gitignore. ?