By default, JPEGs use YCbCr to encode colors however other encoding
exist. This patch adds the logic to determine which transformation is
needed and support for RGB encoded JPEGs :^).
This half-standardized application specific segment is used for color
transform information. It means that the decoder is know informed if the
image uses YCbCr, RGB, CMYK or even YCCK.
Calling it was harmless as add_ac iterates over the spectral selection,
hence it won't do anything if not needed. However, this patch remains
useful as it prevents dereferencing the iterator returned by find, in
case the AC table isn't defined yet. This case happens with SOF2 images
and is (pretty harmless as read only but still) undefined behavior.
This patch brings support for SOF2 JPEGs that only use spectral
selection :^)
We still don't have achieved full support for SOF2 images, but as an
example, we decode progressive JPEG from Cloudinary.
Scan with only one component are by definition not interleaved, meaning
that each value is linearly ordered in the stream. Grayscale images
were supported thanks to a hack, by forcing the subsampling to 1.
Now we properly support grayscale image with other subsampling (even if
it doesn't make sense) and more generally scans with only one component
and any sampling factors.
While this solution is more general than the last one it also feels a
bit hackish. We should probably refactor the way we iterate over
components and macroblocks. But that's work for latter, especially when
we will add support for other subsampling than 4-2-2.
Huffman streams are encountered in the scan segment. They have nothing
to do outside this segment, hence they shouldn't outlive the scan.
Please note that this patch changes behavior. The stream is now reset
after each scan.
A scan can contain fewer components that the full image. However, if
there is multiple components, they have to follow the ordering of the
frame header. It means that we can loop over components of the image
and skip those that doesn't correspond.
For now, we exit after the first scan without needing to parse `EOI`.
However, to read scans in a loop we will need to properly detect and
parse `EOI`.
This patch brings us closer to the spec point of view. And while it
makes no functional changes, it reduces the number of places where you
can misuse scan-specific data and improve support for multiple scans.
Nobody made use of the ErrorOr return value and it just added more
chance of confusion, since it was not clear if failing to sniff an
image should return an error or false. The answer was false, if you
returned Error you'd crash the ImageDecoder.
In other words: only consider coefficient of the current scan when
adding coefficients to a macroblock. Information about which
coefficients are present in the stream are passed through the spectral
information in the context.
In progressive mode, this functions will need to be called multiple time
on the same macroblocks, so it shouldn't create the vector every
time it's called.
This means that we should read markers in a loop instead of quiting on
the first scan. This is useless for now as `SOF0` frames only have one
scan, but this is a step forward `SOF2` support.
As a JPEG file can contain multiples scans, we should return from
`scan_huffman_stream` on all new markers (except restart markers) and
not only `JPEG_EOI`.
Miscellaneous and tables segments can also be placed between scans,
placing this code in a function will allow us to avoid duplication when
we get there.
Rename "reset_marker" to "restart_marker" as described by the spec. It
also concerns disambiguate the situation as the DRI was also called a
reset marker.
Restart markers are supposed to be applied every restart interval.
However, in these loops macroblocks are counted taking the luma sampling
factor into consideration. Meaning that we need to correct this factor
when testing if we should reset the DC.
Also, the decoder was discarding the first byte of every scan with a set
restart interval, as `0 % n == 0` is always true.
The patch also contains modifications on several classes, functions or
files that are related to the `JPGLoader`.
Renaming include:
- JPGLoader{.h, .cpp}
- JPGImageDecoderPlugin
- JPGLoadingContext
- JPG_DEBUG
- decode_jpg
- FuzzJPGLoader.cpp
- Few string literals or texts
2023-02-18 23:56:24 +01:00
Renamed from Userland/Libraries/LibGfx/JPGLoader.cpp (Browse further)
