These are written by `mutool extract` for CMYK images.
They don't contain color profiles so they're not super convenient.
But `image` can convert them (*) to sRGB as long as you use it with
`--assign-color-profile` pointing to some CMYK icc profile of your
choice.
*: Once #22922 is merged.
.pam is a "portrable arbitrarymap" as documented at
https://netpbm.sourceforge.net/doc/pam.html
It's very similar to .pbm, .pgm, and .ppm, so this uses the
PortableImageMapLoader framework. The header is slightly different,
so this has a custom header parsing function.
Also, .pam only exixts in binary form, so the ascii form support
becomes optional.
This change introduces a method for direct access to the paintable of
a PaintableFragment. This method is intended to replace the usage of
the layout node pointer. Currently, we are only eliminating the use
of `layout_node()` in hit testing.
Additionally, we no longer check if a fragment's layout node is a
`BlockContainer` before recursing into its children during hit testing.
This check was likely relevant when all fragments were owned by
`PaintableWithLines`, but now it should be safe to remove this check.
I opened Base/res/graphics/buggie.png in Photoshop, converted it
to U.S. Web Coated (SWOP) v2, flattened the image so we don't have
CMYK with alpha, and saved it as a jpeg (with color profile embedded).
It converts from a CMYKBitmap to an (rgb) bitmap, using a real
color profile.
The API design here isn't super scalable (what if we want to also
handle grayscale inputs? What if we also want to convert _to_ cmyk
or grayscale?), but we have to start somewhere. Uses of this can
inform future API improvements.
Every single of images's functions then go ahead and error out on
CMYKBitmaps for now.
(Alternatively, we could make them the low-quality CMYK->RGB
conversion that previously happened implicitly, but let's go
with this for now.)
(With this structure, we could also do something smarter for
Vector images in the future.)
Here's how this looks:
% Build/lagom/bin/image \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Can't save CMYK bitmaps yet, convert to RGB first
with --convert-to-color-profile
% Build/lagom/bin/image \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: No source color space embedded in image.
Pass one with --assign-color-profile.
% Build/lagom/bin/image \
--assign-color-profile path/to/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Psych, can't convert CMYK bitmaps yet either
As usual, serenity-sRGB.icc is from
`Build/lagom/bin/icc -n sRGB --reencode-to serenity-sRGB.icc` and
the adobe cmyk profiles are available at
https://www.adobe.com/support/downloads/iccprofiles/iccprofiles_win.html
which ultimately leads to:
https://download.adobe.com/pub/adobe/iccprofiles/win/AdobeICCProfilesCS4Win_end-user.zip
This makes it easier to move the color space conversion code out
into a helper function, and will be used to pass around CMYK bitmaps.
No behavior change.
...instead of warn() + manual return.
Before:
% Build/lagom/bin/image -o out.asdf in.png
can only write .bmp, .png, .ppm, and .qoi
Now:
% Build/lagom/bin/image -o out.asdf in.png
Runtime error: can only write .bmp, .png, .ppm, and .qoi
That doesn't look worse, and it's less code (and makes moving the
code into helper functions easier).
Before this change, it was possible for flex lines with negative
remaining space (due to overflowing items) to put a negative amount
of space between items for some values of `justify-content`.
This makes https://polar.sh/SerenityOS look much better :^)
The -p flag is equivalent to the previous behavior: outputting the
uptime in a human-readable form.
We don't seem to expose the number of online users or the load averages,
so those sections are missing from the output compared to those OSes.
This attribute has some compatbility issues...
- The spec says it should be an SVGAnimatedRect which contains
a DOMRect and a DOMReadOnlyRect.
- Blink gives you an SVGAnimatedRect with 2x SVGRect
- Gecko gives you an SVGAnimatedRect with 2x SVGRect? (nullable)
I ended up with something similar to Gecko, an SVGAnimatedRect
with 2x DOMRect? (nullable)
With this fixed, we can now load https://polar.sh/ :^)
As of commit ccd701809f, the formatter for
JsonValue now fully serializes the value. The serializer will surround
the string value with quotes. We want control over when we add quotes to
the generated Inspector HTML, so avoid formatting attributes as raw JSON
values.
This works by defining a set of weak symbols in dynamic linker whose
value would be provided by it. This has the same effect as preloading
library that magically knows right addresses of functions shared between
dynamic linker and LibC.
We were previously passing the same information by rewriting values
based on hardcoded library name, so the new approach seems a little
nicer to me.
When decoding a CMYK image and asked for a normal `frame()`, the decoder
would convert the CMYK bitmap into an RGB bitmap. Calling `cmyk_frame()`
after that point will provoke a null-dereference.
The only downside is we are limited to 4 recent projects now. LibGUI
currently relies on the number of recent files being constexpr, so that
will take some more work to make it variable.
We previously assumed that `set_most_recently_open_file()` would only be
called after `Menu::add_recent_files_list()` had been called, and would
crash if we hadn't called it yet. This stops the crash. We're fine to
do this, because we always call `update_recent_file_actions()` in
`register_recent_file_actions()` so it's guaranteed to be up to date
when we do need it.
