It's about time I have a README for this thing. I need somewhere to put
the test setup instructions, making now as good a time as any to get
around to it.
Those construction functions were setting an image size of 0x0, which is
no longer acceptable because of the iteration limiter. There is now an
extra argument for the expected pixel count.
I was thinking about doing some partial parsing where I retrieve a few
extra bytes to see if it's a footer, but that's really hard with an
iterator as an input stream.
Instead, I'm just going to count how many pixels the decoder has output
and stop iterating at that point.
Now to fix the test cases that don't have an image size assigned.
This is a full QOI file decode routine, although the image it contains
is just one single blue pixel. I've added this because I finally found
the bug I've been hunting:
I'm using `tests/codec.rs` to load reference files and decode them, but
this is resulting in data size errors. There are 32 extra bytes coming
out of the decoder -- too much for the WIDTH x HEIGHT number of pixels,
and it happens to every image.
The cause is the 8-byte end marker. It is not properly detected by the
decoder and is instead used as additional data (probably QOI_OP_INDEX).
Since the decoder emits *pixels*, each of which are 4 bytes, we have 32
bytes of garbage data coming out of the decoder.
Bug found! Now to make the test pass...
The codec library doesn't use any external dependencies. The PNG crate
is only to load some source material for testing the codec. Turning the
test driver into a real test lets me turn the PNG dependency into a
dev-dependency.
The byte count on this 800x600 32-bit image should come to 1,920,000
bytes... But it came to 1,920,032 bytes. I'm not sure where the extra
32 bytes come from, but I have to go fix it before I get to call the
decoder complete.
I've pulled in the PNG crate to write the images back out as regular
PNG images. Now I can compare the results of my decoder against the
reference images.
I also made a weird utility iterator thing to wrap the Decoder's pixel
iterator because the PNG crate wants a &[u8], not a bunch of u32's or
custom pixels structs. I should learn how to impl the right traits so
that I can just `.to_components()` on an Iterator<Item=PixelRGBA>
instead of the wrapper constructor thing I have now.
I should maybe set the properties to be private and accessible strictly
through accessor methods. That way nobody can accidentally write into
the values. Oh well, that's a thing for later.
The other magic constructors were no longer valid because of the added
struct members. The calls to `new()` have been reattached to
`new_with_no_metadata()`. Tests pass, still!
The old `Decoder::new()` method would not pull the image header out of
the iterator. This was fine for the design then, but I've just decided
that I want to collect this info and store it in the Decoder struct.
I've moved the old method down into the test module so that I can still
use it to test the decoder parts alone. Same philosophy as the
`new_with_previous_pixel()` and `new_with_backbuffer()` methods.
The qoi_header is specified as knowing the width, height, channels, and
colorspace. I figure this information would be captured by the decoder,
if anywhere. I've added more properties to the struct, and created a
new, fallible construction function.
I'm saving this to the repo so I can possibly come back and fix it up
correctly.
A major API change is going to be attempted. The iterator-based stream
processing has proven to be fiddly and annoying, so I'm going to switch
to a processing the complete image.
Wow, what a mess. Why was I making one giant file to contain everything?
I'm splitting it out into several files and taking another crack at
completing the decoder.
The previous pixel needs to be captured before the iterator is advanced.
Otherwise it's just getting the same pixel back out, and all that's
tested is the assignment operator.
The expected alpha value for the first OP_RGBA was set wrong.
The OP_LUMA was missing whole bits. SMH my head.
After changing the prev-pixel check order, the final OP_RGBA *is*
required. Include that in the expected output.
The backbuffer indices were all kinds of wrong, and there was even a
state corruption bug.
Hash values were simply done wrong. I've added some value delta notes
to the compressed byte array, and then tracked all the state changes
next to the expected indices array. The last RGBA value also needed to
be included. Off by one, oops.
The state corruption exists as a side effect of malformed OP_INDEXs.
This is actually a bigger issue, and I'll need to add a new test for it.
Basically: A pixel produced by an OP_INDEX will hash to that index.
That's the definition of an OP_INDEX. What happens if an OP_INDEX picks
up a pixel that hashes to a different index? Because an OP_INDEX is
reading from the backbuffer array without modification, it doesn't need
to write. An otherwise valid encoder can then skip the write step. This
causes a missing buffer update when the pixel should land on another
index. The decoder is now in a corrupted state.
The wrapping wasn't working properly, clearly, but I forgot about the
previous pixel entirely.
I'll add some more explicit tests for the previous pixel behavior. I
think it's still broken for RGB and RGBA, because I'm dumb.
The op codes are now being recognized properly. I just gotta decode them
the right way. I fixed an error where I was bitwise-or -ing the values
instead of bitwise-and -ing them. Small brain up in here.
The run length can simply be extracted and stored as part of the
iterator state. For each iteration, check if the length is > 0, and emit
more pixels until it isn't. Then continue the normal decode process.
I was going to try to match over the op codes, but that isn't possible.
Most of the decoders are done, too, but I'm quite sure that the delta
operations will encounter a wrap around and then panic. The OP_RUN is a
problem, as well. I think I'm going to cheat this problem by holding a
counter. This way I can see if I'm in a run, and then emit another pixel
copy until counter == 0.
I want to iterate over the input elements, and I couldn't figure out how
to get the slice lifetime to be specified properly. I've swapped the
slice for any Iterator that emits u8's.
These tests can be used to verify the fundamentals of the decoder: That
individual instructions are parsed correctly and converted back into
the correct pixel values.
