You can now run
image -o out.png Tests/LibGfx/test-inputs/bmp/bitmap.bmp \
--crop 130,86,108,114
and end up with the nose part of that image in out.png.
...from try_create_for_raw_bytes().
If a plugin returns `true` from sniff but then fails when calling
its `create()` method, we now no longer swallow that error.
Allows `image` (and other places in the system) to print a more
actionable error if early image headers are invalid.
(We now no longer try to find another plugin that can also handle
the image.)
Fixes a regression from #20063 / #19893 -- before then, we didn't
do fallible work this early.
This is useful for working with CMYK jpegs extracted from PDFs
by mutool. CMYK channels for jpegs in PDFs are inverted compared to
CMYK channels in standalone jpegs (!), and mutool doesn't compensate
for that.
You can now do:
mutool extract ~/Downloads/0000/0000711.pdf 461
Followed by:
Build/lagom/bin/image -o out.png \
--invert-cmyk \
--assign-color-profile \
Build/lagom/Root/res/icc/Adobe/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
cmyk.jpg
Doesn't exactly roll off the keyboard, but at least it's possible.
(We should probably add an implicit default CMYK color profile if
the input file doesn't have one, and assume conversion to sRGB when
saving to a format that can only store RGB.)
These were here due to the prefix-less name conflicting with a local
bool, but now that options are in a struct that's no longer a problem.
No behavior change.
`image` can't transform from RGB to CMYK yet, so the only way to
do this is by having a CMYK input.
For example, this works now (and it does a full decode and re-encode):
Build/lagom/bin/image -o out.jpg \
Tests/LibGfx/test-inputs/jpg/buggie-cmyk.jpg
Using this to convert `.pam` files written by `mutool extract`
to jpegs is a somewhat convenient method of looking at these
.pam files.
Previously `image -o foo.asdf foo.png` would create a 0-byte foo.asdf
before complaining that it doesn't know how to write .asdf images.
(Lifetimes of temporaries are extended to the end of the full
expresion, so this is fine.)
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).
Since it will become a stream in a little bit, it should behave like all
non-trivial stream classes, who are not primarily intended to have
shared ownership to make closing behavior more predictable. Across all
uses of MappedFile, there is only one use case of shared mapped files in
LibVideo, which now uses the thin SharedMappedFile wrapper.
I didn't put this as a method on Bitmap since it doesn't seem generally
useful. Easy to move the impl over to Bitmap in the future if we want
to use it elsewhere.
This is useful for timing just decoder performance.
(It'd be nice to add a `-t` flag that prints timings for all
the different phases, but for now just disabling writing is
sufficient for me.)
As we directly write to the stream, we don't need to store a copy of the
entire image in memory. However, writing to a stream is heavier on the
CPU than to a ByteBuffer. This commit unfortunately makes `add_pixels`
two times slower.
For now, only for color spaces that are supported by Profile::to_pcs()
and Profile::from_pcs(), which currently means that all matrix profiles
(but not LUT profiles) in the source color space work, and that
matrix profiles with parametric curves in the destination color
space work.
This adds Profile::convert_image(Bitmap, source_profile), and
adds a `--convert-to-color-profile file.icc` flag to `image`.
It only takes a file path, so to use it with the built-in
sRGB profile, you have to write it to a file first:
% Build/lagom/icc -n sRGB --reencode-to serenity-sRGB.icc
`image` by default writes the source image's color profile
to the output image, and most image viewers display images
looking at the profile.
For example, take `Seven_Coloured_Pencils_(rg-switch_sRGB).jpg`
from https://commons.wikimedia.org/wiki/User:Colin/BrowserTest.
It looks normal in image viewers because they apply the unusual
profile embedded in the profile. But if you run
% Build/lagom/image -o huh.png --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
and then look at huh.png, you can see how the image's colors
look like when interpreted as sRGB (which is the color space
PNG data is in if the PNG doesn't store an embedded profile).
If you now run
% Build/lagom/image -o wow.png \
--convert-to-color-profile serenity-sRGB.icc --strip-color-profile \
'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
this will convert that image to sRGB, but then not write
the profile to the output image (verify with `Build/lagom/icc wow.png`).
It will look correct in image viewers, since they display PNGs without
an embedded color profile as sRGB.
(This works because 'Seven_Coloured_Pencils_(rg-switch_sRGB).jpeg'
contains a matrix profile, and Serenity's built-in sRGB profile
uses a matrix profile with a parametric curve.)
If the input file didn't exist at all, the TRY(MappedFile::map())
gives us a (cryptic) error message, but if it existed but wasn't an
image file, we would crash. Now we print a message instead.
This allows assigning a color profile from a .icc file to the output.
No pixel data conversion is taking place: the output will just contain
this profile, so it better matches the image data already.
This probably does strange things for CMYK jpegs, since JPEGLoader
converts those from CMYK to RGB but the ICC profile is still an CMYK
profile. The Right Fix for that is probably for JPEGLoader to consume
the profile when it does CMYK->RGB conversion and then not hand out
the profile data. (Or we could add a CMYK bitmap type.)
But most of the time, this is a progression :^)
