24
edits
mNo edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
== June 21st - Header parsing progress == | |||
So, I have defined some data types corresponding to the JPEG-XR headers. The jpegxr_decompress_struct now contains instances of these new structures, along with memory and error management stuff copied over from libjpeg. Next step is to fill out these fields by parsing the codestream. I intend to use the libjpeg code for INPUT_2BYTES and INPUT_BYTE for reference - though I will NOT be using an input controller as libjpeg does. | |||
Two things I wish to note: | |||
# It seems that the first big difference (from what I can tell) between decoding JPEG and JPEG-XR is the complexity of the header - JPEG barely has one whereas the XR header is quite lengthy. | |||
# For the purpose of clarity, I have decided to make a distinction between the segmentation of the codestream into header fields, and the processing of these fields to calculate decompression parameters. Header fields will probably be discarded after the second pass is complete. | |||
== June 15th - Parsing outline == | == June 15th - Parsing outline == | ||
edits