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 dis
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?
>
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 th
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.
> W
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
add
> 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 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 q
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:
http://mattmahoney.net/d
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 libjpeg-
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
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 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
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 fi
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 C
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 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 al
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 J
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 J
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 chai
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
dev-platform@lists.moz
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".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https:
21 matches
Mail list logo
