[
https://issues.apache.org/jira/browse/IMAGING-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858221#comment-16858221
]
Bruno P. Kinoshita commented on IMAGING-130:
--------------------------------------------
There is a GIF image (attached here for reference later, o23L9.gif) that is
correctly rendered in Firefox/Chrome, but fails to be read by Apache Commons
Imaging (also by the JDK decoder as reported in the SO answer).
When I try the following code:
{code:java}
package org.apache.commons.imaging;
import java.io.File;
public class Test {
public static void main(String[] args) throws Exception {
Imaging.getBufferedImage(new File("/home/kinow/Downloads/test.gif"));
}
}{code}
I get:
{noformat}
Exception in thread "main" java.io.IOException: AddStringToTable: codes: 4096
code_size: 12
at
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.addStringToTable(MyLzwDecompressor.java:112)
at
org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:167)
at
org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:397)
at
org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:260)
at
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:460)
at
org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:444)
at
org.apache.commons.imaging.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:649)
at org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1439)
at org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1401)
at org.apache.commons.imaging.TTT.main(TTT.java:8)
{noformat}
But using the code of the Pull request, no exception happens. What is discussed
in the SO is ignoring when the string table is full.
>From what I understood, we are talking about the LZW (Lempel-Ziv Welch)
>compression algorithm used with the GIF format (or a variant of the original
>LZW). The string table is a table with strings, and strings are accumulators
>of characters (which can be a character, but for GIF they are color indexes),
>used to compress/decompress data in LZW.
And there is a part of the GIF89a specification that states:
{noformat}
There has been confusion about where clear codes can be found in the
data stream. As the specification says, they may appear at anytime. There
is not a requirement to send a clear code when the string table is full.
It is the encoder's decision as to when the table should be cleared. When
the table is full, the encoder can chose to use the table as is, making no
changes to it until the encoder chooses to clear it. The encoder during
this time sends out codes that are of the maximum Code Size.
As we can see from the above, when the decoder's table is full, it must
not change the table until a clear code is received. The Code Size is that
of the maximum Code Size. Processing other than this is done normally.
Because of a large base of decoders that do not handle the decompression in
this manner, we ask developers of GIF encoding software to NOT implement
this feature until at least January 1991 and later if they see that their
particular market is not ready for it. This will give developers of GIF
decoding software time to implement this feature and to get it into the
hands of their clients before the decoders start "breaking" on the new
GIF's. It is not required that encoders change their software to take
advantage of the deferred clear code, but it is for decoders.{noformat}
Clear codes are used when you start creating your color table. But there is no
requirement to send one when the table is full. It also doesn't say that you
must throw an error when the string table is full.
So the fix looks good to me. Tested, and I can successfully parse the GIF
attached in the StackOverflow thread. Merging PR and adding to 1.0-alpha2.
References I used besides this issue and SO:
* [https://www.w3.org/Graphics/GIF/spec-gif89a.txt]
* [https://www.cs.cmu.edu/~cil/lzw.and.gif.txt]
Thanks for creating the issue with good description, thanks to the contributor
who submitted the PR, and will log in to thank others in StackOverflow as well.
Bruno
> Reading of some GIF images throws java.io.IOException: AddStringToTable:
> codes: 4096 code_size: 12
> --------------------------------------------------------------------------------------------------
>
> Key: IMAGING-130
> URL: https://issues.apache.org/jira/browse/IMAGING-130
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: GIF
> Affects Versions: 1.0-alpha1
> Environment: Oracle JRE 1.7.0_45 on Windows 7
> Oracle JRE 1.7.0_55-b13 on Debian 7.5
> Reporter: Dhyan Blum
> Assignee: Bruno P. Kinoshita
> Priority: Major
> Fix For: Patch Needed
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hi guys,
> for some GIF images Imaging.getBufferedImage(byte[] bytes) throws the
> following exception:
> {quote}
> java.io.IOException: AddStringToTable: codes: 4096 code_size: 12
> at
> org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.addStringToTable(MyLzwDecompressor.java:112)
> at
> org.apache.commons.imaging.common.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:168)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:388)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:251)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:455)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:435)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:646)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1378)
> at
> org.apache.commons.imaging.Imaging.getBufferedImage(Imaging.java:1292)
> {quote}
> I have the same problem when using ImageIO.read(). In my post on
> Stackoverflow (
> http://stackoverflow.com/questions/22259714/arrayindexoutofboundsexception-4096-while-reading-gif-file
> ) you will find an example image to reproduce the exception and a similar
> looking JDK bug report that I found using Google. Quote from the bug report:
> {quote}
> A DESCRIPTION OF THE PROBLEM :
> according to specification
> http://www.w3.org/Graphics/GIF/spec-gif89a.txt
> > There is not a requirement to send a clear code when the string table is
> > full.
> However, GIFImageReader requires the clear code when the string table is full.
> GIFImageReader violates the specification, clearly.
> In the real world, sometimes people finds such high compressed gif image.
> so you should fix this bug.
> {quote}
> I hope you will find this information helpful.
> Kind regards
> Dhyan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
