How do we compress a jpg without changing dimensions

If you want to use PHPRUNNER, I would change the dimensions but have the webpage show a higher dimension.

https://www.jclabs.co.uk/generate-webp-images-in-php-using-and-gd-or-imagick/

PHP script to convert PNG, JPG and GIF to much smaller WEBP format.
Definitely over-time for PHPRunner to make use it as the PNG size for example
is said to shrink by 26% by conversion into WEBP format.

Thanks, that code looks fairly easy to understand.

I use tinypng which has reduced my png files by 64% ie 43 kb -> 16 kb.

I'd like to keep the original png or jpg format - is that possible using that script?

It would be great to have this type of facility built-in to the image upload options tab of phprunner.

HI,

The Best Way to Compress JPG Files with ImageMagick

I have an example of Imagick's use in a Phprunner project. https://fhumanes.com/blog/guias-desarrollo/guia-63-convertir-pdf-a-png/

With this Imagick library you can perform wonders with the images.

Greetings,
fernando

Thank you Fernando, that looks very useful.

I'll see if I can work out how to code it to compress images

Regards
Pete

My post was a SERVER-SIDE oriented one where many users are e.g. uploading photos.
And if wanting to do it right, a Base64 conversion should as well happen on the server-side.
Sure, this has nothing to with PHPRunner at all. It's just a nice tool to easily inject e.g. code
snippets like that, but it is up to you to judge whether it is of time saving character to you
and your users. Base64 image conversion would strongly reduce the server request. The
reason is that for each picture contained, a fresh request by the server is necessary.

Example: You have e.g. 20 pictures in your page. So, the server would need to run 20 requests
to load the page for display. Now, if the 20 pictures are converted into Base64 links, the server
would be able to swallow same like the HTML or PHP code in the page, = only 1 server request
for all the stuff. Given, you a FREE web page over there in the web under shared hosting (250+
users per server) and your server limit is 20 request per second, it could happen during peak
times that your shared hosting is getting bottlenecked, resulting in a delayed display of your
content or worst, your web visitor is getting nothing to view at all.

Accordingly, the content of this thread is likely more a worldwide community related one rather
than to serve one user to somehow optimize his own page(s).

I only came across that recently after having been purchasing a web design tool where BOTH
features as seen within the graph are built-in and can be called on request.

That's interesting, thanks.

I have used base64 for making standalone html files with images. It does increase size by around 30%.

@Pumuckl

As I tried to explain, we have to differ between COMPRESSED image files BEFORE upload into the web
and server-side traffic issue (limited requests per user) here, so, even if the Base64 implementation would
increase to upload file size (as you said), fact remains that the more non-Base64 images you have in your
page, the longer it takes to re-display of what is on the server to the web visitor.

By yesterday, I looked around on how PHP 8.3 is performing towards the elder versions. It was mentioned
in that web page AFAIR that PHP 8.3 is able to handle 192 requests per second. So, basing on SHARED
web hosting (250+ users and their pages on one server), calculate yourself, by the given example of let us
say 20 pictures per web page (do not forget logos, bullets or icons) = roughly 10% of the aforesaid requests
performance is swallowed by the non-Base64 images, all on per second basis. Now, to reach out to 100% of
request performance, again on per second basis, some 10 user pages with each 20 pictures inside can be
handled by the shared server. What happens for that very second on the rest of 240 users pages shared
hosted? Well, after the first 10 user pages had been served, the very next 10 user pages are then going be
to displayed, and so on and so on, on full number of shared hosting users, this would happen again 23 times.
Now, of course, not all pages of all shared hosted users are experiencing 100% web visitor demand to get
displayed, so a linear calculation is not providing true results at all, yet, what can be said is that for sure
there is a DELAYED web page display happening (maybe be 5 to 10 seconds which no one, not knowing
the background, does not really brain or bothering about at all). But on the long run, users may get tired to
know, a specific page content in their favour kills some 10 seconds or more of their surfing time and this
could led to some annoyance or worst, to forget about that page content at all.

Quint-Essence: Whether or not to compress/base64 something on the UPLOAD side, does not really once
the overall target by the content publisher is to serve as many as possible web visitor on his displayed
content and at least by then, the point on "How long does it take until the page is fully displayed" starts
to somehow matter, commercially speaking.

P.S. When you look how AI upload files are handled, you are about to discover that BEFORE your file is
reaching out to the processing servers, it is compressed/algorythmed that way, only fraction of the original
size is touching on the processing server, for reasons to somehow minimize costly web traffic when it comes
to a larger scale (here, the WORLDWIDE USER community).

Sure, if the ordinary web page publisher is more than happy to own 30 visits PER DAY or so, all the above,
all discussions about the details are getting use- and meaningless. It matters so much for what reasons any
pubiished content is of a kind of worthiness and in case, it is, the more web visitors could be expected.