Home > Archive > Compression > January 2006 > Raw JPEG Data Size
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Raw JPEG Data Size
|
|
| nozisles_2000@yahoo.com 2006-01-10, 3:57 am |
| I have a raw stream of data, part of which contains a JPEG (possibly
not in its entirity). I am attempting to extract (just extract, not
interpret) the image. Currently I detect the JPEG (JFIF) signature,
then walk through the image for as long as possible by detecting valid
headers and their size. Unfortunately, once I reach the start of a
scan (M_SOS) I am lost as to how to detect the correct/appropriate
size. I could attempt to scan for M_EOI however, this is extremely
unreliable as a) it may occur in data (?) and b) there is the
possiblity it will not be there at all and my extraction will never
end. I am not very versed in the ways of JPEG and any help on this
matter will be great. I have looked over IJG's code on the subject and
it seems rather advanced for what I am trying to do. Is there any
simple calculations I can use to get the size of the scan or the
distance from any unique marker to M_EOI?
Thanks for the help.
-- James
| |
| Pete Fraser 2006-01-10, 3:57 am |
| <nozisles_2000@yahoo.com> wrote in message
news:1136833978.124058.79510@g14g2000cwa.googlegroups.com...
>I have a raw stream of data, part of which contains a JPEG (possibly
> not in its entirity). I am attempting to extract (just extract, not
> interpret) the image. Currently I detect the JPEG (JFIF) signature,
> then walk through the image for as long as possible by detecting valid
> headers and their size. Unfortunately, once I reach the start of a
> scan (M_SOS) I am lost as to how to detect the correct/appropriate
> size.
I think you have to decode it.
> I could attempt to scan for M_EOI however, this is extremely
> unreliable as a) it may occur in data (?)
Not legally. Any image data that looks like a valid marker has a 0x00
inserted in the middle.
> and b) there is the
> possiblity it will not be there at all and my extraction will never
> end. I am not very versed in the ways of JPEG and any help on this
> matter will be great. I have looked over IJG's code on the subject and
> it seems rather advanced for what I am trying to do. Is there any
> simple calculations I can use to get the size of the scan or the
> distance from any unique marker to M_EOI?
If your codestream is complete, looking for the FFD9 should work.
If it's truncated, I think you need to decode till you can decode no more
(assuming I've understood your question correctly).
| |
| nozisles_2000@yahoo.com 2006-01-10, 7:55 am |
| It does appear that you have understood the question correctly. The
answer however is what I have dreaded.
Thank you for your reply.
| |
| Arne Demmers 2006-01-10, 9:55 pm |
|
> Not legally. Any image data that looks like a valid marker has a 0x00
> inserted in the middle.
>
This 0x00 you speak of is this discribed anyware in JFIF specs and/or T.81?
Because this is the first time I hear of it, but this could be the answer to
my problems. Inside IJG which file/function takes care of removing this
0x00?
Thanks in advance
Arne Demmers
| |
| Pete Fraser 2006-01-10, 9:55 pm |
| "Arne Demmers" <arne.demmers@scarlet.be> wrote in message
news:jeGdnVXmyciSUl7enZ2dnUVZ8tydnZ2d@sc
arlet.biz...
>
> This 0x00 you speak of is this discribed anyware in JFIF specs and/or
> T.81?
T.81 B.1.1.5 Entropy-coded data segments
NOTES
2 In order to ensure that a marker does not occur within an entropy-
coded segment, and 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 followed by "stuffed"
zero byte (see D.1.6 and F.1.2.3).
> Because this is the first time I hear of it, but this could be the answer
> to my problems. Inside IJG which file/function takes care of removing this
> 0x00?
I'm not familiar with the IJG code.
Sorry.
| |
| Martin Brown 2006-01-10, 9:55 pm |
| Arne Demmers wrote:
>
> This 0x00 you speak of is this discribed anyware in JFIF specs and/or T.81?
It is defined in the JPEG specification. If the Huffman encoder wants to
emit 0xFF in the compressed data stream it will always put a null byte
0x00 afterwards. This allows for fast easy scanning for JPEG markers.
> Because this is the first time I hear of it, but this could be the answer to
> my problems. Inside IJG which file/function takes care of removing this
> 0x00?
ISTR Something in the get a byte buffering.
Regards,
Martin Brown
|
|
|
|
|