Having said that, MacOS preview is perfectly happy with opening thumbimg.jpg and displaying a big green rectangle (is
that what the file is supposed to look like?), so we should probably successfully read the image. Have we tried to open
it with any other file utilities to see if it is universally considered a valid JPEG?
...jim
On 7/12/16 6:57 PM, Jim Graham wrote:
That doesn't appear to be happening in this case. If you take the APP0 marker
lengths at face value, there are 3 APP0
markers. The first has a length that brings you to the second one. The second
one has a length that takes you 2 bytes
short of the next. The intervening bytes are 00,00 which do not follow the
indicated rule, but are consistent with the
fact that that data block contains hundreds of triplets of "ff 00 00" in a row.
The third has a length that also is 2
bytes short before the next marker and the intervening bytes in that case are
00,ff which again does not follow the
indicated rule, but is again consistent with the fact that the data block is hundreds of
copies of the triplet "00 00 ff".
In short, it appears that the file simply has 2 APP0 markers where the utility
that constructed it forgot that the 2
size bytes are included in the length of the APP field. If you add 2 to each
of those lengths to account for this
assumption, then the file is perfectly formed with no fill bytes.
Another reference says that FF are frequently used as fill bytes, but must not
appear in entropy encoded data - meaning
don't just randomly spew FF bytes into data that is traversed via searching
(entropy encoded data is the only data that
has no length field. It follows an SOS marker which has a length for some
initial data, but immediately falls into
entropy encoding where you have to scan for FF markers again).
I don't see any evidence that this text is meant to allow an arbitrary set of
FF bytes to be just insert before markers
and even if it did, the file in question (thumbimg.jpg) has bytes other than FF
inserted.
Where did thumbimg.jpg come from? Are we sure that it is a validly constructed
JPEG file?
...jim
On 7/8/16 12:07 PM, Phil Race wrote:
On 07/08/2016 04:08 AM, Jayathirth D V wrote:
Hi,
In JDK-8152672 <https://bugs.openjdk.java.net/browse/JDK-8152672> we modified
skipImage() in JpegImageReader.java and
added tighter checks for parsing Jpeg data.
We have to find any marker,0 or EOF after we find "FF" while parsing JPEG data.
But in JDK-8160943 <https://bugs.openjdk.java.net/browse/JDK-8160943> we have
gap between APP0 marker and DQT(FF DB)
marker which contains data “00 FF”.
APP0_End -> 00 FF -> FF DB(DQT)
So after we skip APP0 marker we find two bytes of data which is “FF FF”. In the
present code we consider this as
invalid marker.
See https://www.w3.org/Graphics/JPEG/itu-t81.pdf
B.1.1.2 Markers
Markers serve to identify the various structural parts of the compressed data
formats.
Most markers start marker segments containing a related group of parameters;
some markers stand alone. All markers are assigned two-byte codes: an
X’FF’ byte followed by a byte which is not equal to 0 or X’FF’ (see Table B.1).
Any marker may optionally be preceded by any number of fill bytes,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
which are bytes assigned code X’FF
^^^^^^^^^^^^^^^^^^^^^^
-phil.
Because of this JDK-8160943 <https://bugs.openjdk.java.net/browse/JDK-8160943>
is failing.
Is the length of APP0 marker not valid in the image or we should not consider
“FF FF” as invalid maker?
Please let me know your input.
Thanks,
Jay
