Introduced in 2c98eff, support for non-interleaved scans was not working
for frames with a number of MCU per line or column that is odd. Indeed,
the decoder assumed that they have scans that include a fabricated MCU
like scans with multiple components.
This patch makes the decoder handle images with a number of MCU per line
or column that is odd. To do so, as in the current decoder state we do
not know if components are interleaved at allocation time, we skip over
falsely-created macroblocks when filling them. As stated in 2c98eff,
this is probably not a good solution and a whole refactor will be
welcome.
It also comes with a test that open a square image with a side of 600px,
meaning 75 MCUs.
You can generate one by using `cjpeg` with the -scan argument.
This image has been generated with the following scan file:
0 1 2: 0 0 0 0;
0: 1 9 0 0;
2: 1 63 0 0 ;
1: 1 63 0 0 ;
0: 10 63 0 0;
This type of image isn't common, and you can probably only find one by
generating it yourself. It can be done using `cjpeg` with the -scan
argument.
This image has been generated with the following scan file:
0: 0 63 0 0;
1: 0 63 0 0;
2: 0 63 0 0;
Turns out extended-lossless-animated.webp did have a loop count of 0.
So I opened it in Hex Fiend and changed the byte at position 42
(which is the first byte of the little-endian u16 storing the loop
count) to 0x2A, so that the test can compare the loop count to something
not 0.
I drew the two webp files in Photoshop and saved them using the
"Save a Copy..." dialog, with ICC profile and all other boxes checked.
(I also tried saving with all the boxes unchecked, but it still wrote an
extended webp instead of a basic file.)
The lossless file exposed a bug: I didn't handle chunk padding
correctly before this patch.
The test verifies that loading an icc file and serializing it
again produces exactly the same output as the input. That's not
always the case, but often. It requires the input file either
not having any padding or using null bytes as padding, it
requires the input file putting tag data in the order the
tag data is referenced in in the tag table, and it requires the
input file only using known tag types (which at the moment
means it only works for v4 profiles, but that part will change
in the future).
The new file p3-v4.icc was extracted from a jpeg taken by an
iPhone Mini.
icc-v4.jpg is Meta/Websites/serenityos.org/happy/3rd/bgianf.jpg.
There are a whole bunch of jpgs with v4 color profiles and I just picked
one fairly arbitrarily. It looks like a fairly standard v4 matrix
profile that in this form is also present in many jpgs taken by mobile
phone cameras. It uses parametric curves.
icc-v2.png is based on ./Documentation/WebServer_localhost.jpg since
that is the only image in the repo with a v2 color profile. It also has
all kinds of interesting and somewhat exotic tags, such as an 'dscm' (an
Apple extension to have a description of type 'mluc', since normal
'desc' is required ot have type 'desc' in v2 files -- in v4, 'desc' has
type 'mluc') tag of type 'mluc' that actually contains data in several
languages and that exercises the non-BMP UTF-16BE decoder. It's however
still also a fairly standard v2 matrix profile, which uses 'curv'
instead of 'para' for its curves ('para' is v4-only).
I converted that jpeg file to png, and cropped most of the image
data to save on file size by running:
sips -s format png --cropToHeightWidth 21 42 in.jpg --out out.png
Rather than reading files out of /res, put them in a subfolder of
Tests/LibGfx/ and pick the path based on AK_OS_SERENITY.
That way, the tests can also pass when run under lagom.
(I just `cp`d all the files that the test previously read from
random places into Tests/LibGfx/test-inputs.)
Rather than reading files out of /res, put them in a subfolder of
Tests/LibGfx/ and pick the path based on AK_OS_SERENITY.
That way, the tests can also pass when run under lagom.
