#80

Thanks for all the well written replies to give some insight on what’s happening and why.

Something I didn’t see addressed directly is the addition of a link to view the original image
As mentioned most image urls can currently add :orig to see the original

If the reason for this change is to reduce page/image load times for users on low bandwidth internet, wouldn’t it make sense to serve (all) users those smaller (thumbnail) images in their feed, while still allowing users to click ‘View original image’ ?

It seems this could be easily achieved with all the image sizes you already have.
As you said most places already use thumbnails since using the full res images in small containers makes the UI slow)

Having a link to view to original image seems trivial to implement and should not affect loading times for anyone that chooses not to click on it.
People on 2g networks would be aware, or could be warned, that clicking ‘original quality’ would mean longer load times while still allowing everyone in the world to access them

You previously agreed it might be good to link to imgur for the original image, why not help artists and keep users on Twitter.com by doing this for them with the data you already have?

Additionally, this would allow for users to opt in to the original quality in their whole feed if they would install a userscript like the following GitHub - eight04/twitter-original-image: An userscript to add ":orig" to twitter images. (even better if this was an advanced setting built in to Twitter)

I understand the need to standardize and improve page load times for all users, but having an option to at least manually click ‘View original image’ would give people the choice of how they want to use their bandwidth for Twitter when they can.

#81

Thanks for the comment, @MvEerd. It was well thought out and I appreciate wanting to solve for all users.

First, I should point out that the orig variant of images is an internal only variant. Twitter makes no guarantees related to it and it is not intended for any outside consumption. Don’t read orig as meaning “original” but as meaning “origin”, aka from the source in our data center. I would dissuade users from ever accessing that variant.

Your suggestion to have a way to persist access to the originally uploaded version of the image is fair and not unheard of. But your assertion that it would be “trivial to implement” is unfortunately not the case. Our system, built around scalability, is not really like a file system where we can store arbitrary files and be selective of which version we serve out. It would be a very complex effort and would likely require an entirely new service to be spun up for this special case of hosting original images.

Do also remember that extra variants (and increased file sizes) is not purely a matter of transferring the data, it also has an impact on our CDN hit rates. More large files that get cached on CDNs mean even more smaller files being purged from our CDNs, hurting hit rates. For every user with fast internet getting the heavy file size image they want in the highest fidelity, there are many more users that will be faced with slower content loading because the content they are trying to see is not in proximity to them anymore since it was purged from the CDN to make room for the heavy files. It’s a non-trivial balancing act, but we’ll keep working to improve things.

As we continue to improve the balance between quality and performance, these ideas will be kept in mind.

#82

How much information can you give about how to tell whether a PNG file will be recompressed based on a hypothetical JPEG version’s filesize?

I’m making a tool that allows users to optimize their art before uploading to twitter, by losslessly compressing it in optiPNG to see if it’ll come in small enough, and then offering to lossily compress it to 256-color in case that looks less bad than the eventual JPEG compression will.

But how are users supposed to know what approach to take? What good does an “if it’s smaller than the JPEG” clause do, if users don’t KNOW whether it’s going to be smaller than a JPEG whose settings we don’t know? The only way to learn what approach to take is to have already posted the image and seen what filesize it gave once it was online in front of everyone.

I know you said you don’t want to say in case the settings wind up changing, but I can tell you now, on February 11th I’m going to upload a test file, then look at the result in exiftool, and base my script on whatever it gives, and so will anyone else trying to deal with this vague rule that we’re depending on, so you may as well tell us what the initial settings are going to be, rather than making us scramble on the day the change goes live to find out the same information the hard way.

#83

Just to be clear: I’m aware of the “85% quality” figure, but I’ve gotten very different filesizes out of the same “quality” setting in different programs, according to things like 4:4:4 vs 4:2:0, etc


Can you give us a few example files to compare against, to at least identify a way to locally compare results before the day that the switch is thrown?

#84

Really great questions, @RavenWorks. I really appreciate that you are trying to work within the boundaries to make new tools to benefit all users.

First, I think the easiest thing to do is, if the image has 256 colors or less, just automatically convert to PNG8. I would like to work with the team to make that more automated on our side. For now that is just an idea and so external tooling doing it would make sense until I can make the case internally.

Using something like optiPNG or oxiPNG is a great idea, I like that a lot. It cannot scale internally, but moving that onto the user’s computer makes it much more likely to be viable.

For comparing between JPEG to see if it meets the threshold, I will share the specifics of our internal codec – however, that is entirely subject to change (as you’ve noted) and I cannot guarantee it will persist. The threshold could itself end up changing too (hopefully to be more permissive). In any-case, the closest match you can get is the following:

  • libjpeg-turbo codec
  • progressive encoding
  • 85% JFIF quality
  • 4:2:0 chroma subsampling

I hope this helps with tooling you might want to develop, but it doesn’t really come with guarantees. It should be pretty good though.

1 Like
#85

Thank you so much! :slight_smile: That’s definitely a helpful starting point. Do you think there would be public announcements somewhere if it were expected to change in the future?

#86

That’s a fair question, @RavenWorks, but I’m afraid not. The public communication has been intentional to preserve areas that are subject to us making changes for the benefit of the platform, and it would be untenable to try to couple that to public announcements/documentation. I hope there could be a way, perhaps with the media upload Twitter API, to detect when changes do happen for developers that are concerned enough, but I can’t make any promises for communications.

If you ever are wondering if something changed though, you are free to contact myself (@NolanOBrien) or @andypiper and we can see about finding out. I’m sorry if that’s not a great dependency to have, but I want to be transparent to set expectations.

1 Like
#87

That’s alright, thanks anyway! Maybe I’ll just make a script that uploads a test image and compares the resulting file once a month or something


1 Like
#88

@NolanOBrien thanks for getting back to me.

I believe this link should be accessible to you: Pasteboard - Uploaded Image

I downloaded and it was the same size in Finder as the original image, 2.9 MB.

I also tried attaching this image to a tweet via the Twitter desktop UI and publishing. It failed. Assume this still happens with the API, too.

#89

@cstesto, thanks for sharing. I can reproduce the issue which means our engineers should be able to debug it. I’ll file a bug report right away. Thanks!

1 Like
#90

Is there a particular time of day planned for the changeover?

#91

Good question. The rollout will take a while and will likely roll out in phases throughout the week. Today (Feb 11th) will mark the first phase and a subset of users and image categories getting moved over. We hope to complete the transition by the end of the week, but it might take longer. I’ll comment on the announcement once it has completed.

#92

hey there! it’s me from earlier in the thread, i just wanna say i’m happy with the compromises made.

particularly, i am very interested in avatars being left alone. that has been a big point of contention for me since avatars started being compressed years ago. but i have a concern - will this change apply to tweetdeck, as it did before?
currently, my icon looks a LOT worse on tweetdeck than it does on web twitter, i’m not sure how tweetdeck handles icons, since it uses different sizes, but here’s a visual comparison anyway;

avatar
avatar984×740 142 KB

i believe that my web twitter is still compressing avatars, but tweetdeck just looks horrendous in comparison. do you know if the changes will affect tweetdeck or not? i wrote this at 12:18pm PST roughly. thanks!

EDIT: just to clarify, tweetdeck changed to compressing avatars when web twitter did. im not sure how linked the two are, but yeah!

#93

The avatars on all platforms should properly reflect the change. If you have any issues once the transition is completed, please feel free to let me (@NolanOBrien) or @andypiper know.

1 Like
#94

Nolan, are you sure you don’t run a PNG optimizer? I just twitted a small (47040 bytes) animated PNG8 and it turned into a smaller (1377 bytes) static PNG8 file. Sad.

#95

I could be mistaken on this (apologies if so!) But I do not believe animated PNG has ever been a supported format, so I’m not surprised that this converted to something static. I’ll need a co-worker to confirm that the expected behaviour, but it is certainly what I would expect to see.

#96

Andy is correct. Animated PNGs are not supported. By happenstance the format for animated PNG can be decoded as a single frame and Twitter will support that, transcoding it into a new static image file which will be smaller in size than the animation.

1 Like
#97

hi there - just wanted to come back and say that the change has been applied to avatars for me. they’re now in perfect quality, and it’s awesome. thank you guys!

1 Like
#98

Hmm. I don’t think you need to do anything to support it, just don’t remove the frames. All modern browsers support APNG, so I suspect it will “just work” for most users.

#99

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.