The image/jpeg encoder currently has fast-ish code paths if the image
being encoded is an *image.Gray or an *image.RGBA (see the writeSOS
method in image/jpeg/writer.go). If not, it will go through a much
slower path. The fact that your profile spends most of its time in
image/jpeg.toYCbCr (and image.(*YCbCr).At) suggests that you're going
through the slower path, and I'm guessing that your source images are
*image.YCbCr, as you would get if you're decoding JPEGs.

As medium term approaches, the image/jpeg library could add a fast-ish
code path for more image types. Specifically, encoding an *image.YCbCr
definitely should not need to round-trip through color.Color's RGBA
representation. The fast-ish code path could undoubtedly also be made
to go faster, if not significantly faster. There hasn't been much work
put into optimizing the encoder yet. There's definitely implementation
work that's worth doing, but I don't believe that the underlying
"image" and "image/etc" package designs are fundamentally flawed.

Unfortunately, I don't have much time to work on these medium term
suggestions myself, due to non-work-related reasons.

In the short term, you might see a noticable speed-up if you first
convert your images to *image.RGBA before encoding, which is
admittedly a lossy process, but JPEG is already lossy. In the long
term, once those optimizations above are done, this will end up being
slower than what you're doing now, but it might be faster right now.
See the "Converting an Image to RGBA" section of

As for encoding a subsample ratio other than 4:2:0, the jpeg.Options
struct gives us the ability to implement that if we wanted to. Again,
it's a matter of finding the time to do the work, and not necessarily
(in my biased opinion) that, modulo backwards compatibility, the APIs
require significant changes.

As for chroma interpolation when decoding, that is a classic time vs
quality trade-off. The standard library does the simpler, faster
choice of no interpolation, but the image.YCbCr type should have
enough information for someone to implement the more complicated,
slower but better looking version if they want to.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 7 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 14, '15 at 12:29a
activeOct 15, '15 at 12:51a



site design / logo © 2021 Grokbase