Add support for WebP format images about vip

[jrit]

@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.

[scottferg]

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?

[scottferg]

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

[jrit]

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.

[scottferg]

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" [email protected] 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).

[foresmac]

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.

[scottferg]

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" [email protected] 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).

[foresmac]

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?)

[scottferg]

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" [email protected] 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).

[jrit]

That is what I was thinking @scottferg

[foresmac]

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

[scottferg]

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.

[scottferg]

To your point though, probably PNG because of transparency.

[foresmac]

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?

[scottferg]

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.

[jrit]

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.

[foresmac]

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

[scottferg]

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.

[scottferg]

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

[foresmac]

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

[scottferg]

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.

[foresmac]

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)
}

[scottferg]

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

[scottferg]

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

[scottferg]

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.

[scottferg]

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

[WorkHorseIndustries]

queue is implemented.

[scottferg]

Awww yesssss
On Feb 3, 2015 11:53 PM, "Alex Nimmer" [email protected] wrote:

github.com/vokal/q

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