-
Notifications
You must be signed in to change notification settings - Fork 317
plugins/gimp: Support for decoding animations #1863
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Test file: Follows up to work done by @xiota and others. |
|
Thanks a lot for the contribution, @ctrlcctrlv! I tested plugin with an animation from our conformace repo animation_icos4d/input.jxl Looking forward to a pull request for encoding animation, like you propose in #1864, if you come around doing that. |
|
I fixed the failing authors check and linting https://github.com/libjxl/libjxl/actions/runs/3392132321/jobs/5643700386, taking the name from the commit. |
sboukortt
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks!
|
I apologize for the offensive image originally used. It was an art project, and I wasn't aware there was an existing animation I could use as a test. |
|
Besides handling review comments, 21adf35 handles blend modes equivalently to how it is done in the GIF loading plugin. Therefore, it is possible to export directly as GIF (and WebP!) now. #!/bin/bash
anim_dump -folder /tmp/webp -tiff input.webp && \
ffmpeg -f tiff -f lavfi -i "color=white" -i /tmp/webp/dump_%04d.tiff -c:v h264_nvenc -r 30 -qp 0 \
-pix_fmt yuv420p -filter_complex "scale2ref,overlay=shortest=1,setsar=1,scale=max(320\,iw):-1" -y \
/tmp/webp.mp4webp.mp4 |
efd4823 to
97a1ca9
Compare
f150585 to
b81ff91
Compare
|
Thanks for being so careful @alistair7. It was working for me with my test files because they all had the same denominator/numerator. My original commit (f150585) didn't quite fix it, it only fixed it for your files and not mine, so I based b81ff91 on That's 7z a -v24M /tmp/Wikipedia.jxl.7z.00 /tmp/Wikipedia.jxl
zip -Z store /tmp/Wikipedia.jxl.7z.001.zip /tmp/Wikipedia.jxl.7z.00.001
zip -Z store /tmp/Wikipedia.jxl.7z.002.zip /tmp/Wikipedia.jxl.7z.00.002 |
|
No problem. Nice work! |
|
78d0a94 omits frames of zero duration, which shouldn't cause issues, but did indeed cause flickering in GIMP's animation playback function. There are no more blank frames in |
|
I noticed that there was |
|
Sorry @mo271 but I feel like I need the coalescing. It makes the output much more useful to actually edit, especially for my original example, Russian Propaganda.jxl. |
When you say "I need the coalescing" do you mean "I need set coalescing to be true" or "I need set coalescing to be false"? I checked and it seems that the two frames in that image work exactly as intended with the coalescing set to be true, which is what is done in main...mo271:libjxl:coalescing_gimp. In what way does it make the output more useful to actually edit? (I'm not sure I'm understanding this correctly...) |
|
Sounds like they're saying that they want the separate layers to remain separate so they can be treated as layers in GIMP. |
Even with coalescing set to true, each frame in the animation will be separate layers in GIMP. Not sure what is going on with the empty frames of duration zero when we turn off coalescing, perhaps GIMP can't handle properly frames of different dimensions. Will open a bug for further understand of what is going on. |
Yes, but with the entire background. Not as easy to edit at all. |
|
Another complication with having coalescing disabled is that a frame's I don't know the best approach to dealing with this (if at all). I guess at worst, you could consider throwing an error if we find a frame where Or would it make any sense for the plugin to try decoding without coalescing, but on finding any non-trivial blending, reset the decoder and try again with coalescing enabled? Maybe that's overcomplicating it... |
|
I think this points to a gap in our current API, since there are currently only two options:
What would be useful here is an option to merge the zero-duration frames but not to blend the nonzero-duration frames, i.e. return only nonzero-duration frames but still have them as they are before blending and making them canvas-sized. The question is if this can even be done in general, since jxl's frame blending model is not simply a linear stack where every next frame is "on top" of the one before, but frame blending can take other "source frames" than the usual one that is the current canvas state. This model is strictly richer than what can be expressed in GIF/APNG and in Gimp layers, so in the general case there is no way to map a jxl frame sequence to that. For the specific case of transcoded GIF/APNG/AWebP though, there should be a way to map the jxl frame sequence to a suitable Gimp layer stack. I suspect the dummy empty frames cjxl generates are just a way to circumvent the lack of dispose modes in jxl, or something like that. |
|
Not related to this, but another coalescing mode that would be good to have for animation display, is one where the returned frames are blended but only the crop box containing modified pixels gets returned (so it only returns kReplace frames like the default coalescing, but not necessarily canvas-sized ones). This has obvious advantages in terms of buffer sizes and would allow e.g. browsers to have a higher likelihood of being able to keep the entire animation in memory. So I think we basically need one boolean setting to indicate whether zero-duration frames should be blended or not, and another boolean setting to indicate whether cropped frames should be returned or canvas-sized ones. We currently only have an option where it is (true,false) (the default coalescing==true) and another where it is (false,true) (this is what coalescing==false does). And then we need to find a way for dealing with exotic blend source choices; probably this is something most applications will not want to deal with so it's probably best if by default anything that is not a simple "stack of layers" gets converted in something that is (we can always do the blending and turn anything into a kReplace frame that overwrites the whole canvas), and only when some new option is set, you can get the original thing which may be quite exotic. |
|
So how to best proceed here?
The problem for 2. and 3. is that there will be animated jxl files that blend source will not be the previous frame, which gimp cannot seemt to handle, like @alistair7 pointed out. Might it be possible to make the user select an option during the opening of a file, if there are frames of duration 0? I think right now the cleanest approach would be 1., because it seems to work in all cases, however I can see that it would be nicer if the structure of the layers would be preserved. Really great that you implemented the decoding (and encoding!) of animated JXLs in the gimp plugin, @ctrlcctrlv, showing that the API with respect to coalescing can possibly be improved. The source of the problem comes from the fact that jxl is more with frames and layers than gimp... Would the problem with solution 2. other than the problem with further-back-reference, be that flickering in GIMP's animation playback function? Perhaps one could get that resolved in GIMP somehow. |
|
Zero-duration frames in Gimp will not only be an issue for its own playback, but it will be even worse if you then save it as GIF/APNG/WebP where typical players impose a minimum duration per frame because of legacy content that relies on that. |
|
I think wrong assumptions about GIMP's blending modes are being made. GIMP has many blending modes. I just didn't implement this because the plugin as it existed before my patches was already so incomplete I viewed my patchset(s) as incremental improvements, but it seems that I'm being held to a higher standard than the original patches. In any event, GIMP has plenty of support. But, the API issue remains, because GIMP is not the only editor out there. And, as @jonsneyers correctly notes, in other formats there's a minimum delay, so the Coalescing API needs fixed anyway. |
|
I agree; I think having the ability to decode at least some (not too exotic) animations is clearly an improvement over the current state of the gimp plugin. Do you prefer to get the version in c28e358 (with the hack to remove 0 duration frames in gimp, while setting coalescing to false) or the versio in |
|
Coalescing frames has the disadvantage that going gif -> jxl -> gif will potentially produce a way larger gif, when the original had many frames that update only a small area. Then again I think Gimp does have an "optimize for gif" thing that can trim the frames again. So if we want to get something that works in all cases first and make it better later, then coalescing=true is the way to go for now, I think. But we should expand the api to get a way to avoid coalescing while not returning exotic blend sources/modes — i.e. have a way to select which blend modes you want to keep in output and which ones you want libjxl to convert to kReplace, and also have a way to get only "blend source for current frame is current canvas state". This would be useful in browsers/viewers (to save memory and repaint by avoiding all frames to be full canvas sized), where you would want to get only kReplace, and also for Gimp, where you want to get both kReplace and kBlend. For animations, merging zero-duration frames makes sense, but for layered images, keeping them as seperate layers makes more sense. So I think this is an orthogonal thing that should be configurable. For this plugin, it would make sense to merge zero-duration frames iff it is an animation, and to keep them as separate layers if it is a layered still image. The case of animations with layered frames is not something Gimp can currently handle and it is not something that will exist in the wild since there are no existing formats that can do that, or authoring tools that produce them, so merging the layers within each frame is OK in this case. |
|
I'm OK with coalescing=true for now. Users of the GIF format already are well aware of its many shortcomings and know that they may have to use e.g. IM with |
c28e358 to
e627778
Compare
|
Many thanks again, @ctrlcctrlv! |
|
My pleasure :o) |
* Add first version of streaming JPEG decoder. Benchmark before: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------------ jpeg:q90 13270 4838710 2.9169834 63.705 161.410 2.40070152 0.68663652 2.002907346396 0 jpeg:q90:djxl8 13270 4838710 2.9169834 63.213 112.574 2.17603183 0.62092407 1.811225220808 0 jpeg:q90:djxl16 13270 4838710 2.9169834 63.008 109.120 2.16807723 0.61567343 1.795909190468 0 jpeg:yuv420:q90 13270 3660915 2.2069577 93.729 238.752 6.07282543 0.95039908 2.097490592679 0 jpeg:yuv420:q90:djxl8 13270 3660915 2.2069577 93.761 156.263 6.05725956 0.91959307 2.029503031911 0 jpeg:yuv420:q90:djxl16 13270 3660915 2.2069577 95.847 152.478 6.05378914 0.91638444 2.022421724515 0 jpeg:libjxl 13270 3197015 1.9272988 18.429 99.632 2.19571280 0.70762796 1.363810502985 0 jpeg:libjxl:djxl8 13270 3197015 1.9272988 18.652 86.314 2.25490046 0.70510193 1.358942071174 0 jpeg:libjxl:djxl16 13270 3197015 1.9272988 18.639 84.488 2.29413509 0.69006634 1.329964006217 0 ``` Benchmark after: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------------ jpeg:q90 13270 4838710 2.9169834 64.733 166.560 2.40070152 0.68663652 2.002907346396 0 jpeg:q90:djxl8 13270 4838710 2.9169834 63.666 105.345 2.17603183 0.62092407 1.811225220808 0 jpeg:q90:djxl16 13270 4838710 2.9169834 63.061 104.653 2.16807723 0.61567343 1.795909190468 0 jpeg:yuv420:q90 13270 3660915 2.2069577 96.172 246.808 6.07282543 0.95039908 2.097490592679 0 jpeg:yuv420:q90:djxl8 13270 3660915 2.2069577 97.151 156.914 6.05725956 0.91959307 2.029503031911 0 jpeg:yuv420:q90:djxl16 13270 3660915 2.2069577 97.868 153.058 6.05378914 0.91638444 2.022421724515 0 jpeg:libjxl 13270 3197015 1.9272988 18.323 97.172 2.19571280 0.70762796 1.363810502985 0 jpeg:libjxl:djxl8 13270 3197015 1.9272988 18.660 76.811 2.25490046 0.70510193 1.358942071174 0 jpeg:libjxl:djxl16 13270 3197015 1.9272988 18.711 76.222 2.29413509 0.69006634 1.329964006217 0 ``` * Dont save MCU coding state if there are enough bytes in buffer. Benchmark before: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ----------------------------------------------------------------------------------------------------------------------- jpeg:q90:djxl8 13270 4838710 2.9169834 65.817 112.747 2.17603183 0.62092407 1.811225220808 0 jpeg:yuv420:q90:djxl8 13270 3660915 2.2069577 96.322 164.534 6.05725956 0.91959307 2.029503031911 0 jpeg:libjxl:djxl8 13270 3197015 1.9272988 19.046 79.233 2.25490046 0.70510193 1.358942071174 0 ``` Benchmark after: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ----------------------------------------------------------------------------------------------------------------------- jpeg:q90:djxl8 13270 4838710 2.9169834 66.330 118.045 2.17603183 0.62092407 1.811225220808 0 jpeg:yuv420:q90:djxl8 13270 3660915 2.2069577 96.814 169.467 6.05725956 0.91959307 2.029503031911 0 jpeg:libjxl:djxl8 13270 3197015 1.9272988 18.882 82.873 2.25490046 0.70510193 1.358942071174 0 ``` * Fix JPEG reconstruction error. Fixes libjxl#1790. * tools/libjxl_test.c: avoid function declaration without prototype (libjxl#1867) Avoid declaring int main() without a prototype as this is deprecated in all versions of C. * Make jpeg decoder more self-contained. (libjxl#1866) Add specialized 8x8 IDCT and transpose from jpeg xl. * Encode intrinsic dimensions (libjxl#1860) Make the encoder store the `intrinsic_xsize` and `intrinsic_ysize` from JxlBasicInfo. Setting these previously had no effect. * Add a build mode without box decoding and jpeg transcoding. In this case brotli decoder is also not needed. Brotli compressed WASM binary size is 155k. * XYB-jpeg: jpeg-specific clustering and more progression. (libjxl#1875) Benchmark before: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d1.0 13270 3197015 1.9272988 5.469 29.993 2.19093180 0.70477101 1.358304300765 0 ``` Benchmark after: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d1.0 13270 3163678 1.9072018 4.031 25.939 2.19093180 0.70477101 1.344140529099 0 ``` * fast_lossless: rename FastLosslessEncode Adding a "Jxl" prefix disambiguates it when combining it with e.g. a fast PNG encoder or fast WebP encoder. Some lines were subsequently re-formatted to fit within 80 columns. Also wrap an "extern C" around that function. Also wrap an anonymous namespace around the implementation, so that the fjxl BitWriter doesn't conflict with e.g. fpnge's BitWriter. Also fix some -Wunknown-pragmas and -Wsign-compare g++ warnings. Fixes libjxl#1855 * lint and author file * Simplex-search optimized xyb-jpeg quantization matrix parameters. (libjxl#1877) Benchmark before: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d0.5 13270 4804698 2.8964795 3.723 22.242 1.56636882 0.47385977 1.372525138424 0 jpeg:libjxl:d0.8 13270 3636329 2.1921362 4.089 25.696 1.87652230 0.61543190 1.349110553678 0 jpeg:libjxl:d0.9 13270 3378595 2.0367630 3.790 23.042 2.17102480 0.66006343 1.344392804990 0 jpeg:libjxl:d1.0 13270 3163678 1.9072018 4.064 24.490 2.19093180 0.70477101 1.344140529099 0 jpeg:libjxl:d1.1 13270 2984772 1.7993495 3.966 26.363 2.11484838 0.75048089 1.350377429818 0 jpeg:libjxl:d1.2 13270 2828203 1.7049630 4.278 28.153 2.29096746 0.78898283 1.345186506645 0 jpeg:libjxl:d1.5 13270 2447451 1.4754292 4.083 26.287 3.02021217 0.91575531 1.351132125102 0 jpeg:libjxl:d2.0 13270 2015903 1.2152734 4.220 31.476 3.28036547 1.09683000 1.332948351442 0 Aggregate: 13270 3064488 1.8474056 4.023 25.829 2.25605616 0.73004342 1.348686280677 0 ``` Benchmark after: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d0.5 13270 4654354 2.8058457 3.971 20.967 1.54231071 0.46554951 1.306260075416 0 jpeg:libjxl:d0.8 13270 3482816 2.0995920 4.085 24.342 1.70935893 0.61929160 1.300259661216 0 jpeg:libjxl:d0.9 13270 3223473 1.9432488 4.163 22.163 1.84545839 0.67493955 1.311575456149 0 jpeg:libjxl:d1.0 13270 3028977 1.8259982 4.598 25.571 1.90735793 0.71123393 1.298711878895 0 jpeg:libjxl:d1.1 13270 2833331 1.7080543 4.518 26.407 2.19600940 0.76419471 1.305286098499 0 jpeg:libjxl:d1.2 13270 2694178 1.6241669 3.971 25.394 2.27468419 0.79893476 1.297603396949 0 jpeg:libjxl:d1.5 13270 2307256 1.3909136 4.331 26.717 2.60481334 0.94243889 1.310851074545 0 jpeg:libjxl:d2.0 13270 1894603 1.1421485 4.573 33.426 3.18599176 1.12675147 1.286917548072 0 Aggregate: 13270 2919735 1.7601424 4.269 25.400 2.10445561 0.73980436 1.302161048110 0 ``` * don't compile debug print tree code (libjxl#1881) * Read the CICP tag from ICC profiles if present * Remove xyb-jpegs dependence on JXL's parameterized quant matrix. Optimize the set of remaining 105 free AC quant weights (since we want the quant matrix to be symmetric). Benchmark before: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d0.5 13270 4654354 2.8058457 3.663 20.463 1.54231071 0.46554951 1.306260075416 0 jpeg:libjxl:d0.8 13270 3482816 2.0995920 3.796 25.002 1.70935893 0.61929160 1.300259661216 0 jpeg:libjxl:d0.9 13270 3223473 1.9432488 3.822 22.895 1.84545839 0.67493955 1.311575456149 0 jpeg:libjxl:d1.0 13270 3028977 1.8259982 3.726 21.924 1.90735793 0.71123393 1.298711878895 0 jpeg:libjxl:d1.1 13270 2833331 1.7080543 3.716 22.769 2.19600940 0.76419471 1.305286098499 0 jpeg:libjxl:d1.2 13270 2694178 1.6241669 3.751 23.004 2.27468419 0.79893476 1.297603396949 0 jpeg:libjxl:d1.5 13270 2307256 1.3909136 4.096 27.922 2.60481334 0.94243889 1.310851074545 0 jpeg:libjxl:d2.0 13270 1894603 1.1421485 3.831 22.792 3.18599176 1.12675147 1.286917548072 0 Aggregate: 13270 2919735 1.7601424 3.798 23.258 2.10445561 0.73980436 1.302161048110 0 ``` Benchmark after: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------------ jpeg:libjxl:d0.5 13270 4604435 2.7757524 3.217 18.406 1.67270899 0.46916401 1.302283114386 0 jpeg:libjxl:d0.8 13270 3451612 2.0807808 3.843 21.973 1.71237743 0.62384150 1.298077432889 0 jpeg:libjxl:d0.9 13270 3189961 1.9230463 3.432 19.557 1.81622076 0.67879120 1.305346906713 0 jpeg:libjxl:d1.0 13270 2999278 1.8080944 3.483 20.767 1.95959663 0.71370775 1.290450959433 0 jpeg:libjxl:d1.1 13270 2801626 1.6889412 3.668 22.541 2.30924606 0.76993853 1.300380906241 0 jpeg:libjxl:d1.2 13270 2650997 1.5981355 3.619 22.952 2.31698585 0.81157827 1.297012067011 0 jpeg:libjxl:d1.5 13270 2280336 1.3746851 3.652 24.685 2.72100186 0.94873410 1.304210588039 0 jpeg:libjxl:d2.0 13270 1875238 1.1304745 3.880 27.784 3.36580706 1.13450375 1.282527537475 0 Aggregate: 13270 2887250 1.7405590 3.593 22.166 2.17430696 0.74545951 1.297516262872 0 ``` * [butteraugli] Add support for writing the distmap to pfm. * plugins/gimp: Support for decoding animations (libjxl#1863) * plugins/gimp: Support for decoding animations * lint * fix authors check * plugins/gimp: Handle the two blend modes GIMP understands. * plugins/gimp: Handle named frames * plugins/gimp: Fix maths fail * plugins/gimp: Start layer index from 1 to match WebP/gif plugins * set coalescing to true Co-authored-by: Moritz Firsching <firsching@google.com> * ssimulacra2: linear downscaling, fixed SSIM formula (libjxl#1848) * Reapply the noise LUT fix from libjxl#1238 to the render pipeline (libjxl#1893) * Use libjpeg's source manager api in streaming jpeg decoder. This is a step towards having the same API as libjpeg. * Use jpeg_decompress_struct fields for image dimensions. * Make jpeg decoder's API more similar to libjpeg's API. Modify ReadHeaders() to read until SOS marker as in libjpeg. Add a StartDecompress() API function that will read whole input for progressive images. This is the same behaviour as in libjpeg's jpeg_start_decompress() for non-buffered-image mode. * plugins/gimp: Fix progressive decoding (closes libjxl#1845 and libjxl#638) (libjxl#1870) * Refactor WASM demo code * Update dec_xyb.cc to fix wasm decode issue (libjxl#1900) * Update dec_xyb.cc Changed OR to AND. In WASM, images that were not XYB encoded would fail to decode, as `CanOutputToColorEncoding(c_desired)` is never called. * fix authors check Co-authored-by: Moritz Firsching <firsching@google.com> * Fix the automatic setting of intensity_target from the input colorspace (libjxl#1899) * Use Set(Quality|Distance) where appropriate Goal: fix gcc-10 warning SetQuality is unused. * Add demo site generator * Add option to run custom cjpeg command in jpeg benchmark. (libjxl#1905) With this addition, one can benchmark against a decoder-only libpeg implementation by setting a custom LD_LIBRARY_PATH and using a statically built cjpeg in the benchmark. * Fix WASM test * First version of decoder-only jpegli library. (libjxl#1909) The jpegli library is a drop-in replacement to libjpeg62, with improvements inspired by the JPEG XL codec. The commit adds a minimal version of the libjpeg decoding API. After building the jpeg and benchmark_xl targets, the following command can be used to convert an input.jpg file to PNG: ``` LD_PRELOAD=./build/libjpeg.so.62 ./build/tools/benchmark_xl --input input.jpg --codec=jpeg --decode_only --save_decompressed --output_dir . ``` * Support 16 bit output buffer in libjpegli decoder. (libjxl#1913) This can be enabled by the application by setting ``` cinfo.quantize_colors = FALSE; cinfo.desired_number_of_colors = 65536; ``` In this case a scanline buffer should be twice as long. Other changes in the commit: * Remove code duplication between input reading API functions. * Use the existing cinfo fields for marker parsing and keeping internal state, remove redundant fields from jpeg_decomp_master. * Add trivial implementation of jpeg_calc_output_dimensions and use cinfo->output_{width,height}, cinfo->out_color_components where appropiate. * Update HWY Add WASM-256 to build matrix * Refactor ServiceWorker code ... to make it readable / hackable. * libjpegli: reuse more fields of cinfo, fix build. * mention Pale Moon support (libjxl#1915) closes libjxl#1914 * Disable libjpegli on release and debian package builds. * Avoid ODR violations * Ensure alignment in OpHlg * mention GraphicsMagick support (libjxl#1923) * jpegli: fix decoding of non-interleaved sequential jpegs. (libjxl#1922) * Add 16 bit jpeg output mode to benchmark_xl and cjxl. (libjxl#1918) If the benchmark_xl and cjxl binaries are run with libjpegli, then they will decode jpegs to 16 bit ppfs, otherwise they work as before. * Read cICP chunks from PNGs - Where possible, create an encoded profile from the cICP values instead of using an ICC profile. - Change default rendering intent for decoded PNGs to "Relative". - Honor the rendering intent specified by sRGB chunks when applicable. * Explicitly set sRGB profile when reading the chunk To ensure that sRGB takes priority when cHRM/gAMA occur earlier in the file. * fix hshift/vshift of metachannels (libjxl#1925) * cjpeg_hdr: reuse EncodeJpeg Co-authored-by: Luca Versari <veluca@google.com> * Add a basic quality setting to cjpeg_hdr Co-authored-by: Luca Versari <veluca@google.com> * Fix NEON SIMD implementation of fast_lossless Also enable SIMD in build scripts. * remove deprecated or dead code * jpegli: implement jpeg_consume_input() Added tests for suspending source manager use-case, and tests for consuming input ahead of the output processing. * Refactor fast_lossless to support 16-bit data. >8 bit paths are not SIMDfied yet. * premultiply alpha in BufferToImageBundle (libjxl#1927) * premultiply alpha in BufferToImageBundle * remove premultiply_alpha arg * remove arg also from SetAlpha * don't include *_gbench.cc in code coverage report (libjxl#1939) * Fix asan build. * don't generate unused noise (libjxl#1943) Fixes libjxl#1888 * Fix ExternalImageTest asan failure. * Add an --update_on_failure flag to the conformance test runner. Also update the conformance test set commit to make the tests pass. * jpegli: implement buffered image mode * jpegli: implement decoding to cropped output. The implementation is not yet optimal, it just calls jpeg_read_scanlines and discards the output that is not needed. * Build release package for Ubuntu 22.04 * jpegli: implement raw data output mode Drive-by: fix bug in bias computation for buffered image mode and 32-bit architecture. * Add libjpegli's libjpeg.so target to build/lib/jpegli directory. * SIMDfy >8-bit fjxl on ARM NEON. Benchmark on a A51, approximately a 10% speedup on a single core: ``` Before: ./fast_lossless artificial8.ppm x.jxl 2 100 63.178 MP/s 2.755 bits/pixel ./fast_lossless artificial13.ppm x.jxl 2 100 32.670 MP/s 6.994 bits/pixel ./fast_lossless artificial14.ppm x.jxl 2 100 32.285 MP/s 7.956 bits/pixel ./fast_lossless artificial16.ppm x.jxl 2 100 27.592 MP/s 10.411 bits/pixel ./fast_lossless bb8.ppm x.jxl 2 20 37.628 MP/s 11.895 bits/pixel ./fast_lossless bb13.ppm x.jxl 2 20 21.407 MP/s 26.594 bits/pixel ./fast_lossless bb14.ppm x.jxl 2 20 20.894 MP/s 29.654 bits/pixel ./fast_lossless bb16.ppm x.jxl 2 20 18.621 MP/s 35.989 bits/pixel After: ./fast_lossless artificial8.ppm x.jxl 2 100 63.353 MP/s 2.755 bits/pixel ./fast_lossless artificial13.ppm x.jxl 2 100 36.205 MP/s 6.994 bits/pixel ./fast_lossless artificial14.ppm x.jxl 2 100 34.875 MP/s 7.956 bits/pixel ./fast_lossless artificial16.ppm x.jxl 2 100 29.342 MP/s 10.411 bits/pixel ./fast_lossless bb8.ppm x.jxl 2 20 38.161 MP/s 11.895 bits/pixel ./fast_lossless bb13.ppm x.jxl 2 20 23.457 MP/s 26.594 bits/pixel ./fast_lossless bb14.ppm x.jxl 2 20 22.861 MP/s 29.654 bits/pixel ./fast_lossless bb16.ppm x.jxl 2 20 20.144 MP/s 35.989 bits/pixel ``` Co-authored-by: Zoltan Szabadka <szabadka@google.com> Co-authored-by: Leo Izen <leo.izen@gmail.com> Co-authored-by: szabadka <9074039+szabadka@users.noreply.github.com> Co-authored-by: alistair7 <alistair7@users.noreply.github.com> Co-authored-by: Nigel Tao <nigeltao@golang.org> Co-authored-by: Moritz Firsching <firsching@google.com> Co-authored-by: Jon Sneyers <jon@cloudinary.com> Co-authored-by: Sami Boukortt <sboukortt@google.com> Co-authored-by: Luca Versari <veluca@google.com> Co-authored-by: Fredrick Brennan <copypaste@kittens.ph> Co-authored-by: Evgenii Kliuchnikov <eustas@google.com> Co-authored-by: Jim Robinson <jimbo2150@gmail.com> Co-authored-by: Damiano Albani <damiano.albani@gmail.com>
* plugins/gimp: Support for decoding animations * lint * fix authors check * plugins/gimp: Handle the two blend modes GIMP understands. * plugins/gimp: Handle named frames * plugins/gimp: Fix maths fail * plugins/gimp: Start layer index from 1 to match WebP/gif plugins * set coalescing to true Co-authored-by: Moritz Firsching <firsching@google.com>
(edited by @mo271)