I'm trying to find out where the JPEG file ends, mainly to find out whether there's any information appended to the end of the file. I've tried searching for the EOF (FF D9), but to my surprise, this is repeated multiple times in the file in 1 out of 5 files.
Is there a way to safely determine where the JPEG file ends?
>>1 "I've tried searching for the EOF (FF D9)"
What are you, retarded? A filesystem might use that byte sequence to mark the end of the file, but it doesn't pass it along to a program that reads the file.
>>13
Then you've probably appended a JPEG to a JPEG. Which would probably be a stupid thing to do. And if >>1 wanted the check to be robust, tha'd just parse the file.
So there can't be sequences FF,D8 FF,D9 anywhere in JPEG streams? Why did they do it? Simplicity of parsers?
Name:
Anonymous2008-08-15 9:36
>>37
There can be those sequences inside the JPEG stream besides the tags.
Look, it's not that difficult, you shitbag wannabes. JPEG is a compression format. They're not going to put any extra bytes in that can be inferred from elsewhere, nor are they going to bother with adding escape codes around FF D8|D9 pairs just so your lazy ass can grep for them.
Name:
Anonymous2008-08-15 10:49
>>38 nor are they going to bother with adding escape codes around FF D8|D9 pairs just so your lazy ass can grep for them.
Actually, remember that the JPEG bitstream format was designed by idiots. It is not sensible like PNG. From the JPEG standard: byte stuffing: A procedure in which either the Huffman coder or the arithmetic coder inserts a zero byte into the entropy-coded segment following the generation of an encoded hexadecimal X’FF’ byte. In order to ensure that a marker does not occur within an entropy-coded segment, any X’FF’ byte generated by either a Huffman or arithmetic encoder, or an X’FF’ byte that was generated by the padding of 1-bits described in NOTE 1 above, is followedby a “stuffed” zero byte (see D.1.6 and F.1.2.3).