Not a bug Resource Icon upload file format limited to "jpg"?

[Freelancer]

The default resource icon can be a ".png" while the custom uploaded icons are automatically converted to JPG with the name then being "*.jpg.png" which seems odd to me. Is this bug?

It would be great to have PNGs with their alpha channel appreciated especially since the resource icon is being displayed on different backgrounds (Resource View, Resource List View, Featured Resources, for example) and I am using PNG Glyph Icons throughout the forum.

 

[Mike]

The file format specified in the original upload will be maintained, though they are saved as .jpg. The browser will interpret the file format as necessary.

 

[Freelancer]

I guess I will suggest it as a new feature then?

 

[Mike]

Saving with the specified file extension? I believe there is a suggestion for avatars, though unlikely to be one for resource icons. They behave the same way though. The only real difference you'd see is if you save the image back; it's not going to expose any different functionality to what happens to right now.

(To confirm, my previous message, when I said they were saved as ".jpg", I meant the file name, not the actual data. The actual data is in whatever format the original upload used.)

 

[Freelancer]

Okay, not that there is a misunderstanding: The PNG file saved was actually interpreted as JPG and has no transparency (alpha) background anymore. I should have mentioned that.

What I would wish for is that PNGs are displayed as they are with full transparency.

 

[Chris D]

They are. I just tested it with a transparent image as a resource icon, and it retains the transparency. Bear in mind the background colour of its container is white (on the default style) though.

 

[Deebs]

Saving with the specified file extension? I believe there is a suggestion for avatars, though unlikely to be one for resource icons. They behave the same way though. The only real difference you'd see is if you save the image back; it's not going to expose any different functionality to what happens to right now.

(To confirm, my previous message, when I said they were saved as ".jpg", I meant the file name, not the actual data. The actual data is in whatever format the original upload used.)

The problem with this approach is that you cannot deploy X-Content-Type-Options nosniff header as it stops image types from being loaded as they will violate the header enforcement.

 

[Chris D]

Okay, not that there is a misunderstanding: The PNG file saved was actually interpreted as JPG and has no transparency (alpha) background anymore. I should have mentioned that.

What I would wish for is that PNGs are displayed as they are with full transparency.

They are. I just tested it with a transparent image as a resource icon, and it retains the transparency. Bear in mind the background colour of its container is white (on the default style) though.

See the resource icon here:
https://xenforo.com/community/resources/xen-notices.870/

If I hack the background colour of its container with the element inspector:


Or even download the "jpg" file you can see it maintains its transparency. This is a screenshot from the default Windows 10 image viewer:

 

[Freelancer]

They are. I just tested it with a transparent image as a resource icon, and it retains the transparency. Bear in mind the background colour of its container is white (on the default style) though.

After 20 years of digital picture editing, I swear I know the difference...

And it is a PNG24 uploaded and then it shows as a solid icon with white background. The file name is ".jpg.png"

See the background I have is khaki and the icon is with white background, while the DEFAULT linked resource icon (my custom version) is showing correctly...

Here the default resource icon that loads from its path in the "styles" folder:


Here my PNG i want to upload (Mac Users will recognize the "proof" for transparency)


And finally the RESULT:



And as if this is not enough... take this:



I guess there is something not working on my setup or server... maybe?

 

[Chris D]

I can't comment on your personal experience, of course. Not implying you can't tell the difference.

I'm just asserting that it's working fine here for me and locally, and demonstrating that.

I guess there is something not working on my setup or server... maybe?

Yep, guess so.

 

[Mike]

I can't see it to confirm your case, but--like avatars--resource icons are served with a background color set in CSS. You'd have to remove that to get what you want. Given that I can see a border-radius on the background in your demo, it looks like the background color is from that, though without seeing the CSS it's difficult to say.

But if that's not it, it would imply it's an issue with the image manipulation package on your server.

 

[Freelancer]

I think we can skip looking at CSS or wrong file generation. I doubled checked that and it is not the cause. Also a proof that the image is changed on the upload process is that when I download it again from the browser it definitely has a white background.

The only picture processing relevant setup changes I have in mind is imagick PECL extension installed. I actually use the "Watermark" feature of XFMG.

EDIT: The below is "OPTIONS ---> ATTACHMENTS"

 

[Freelancer]

Well.... I turned it OFF and back to PHP built-in GD image library and guess what happened with the next try.... BAM...

Can I get a confirmed kill?

 

[Freelancer]

To be more helpful I checked PHP Info to give you more insight:

PHP Version 5.6.2
imagick module version 3.2.0RC1

PNG definitely is supported according to the setup.

 

[Chris D]

Still not a bug as far as I can tell; I just deleted the icon, enabled Imagick here and uploaded again:


I have turned it back off, but you can see the uploaded image has maintained it's transparency.

I have tried it locally with Imagick enabled and it also works fine.

In the first instance I would recommend having your host change the Imagick version. You're not necessarily using a version that's too old, or anything, but it's not uncommon for us to see issues like this where certain builds of Imagick don't work with certain builds of PHP. There could also be some PHP dependencies missing, but I'm not entirely sure.

If changing the Imagick version doesn't work, changing the PHP (minor) version might.

 

[Freelancer]

Okay, check.

What exactly does the imagick PECL with attachments bring as advantage over the PHP script processing? Performance? I just realized that the attachments option is separated from the XFMG option, so I could just turn it back off until the versions are updated? I will contact my hoster about the imagick Version.

 

[Chris D]

Imagick usually handles images in a more optimised way; quicker processing, less memory usage, perhaps slightly better compression too though I've never looked at that in detail. Another benefit of Imagick is how it can handle resizing animated images. When you run a GIF through GD, it grabs the first frame and resizes that only. Imagick grabs all frames, resizes each one, and puts the frames back together (this generally allows animated avatars, and similar).

It might be worth bumping the PHP version, too. e.g. if you're running an older build of PHP 5.6 it might be worth moving to the newest PHP 5.6 (5.6.18).

 

[Freelancer]

Thanx for the help to both so far, I will check if new versions are available!