[OpenJDK 2D-Dev] REG : JDK-8160943 : [PIT] new failure of closed/javax/imageio/ReadAllThumbnailsTest.java

[Jim Graham]

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
>>>
>>