User:Chris48/Progress Report

August 9th - Slight refactor

I was getting lots of segmentation faults due to referencing the stack. This has been fixed, along with a slight adjustment to my approach. Codestreams are now parsed into a header structure, which is statically allocated. Global decompression variables are calculated from this, during parsing, dynamically allocated and saved to the decompression object to be used later for the decompression stage.

Currently the adaptive MB and tile parameters need to be parsed before actual decompression can be begin.

July 25th - Parsing semi-complete

Parsing is now (roughly) complete up to the coded tiles syntax elements. Tile and macroblock layer metadata still needs to be extracted.

The image contains profile and level information which determines the content of the image. Images may conform to one of the following profiles:

• Sub-baseline
• Baseline
• Main
• Advanced

These offer a good set of milestones to now aim for. In particular, it would be good if at least a sub-baseline image could be decoded before the end of the project.

July 20th - QP sets

Quantisation parameters sets can now be read. This required creating a read macro for reading single bits at a time, called INPUT_BITS, and also a macro INPUT_ALIGN to skip back to the end of the byte.

I have also further modified the interface, the amendments have been added to the previous entry.

July 15th - Error messages

I'm now using the macros in jerror.c to output trace and error messages. I've also added some indentation, which I may remove eventually, just to make the trace a little clearer.

In particular, I'm tracing at what offset in the stream key milestones occur and trying to check for any reserved values, or values that denote non-conformance or a future specification.

July 4th - Interface changes

Naming has begun to get a bit confusing, even for me, so I have decided to make some changes to the library interface that reflect the differences between JPEG and JPEG-XR. Decompression (actually so far only reading headers and metadata) will now performed by the following routines:

File layer

• jpegxr_file_read_header(finfo) - reads the file header at the start of a data source stream.

• jpegxr_file_read_metadata(finfo) - reads the file header, then continues to read any directory (and image) metadata from the rest of the data source stream.

Directory layer

• jpegxr_dir_read_header(dinfo) - reads the directory header and any IFD entry values.

• jpegxr_dir_read_metadata_(dinfo) - reads the directory header and IFD entry values and then continues to read any image headers for images associated with that directory.

Image layer

• jpegxr_image_read_metadata(iinfo) - reads metadata from the codestream, including tile and MB layer info. Essentially performs the parsing process as its called in the specification.

July 3rd - Input source modifications

I have modified jdatasrc.c to keep track of the current offset from the start of the file. This has allowed me to add a seek function, which is useful since offsets in header fields are normally specified from the point. I can also seek backwards provided I don't seek outside the current input buffer.

I have also split the decompression object into three types - file, directory and image. A file object contains a list of directory objects, each of which contain one or two (or possibly more, currently uncertain) image objects. My justification - I still want to be able to decode a standalone image or directory as well as a file. Currently composited images will use a pointer to their parent's source and error managers, but their own memory manager. This seems to be working for now, but probably will need more thought.

The specification gives a lot of detail on the file and image formats which is not present in the sample .jxr files. I am therefore going to move on since parsing image and tile layer data should have been complete weeks ago.

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:

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

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

First goal is to just parse an XR header correctly. This involves (adapted from libjpeg):

1. Allocating and initialising decompression object.
2. Assigning an error manager.
3. Specifying a source.
4. Reading the header.
5. Verifying header was parsed correctly.
6. Aborting compression.

First I adapted djpeg-xr to abort early - later when actually decompressing I will probably pull some code back in. For now, steps 2 and 3 are exactly the same. The rest of the process is also the same, except for the following alterations:

• jpeg_decompress_struct is replaced by an XR specific copy, in jpeglib.h.
• jpeg_create_decompress is replaced by an XR specific copy, in jdapimin.c.
• jpeg_read_header is replaced by an XR specific copy, in jdapimin.c.
• jpeg_destroy_decompress is replaced by an XR specific copy, in jcomapi.c.

This is done by creating XR specific copies of the source files:

• jpegxrlib.h - interface definition.
• jxrdapimin.c - interface routines for decompression (minimal required, more in jdapistd.c).
• jxrcomapi.c - interface routines common to both compression and decompression.

Note that even though this is a decompression library, I keep the distinction between algorithms and data types for "compression", "decompression" and "common to both". Why? I figure I might as well - maybe one day someone will want to adapt the library for encoding, and either way its roughly the same effort on my part.

Again my approach is to first build a duplicate, independent copy that can decode a JPEG. Next step, however, is to rewrite jpegxrlib.h pretty much from scratch, based exactly on the specification.

June 14th - Initial clone of libjpeg

My starting point is a copy of the libjpeg library. Thus far, the following have been stripped out:

• Makefiles of the form "makefile.unix" which appear to be from before the build process was upgraded.
• Image test files.
• Change logs and a few other pieces of documentation no longer relevant.

At some point a lot more needs to be removed, but I will wait till the project is a little further on since I'm not sure right now what will or won't be needed.

I have also made the following additions/modifications:

• Separated source, build and documentation files.
• Added a clone of djpeg, called djpeg-xr, in to the build process, with its own man page.
• Added a script cleanup.sh to undo the action of autogen.sh, for debugging purposes.

Right now I can run autogen.py, build and install from the build directory. Running the included tests with djpeg-xr instead of djpeg seems to work as expected. Next step is to modify djpeg-xr to perform parsing of JPEG XR headers.