Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compression > #1611 > unrolled thread
| Started by | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| First post | 2012-11-17 13:55 +0100 |
| Last post | 2012-11-17 09:25 -0800 |
| Articles | 4 — 2 participants |
Back to article view | Back to comp.compression
JPEG's libjpeg updated Thomas Richter <thor@math.tu-berlin.de> - 2012-11-17 13:55 +0100
Re: JPEG's libjpeg updated pfraser <pete_fraser@comcast.net> - 2012-11-17 07:10 -0800
Re: JPEG's libjpeg updated Thomas Richter <thor@math.tu-berlin.de> - 2012-11-17 16:25 +0100
Re: JPEG's libjpeg updated pfraser <pete_fraser@comcast.net> - 2012-11-17 09:25 -0800
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2012-11-17 13:55 +0100 |
| Subject | JPEG's libjpeg updated |
| Message-ID | <k881fe$dcf$1@news2.informatik.uni-stuttgart.de> |
Dear readers, please find a new version of the JPEG's libjpeg implementation at https://github.com/thorfdbg/libjpeg To remind you, this code implements some of the new features currently in discussion for the new JPEG standard, a backwards compatible JPEG implementation. Amongst others, it supports high-bitdepth coding and lossless coding, completely compatible with legacy applications (certainly, then not high-bitdepths neither lossless). The repository also contains the current version of the ISO working draft for the new standard. Note that there is no binary version available right now because neither the specifications nor the software is considered finite. Fixes since the last release: * Coding of images whose first pixel value represents an ASCII whitespace was broken. * Coding of grey-scale images was broken. * The implementation of the hierarchical mode was broken for images whose height was not divisible by 2^n * 8, where n is the number of levels. Have fun, Thomas
[toc] | [next] | [standalone]
| From | pfraser <pete_fraser@comcast.net> |
|---|---|
| Date | 2012-11-17 07:10 -0800 |
| Message-ID | <k889ds$do$1@dont-email.me> |
| In reply to | #1611 |
Thomas Richter wrote: > Dear readers, > > please find a new version of the JPEG's libjpeg implementation > it supports [...] lossless coding, Is this LOCO stuff, or the old lossless JPEG, or something else entirely?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2012-11-17 16:25 +0100 |
| Message-ID | <k88a90$fed$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #1612 |
Am 17.11.2012 16:10, schrieb pfraser: > Thomas Richter wrote: >> Dear readers, >> >> please find a new version of the JPEG's libjpeg implementation > >> it supports [...] lossless coding, > > Is this LOCO stuff, or the old lossless JPEG, or something > else entirely? Yes, yes, and yes. (-: Ok, to be precise: libjpeg supports 10918-1 lossless, the old predictive lossless mode, as well as LOCO aka JPEG-LS aka 14495-1 plus a bit of 14495-2, and a new backwards compatible lossless mode. It also supports a hybrid lossless mode combining 10918-1 hierarchical coding plus 10918-1 predictive lossless (that's a bit "fake" since it requires a precise definition of the DCT process 10918-1 does not offer). The *new* lossless mode that is currently under standardization is backwards compatible to 10918-1 in the sense that the base layer is a 10918-1 compliant codestream every legacy decoder can decode. A decoder compliant to the new standard will get additional residual data that will allow lossless reconstruction if combined with the standard-defined fixpoint DCT and the standard-defined inverse multi-component decorrelation transformation (the I-FCT). The details are in the current working draft, which you also find in the repository (WD2.pdf). Sorry, the document is a very *early* draft, so it is partially inconsistent, and incomplete, and will likely change quite a bit over the next standardization meetings. Greetings, Thomas
[toc] | [prev] | [next] | [standalone]
| From | pfraser <pete_fraser@comcast.net> |
|---|---|
| Date | 2012-11-17 09:25 -0800 |
| Message-ID | <k88han$fdj$1@dont-email.me> |
| In reply to | #1613 |
Thomas Richter wrote: > Am 17.11.2012 16:10, schrieb pfraser: >> Thomas Richter wrote: >>> Dear readers, >>> >>> please find a new version of the JPEG's libjpeg implementation >> >>> it supports [...] lossless coding, >> >> Is this LOCO stuff, or the old lossless JPEG, or something >> else entirely? > > Yes, yes, and yes. (-: > > Ok, to be precise: libjpeg supports 10918-1 lossless, the old predictive > lossless mode, as well as LOCO aka JPEG-LS aka 14495-1 plus a bit of > 14495-2, and a new backwards compatible lossless mode. It also supports > a hybrid lossless mode combining 10918-1 hierarchical coding plus > 10918-1 predictive lossless (that's a bit "fake" since it requires a > precise definition of the DCT process 10918-1 does not offer). > > The *new* lossless mode that is currently under standardization is > backwards compatible to 10918-1 in the sense that the base layer is a > 10918-1 compliant codestream every legacy decoder can decode. A decoder > compliant to the new standard will get additional residual data that > will allow lossless reconstruction if combined with the standard-defined > fixpoint DCT and the standard-defined inverse multi-component > decorrelation transformation (the I-FCT). Thanks. > > The details are in the current working draft, which you also find in the > repository (WD2.pdf). Sorry, the document is a very *early* draft, so it > is partially inconsistent, and incomplete, and will likely change quite > a bit over the next standardization meetings. Yes. That's why I took the lazy route and asked you, rather than poring over the original documents. I was worried that I could spend hours, and still not understand. Pete
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compression
csiph-web