beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-21 15:10:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Utilities/animation.cpp

71 lines
2.7 KiB
C++
Raw Normal View History

LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
/*
* Copyright (c) 2024, Nico Weber <thakis@chromium.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibCore/ArgsParser.h>
#include <LibCore/File.h>
#include <LibCore/MappedFile.h>
LibGfx: Move AnimationWriter to its own file No behavior change.
2024-05-11 23:53:38 +00:00
#include <LibGfx/ImageFormats/AnimationWriter.h>
LibGfx+animation: Support writing animated GIF files
2024-05-19 00:26:48 +00:00
#include <LibGfx/ImageFormats/GIFWriter.h>
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
#include <LibGfx/ImageFormats/ImageDecoder.h>
#include <LibGfx/ImageFormats/WebPWriter.h>
struct Options {
StringView in_path;
StringView out_path;
LibGfx+animation: Only store changed pixels in animation frames For example, for 7z7c.gif, we now store one 500x500 frame and then a 94x78 frame at (196, 208) and a 91x78 frame at (198, 208). This reduces how much data we have to store. We currently store all pixels in the rect with changed pixels. We could in the future store pixels that are equal in that rect as transparent pixels. When inputs are gif files, this would guaranteee that new frames only have at most 256 distinct colors (since GIFs require that), which would help a future color indexing transform. For now, we don't do that though. The API I'm adding here is a bit ugly: * WebPs can only store x/y offsets that are a multiple of 2. This currently leaks into the AnimationWriter base class. (Since we potentially have to make a webp frame 1 pixel wider and higher due to this, it's possible to have a frame that has <= 256 colors in a gif input but > 256 colors in the webp, if we do the technique above.) * Every client writing animations has to have logic to track previous frames, decide which of the two functions to call, etc. This also adds an opt-out flag to `animation`, because: 1. Some clients apparently assume the size of the last VP8L chunk is the size of the image (see https://github.com/discord/lilliput/issues/159). 2. Having incremental frames is good for filesize and for playing the animation start-to-end, but it makes it hard to extract arbitrary frames (have to extract all frames from start to target frame) -- but this is mean tto be a delivery codec, not an editing codec. It's also more vulnerable to corrupted bytes in the middle of the file -- but transport protocols are good these days. (It'd also be an idea to write a full frame every N frames.) For https://giphy.com/gifs/XT9HMdwmpHqqOu1f1a (an 184K gif), output webp size goes from 21M to 11M. For 7z7c.gif (an 11K gif), output webp size goes from 2.1M to 775K. (The webp image data still isn't compressed at all.)
2024-05-12 00:23:41 +00:00
bool write_full_frames { false };
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
};
static ErrorOr<Options> parse_options(Main::Arguments arguments)
{
Options options;
Core::ArgsParser args_parser;
args_parser.add_positional_argument(options.in_path, "Path to input image file", "FILE");
args_parser.add_option(options.out_path, "Path to output image file", "output", 'o', "FILE");
LibGfx+animation: Only store changed pixels in animation frames For example, for 7z7c.gif, we now store one 500x500 frame and then a 94x78 frame at (196, 208) and a 91x78 frame at (198, 208). This reduces how much data we have to store. We currently store all pixels in the rect with changed pixels. We could in the future store pixels that are equal in that rect as transparent pixels. When inputs are gif files, this would guaranteee that new frames only have at most 256 distinct colors (since GIFs require that), which would help a future color indexing transform. For now, we don't do that though. The API I'm adding here is a bit ugly: * WebPs can only store x/y offsets that are a multiple of 2. This currently leaks into the AnimationWriter base class. (Since we potentially have to make a webp frame 1 pixel wider and higher due to this, it's possible to have a frame that has <= 256 colors in a gif input but > 256 colors in the webp, if we do the technique above.) * Every client writing animations has to have logic to track previous frames, decide which of the two functions to call, etc. This also adds an opt-out flag to `animation`, because: 1. Some clients apparently assume the size of the last VP8L chunk is the size of the image (see https://github.com/discord/lilliput/issues/159). 2. Having incremental frames is good for filesize and for playing the animation start-to-end, but it makes it hard to extract arbitrary frames (have to extract all frames from start to target frame) -- but this is mean tto be a delivery codec, not an editing codec. It's also more vulnerable to corrupted bytes in the middle of the file -- but transport protocols are good these days. (It'd also be an idea to write a full frame every N frames.) For https://giphy.com/gifs/XT9HMdwmpHqqOu1f1a (an 184K gif), output webp size goes from 21M to 11M. For 7z7c.gif (an 11K gif), output webp size goes from 2.1M to 775K. (The webp image data still isn't compressed at all.)
2024-05-12 00:23:41 +00:00
args_parser.add_option(options.write_full_frames, "Do not store incremental frames. Produces larger files.", "write-full-frames");
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
args_parser.parse(arguments);
if (options.out_path.is_empty())
Everywhere: Convert from_string_view -> from_string_literal where static
2024-09-05 11:06:15 +00:00
return Error::from_string_literal("-o is required ");
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
return options;
}
ErrorOr<int> serenity_main(Main::Arguments arguments)
{
Options options = TRY(parse_options(arguments));
// FIXME: Allow multiple single frames as input too, and allow manually setting their duration.
auto file = TRY(Core::MappedFile::map(options.in_path));
auto decoder = TRY(Gfx::ImageDecoder::try_create_for_raw_bytes(file->bytes()));
if (!decoder)
Everywhere: Convert from_string_view -> from_string_literal where static
2024-09-05 11:06:15 +00:00
return Error::from_string_literal("Could not find decoder for input file");
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
auto output_file = TRY(Core::File::open(options.out_path, Core::File::OpenMode::Write));
auto output_stream = TRY(Core::OutputBufferedFile::create(move(output_file)));
LibGfx+animation: Support writing animated GIF files
2024-05-19 00:26:48 +00:00
auto animation_writer = TRY([&]() -> ErrorOr<NonnullOwnPtr<Gfx::AnimationWriter>> {
if (options.out_path.ends_with(".webp"sv))
return Gfx::WebPWriter::start_encoding_animation(*output_stream, decoder->size(), decoder->loop_count());
if (options.out_path.ends_with(".gif"sv))
LibGfx/GIF: Write the netscape extension block This allows us to encode the required number of loops in the file.
2024-05-19 01:05:33 +00:00
return Gfx::GIFWriter::start_encoding_animation(*output_stream, decoder->size(), decoder->loop_count());
LibGfx+animation: Support writing animated GIF files
2024-05-19 00:26:48 +00:00
return Error::from_string_literal("Unable to find a encoder for the requested extension.");
}());
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
LibGfx+animation: Only store changed pixels in animation frames For example, for 7z7c.gif, we now store one 500x500 frame and then a 94x78 frame at (196, 208) and a 91x78 frame at (198, 208). This reduces how much data we have to store. We currently store all pixels in the rect with changed pixels. We could in the future store pixels that are equal in that rect as transparent pixels. When inputs are gif files, this would guaranteee that new frames only have at most 256 distinct colors (since GIFs require that), which would help a future color indexing transform. For now, we don't do that though. The API I'm adding here is a bit ugly: * WebPs can only store x/y offsets that are a multiple of 2. This currently leaks into the AnimationWriter base class. (Since we potentially have to make a webp frame 1 pixel wider and higher due to this, it's possible to have a frame that has <= 256 colors in a gif input but > 256 colors in the webp, if we do the technique above.) * Every client writing animations has to have logic to track previous frames, decide which of the two functions to call, etc. This also adds an opt-out flag to `animation`, because: 1. Some clients apparently assume the size of the last VP8L chunk is the size of the image (see https://github.com/discord/lilliput/issues/159). 2. Having incremental frames is good for filesize and for playing the animation start-to-end, but it makes it hard to extract arbitrary frames (have to extract all frames from start to target frame) -- but this is mean tto be a delivery codec, not an editing codec. It's also more vulnerable to corrupted bytes in the middle of the file -- but transport protocols are good these days. (It'd also be an idea to write a full frame every N frames.) For https://giphy.com/gifs/XT9HMdwmpHqqOu1f1a (an 184K gif), output webp size goes from 21M to 11M. For 7z7c.gif (an 11K gif), output webp size goes from 2.1M to 775K. (The webp image data still isn't compressed at all.)
2024-05-12 00:23:41 +00:00
RefPtr<Gfx::Bitmap> last_frame;
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
for (size_t i = 0; i < decoder->frame_count(); ++i) {
auto frame = TRY(decoder->frame(i));
LibGfx+animation: Only store changed pixels in animation frames For example, for 7z7c.gif, we now store one 500x500 frame and then a 94x78 frame at (196, 208) and a 91x78 frame at (198, 208). This reduces how much data we have to store. We currently store all pixels in the rect with changed pixels. We could in the future store pixels that are equal in that rect as transparent pixels. When inputs are gif files, this would guaranteee that new frames only have at most 256 distinct colors (since GIFs require that), which would help a future color indexing transform. For now, we don't do that though. The API I'm adding here is a bit ugly: * WebPs can only store x/y offsets that are a multiple of 2. This currently leaks into the AnimationWriter base class. (Since we potentially have to make a webp frame 1 pixel wider and higher due to this, it's possible to have a frame that has <= 256 colors in a gif input but > 256 colors in the webp, if we do the technique above.) * Every client writing animations has to have logic to track previous frames, decide which of the two functions to call, etc. This also adds an opt-out flag to `animation`, because: 1. Some clients apparently assume the size of the last VP8L chunk is the size of the image (see https://github.com/discord/lilliput/issues/159). 2. Having incremental frames is good for filesize and for playing the animation start-to-end, but it makes it hard to extract arbitrary frames (have to extract all frames from start to target frame) -- but this is mean tto be a delivery codec, not an editing codec. It's also more vulnerable to corrupted bytes in the middle of the file -- but transport protocols are good these days. (It'd also be an idea to write a full frame every N frames.) For https://giphy.com/gifs/XT9HMdwmpHqqOu1f1a (an 184K gif), output webp size goes from 21M to 11M. For 7z7c.gif (an 11K gif), output webp size goes from 2.1M to 775K. (The webp image data still isn't compressed at all.)
2024-05-12 00:23:41 +00:00
if (options.write_full_frames) {
TRY(animation_writer->add_frame(*frame.image, frame.duration));
} else {
TRY(animation_writer->add_frame_relative_to_last_frame(*frame.image, frame.duration, last_frame));
last_frame = frame.image;
}
LibGfx+Utilities: Add `animation` utility, make it write animated webps The high-level design is that we have a static method on WebPWriter that returns an AnimationWriter object. AnimationWriter has a virtual method for writing individual frames. This allows streaming animations to disk, without having to buffer up the entire animation in memory first. The semantics of this function, add_frame(), are that data is flushed to disk every time the function is called, so that no explicit `close()` method is needed. For some formats that store animation length at the start of the file, including WebP, this means that this needs to write to a SeekableStream, so that add_frame() can seek to the start and update the size when a frame is written. This design should work for GIF and APNG writing as well. We can move AnimationWriter to a new header if we add writers for these. Currently, `animation` can read any animated image format we can read (apng, gif, webp) and convert it to an animated webp file. The written animated webp file is not compressed whatsoever, so this creates large output files at the moment.
2024-05-06 21:44:57 +00:00
}
return 0;
}
Reference in a new issue Copy permalink