I think this kerfuffle does point at something that would be nice to have ratified in the HTML spec somewhere: the idea that content exists in different qualities and formats, and that when the user requests to download the content, she's presented with the different options possible. Content negotiation still only has one chosen format come down the pipe; a decision that the user probably hasn't made.
Right now, we're stuck with everybody doing something different in the page design to do something that's pretty important and fairly intrinsic to much of what happens on the web. And so users just default to the thing they know works everywhere, which is Save As... It's not surprising some of them are upset.
The only issue I can see with this is that there are security concerns with being able to override what is actually downloaded when Save As is used.
Why not trans-code the image format to something more common if the user wants to save the image? I would imagine that would be far more useful to the vast majority of users.
I always wish HTTP Accept was widely used to present alternate formats and presented to users in a nicer way. It basically solves all this kerfuffle, it seems oft forgotten outside of XML/JSON/HTML in api's though sadly.
We just landed "image/webp" in Accept header in Chrome, behind a flag.. Opera already advertises WebP support in their Accept header. So, with that in place, it should make things a lot simpler (although it doesn't solve the Save As case).
The primary complaint here is users don't know what to do with a .webp when they download their photos. And support does seem limited; it looks like Photoshop needs a plugin, for instance. But Facebook could solve that specific problem by having a real "Download as JPG" button while still using WebP for inline images.
Why does Facebook have to do anything here? Isn't reducing file sizes and load times the right thing to do for them? Shouldn't the burden fall on image viewers/editors?
If the format beats out PNG & JPG, the industry will follow and image editors will get built in support.
Reducing file size is more important than short term convenience here.
If they're right-clicking the image to download the photo, it's already broken -- Facebook serves a heavily re-compressed JPEG by default. You need to use the menu option to download the original.
I wouldn't hire the graphic designer quoted in the article; they should be able to see the compression artifacts that Facebook leaves in the images they upload, and be aware that they should be using flickr or dropbox or another photo storage service instead.
No, they didn't. The web works fine. They can browse it without any issues. The problems occur when they're trying to do stuff on their local machines.
> Not for users, no. The only gain here is facebook's bandwidth costs, at the expense (and inconvenience) of its users.
> The problems occur when they're trying to do stuff on their local machines.
By all means, try to explain that to users if you like, and if you think they'd care. The issue is that it breaks the user experience, whatever technical reason you'd like to attribute that to.
I'm not explaining anything to the users, I'm just explaining to you how you're wrong when you state that they "broke the web for their users".
The users are completely irrelevant, because no matter how much they bitch and moan, they're not going to leave Facebook. Its network effects are too powerful. And so, for once, I actually support Facebook. They're using their dominant market position to push a new standard that is quite good. This will hopefully force companies like Adobe to start adding support for WebP by default. Then we'll finally able to ditch obsolete standards like JPEG and its ilk once and for all.
This is one of those times where changing something breaks somebody's work flow because they're doing things outside of spec. And in cases like this, you have to say "get over it."
Facebook is still doing what Facebook intends to do, in fact they do it better! It's unfortunate that a tiny margin of users are slightly inconvenienced, but they need to get over it.
> Not for users, no. The only gain here is facebook's bandwidth costs, at the expense (and inconvenience) of its users.
If it saves a significant amount of bandwidth it could be useful to mobile users too, who might find themselves stuck somewhere with nothing but GPRS in a congested cell.
> The only gain here is facebook's bandwidth costs, at the expense (and inconvenience) of its users.
Users love faster websites. If you make your website faster, people will use it more. If you're selling something, they will buy more if your site is fast.
This has been A/B tested by countless companies like Google, Microsoft, Amazon, Netflix, Shopzilla, and so forth. Front-end performance is amazingly important.
Rather than dwelling on the phrase "they broke the web", read it as "they broke an important use case".
Facebook is integral to the everyday lives of many ordinary people, and the lesson here is that the designers at Facebook need to think beyond the specific tech and content that they build and deliver; they need to also consider the context in which their product is used.
If you want web to progress forward, then things are going to get broken. WebP is an efficient format, and face-book is doing a good thing by increasing it's adoption speed.
They broke a use case that does not generate advertising revenue. Of course they don't care.
Actually, I wouldn't be at all surprised to see someone, somewhere tout that as an advantage of WebP: "Joe Shmoe can't rip off your pictures in Photoshop!"
Facebook has to do "anything" here, because they are the ones implementing the format. If they want users to accept the change, they need to slowly phase out jpeg via this Download button.
What is much easier? Waiting for the next version of Photoshop to come (if you need built-in support for WebP, or APNG or whatnot) and splash out $1000 on that
There is a download link under options for pictures in "theater" mode. I haven't run into any WebP images yet, so I'm not sure if it downloads as jpg or not, but I've read it gives you the jpg link.
In the case of the images linked in the CNet article (https://www.facebook.com/photo.php?fbid=457095677701847&...), it gives you a download link for the jpeg. However, the images in that album are displayed as jpeg (for me), and the only way to view the .webp image is to open in a new tab and add the .webp extension in the url myself.
This is slightly orthogonal, but still worth mentioning: there is WebP codec available for Windows, which adds WebP support in explorer and all the other common tools. Download page: https://developers.google.com/speed/webp/download
I agree, that pushing WebP now is too soon as almost no image editors support it. I have added latest WebP codec (that also supports animations) into my RealWorld Paint ( http://www.rw-designer.com/image-editor ) few weeks ago and I doubt anyone else did it since that time. Chrome is really crazy supporting WebP now while it is still immature. Image editors and web server libraries should be the first ones to support WebP, web browsers should be last.
The basic jpeg-like functionality has been widely available for a while. And as in this case, high traffic websites (often Google's own) that are already re-processing millions of photos and/or images and Chrome are the obvious first places to get a foothold, long before anyone would think about actually editing a webp by hand in photoshop.
I feel that this is the reason Facebook is trying such formats. If people have difficulty downloading the photos, they will visit the website more, and share more photos through FB than go through the "download -> edit -> non-facebook sharing medium (email/dropbox)" pipeline.
I really don't think that's the chief reason. A very tiny number of Facebook users save images locally as it is, and by switching to webp Facebook really does save them a tremendous amount of money. Also, since webp is an open format, it's not like users can't use very easy converters/viewers to make webp quite usable.
I don't feel like this move is significantly more than an economic one.
Indeed. If Facebook is trying to lock users in, a non-patent-encumbered format with a free BSD-licensed reference implementation seems like the wrong way to do it.
Is this really happening via the "Download" link, or is this being caused by people right clicking and saying "Save Image As..." because if you want to preserve or work with images, you probably should not be saving images from the context menu, which are often scaled and processed, and instead be asking for the original/raw/high resolution upload.
That's nice in theory, but for years, Facebook photos had no download link, and the only option was to Save As the one you could see. It's very confusing for people when the only way to do something suddenly becomes the wrong way to do it, for no reason they can see.
So we should all stand still in time because current tech is understood by this generation?
You have to draw a line somewhere. The download has in fact been there for years now, at least since late '09. I only remember because we had to download a bunch of images and our only source without giving away a surprise was FB. I was given a bunch of crappy 70% 800x600 .jpgs and I had to show the person getting the images the download like, which at the time wasn't even in the Options menu. Users...
I'm not sure if one user's ungrammatical post to a mailing list means much. These are the people that post angry comments on readwriteweb when they search for "facebook login" and click through to an article instead of Facebook:
Why is this even a news story? Surely if anything we should be praising the use of a new and arguably beneficial image format rather than complaining about some users incompetence to grab a view to open it on their computer.
It really seems such a bizarre thing to be complaining about. Facebook could make it a little easier by having a download as jpeg image option as well.
The world is always moving forward, why don't we just go back to bitmaps!
People care about pictures which are important to them. They don't care about the encoding scheme currently in vogue or reducing Facebook's bandwidth bill by a small percentage at a significant interoperability and thus usability hit. The average computer user has been able to use “Save As” on images for every image they've every seen online with little question that the result will work with their local applications – until now.
The most charitable way I can describe your decision to blame the user is poorly considered. I would like to see new formats catch on but early adopters have to assume responsibility for the growing pains – Facebook making the trivial effort required to make their download link more prominent is about as easy as it gets.
WebP is a pretty "meh" format. The improvements it offers are, at best, very marginal.
Given the large amount of work required for widespread adoption of new image formats, the effort would be better spent on better formats.
[E.g. (and I'm no fan of MS) MS's new image format, JPEG XR†, which seems vastly superior to WebP in almost every way—it actually does have compelling new features.]
Not sure why it's news, but it is definitely an interesting thing to consider for web developers. Serving people WebM in contexts where they might want to save the file will be surprisingly problematic.
JPEG was an enormous improvement, particularly given the far slower connections in use at the time: waiting minutes rather than hours to download an image over my 2400bps modem was huge. In contrast, WebP offers marginal compression improvements, significantly increased hardware requirements and only a few technical improvements (e.g. alpha channels & lossless, although since the latter is so much slower and less effective than PNG I'm not sure there's much of a point).
For many users, this simply isn't enough to justify pushing it through the toolchain.
Less effective = lower compression savings. I was testing with source lossless JP2s in the 6MB range: PNG was 14MB and WebP took at least 10x compression time to hit 20MB (tied with TIFF LZW for least savings).
So it looks like it is effective in web use cases, like lossy photos (especially with alpha), logos, icons etc., but not for non-web cases like large, lossless photos that need to be compressed quickly. Seems like a good engineering tradeoff to me.
First, declaring everything WebP is bad at as "non web" assumes that everyone uses the web only for things they don't care about, which isn't remotely true as the original article shows. People save what they can see - and normal people don't want to switch tools for each situation.
Second, it's still not the case that WebP offers a significant advantage over JPEG-2000 or JPEG-XR, both of which are standardized, better supported, more flexible, and have much better designed file formats.
But JPG was like 10x better than the other image formats available at that time for photographs. WebP hardly delivers 1.2x improvement... This is virtually unnoticeable.
Solution: Someone write chrome plugin that will let people convert from webp to jpeg when downloading from chrome:
https://groups.google.com/a/chromium.org/forum/?fromgroups=#... .
Just add option "Save and convert webp to jpeg" next to "save as" if plugin detects it may be webp.
Or just have the browser add a "Save Image as JPEG" button that does automatic conversion.
I don't know if jpg can reuse the information from webp or if you have to do full uncompression and then recompression but if you care about that you probably wouldn't have this problem in the first place.
They're doing that anyway because they serve non-webp images to users with non-webp-supporting browsers. Anyhow, this is the image that's for display, which is resized/compressed; they store and allow you to download the original no matter what.
I'm skeptical of this solution for other reasons, though (like that it assumes users know what JPG means).
Users who don't know what JPG means are not going to be attempting to edit the images in photoshop. Although perhaps they are saving the files to their local windows machine.
But then the jpg file will be optionally downloaded, thus reducing the bandwith usage (desired effect), and accelerating the page-load (another desired effect).
It is a symptom of lack of interoperability. People do share images. They link them. They save them. They e-mail them. They mix and edit. They re-upload them to other sites.
JPEG has such a broad interoperability that we don't even notice just how incredibly many sites/apps/libraries/OSes/devices support it. Having WebP support only in Chrome is not enough for it to be 1st class citizen.
Just think how many apps and services need to adopt the format before you'll able to upload your avatar in WebP without worrying it won't work.
I was struck by the supposed reluctance to update the browser's accept header to specify that the browser now accepts this image type. It's what it's for.
The "every time you add a byte it stays" argument is specious -- how often have we added an image format to the web?
My understanding is that WebP is superior to Jpeg when encoding from a lossless image but:
(1) if I upload a lossy jpeg what gains is FB really getting by using WebP?
(2) Or am I taking a quality hit on what they serve?
Let's say there's no quality hit and somehow they make a lossless WebP version of my lossy jpeg that still fits in 20% fewer bytes. Define X as the dollar savings gained by delivering these images scaled up to quadrillions of images served.
My understanding is that WebP makes it's gains by a 10x longer encode. Define Y as the dollar cost of encoding and storing trillions of images in WebP.
(3) What are the odds X is actually greater than Y?
This can only be a troll... 'all the open source image tools'? That seems like an intractable set to me. They shouldn't need to. I see there's an imlib2 webp loader. It is BSD licensed. I don't see that it came from Google.
So what's your point? We're supposed to be hating Facebook anyway, not Google in this article.
There is a set of command-line utilities, a library with source, and a codec for Windows Imaging Component which has no parallel in Linux that I am aware of. (save imlib2 and friends)
I don't know any project that uses image formats in any way and does not link directly with libpng, libjpeg, lib(un)gif, or other directly supporting libraries that are tied to individual formats. There is an evas webp loader on eina, which is no help to Gnome or KDE users, and there are dozens if not hundreds of projects that probably need support to be added.
Don't know how ubiquitous Windows Imaging Component is in MS-land, but it seems like a much easier problem to have solved.
Right now, we're stuck with everybody doing something different in the page design to do something that's pretty important and fairly intrinsic to much of what happens on the web. And so users just default to the thing they know works everywhere, which is Save As... It's not surprising some of them are upset.
The only issue I can see with this is that there are security concerns with being able to override what is actually downloaded when Save As is used.