Bug overview description.
Black thumbnail generated for image with transparency (and otherwise only black content).

What part(s) of the site page(s) are affected?
Uploaded images.
https://e621.net/post/index/1/alpha_channel%20line_art though it also affects every other image with an alpha_channel tag.

What is the expected behavior?
Generate a thumbnail in a similar or upward compatible format to the uploaded image, including with alpha layers if the source image had them.

What actual behavior is given instead?
All thumbnails are jpeg format, and thus lack alpha layer. Replacing the transparent background with black seems to be the default.

I'd have coded it to maintain the extension and format and then fall back to a conservative catch all if the first attempt failed.

Time of incident (if applicable).
Here's an example: https://e621.net/post/show/1462378/

Can you reproduce the bug every time?
Yes, it is easy to find examples thanks to: https://e621.net/post/index/1/alpha_channel%20line_art though it also affects every other image with an alpha_channel tag.

What steps did you take to replicate this bug?
Upload an image with transparency to e621.

Errors or other messages returned (if any).
None that I recall.

its not a bug. this is how its intended to function since thumbnails are intentionally jpg and this is just what jpg does with transparency. if you want to suggest some other method for dealing with the thumbnails that would also allow transparency, you would need to make feature request instead.

Commander_Eggplant said:
its not a bug. this is how its intended to function since thumbnails are intentionally jpg and this is just what jpg does with transparency. if you want to suggest some other method for dealing with the thumbnails that would also allow transparency, you would need to make feature request instead.

Exactly. Also technically it would be possible to replace the alpha channel with any color, but I remember Kira mentioning something about the thumbnailing system which at least now would make this hard thing to change, so no checkboard patterns in near future either.

WebP has lossy setting which looks better than JPG with similar compression levels and can support transparency, so if only all browsers would support the format that would be really good thing to use also for samples.

There was no choice to use black afaik, that is just what most software fills entirely transparent pixels with to improve compression, you normally can't see that though. If you remove the transparency, you get whatever was saved in the color section.

Thumbnails are all saved in jpg, and converting them to png would make them larger, often with no real improvement. webp when?

Would one of the following work as a workaround until a 'widely supported lossy format which does support transparency in some form' exists (in say 10-20 years given the historic rate at which some OS's default browsers gained support for PNG at all)...

• Allow for uploaders to provide an alternative thumbnail, possibly moderator approved.
• Generate thumbnail images with a color suitable for viewing in all site themes (that isn't black or white).
• Allow the uploader to pick the background color used for the transparency, and to try again with some kind of rate limit* (probably queue request for idle priority processing, some limit by account or ip per unit of time).

KiraNoot said:
Thumbnails are all saved in jpg, and converting them to png would make them larger, often with no real improvement. webp when?

sxiv takes the approach of : Things that have transparency use PNG thumbnails. Everything else has JPG thumbnails.

Obviously the 'fallback' strategy sxiv uses is not quite as easy to apply on a webserver, but it does seem like a reasonable compromise.

Ketsueki said:

• Allow for uploaders to provide an alternative thumbnail, possibly moderator approved.
• Generate thumbnail images with a color suitable for viewing in all site themes (that isn't black or white).
• Allow the uploader to pick the background color used for the transparency, and to try again with some kind of rate limit* (probably queue request for idle priority processing, some limit by account or ip per unit of time).

1. Moderators already have enough work to do :)
2. That's pretty tricky since the site's themes are basically 'all the colors'... white and black... are the best options, haha. :) and even if we did change it to , say, blue--that color might clash with the picture itself. It's a problem no matter what the background color is, but at least with black, everything's got a fighting chance.
3. This is an interesting idea, but.. you'll have some people who troll by purposefully picking bad colors, people who just don't have ANY idea what a good color is.... or people who decide that they're gonna pick their FAVORITE color all the time, or ALWAYS pick the same color, regardless of what the content is.

Plsu, it's kinda modifying the original work, and a bad background color can really ruin a good piece of art.

SnowWolf said:
Plus, it's kinda modifying the original work, and a bad background color can really ruin a good piece of art.

The solution that savageorange mentioned (image formats with transparency included getting a thumbnail that retains transparency) is the /only/ solution that does not modify the content (other than resizing).

//already// adding in a back background modifies the original work, hence this bug report.

If allowing the end user to pick backgrounds, but worried about colors, an obvious compromise is to force them to pick from a list. Of course if doing that a background could be generated per theme so that the image retains the same or similar background as the theme. Of course it'd be more space efficient for the site to use just transparency.

Taking the example that caused this report, scaling down with GIMP to 150 width, saving as .jpg (adding a *shudder* white background, 75% quality) and .png (then optipng)...

The difference of size is 2639 and someone new replying with a single /comment/ adds a thumbnail of their own that's larger than /either/ example. (because it's more complex than lineart)

this isn't confirming anything don't get your hopes up
Technically speaking, we wouldn't have to switch entirely to png.
We could do a if check if a image has a alpha channel and it is in use(EG: Alpha channel present and doesn't consist purely of 255 value alpha pixels), then use png OR gif OR webp.

Again, not confirming anything, just a half awake thought.

Yeah, that's what I was suggesting. Any solution that effectively modifies the pixel content would be a hack IMO, and probably generate more problems than it solves.