Skip to main content

Artihmetic/Huffman lossless jpeg

9 replies [Last post]
cij100
Offline
Joined: 2007-05-12
Points: 0

I've been having issues with one of the readers that I use for testing images I produce when viewing lossless jpegs. The images are being wrapped in a NSIF/NITF file. The application can view the intermediate lossless jpeg that imageio produces, but when in a NITF file it contains lots of white pixesl/artefacts and some artefacts that span a line.

I initially thought it was a problem with the predictor values, as the artefacts changed when I manually set the values. It's currently not possible to set the predictor values through the imageio interface, although I notice there is an enhancement request 'in progress'. Can anyone say how it is progressing/when it's likely to be made available?

I now believe the issue is that the imageio is encoding the JPEG lossless using the Huffman principle (process 1), where as the NITF reader is expecting it encoded using the arithmetic (process 2). I understand the latter is normally avoided, but is there any easy way or translating between the two, or does anyone know of an encoder that can encode a Lossless jpeg with arithmetic processing (assuming ImageIO can't).

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
David Clunie

Hi

jai-imageio@javadesktop.org wrote:
> I've been having issues with one of the readers that I use for testing images I produce when viewing lossless jpegs. The images are being wrapped in a NSIF/NITF file. The application can view the intermediate lossless jpeg that imageio produces, but when in a NITF file it contains lots of white pixesl/artefacts and some artefacts that span a line.
>
> I initially thought it was a problem with the predictor values, as the artefacts changed when I manually set the values. It's currently not possible to set the predictor values through the imageio interface, although I notice there is an enhancement request 'in progress'. Can anyone say how it is progressing/when it's likely to be made available?
>
> I now believe the issue is that the imageio is encoding the JPEG lossless using the Huffman principle (process 1), where as the NITF reader is expecting it encoded using the arithmetic (process 2). I understand the latter is normally avoided, but is there any easy way or translating between the two, or does anyone know of an encoder that can encode a Lossless jpeg with arithmetic processing (assuming ImageIO can't).

This could possibly be due to a "16 bit signed data" bug (or
at least difference in interpretation of ISO 10981-1) by
different codecs, which is often seen in the medical
imaging community.

Is your data 16 bit ?

I would suggest that you extract the JPEG lossless bit stream
from its NITF wrapper and then try decompressing it in various
different codecs, including the PVRG codec.

David
[dclunie.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

jxc
Offline
Joined: 2005-02-24
Points: 0

> I now believe the issue is that the imageio is
> encoding the JPEG lossless using the Huffman
> principle (process 1), where as the NITF reader is
> expecting it encoded using the arithmetic (process
> 2). I understand the latter is normally avoided, but
> is there any easy way or translating between the two,
> or does anyone know of an encoder that can encode a
> Lossless jpeg with arithmetic processing (assuming
> ImageIO can't).

I think the assumption is right. In the meantime, I wonder
if you could use JPEG-LS instead of JPEG-LOSSLESS.

Thanks,
-James

jxc
Offline
Joined: 2005-02-24
Points: 0

> > I now believe the issue is that the imageio is
> > encoding the JPEG lossless using the Huffman
> > principle (process 1), where as the NITF reader is
> > expecting it encoded using the arithmetic (process
> > 2). I understand the latter is normally avoided,
> but
> > is there any easy way or translating between the
> two,
> > or does anyone know of an encoder that can encode
> a
> > Lossless jpeg with arithmetic processing (assuming
> > ImageIO can't).
>
> I think the assumption is right. In the meantime, I
> wonder
> if you could use JPEG-LS instead of JPEG-LOSSLESS.

I'd like to take back the last sentence, if possible. :-) NITF
doesn't seem to support JPEG-LS, according to this document
http://www.gwg.nga.mil/ntb/baseline/docs/n010697/bwcguide25aug98.pdf
But it doesn't require arithmetic coding, as far as I can see.

Regards,
-James

cij100
Offline
Joined: 2007-05-12
Points: 0

Thanks for taking the time to look and reply. I think you are right. What had confused me was that the JPEG process id specified in 188-198 to be used when encoding a lossless jpeg nitf was 14, and apparently that tied in with the main jpeg standard (itu t81). In the jpeg standard process 14 indicates the use of sequential lossless with arithmetic encoding. If the huffman encoding was used then the process number should be 13.

However the sample lossless file on the nga website is a huffman encoded one, and the text in the standard suggests that either huffman or arithmetic can be used (depending on the document version). Strange.

Ken Warner

You should write for Startrek :-)

jai-imageio@javadesktop.org wrote:
> Thanks for taking the time to look and reply. I think you are right. What had confused me was that the JPEG process id specified in 188-198 to be used when encoding a lossless jpeg nitf was 14, and apparently that tied in with the main jpeg standard (itu t81). In the jpeg standard process 14 indicates the use of sequential lossless with arithmetic encoding. If the huffman encoding was used then the process number should be 13.
>
> However the sample lossless file on the nga website is a huffman encoded one, and the text in the standard suggests that either huffman or arithmetic can be used (depending on the document version). Strange.
> [Message sent by forum member 'cij100' (cij100)]
>
> http://forums.java.net/jive/thread.jspa?messageID=225011
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

cij100
Offline
Joined: 2007-05-12
Points: 0

Er, yeah. I'm trying to make sense of a pretty large set of standards, I forget that it won't make much sense to anyone else (or to me in many cases) :).

> You should write for Startrek :-)

Ken Warner

The nice thing about standards is that one has so many to choose from.....

jai-imageio@javadesktop.org wrote:
> Er, yeah. I'm trying to make sense of a pretty large set of standards, I forget that it won't make much sense to anyone else (or to me in many cases) :).
>
>
>>You should write for Startrek :-)
>
> [Message sent by forum member 'cij100' (cij100)]
>
> http://forums.java.net/jive/thread.jspa?messageID=225170
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

jwenting
Offline
Joined: 2003-12-02
Points: 0

You do have to remember that lossless JPEG does not in fact exist!
You can reduce the compression ratio, which will reduce losses, but AFAIK it's impossible to have guaranteed lossless storage with JPEG even with compression set to zero (there may be no visual losses, but the original image can't be restored from the encoded one pixel for pixel).

wfvoogd
Offline
Joined: 2004-10-01
Points: 0