Skip to main content ↑ ↓
Topic: Feature request: Image Proxy (Read 23727 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Feature request: Image Proxy

Reply #60 –

@radu81 Thanks! I didn't realize there were more settings related to the add-on outside of "Image Cache Settings".

Re: Feature request: Image Proxy

Reply #61 –

The problem is really with ElkArte. 

The image cache calls the function resizeImageFile() function which in turn will call function resizeImage() but it does so with the $force_resize flag set to true (no way to override that either, at least from that path).

The Imagick logic prevents $force_resize from scaling an image up, however the GD functions will let it scale up. So that is what we are seeing here.

So the question becomes what is wrong ... In some respects the Imagick is not honoring the force_resize flag, so that really is a bug even though in this case its producing what we want.  GD is doing whats its told, although its horrible.  function resizeImageFile() should really allow us to pass the force flag value.

Anyway something needs to be changed, just not sure which one !

Re: Feature request: Image Proxy

Reply #62 –

So my feeling was right. :P
resizeImageFile is used in the attachments (including thumbnails) and avatar resizing.
I think the original intent was to have the max_width/heigh as "stretch the images in order to fit the size" in both cases (at least that's what I get from the history).

The cleanest way would be to have another function that does what we need, but if we are sure we don't mind having avatars or thumbnails smaller than the set size, then I guess is it fine to just have resizeImageFile to scale down only if the size is bigger.
Bugs creator.
Features destroyer.
Template killer.

Re: Feature request: Image Proxy

Reply #63 –

Fifteen, maybe even ten years ago some browsers used rather ugly (faster) resizing algorithms so that it would've probably made sense to do it on the server. At least in ImageMagick… less sure about GD. But seeing how you're basically just making the image larger and uglier I'd say only resize it down. And heck, even resizing down should perhaps be more of a size in bytes kind of thing than size in pixels.

An interesting trick to potentially obtain higher quality JPEG images at lower filesizes is to make them a higher resolution with lower quality compression.

To quote myself from elsewhere a few years ago:
QuoteA screenshot of your comment is 16kB in PNG. Subsequently running pngquant gives a 6.2kB result with no discernible loss in quality. A libjpeg optimized JPEG looks alright at 14-18kB, but it has some relatively minor artifacts. You can easily reach about 6kB with JPEG as well, but the artifacts then become really distracting to the point where it looks more like one of those illegible CAPTCHAs.

These results indicate that the system should check how filesize compares between e.g. carefully crafted PNGs and its own low-quality JPEGs, otherwise it shoots itself in the foot. For that matter, it really shouldn't add another layer of noise to a properly optimized JPEG either. In the past I've uploaded a JPEG to Facebook, which consequently made the file bulkier and uglier.

Re: Feature request: Image Proxy

Reply #64 –

Yeah, I think the scale up is more a relic of when the template was composed of only nested tables and have all the images of the same size was the only way (or at least an easy way... or at least a consistent way across browsers LOL) to ensure some consistency of the whole thing.
Bugs creator.
Features destroyer.
Template killer.

Re: Feature request: Image Proxy

Reply #65 –

I can't speak for the IE4/Netscape 4 days, but from IE5 and up I know for sure that setting a width on an image had consistent results as far as the layout goes. Except for the fact that it was freaking ugly in both IE and Firefox.[1]
1 Naturally even pre-Presto Opera (6.0) is still on par with the current batch of browsers. :P Pity it doesn't support CSS Grid.↵

Re: Feature request: Image Proxy

Reply #66 –

Since the flag already existed in resizeImage, I added the capability to pass a "force" flag to the resizeImageFile function and then in turn to the resizeImage function.  While I was at it made imagick respect the flag as well, so now GD and Imagick act the same to fix that inconsistency.

All these graphics functions need a facelift in 2.0, scale up could certainly be improved.

Anyway that fixes the reported image cache issue, at least on my local.  In testing I also noticed that if you uploaded an avatar, the image cache was creating a proxy for that, so I fixed that on my local as well.

Just to note, the proxy does not "work" with animated gifs,  it will result  in single frame of an animated gif.  That could be fixed using imagick not sure with GD.  You would have to detect animated, resized each frame (if needed),  coalesce and save.  If you are an animated gif fan PR's are welcome ;)

Re: Feature request: Image Proxy

Reply #67 –

@Spuds I'm not but I do have a vested interest in them. :P

Where should I look when I do that? The resizeImageFile function?

Re: Feature request: Image Proxy

Reply #68 –

Just thinking out loud, I'd probably add a new function to the image cache class and drop the dependency on resizeImageFile   Right now some of those graphic functions have an inflexible flow, at least resizeImageFile does.

So I'd add a custom handler to the fetch the image (using the good parts of resizeImageFile, and call it fetchImageFile) in the cache class  Then you can control what resize function to call, a new resizeGifImage or the existing resizeImage.  resizeGifImage could be added to graphic.subs so its available to other addons as well. 

Have not looked to see if GD can handle animated gifs, if not its fine IMO to just have an imagick function.

Just some quick thoughts.

Re: Feature request: Image Proxy

Reply #69 –

Or doNothingToImage(). :P (Do GIFs have security concerns?)

Re: Feature request: Image Proxy

Reply #70 –

Do nothing, if sized right, can be an option. 

Re: Feature request: Image Proxy

Reply #71 –

That's what I mean, yes, which applies to the vast majority of images — GIF, PNG, and JPEG alike, but most notably GIF for obvious reasons. :P

Re: Feature request: Image Proxy

Reply #72 –

Yup we are on the same page.  To be cautious, if the image is below the size limit and we just want to save it, we can run the image through checkImageContents()  It is possible for a gif to hide meta data that could get executed on a poorly configured server, and then if you could find the file. 

Re: Feature request: Image Proxy

Reply #73 –

I have to say that the checks in that function were just about the last thing I was thinking of when asking about security concerns. That must be one very poorly configured server. :P

Re: Feature request: Image Proxy

Reply #74 –

Sadly yes  :-X  ... and those type of checks are found in other net software (Not just ElkArte and its crazy Uncle Buck)