MODX Community

PThumbTransparent WebP Images

Hi there,

I have started dabbling with webP images with a PNG fallback for IOS/safari.
Pthumb does its stuff and creates the WebP version of the image, but when i use a transparent image as the source file, the WebP file created doesn’t support transparency.

Here’s my call in the template:

    <picture>
    <source type="image/png" media="(min-width: 1201px)"  srcset="[[*image:pthumb=`f=webP&w=500`]] 1x,  [[*image:pthumb=`f=webP&w=1000`]] 2x">
    <img class="homeBin" src="[[*image:pthumb=`f=png&w=320&h=600&far=l`]]"  alt="DuraFlex 1100 L Metal Bin - Red" />
    </picture>

If I change webP to PNG, it retains transparency, but when i use WebP the resulting image has a white background.
Any ideas anyone?

Keen to use webP files as the file sizes are so much smaller!

Thanks
Andy

1 Like

I checked the phpThumb docs but they are very out of date it seems as there’s no mention of WebP even though the format IS supported.

http://phpthumb.sourceforge.net/

1 Like

Could you attack this with css?

No. The output image has lost its transparent background. That’s not something CSS can do anything about unfortunately.

It’s basically a product cutout image.

Thanks
Andy

1 Like

Yeah I figured not.

Looking into it, there seems to be no magic to the transparency of the file type.

So the files created have lost their transparency? Just to be clear. Its not in the display but in the file created itself? That might seem obvious, I am not sure.

Pthumb may have trouble with the alpha channels used in the file type? Weird that it can handle other file types

Yes so the original image is a product with a transparent background. It’s a png file.
If I change the image output to f=png then it resizes it and the transparency is fine. But if I change it to f=webP the image itself now has a sold white background. I would expect this if i was converting it to a jpg!!
I even tried with the original being a webP file WITH a transparent background, but after thumb has processed it, the resulting webP reverts to having a white background on the file!

Is this just a limitation of pthump?

1 Like

I wonder if resizer is the package that pthumb is using to make the conversion

You don’t happen to be running an old version of php, are you?

Here’s an old thread that is hardly useful but has one possibly useful comment

Maybe go through the snippet and check whether alpha actually is being preserved or not.

https://forums.modx.com/thread/49458/uploaded-transparent-png-or-gifs-loos-there-transparency

Thanks for this. I will check to see if I’m using resizer or not. That’s a good question. Maybe that handles it better (or worse!)
I know the snippet can handle transparency because it works with pngs, but maybe it cannot handle transparency with webP files.

Thanks - I will experiment further and let you know the results!

1 Like

From my experience reziser doesn’t actually work with webp images. I always get – Can not save file – in the error log when using resizer.

I’ve actually been working on this alot lately and have come to notice that the file size for a WebP image generated with Phpthumb is exactly the same filesize as the JPG image… This got me thinking… what if Phpthumb is just generating a jpg file with a webp extension.

Downloading both images and running identify img.webp I get JPEG 420x280 420x280+0+0 8-bit sRGB 12993B 0.000u 0:00.000 which is identical to running identify on the jpg image. When running identify on an actual WEBP Image I get this error : identify: delegate failed 'dwebp' -pam '%i' -o '%o'' @ error/delegate.c/InvokeDelegate/1845.

EDIT: Just tested with a PNG file converted to WEBP – Same output as JPG file : JPEG 420x352 420x352+0+0 8-bit sRGB 7586B 0.000u 0:00.000

Pretty much confirms my suspicion that it’s not actually a WEBP file at all.

I’m looking into Phpthumbs on github now, if they have upgraded the converter to include webp then we’ll need to look at updating the MODX extras i.e. Phpthumbof and PThumbs

EDIT 2: Further testing using https://libwebpjs.appspot.com/ shows that when you drop a webp file created using PHPThumb you get a wrong signature error. suspicion confirmed

2 Likes

Wow ok. Interesting! I did wonder because like you say the file size is very similar to the jpg, but if I create a webP in photoshop then it’s much smaller.

1 Like

What version imagik and GD are you using? Checking my phpinfo() file I see that both GD and Imagik don’t have support for webp. I’m hoping that when these are updated to the latest version I can use resizer to create webp files. Will update when I’m closer :smiley:

1 Like

OK thanks - I will check which versions I’m on.

1 Like

Hi again - so this is the spec I have - it seems webP is NOT supported on mine either!!

GD Support => enabled
GD Version => bundled (2.1.0 compatible)
Imagick compiled with ImageMagick version => ImageMagick 6.7.8-9 2016-06-16 Q16 http://www.imagemagick.org
Imagick using ImageMagick library version => ImageMagick 6.7.8-9 2019-08-08 Q16 http://www.imagemagick.org
ImageMagick copyright => Copyright © 1999-2012 ImageMagick Studio LLC
ImageMagick release date => 2019-08-08
ImageMagick number of supported formats: => 209
ImageMagick supported formats => 3FR, A, AAI, AI, ART, ARW, AVI, AVS, B, BGR, BGRA, BMP, BMP2, BMP3, BRF, C, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CRW, CUR, CUT, DCM, DCR, DCX, DDS, DFONT, DNG, DOT, DPX, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FITS, FRACTAL, FTS, G, G3, GIF, GIF87, GRADIENT, GRAY, GROUP4, HALD, HDR, HISTOGRAM, HRZ, HTM, HTML, ICB, ICO, ICON, INFO, INLINE, IPL, ISOBRL, J2C, J2K, JNG, JP2, JPC, JPEG, JPG, JPX, K, K25, KDC, LABEL, M, M2V, M4V, MAC, MAP, MAT, MATTE, MEF, MIFF, MNG, MONO, MOV, MP4, MPC, MPEG, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, O, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG24, PNG32, PNG8, PNM, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, R, RADIAL-GRADIENT, RAF, RAS, RGB, RGBA, RGBO, RLA, RLE, SCR, SCT, SFW, SGI, SHTML, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UIL, UYVY, VDA, VICAR, VID, VIFF, VST, WBMP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, Y, YCbCr, YCbCrA, YUV

1 Like

Sorry if this is opening up an older thread, but does anyone think the use of imagewebp() function could accomplish this task and be integrated into pthumb? It’s beyond what I can do myself, but does at first glance seem like an option as far as expanding pthumb’s capabilities. Google speed rankings seem to take this into account now, Lighthouse as well, and it would be very useful. Even if Modernizer JS or use of the element is needed for fallbacks on safari and older ie/edge browsers, it would still be a great feature.

1 Like

Is webp installed on your server?
e.g. sudo apt install webp

1 Like

Yes WebP is installed on the server - it seems like it’s a limitation with pThumb itself.

Might be worth adding an issue to the resizer repo.

For now perhaps disable resizer in pThumb.

Thanks - the system setting useResizer is already set to NO.
I will add the issue to the resizer repo though

Thanks

UPDATE: So - Although useresizer system setting is set to know, the resizer extra was still installed.
I have now uninstalled resizer to see what happens.

It outputs a file with a webP extension, but it was doing that before.The problem is that I can’t be sure the file is actually a webP file type, or whether Modx has just given it the webP extension.

Does anyone know how to test a file to see if it is in fact a webP file?