...and add a test case that shows why it's incorrect.
If one dimension is 2^n + 1 and the other side is just 1, then the
topmost node will have 2^n x 1 and 1 x 1 children. The first child will
have n levels of children. The 1 x 1 child could end immediately, or it
could require that it also has n levels of (all 1 x 1) children. The
spec isn't clear on which of the two alternatives should happen. We
currently have n levels of 1 x 1 blocks.
This test case shows that a VERIFY we had was incorrect, so remove it.
The alternative implementation is to keep the VERIFY and to add a
if (x_count == 1 && y_count == 1)
level = 0;
to the top of TagTreeNode::create(). Then we don't have multiple levels
of 1 x 1 nodes, and we need to read fewer bits.
The images in the spec suggest that all nodes should have the same
number of levels, so go with that interpretation for now. Once we can
actually decode images, we'll hopefully see which of the two
interpretations is correct.
(The removed VERIFY() is hit when decoding
Tests/LibGfx/test-inputs/jpeg2000/buggie-gray.jpf in a local branch that
has some image decoding implemented. That file contains a packet with
1x3 code-blocks, which hits this case.)
Most JPEG2000 files put the codestream in an ISOBMFF box structure
(which is useful for including metadata that's bigger than the
~65k marker segment data limit, such as large ICC profiles), but
some files just store the codestream directly, for example
https://sembiance.com/fileFormatSamples/image/jpeg2000/balloon.j2c
See https://www.iana.org/assignments/media-types/image/j2c for the
mime type.
The main motivation is to be able to use the test data in J.10 in
the spec as a test case.
These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
A tag tree is a data structure used for deserializing JPEG2000
packet headers.
We don't use them for anything yet, except from tests.
The implementation feels a bit awkward to me, but we can always polish
it later.
The spec thankfully includes two concrete examples. The code is
correct enough to pass those -- I added them as test.
For text, we always ended up with a leading \0 byte (on little-endian),
which prints as nothing. Since that's the only thing we do with this
data, no actual behavior change.
We don't do anything with this (except log the contents if
JPEG2000_DEBUG is 1).
The motivation is that we now decode all marker segments that are
used in all JPEG2000 files I've seen so far, allowing us to make
remaining unknown marker types fatal.
The halftone region decoding procedure can draw patterns completely
outside the page bitmap. I haven't seen this in practice yet (not
many files use pattern/halftone segments), but it seems like it's
possible in theory and seems like a good thing to check for.
Annex C describes how to read a grayscale bitmap with n bits per pixel:
It's encoded as n bilevel bitmaps, where each bilevel bitmap stores one
bit of the grayscale value (using a en.wikipedia.org/wiki/Gray_code,
which is named after Frank Gray and doesn't normally have much to do
with grayscale images).
A halftone region stores a grayscale bitmap and a linear coordinate
system the grayscale bitmap is in. The grayscale bitmap is overlaid
the halftone region using the coordinate system, and each sample in
the grayscale bitmap is used as an index into a pattern dictionary
and the bitmap at that index is drawn at the current location.
This allows for efficient compression of ordered dithering
(but not error-diffusion dithering).
This does not yet implement halftone region decoding for MMR bitmaps.
The halftone region decoding procedure is the only way to call the
generic region decoding procedure with a skip pattern. This does
include code to compute the skip pattern, but support for that
is not yet implemented in the generic region decoding procedure,
so it'll error out when encountered. (I haven't yet found a file
using this feature, not a way to create such a file yet.)
A pattern dictionary stores n bitmaps with the same dimensions w x h.
They're stored in a single bitmap of width `n * w` that's then cut
into n stripes.
The implementation is very similar to #23831.
I created the test exactly like in #23713, except that I replaced the
last four lines in the ini file with:
```
-txt -Param -rATX1 10
-txt -Param -rATY1 -1
-txt -Param -rATX2 4
-txt -Param -rATY2 15
```
...in the generic region decoding procedure (not yet in the generic
refinement region procedure). Not yet for EXTTEMPLATE though.
I haven't seen these being used in the wild, but:
* I want to optimize this code some, and it's probably good if it
is feature complete (and well-tested) before being optimized
* Other PDF engines implement support for this
* The Pattern/Halftone feature (which we don't yet implement either,
but which I'd like to implement because see previous two bullets)
calls the generic region decoding procedure with custom adaptive
template pixels
Only the coordinates get transposed -- the bitmaps apparently don't.
And all the prose amounts to "if the transposed bit is set, swap
instance s and t coordinates before painting", as far as I can tell.
Makes pages 3/4 and 7/8 in 0001346.pdf render. (But here the feature
isn't used to render transposed text -- it just has stripes that keep s
roughy constant, which would normally produce vertical runs but here
produces regular horizontal runs. It's not clear to me why this feature
is used for these pages!)
