Do we still want server-side image resize by default?

[mflorea]

Hi everyone,

We got this feedback regarding server-side image resizing:

Just makes me wonder - the very strong comprerssion and low quality (both settings) are probably defaults from many years ago when bandwiths and data plans were quite low, processing power and RAM on Servers and devices were low too.

Wouldn’t it maybe be good to change these values to new higher quality defaults as todays bandwiths, data allowance and processing power of devices and servers are much better now?

I know we had a few complains over the years regarding this, and I assume many XWiki instances are disabling the server-side image resize using:

rendering.imageDimensionsIncludedInImageURL = false

But I’m not sure if we can detect how many. Do we still think this is useful for most of our users (so that it remains enabled by default)?

I have mixed feelings. I wish we had actual data of how much this features is being used.

WDYT?

Thanks,
Marius

[tmortagne]

I honestly never been a fan of this feature which cause quite a few problems (default quality just being one of them). But everytime I mention the idea to disable it by default, I’m told it’s obviously needed.

But if we disable it by default, some stuff will need to be fixed for sure as we often notice a few UI issues every time we disable that (mainly code assuming that the source image always have the right size and don’t set it explicitly in the <img>).

[mleduc]

Loading the images at the right dimensions is important for several reasons:

• More work client-side to resize the images (CPU intensive)
• Higher bandwidth use than necessary, leading to slower page rendering
• Marginally higher client-side memory use

Overall this can hurt the user experience, so it would feel like a regression.

I would instead prefer to look for a solution allowing to keep this parameter on, while returning image of better quality.

So I’m currently -1.

PS: Having the capability to return image of good quality at different dimensions is also an essential feature of my srcset proposal.

[vmassol]

@mleduc

More work client-side to resize the images (CPU intensive)

OTOH doing it server-side means using the server CPU and if you have lots of queries asking for that, you’re impacting the server’s performance globally. And thus:

@mleduc

Higher bandwidth use than necessary, leading to slower page rendering

Could actually be the opposite, i.e. that the page would render faster if the computation was one client side (Since doing more CPU work server side makes it slower and that slowness may not compensate the additional time taken to transfer the full image).

I’m playing the devil’s advocate here since, without data, it’s hard to know what is the truth.

@mleduc

Marginally higher memory use

This is client side memory I think.

@mleduc

I would instead prefer to look for a solution allowing to keep this parameter on, while returning image of better quality.

Definitely. However, the problem is now (and has been for a lot of time). So I’m more -1 to continue to not address it and if to address it it means setting rendering.imageDimensionsIncludedInImageURL = false by default while waiting for a better solution, then I’m definitely +1 (users can always turn that on again if need be, for ex it could be a config option indicated in the Performance tuning guide in case you run into perf issues).

Said differently, I think quality trumps performance for a default XWiki instance.

[tmortagne]

@mleduc

Marginally higher memory use

On server side it would require a lot less memory, but maybe you had in mind client side memory.

[mleduc]

@vmassol

I’m playing the devil’s advocate here since, without data, it’s hard to know what is the truth.

+1, I’m always up for more resource monitoring!

@tmortagne

On server side it would require a lot less memory, but maybe you had in mind client side memory.

I indeed meant client-side, I’ve updated my initial post to clarify that.

[mflorea]

@mleduc

More work client-side to resize the images (CPU intensive)

I expect mainstream browsers to be optimized for this, since they have to do it often. Copilot tells me it starts to become an issue, especially on mobile devices, with images above 8 megapixels (4k resolution). Do you think it’s common for XWiki users to upload large image files (8MP/4k)?

@mleduc

Higher bandwidth use than necessary, leading to slower page rendering

When not cached.

@vmassol

Said differently, I think quality trumps performance for a default XWiki instance.

My worry in this case is that the quality loss is noticed by everyone while the performance boost is not needed by everyone (most won’t notice it).

Thanks,
Marius

[vmassol]

@mflorea

My worry in this case is that the quality loss is noticed by everyone while the performance boost is not needed by everyone (most won’t notice it).

Aren’t we saying the same thing? I’m proposing that we use by default the setting that provides the highest quality and that if performance becolmes a problem, we leave it to wiki admins to change the setting (and document it under our Performance doc page).

[mflorea]

@vmassol

Aren’t we saying the same thing? I’m proposing that we use by default the setting that provides the highest quality and that if performance becolmes a problem, we leave it to wiki admins to change the setting (and document it under our Performance doc page).

I tried to emphasize what you wrote, but maybe I haven’t phrased it well. In any case, I agree with you.

[MichaelHamann]

@mflorea

I expect mainstream browsers to be optimized for this, since they have to do it often. Copilot tells me it starts to become an issue, especially on mobile devices, with images above 8 megapixels (4k resolution). Do you think it’s common for XWiki users to upload large image files (8MP/4k)?

Yes. Standard mobile phone cameras have 12MP I think. Non-technical users have no idea how or when to resize an image, they will just upload an image they got from a camera, and then you have a 5MB download for a thumbnail-sized image. So, no, we shouldn’t disable server-side resizing by default, -1 for that. We should ensure that we use appropriate quality settings, and we could decide to only serve certain image sizes and thus partially rely on client-side resizing. We could also decide to generate these fixed image sizes (I’m thinking about something like 64x64px, 128x128px, 256x256px, 512x512px, 10124x1024px, 2028x2048px, but we should probably check what other software does) when the image is uploaded, storing them permanently instead of generating them on the fly at least for the most recent version of an attachment. Or, alternatively, still generate them on the fly but store them permanently - I think this is what Nextcloud does by default.

[vmassol]

We should ensure that we use appropriate quality settings,

@MichaelHamann What value do you recommend?

The idea here is to start doing something about it. Users have been complaining for years about this issue. What you suggest seems to take time and not on any roadmap. Would be good to have something for 18.5.0 final and stopping pushing the issue forever.

Thanks

[MichaelHamann]

@vmassol

@MichaelHamann What value do you recommend?

I asked an AI to perform a quick search for me and apparently, 75-85 are good quality/size tradeoffs, Nextcloud uses 80 and according to this article, WordPress uses 82. I guess we could go with 82?

[mflorea]

@MichaelHamann

Or, alternatively, still generate them on the fly but store them permanently

I’m more in favor of resizing on demand. We are already caching the result AFAIK.

@MichaelHamann

I’m thinking about something like 64x64px, 128x128px, 256x256px, 512x512px, 10124x1024px, 2028x2048px, but we should probably check what other software does

This is inline with what I usually do: resize server-side to a dimension slightly bigger than what I need client-side, then let the browser resize to the final dimension. This would also help with caching: we would cache (and serve) only some predefined dimensions. When we receive a resize request we check what is the first predefined dimension bigger than what the client asks for, and use / cache that value.

Thanks,
Marius

[lucaa]

Hello all,

@tmortagne mentioned:

But if we disable it by default, some stuff will need to be fixed for sure as we often notice a few UI issues every time we disable that (mainly code assuming that the source image always have the right size and don’t set it explicitly in the ).

I would love to have some examples here, since my understanding about the imageDimensionsIncludedInImageURL parameter is that it only controls whether the width and height parameters passed to the xwiki image syntax are appended to the image URL in order to fetch a resized image from the server. What this does not do is

• disable the possibility to resize an image on the server (if the width and height parameters are explicitly passed in the download URL of the attachment)
• disable any sort of “default” resizing.

So I don’t understand what is the thing that a code could rely on and disabling this parameter would endup in it being disabled…
Do you have any example here?

@MichaelHamann mentioned that

Non-technical users have no idea how or when to resize an image, they will just upload an image they got from a camera, and then you have a 5MB download for a thumbnail-sized image.

Indeed, but I’ve also seen XWiki instances crashing with out of memory because they had to generate a ton of thumbnails for images, for the display on the same page (because the requests from the browser do come at the same time, for resized images, because the browser is loading each image async).

Also, let’s not underestimate the fact that once that thumbnail is downloaded, any usage of it on the browser will use it from the browser cache (thumbnail size or full size), whereas, if you do the resize on the server, any new size will result in a new processing and a new transfer to the browser.
I’m not saying that not resizing images on the server is the obvious thing to do, I’m saying that it’s not such a dumb and unacceptable idea, there are some benefits to it.

I don’t have a strong opinion about this issue, even if I did hear the complain about the quality quite a lot. I ended up on this thread because I was trying to understand whether it can cause any issues in pages to disable that or not. From what @tmortagne is saying, yes, from what everyone else is saying, no. From what I understand that this feature should do, no, so I am curious if we have a bug or not.

Thanks,
Anca

[tmortagne]

@lucaa

So I don’t understand what is the thing that a code could rely on and disabling this parameter would endup in it being disabled…
Do you have any example here?

You are right, I mixed with the old trick that was disabling all resize on server side and which was often used in such a case. But indeed the documentation of imageDimensionsIncludedInImageURL suggests it’s only about copying image block width/height to the URL, so it should be fine (I actually did not know about that one and read too quickly).