Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compression > #1611 > unrolled thread

JPEG's libjpeg updated

Started byThomas Richter <thor@math.tu-berlin.de>
First post2012-11-17 13:55 +0100
Last post2012-11-17 09:25 -0800
Articles 4 — 2 participants

Back to article view | Back to comp.compression


Contents

  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

#1611 — JPEG's libjpeg updated

FromThomas Richter <thor@math.tu-berlin.de>
Date2012-11-17 13:55 +0100
SubjectJPEG'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]


#1612

Frompfraser <pete_fraser@comcast.net>
Date2012-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]


#1613

FromThomas Richter <thor@math.tu-berlin.de>
Date2012-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]


#1614

Frompfraser <pete_fraser@comcast.net>
Date2012-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