Add support for WebP format images

Question

Add support for WebP format images

Opened this issue 10 years ago · 28 comments

Here is some helpful research:

image only contains a WebP decoder, not an encoder
Someone built an external library for encoding (and decoding) WebP that uses cgo with what I believe is libwebp. It might be "fun" to translate libwebp from C to Go as an open source project.
Currently only Chrome or Opera support viewing WebP images. We could, like Facebook, YouTube, and Netflix, serve WebP to browsers that send the proper accept header. However, users trying to save the images are frustrated when they can't do anything with them.
In general, WebP uses less data to provide a roughly comparable quality image (Using VP8 keyframe compression) in a format that as optimized for transfer over HTTP (e.g., file size is read from the first 8 bytes, image size within the first 24).
Container spec here
WebP API docs here

Answer 1 · 2014-12-28T17:32:05.000Z

@foresmac thank you for getting this together. The issue in browser of users being unable to do anything expected with saved images should be treated as a usability concern. So I don't think we should use WebP for any image that we could reasonably expect someone might want to save, which is probably everything that would be in vip.

Android doesn't experience the same issue because users don't expect to be able to save images they see in an app by dragging it to their desktop or right clicking, so that seems like a better place to use it.

Answer 2 · 2014-12-29T00:50:29.000Z

We can match Android's user-agent but I disagree that the ability to save is a reason not to do it. Given that Facebook continues to convert to WebP and their user's are certainly a demographic that want to save the images to disk is reason enough to assume we would have no issue with always pushing WebP to Chrome.

Also, on my machine, WebP mimetypes default to Chrome for viewing. Is that not the case on Windows?

Answer 3 · 2014-12-29T00:52:28.000Z

Also, mozjpeg should also be a candidate for support though given the minimal mobile support it's likely less of a priority.

Answer 4 · 2014-12-29T01:06:16.000Z

That is correct that it opens in chrome on windows if saved locally. Isn't mozjpeg just a different encoder that is backwards compatible for all jpegs when decoding?

I'm not convinced it is a good idea generally for web, but that certainly shouldn't prevent you adding support for Android. It is something we'd have to discuss with clients, I wouldn't be comfortable just turning it on by default and then having them be surprised by incompatibilities.

Answer 5 · 2014-12-29T01:25:41.000Z

I'm not as familiar with mozjpeg past it being their competing format that
performs equally as well. Android is the deciding factor here in my opinion.

We can make cross-encoding to WebP optional when running vip. That'd be a
reasonable middle ground.
On Dec 28, 2014 7:06 PM, "Jarrett Widman" notifications@github.com wrote:

That is correct that it opens in chrome on windows if saved locally. Isn't
mozjpeg just a different encoder that is backwards compatible for all jpegs
when decoding?

I'm not convinced it is a good idea generally for web, but that certainly
shouldn't prevent you adding support for Android. It is something we'd have
to discuss with clients, I wouldn't be comfortable just turning it on by
default and then having them be surprised by incompatibilities.

—
Reply to this email directly or view it on GitHub
#61 (comment).

Answer 6 · 2014-12-29T01:28:31.000Z

I don't think the issue (particularly for desktop users) is that they can't view the images after saving, it's that viewing is all you can do with the images. You can't open it in Photoshop, Preview, or any other image editor (except maybe GIMP...). You can't upload it anywhere except Google+ and maybe Facebook. You can't add it to your scrapbooking software, your PowerPoint presentation, your DVD slide show, etc.

Answer 7 · 2014-12-29T01:29:59.000Z

Has Facebook changed how they handle that? Last I checked it still
downloaded the file in WebP if it had been re encoded.
On Dec 28, 2014 7:28 PM, "Chris Foresman" notifications@github.com wrote:

I don't think the issue (particularly for desktop users) is that they
can't view the images after saving, it's that viewing is all you can
do with the images. You can't open it in Photoshop, Preview, or any other
image editor (except maybe GIMP...). You can't upload it anywhere
except Google+ and maybe Facebook. You can't add it to your
scrapbooking software, your PowerPoint presentation, your DVD slide show,
etc.

—
Reply to this email directly or view it on GitHub
#61 (comment).

Answer 8 · 2014-12-29T01:34:08.000Z

I agree it's definitely worth adding support for at the very least sending WebP format to Android devices. We could also support uploading WebP, and basically only serve it directly to Android devices, encoding as JPEG for other platforms.

Once that's built and WebP is more widely supported, it would be easy to progressively enhance it to serve to more devices/platforms/user agents as needed or desired.

(Perhaps we can make a list of user agents or something a launch config option?)

Answer 9 · 2014-12-29T01:37:13.000Z

I think that's more narrow focused than what we should do today. Currently
Vip encoding is fast and we get great performance. By requiring additional
CPU horsepower we can easily cross compile multiple encodings to support a
variety of performant formats.

For example: user uploads a WebP image. We immediately encode it in
parallel as a jpeg for all non-Android users and serve it from the same
key, based on user agent.

The same would work for uploading a jpeg.
On Dec 28, 2014 7:34 PM, "Chris Foresman" notifications@github.com wrote:

I agree it's definitely worth adding support for at the very least sending
WebP format to Android devices. We could also support uploading WebP, and
basically only serve it directly to Android devices, encoding as JPEG for
other platforms.

Once that's built and WebP is more widely supported, it would be easy to
progressively enhance it to serve to more devices/platforms/user agents as
needed or desired.

(Perhaps we can make a list of user agents or something a launch config
option?)

—
Reply to this email directly or view it on GitHub
#61 (comment).

Answer 10 · 2014-12-29T01:57:23.000Z

That is what I was thinking @scottferg

Answer 11 · 2014-12-29T02:06:39.000Z

WebP with alpha could be simultaneously encoded as PNG as well.

Answer 12 · 2014-12-29T02:08:51.000Z

PNG or Jpeg, either is irrelevant if we have a spare CPU which is easily detectable at runtime. If Vip is running on a single core machine then I say we don't cross-encode. Thanks to @Nimzor 's recent bro update, deploying Vip is as simple as an IP and an SSH key so providing a multiple-core machine is fairly trivial.

Answer 13 · 2014-12-29T02:09:18.000Z

To your point though, probably PNG because of transparency.

Answer 14 · 2014-12-29T20:50:44.000Z

Could use something like:

if runtime.NumCpus() > 1 {
    go encodeWebP(src)
    go encodeJpeg(src)
    go encodePNG(src)
} else {
   // do what we already do
}

That's not meant to be a complete and bug free implementation, but the general idea, right?

Answer 15 · 2014-12-29T20:53:57.000Z

Yeah, I'd also output a message on server start for debugging purposes if somebody accidentally deployed on a single core machine and wanted to take advantage of this.

Now to critique your complete and bug free implementation: I'm not opposed to lazily firing off goroutines but it'd likely make sense to build out a worker queue library inside of vip to handle these logically. You can do this really easily with a buffered channel which is a FIFO queue by default. That would let us reliably cross encode in the background without worrying about accidentally triggering a million cross encode requests that devour CPU.

Answer 16 · 2014-12-29T20:56:35.000Z

I think you would generally choose PNG or JPEG based on the uploaded type (not both), but if the upload type is WebP you would have to look into the file I suppose to pick the better encoding possibly based on whether there is transparency or some other attribute I'm not aware of. In any case, there is no point to encoding to a file type that wouldn't be served since when you serve it you are going to have to pick a specific file type.

Answer 17 · 2014-12-29T20:57:30.000Z

@jrit Yeah, you can just look at the file headers and see if has alpha or not and encode appropriately.

Answer 18 · 2014-12-29T20:57:49.000Z

The more likely case is that a person is uploading a JPEG or PNG in which case it's encoded on the fly already. This really should only be calling encodeWebP.

Answer 19 · 2014-12-29T20:58:46.000Z

Actually, the logical place here would be during upload in which case there's no encoding at all.

Answer 20 · 2014-12-29T20:59:09.000Z

Right. I meant for that to be on the upload process.

Answer 21 · 2014-12-29T21:00:17.000Z

Yeah in that case just queue up the encoding and let the HTTP GET handler do the rest if the requesting entity supports WebP. It should be easy to continue serving up the PNG/JPEG image if the encoding is in progress.

Answer 22 · 2014-12-29T21:02:36.000Z

And agree we only need to set up an encode request like so:

switch upload {
case "JPEG":
    go encodeWebP(upload)
case "PNG":
    go encodeWebPAlpha(upload)
case "WebP Alpha":
    go encodePNG(upload)
case "WebP":
    go encodeJpeg(upload)
}

Answer 23 · 2014-12-29T21:03:30.000Z

Based on my limited understanding of WebP's internals, yeah that looks correct.

Answer 24 · 2014-12-29T21:03:56.000Z

Hey @wmbest2 look ^^^^ no break statements!

Answer 25 · 2014-12-30T00:46:33.000Z

With regards to a queuing library baked into Vip, @benghaziboy may find the same library useful for his push management process that he's writing. I'm envisioning something really simple that basically looks like:

type Job interface {
    Run() error
}

var (
    Queue chan Job
)

const (
    QueueSize = 100
)

func init() {
    Queue = make(chan Job, QueueSize)

    go func(q chan Job) {
        for {
            err := <-q.Run()
            if err != nil {
                log.Println(err.Error())
            }
        }
    }(q)
}

Buffered channels act as FIFO queues which means if there are > QueueSize jobs currently waiting in the channel the sender will block. Otherwise the sender will not block. The goroutine simply loops over that channel indefinitely and calls Run() which can do anything.

This could be jazzed up a bit more with a worker pool with many input channels and instead use the fan-in pattern to pull all inputs to Queue in and send them off to dedicated worker goroutines.

Answer 26 · 2014-12-30T00:47:11.000Z

This could live as github.com/vokalinteractive/vip/queue or if @benghaziboy is interested it could be a separate project.

Answer 27 · 2015-02-04T05:53:06.000Z

queue is implemented.

Answer 28 · 2015-02-04T13:01:53.000Z

Awww yesssss
On Feb 3, 2015 11:53 PM, "Alex Nimmer" notifications@github.com wrote:

github.com/vokal/q

—
Reply to this email directly or view it on GitHub
#61 (comment).