On Tuesday, July 15, 2014 7:34:35 AM UTC-7, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
It would help if you would use much more
On Tuesday, July 15, 2014 8:34:35 AM UTC-6, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
Could you post the command lines used for the
On Tuesday, July 15, 2014 1:38:00 PM UTC-6, stone...@gmail.com wrote:
Would be nice if you guys just implemented JPEG2000. It's 2014.
Based on what data?
Not only would you get a lot more than a 5% encoding boost, but you'd get
much higher quality images to boot.
Based on what data?
If
Den torsdag den 24. juli 2014 23.59.58 UTC+2 skrev Josh Aas:
I selected 10,000 random JPEGs that we were caching for customers and ran
them through mozjpeg 2.0 via jpegtran. Some interesting facts:
With mozjpeg you probably want to re-encode with cjpeg rather than jpegtran.
We added
On Tuesday, July 15, 2014 3:15:13 PM UTC-5, perez@gmail.com wrote:
#1 Would it be possible to have the same algorithm that is applied to webP to
be applied to JPEG?
I'm not sure. WebP was created much later than JPEGs, so I'd think/hope they're
already using some equivalent to trellis
Are there any plans to integrate into other tools, specifically imagemagick?
Or would you leave that up to others?
For now we're going to stay focused on improving compression in mozjpeg's
library. I think a larger improved toolchain for optimizing JPEGs would be
great, but it's probably
On Friday, July 18, 2014 10:05:19 AM UTC-5, j...@cloudflare.com wrote:
I selected 10,000 random JPEGs that we were caching for customers and ran
them through mozjpeg 2.0 via jpegtran. Some interesting facts:
With mozjpeg you probably want to re-encode with cjpeg rather than jpegtran. We
On 19/07/2014 22:40, Ralph Giles wrote:
Probably not for Firefox OS, if you mean mozjpeg. Not necessarily
because it uses hardware, but because mozjpeg is about spending more cpu
power to compress images. It's more something you'd use server-side or
in creating apps. The phone uses
One option that I haven't seen compared is the combination of JPEG w/ packJPG
(http://packjpg.encode.ru/?page_id=17). packJPG can further compress JPEG
images another 20%+ and still reproduce the original bit-for-bit.
More details on how this is done can be found here:
Would this code be a candidate for use in Firefox OS or does most of that
happen in the hardware?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2014-07-19 1:14 PM, Caspy7 wrote:
Would this code be a candidate for use in Firefox OS or does most of that
happen in the hardware?
Probably not for Firefox OS, if you mean mozjpeg. Not necessarily
because it uses hardware, but because mozjpeg is about spending more cpu
power to compress
On Tuesday, July 15, 2014 3:34:35 PM UTC+1, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
Josh,
I work for CloudFlare on many things but
Cool
=Re decoding.
I'm replying to this note:
1. We're fans of libjpeg-turbo - it powers JPEG decoding in Firefox because
its focus is on being fast, and that isn't going to change any time soon. The
mozjpeg project focuses solely on encoding, and we trade some CPU cycles for
smaller
Study is here:
http://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/
Blog post is here:
https://blog.mozilla.org/research/2014/07/15/mozilla-advances-jpeg-encoding-with-mozjpeg-2-0/
___
dev-platform mailing list
Hello Josh,
thank you and all involved for your efforts to make the web faster.
Are there any plans to integrate into other tools, specifically imagemagick?
Or would you leave that up to others?
With all the options available for image processing one can end up with
building quite a complex
On Tuesday, July 15, 2014 7:34:35 AM UTC-7, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
Would be nice if you guys just implemented
On Tuesday, July 15, 2014 7:34:35 AM UTC-7, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
Would be nice if you guys just implemented
On Tuesday, July 15, 2014 10:34:35 AM UTC-4, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image
Formats Study and the Mozilla Research blog post entitled Mozilla Advances
JPEG Encoding with mozjpeg 2.0.
#1 Would it be possible to have the same
On 7/15/14 12:38 PM, stonecyp...@gmail.com wrote:
On Tuesday, July 15, 2014 7:34:35 AM UTC-7, Josh Aas wrote:
This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image Formats
Study and the Mozilla Research blog post entitled Mozilla Advances JPEG Encoding
with mozjpeg 2.0.
On 7/15/14 12:38 PM, stonecyp...@gmail.com wrote:
Similarly there's a reason that people are still hacking video into
JPEGs and using animated GIFs.
People are using animated GIFs, but animated GIFs people are using may
not be animated GIFs [1].
(2014/07/16 5:43), Chris Peterson wrote:
Do
20 matches
Mail list logo
