I’m going to be blunt. Don’t try to fix what isn’t broken. Don’t let the bosses make things more complex than they have to be, or more inconvenient for artists. You may not make the roadmap, but you can be a roadblock if you don’t think the map is right.
Well, time to link to Imgur and make a thumbnail that says “FULL RES ON IMGUR” for every post.
@NolanOBrien thanks for engaging. It might be a good idea to provide an override to the default, so users can opt out of compression out of the box. Otherwise it’s just going to be a lot of discontent and every attempt will be made to override or hack the compression. Which will force twitter to patch until it’s unhackable and artists on twitter to leave. My own pixelart content is safe as png8 but I’m still thinking of leaving in solidarity, if enough artists are upset enough to leave.
Also how about adding proper gifs at last? Pixelart absolutely suffers when converted to your video format (stutter when looping, hideous compression artifacts) and it results in larger files. A size test will confirm it every time. I tweeted a dubious and half-working workaround 5 years ago (506px width) and I still get asked about it as if I’m an expert. This isn’t normal
So, let me get this straight. You guys claim that you are supporting the artists, while at the same time robbing them of the last option to post content with good quality? At least save the unmodified originals and make them be accessible through the interface or something! Same goes for the gifs. Give us normal gifs!
Yes, I don’t understand why so many artists arrived at twitter when it is supposed to be a platform for posting tiny text messages, that doesn’t sound like art-friendly place. But they’re here now. And this “improvement” is ABSOLUTELY screws them over. And for what? So that some dude could open his feed in 2.15 seconds instead of 3.5 seconds?
What about Animated PNGs?
Please don’t convert them into JPGs.
If you must, convert them into video, like you do with Animated GIFs.
But don’t convert them into JPGs.
Don’t forget the absolutely random way Twitter crops images when displaying them in the feed. You never know if it will be the middle of the image displayed, or just the bottom-left corner, or some other part.
Hi, artist here. I just want to throw my hat into the “bad move” pile. This really is a horrible change for artists. I post all of my polished work on Twitter, but I also post unfinished pieces and sketches, and the compression makes these especially ugly. Uploading a higher-res image, in JPEG format, to compensate for this actually results in a file size about three times bigger (in a recent sketch) than the 50%-size PNG format I would usually upload it in, so…
Also, after a quick test just now: when uploading a jpeg and a png of this same image, at the same resolution, with the jpeg at 85% quality and clocking in at about 100kb bigger than the png file size, I’m still seeing compression on both images (not the same amount, as I first thought, but it is distinctly there) once they’ve actually uploaded and posted, so idk what the back-end file-size comparison thing is doing, but something seems wrong here. As I understand it, it should be retaining the png file if the png is smaller than the compressed jpeg?
So let me get this straight, you think having a regular size PNG-24 with great quality is worse than having a 4x upscaled JPEG of the same image? There’s a healthy limit for when limitations like this make sense and this goes right through it. Let artists upload a PNG then see if your 4x upscale method actually reduces the file size compared to the original. I also agree with the others here that having the system decide what’s best for users behind the scenes is about as bad UX as it gets. Let the user know well before posting that their image will lose quality (which is looking like >90% of images uploaded by artists I know). Optimize the images on your end as much as possible before making the users hack around and suffer quality loss. Now that Tumblr shot itself in the foot a great number of artists are flocking to Twitter, are you really sure this is the warmest welcome you could give them? They’ll see this announcement and pack up shop to move to a platform that cares. Maybe try getting that through to the executives.
Are there plans to at least make it possible to access full-sized JPGs/PNGs manually? For example, this online tool allows you to embed secret messages/images into a seemingly random PNG image.
Here’s an example image that outputs Hello World. It’s 4x4 pixels in size, so you may need to zoom in to save it.
This image won’t get compressed by Twitter’s servers, at least I hope, so it should be ok.
And here is another example image that outputs a much larger image with the text “Hello World”:
The second image would be rendered unreadable if converted to JPG, as the data embedded into the picture is literally within the pixels. As you mentioned earlier, many people don’t have the bandwidth to download hi-res images all the time. However, perhaps it would be possible to still host the image at its original size, just not to users on their Twitter’s feeds? (In fact, I do believe it’s something you already do, just not for PNG images. https://pbs.twimg.com/media/DrbHwt7U8AA6X05.jpg:orig)
Edit: in case this needs clarification, here’s what Bandcamp does for album covers…
Publicly facing image (shown to the user on an album page): https://f4.bcbits.com/img/a2631671759_10.jpg
Full-sized image (not shown to the user, but still exists on the server. even if the actual image is not a png, it’s still a good idea to add it so you ensure you get a high quality image): https://f4.bcbits.com/img/a2631671759_0.png
Thanks for the reply @isaiahodhner
You’ve made some good comments and I want to respond to each.
It would be nice if Twitter ran a PNG optimizer on the image
This is something we looked at and quickly realized was not feasible at scale. With millions upon millions of images uploaded daily, running a PNG optimizer on our side would take more capacity than we even store at our data centers. The best way to scale PNG optimizing is to push the optimization to pre-upload time and have it be on demand. Not everyone needs to optimize their images so forcing that cost on every user is problematic and even more of a problem is the technical limitations of Web for doing this work – Web is by far the most common platform for providing PNGs since iOS and Android have always automatically converted to JPEG before upload. The identification that tooling to remove the burden from the person posting to make the PNGs more optimal and more likely to be fast enough to deliver globally is a solid recommendation, we will take that back to product for more consideration.
perhaps using gzipped sizes since files would be going over the network
Though it is correct that most content served over the internet is automatically gzipped to reduce its size for transport, media (images, audio and video) do not apply gzip on top. By their very nature, they are already heavily compressed files and applying gzip on top will most often increase the size of the payload. Gzip and most other compression is geared to compressing on redundancy, and something already compressed has inherently already removed redundancy making the value of gzip on top of that less practical. The core underlying issue you are raising is a good one – getting as much information/quality across the internet with the smallest payload possible. We are restricted to PNG and JPEG at this point in time, but we won’t stop evaluating other options as they increase in availability.
…no one wants a black box…should be able to preview…should be able to control it [after the preview]…
This is a really well reasoned point and has been the most consistent feedback. The surprise of the change in the image between upload and viewing it after upload is a problem today and our changes aren’t addressing it. This is something we will bring up with product that the black box approach is something we could be solving in our clients. Having a preview affords much more control for the one posting to make any adjustments at their disposal.
Thank you again for the reply.
“We care for artists” really stinks like a bad PR spiel when you are actively fucking us over with this.
I can’t believe that anybody thinks that “Upload in high enough resolution that JPG artifacts won’t show up in thumbnail.” is a real advice you should give.
I have NEVER saved anything as low as 85% quality JPG. It just looks so absolutely terrible that there is no redeeming it.
Thank you for you comment @singer_joseph
Blunt is very reasonable. Blunt cuts to the core issue you as an individual care about and that helps.
The announcement starts with “we are going to extend this effort to better support users globally with how we handle uploaded images” and regularly mentions that the reason for these changes are for global reach. The reason for these changes are not arbitrary or to increase friction, but are to address the very big problem (the thing that is broken) which is PNG images do not load for more than half the internet and another quarter of the internet see so much latency/lag waiting for PNG images to load they just move on and ignore those Tweets altogether anyway. PNGs are so large that they don’t just impact themselves loading, they impact the everything else too as they network gets constrained from moving these large files over small bandwidths – slowing down timeline loads, DMs, searches, everything.
In reality, so few people out of the entirety of the internet can actually consume the PNG format that the initial solution was to just eliminate PNG altogether. So, to be clear, there is a broken thing we are fixing, that broken thing is the large majority of the world cannot load PNG, and the solution was to eliminate PNG.
Enter the efforts of many individuals at Twitter that have pushed to, instead of eliminating PNG, find a reasonable (though admittedly imperfect) compromise.
First is providing of the PNG8 format (and other low depth formats) so that images that can be structure in those formats can be lossless. These images are close to the JPEG counterpart size but deliver lossless quality at the cost of reduced colors. We hope artists can find creative uses for 256 color palettes to share on Twitter, including pixel art and illustrations that have crisp strokes and solid colors.
The second move was to permit the rare occasional PNG that is able to compress better than JPEG to not be converted to JPEG. This is the most expensive part of the transition and is purely in service of some images being able to retain quality without being slower to load in full than a JPEG counterpart.
I know wanting to serve current use cases is a high priority for those concerned. The truth is that there are so many millions that need changes in what we deliver for images so they can even partake in the images on Twitter. That is the reason for the change, and why we are making this investment.
The benefit, we hope creators can appreciate, is that this is in service of reach. You may not be able to reach everyone with pixel perfect content embedded in the Tweet itself, but the content that you do share now has the ability to reach so many more users – users that are artists and fans themselves with just the unfortunate consequence of being subject to slow internet that is not their fault.
Thank you, again, for your comment – this clarity in why we are doing this is important and we should have addressed the specifics sooner.
I presume that you are being cutting here, which is fair, but I don’t know if your proposal is that bad. An image embedded in the Tweet that has the performance to reach everyone in the world on their internet connection, with the option to go to a full quality image hosted somewhere that can be linked to. I hope artists do provide fans with those options because it can be a big win to defer the full quality loading to users that know they can load it.
Thanks for replying @castpixel
We understand the discontent of artists wanting pixel perfect support. I wish there was a technology readily viable to support that at scale. I would like to refer to this reply I made that can offer more context to understand the reason for the change: Feedback for "Upcoming Changes to PNG Image Support"
Regarding proper GIF support, GIFs would be a similarly bad performance impact vs the converted MP4 animations we show. GIFs are very large and compress poorly. If you can provide examples of GIFs that you believe need better support for when we do the transcode, I can reach out to our Media Platform team and show them cases where the conversion is a problem.
Thanks for commenting @Darth_Biomech
You clearly care about artists and their needs. That is good and I don’t dismiss your frustration at all.
I’ll refer to this other response I gave earlier: Feedback for "Upcoming Changes to PNG Image Support"
Caring about users sometimes means not being able to be perfect for everyone. We are doing what we can to extend support (see above link), and I understand it is not enough. But there are literally billions of people on the internet saying “what about us?” too. We really are not optimizing a feed loading in 2.15 seconds vs 3.5 seconds. We are working to eliminate the number of images and feeds that do not load at all. Not after 10 seconds nor 30 seconds nor 60 seconds. PNGs are just that large and when you are one of the more than 1 billion people in the world that have 2G internet and no other option, a PNG vs a JPEG is the difference between an unusable and usable Twitter experience.
We’ll continue to work on the image pipeline, to see how much further we can drive quality improvements balanced with performance needs. This isn’t the end.
Going to external site for good quality image is extra step only minority will bother to take. That is why major platforms killing decent quality is such big step on artist communities.
@maxst thank you for this question! This is a new one
Twitter does not support Animated PNGs at this time. If an uploaded Animated PNG works by being converted to JPEG that’s likely just a fluke that the backend transcoder is handling it like a static PNG.
I’ll talk with Media Platform about Animated PNGs, but at this time there are a lot of formats Twitter does not support including Animated PNGs.
Thanks for the comment @dmitriid
All images go through a neural network to generate a smart crop. I understand that it is imperfect, but the difference between our cropping before and after this AI investment have been night and day in improvement.
Here’s the blog post for when we launched the smart cropping: https://blog.twitter.com/engineering/en_us/topics/infrastructure/2018/Smart-Auto-Cropping-of-Images.html
If you have concrete use cases for where the smart cropping is not performing well, you can feel free to contact the engineers on that blog post or reach back out to these forums with a new topic.
Your use case is actually one of the reasons we have pushed to have a way for PNGs to remain as-is when they are performant. We are adding a test to see if the uploaded PNG will perform better than the transcoded JPEG. The test currently is just a file size comparison (smaller file wins), but it could get more sophisticated over time (hence the generic terms in the official Announcement). Your use case of uploading a PNG that is smaller than the JPEG, will always stay as a PNG. No pixel transparency trick required.
In fact (and I should point this out somewhere else for higher visibility), the transparent pixel trick often turns a PNG with RGB colors into a PNG with RGBA colors + alpha. That generally leads to an increase in file size to accommodate the extra channel for every pixel, up to 33% increase. So moving away from the trick will improve the chances that the PNG uploaded will actually be smaller than the JPEG.
Thanks for the comment @DJDavid98
This is a good opportunity to straighten some things out that may seem counterintuitive. If we were comparing a 4x size JPEG to the 1x sized PNG, you’re correct, that would not make sense.
This is going to get into the weeds a little, so I hope that’s ok.
When an image is uploaded to Twitter we will transcode it to a “base” image and store that image. However, we don’t serve that specific image every time the image is shown on screen. There are many difference sized views in different clients with different density screens. Loading a 2048x2048 into a thumbnail that is 120x120 would not only be silly, it would be wasteful and slow and, frankly, unusable. As a natural test case we did actually launch Moments on iOS with thumbnails to each moment (roughly 120x120) and it would load the original image which could reach up to 4096x4096 — it was unusable for not only those on slow internet, but even users with high bandwidth connections slogged with the onslaught of enormous images hitting their devices.
The way Twitter serves images is we provide different variants. This is simply that we have a number of different sizes that can be requested based on the needs of the UI it is going into. So an 120x120 view will load the 120x120 variant. If we have a 640x640 view, the 680x680 variant will be loaded. We don’t have a different variant for every single view size, but we do have enough diversity to cover all use cases while keeping the CDNs at a good cache hit rate (so the image doesn’t usually need to load from all the way in our data centers).
So, the recommendation to upload a 2048x2048 image is really that we are recommending that the image be uploaded so that every variant we support can have an image available. Smaller images will use the largest possible size to fill in the larger variants (a 1080x1080 image uploaded will serve a 1080x1080 image for the largest variant which could support 2048x2048). A low resolution image showing in a UI that can support a very large image (like the gallery view) will naturally be showing artifacts from taking the smaller image and enlarging it to fit.
You have really good points that Twitter could do more in the product to support things like previewing the results of an uploaded image before posting it and potentially providing more education and tooling for making the most of an image upload. I will be talking with product owners to look at what is possible in that aspect.