NOTE: libjpeg-turbo trunk now contains a version of jchuff.c
(Huffman encoder) with the optimizations re-written and re-licensed under the
same BSD-style license as the rest of libjpeg.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
That bug is for tracking the decoder. I'm talking about the encoder
now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/612377
Title:
[needs-packaging] libjpeg-turbo
--
ubuntu-bugs mailing list
NOTE: libjpeg-turbo trunk now contains a version of jdhuff.c and
jdhuff.h (Huffman decoder) with the optimizations re-written and re-
licensed under the same BSD-style license as the rest of libjpeg.
Looking into jchuff* as well, but I figured you were probably more
interested in the decoder than
Created attachment 522544
Proposed upstream patch for addressing concern about jround_up() argument types.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/612377
Title:
[needs-packaging]
I'll address the review comments that are relevant to the upstream code
here:
(1) jround_up() argument types: this was the result of a bad game of
Celebrity Whack-a-Mole that I played while trying to port the code to
Win64. Jeff's idea of creating a local, power-of-2-specific round-up
function
And just FYI, another thing that I'm currently being contracted to do is
investigate rewriting the performance optimizations in j{c|d}huff*.
This will hopefully allow me to re-license those files in libjpeg-turbo
1.2.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Created attachment 522583
New proposed upstream patch for addressing concern about jround_up() argument
types.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/612377
Title:
[needs-packaging]
(In reply to comment #166)
+#define PAD(size, align) (((size) + (align) - 1) (~((align) - 1)))
I usually prefer functions over macros for the additional type safety and to
avoid evaluating arguments twice (e.g. PAD(x, a++))
My experience has been that the compiler does a good job of
(In reply to comment #177)
Don't we need to use the libjpeg v8 ABI in order to get this?
No, it works when emulating the v6b ABI as well. It just adds two
additional functions without breaking compatibility with the rest of the
ABI.
--
You received this bug notification because you are a
