Jump to content

Welcome to Geeks to Go - Register now for FREE

Need help with your computer or device? Want to learn new tech skills? You're in the right place!
Geeks to Go is a friendly community of tech experts who can solve any problem you have. Just create a free account and post your question. Our volunteers will reply quickly and guide you through the steps. Don't let tech troubles stop you. Join Geeks to Go now and get the support you need!

How it Works Create Account
Photo

JFIF Image class - Java


  • Please log in to reply

#91
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
the spec gives us the flow charts for writing most huffman code

bytes are extracted from the image header. these bytes are then used to create huffman tables.

here are some design options:

read the image bytes from the file one at a time ... decode each byte
or
store all image bytes(in an array), close the file, then decode the image bytes

huffman table data type options:
1. store bits in the huffman lookup table similar to getBits where each temp[n] represents a bit
2. you already have code for most of this one ... use BITS array along with an array with the values(which are ints in the code). a new method is required to looks up the size found in the image data, then look up the corresponding value. this new method returns a bit representation of the value. for example, if the size(in bits) is 3 and the value is 4, then the method returns 100. if the size were 4 then 0100 is returned.
3. store and process 'bits' using StringBuffer() ... don't use String()
4. it might be possible to represent the values as an int. values with a leading bit of '0' would have to be handled separately. most values, however, start with a bit value of '1'. using this approach, the new method would return an int value of 100(one hundred) for size of 3 and a value of 4.

suggestion: you might take a look at the java tutorial and see if there are any 'int to binary' conversion methods.

regardless of the data type for the image data, parsing is done one bit at a time. start with one bit from the file. see if that 'size' is in the huffman 'size' table. repeat until a valid size is found. get another bit and see if there is a valid value anywhere in the huffman 'value' table. continue one bit at a time until a valid value is found. an exception should be thrown if a valid value is not found after 16 bits are grabbed. repeat the size-value parsing until all of the image data is processed.

Edited by bdlt, 24 September 2007 - 12:31 PM.

  • 0

Advertisements


#92
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
before coding the huffman decode methods, you might want to review the page below. It's the best I've found for huffman decoding.

http://www.impulsead...man-coding.html
  • 0

#93
staticVoid

staticVoid

    Member

  • Topic Starter
  • Member
  • PipPip
  • 94 posts
Sorry for not repling in a while I've been have problems with my OS(s) and I've been working on another project.
I created a custom FileInputStream that has a readBit() method which just reads each bit of the file like the read method. It just stores a byte as a boolean[8] and passes each value when readBit() is called then when it is at the end it reads another byte and stores it in the array.
I need to revise what i've done so far then ill post back.
  • 0

#94
staticVoid

staticVoid

    Member

  • Topic Starter
  • Member
  • PipPip
  • 94 posts
Are the Quantization Tables usally in the same marker? because I keep getting the quantization table marker length to be 132 when a quantization table length is 64 and when you add the precision byte and two length bytes it is 67.
It would make sense right enough if you consider the two tables 64 + 64 add the two precision bytes for each table +2 and then add the two length bytes +2 which equals 132.
  • 0

#95
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
a 'trick' - try going backwards from the next marker

look at pages 39-40 of the spec - Lq Pq and Tq

if it's still confusing, please post the quantization values from the file

I would like to look at your huffman code - please attach a current zip file
  • 0

#96
staticVoid

staticVoid

    Member

  • Topic Starter
  • Member
  • PipPip
  • 94 posts
Heres what ive done so far, i started making the program more object orientated in renewedJPG folder and I've just put the two quantization tables in one class wheras I have a separate huffman table class for each huffman table. I can't view the spec just now because i don't have acrobat reader installed - is there any html or txt version of it?

Attached File  jpg.zip   6.72KB   538 downloads
  • 0

#97
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
I haven't found an html version of the spec.

For now, check out this page. It has a free download of JPEGSnoop.

This program extracts the quantization table, then displays it! I think you
will find this program helpful.

It also does some of the huffman parsing.

There is a lot of other good information on this site too.

http://www.impulsead...jpeg-snoop.html

note - the JPEGSnoop quantization numbers will differ from your numbers because the JPEGSnoop numbers are in zig-zag order.

Edited by bdlt, 12 October 2007 - 12:54 PM.

  • 0

#98
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
your huffman code is looking good!

HUFFCODE and HUFFVAL look accurate.

are you ready to parse some image data?

steps:

1. parse image data until the bit pattern matches a HUFFCODE bit pattern
2. there is a HUFFVAL that corresponds to the HUFFCODE
3. the HUFFVAL is the number of bits to parse and store
4. repeat until one DC value is stored along with 63 AC values

example:
DC
HUFFCODE 0 4 5 12 13 14 30 62 126
HUFFVAL 0 2 6 4 7 9 8 3 5

image data
1111 0011 0110 0110 0111

grab a bit ...
1 = 1 ... does not match any HUFFCODE patterns
11 = 3 ... does not match any HUFFCODE patterns
111 = 7 ... does not match any HUFFCODE patterns
1111 = 15 ... does not match any HUFFCODE patterns
11110 = 30 ... HUFFCODE[6] = 30
HUFFVAL[6] = 8
grab 8 more bits ... 011 0110 0
convert to int = 108 then store

repeat for 63 AC values
  • 0

#99
staticVoid

staticVoid

    Member

  • Topic Starter
  • Member
  • PipPip
  • 94 posts
why do you grab 8 more bits - I thought once you matched one huffcode you just start scanning for another huffcode and then replaced each huffcode with the adjacent huffval ? I'm currently reading the iso/iec standard - It's a lot better reference from all the other websites ive saw and after all it is the standard so if I successfully code an application for viewing jpeg's based on the standard and an image doesn't load etc. then its not going to be my application thats faulty.
Thanx for all the help by the way.

Edited by staticVoid, 03 December 2007 - 04:29 AM.

  • 0

#100
bdlt

bdlt

    Member

  • Member
  • PipPipPip
  • 876 posts
Hi staticvoid,

Let's try to clarify the huffman steps.

We start with the DC value.

Here are the first few image bits:
1111 0011 0110 0110 0111

We look at each bit one at a time until we match a value in the
DC huffcode array. After 5 bits we finally find a value that matches
a value in the DC huffcode array. It is 30(11110).

DC
HUFFCODE 0 4 5 12 13 14 30 62 126
HUFFVAL 0 2 6 4 7 9 8 3 5

We now use the index of the array which happens to be 6(starting
the count at 0).

Next we use the index(6) and grab HUFFVAL[6], which happens to be 8.

We then grab the next 8 bits, based on HUFFVAL[6] = 8.

Those 8 bits are the DC value.

grab 8 more bits ... 011 0110 0
convert to int = 108 then store

I hope this is a little more clear.

bdlt
  • 0

Advertisements







Similar Topics

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

As Featured On:

Microsoft Yahoo BBC MSN PC Magazine Washington Post HP