这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@ctrlcctrlv
Copy link
Contributor

@ctrlcctrlv ctrlcctrlv commented Nov 4, 2022

animated_ico_in_gimp

(edited by @mo271)

@ctrlcctrlv
Copy link
Contributor Author

ctrlcctrlv commented Nov 4, 2022

Test file:
animation_icos4d/input.jxl
(edited by @mo271)

Follows up to work done by @xiota and others.

@mo271
Copy link
Member

mo271 commented Nov 4, 2022

Thanks a lot for the contribution, @ctrlcctrlv!

I tested plugin with an animation from our conformace repo animation_icos4d/input.jxl
Seems to work like a charm.
In order to comply with github-acceptable-use-policies,
I’ll edit your comments to replace the screenshot and link by a screenshot of and link to the icosahedron image.

Looking forward to a pull request for encoding animation, like you propose in #1864, if you come around doing that.

@mo271
Copy link
Member

mo271 commented Nov 4, 2022

I fixed the failing authors check and linting https://github.com/libjxl/libjxl/actions/runs/3392132321/jobs/5643700386, taking the name from the commit.

mo271
mo271 previously approved these changes Nov 4, 2022
@mo271 mo271 requested a review from sboukortt November 4, 2022 15:00
sboukortt
sboukortt previously approved these changes Nov 4, 2022
Copy link
Member

@sboukortt sboukortt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks!

@ctrlcctrlv
Copy link
Contributor Author

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.

@ctrlcctrlv ctrlcctrlv dismissed stale reviews from sboukortt and mo271 via 21adf35 November 5, 2022 06:00
@ctrlcctrlv
Copy link
Contributor Author

ctrlcctrlv commented Nov 5, 2022

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.

input

#!/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.mp4
webp.mp4

Screenshot from 2022-11-05 02-01-58
Screenshot from 2022-11-05 02-01-50

@ctrlcctrlv ctrlcctrlv force-pushed the gimp_animation_decode branch from efd4823 to 97a1ca9 Compare November 5, 2022 06:24
@ctrlcctrlv ctrlcctrlv requested review from mo271 and sboukortt and removed request for mo271 and sboukortt November 5, 2022 06:29
@ctrlcctrlv ctrlcctrlv force-pushed the gimp_animation_decode branch from f150585 to b81ff91 Compare November 5, 2022 17:20
@ctrlcctrlv
Copy link
Contributor Author

ctrlcctrlv commented Nov 5, 2022

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 tools/jxlinfo.c, as that program understands both.

Screenshot from 2022-11-05 13-24-17

That's Wikipedia.jxl:
Wikipedia.jxl.7z.001.zip
Wikipedia.jxl.7z.002.zip

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

@alistair7
Copy link
Contributor

No problem. Nice work!

@ctrlcctrlv
Copy link
Contributor Author

ctrlcctrlv commented Nov 5, 2022

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 Wikipedia.jxl.

Screenshot from 2022-11-05 19-29-16

@mo271
Copy link
Member

mo271 commented Nov 8, 2022

I noticed that there was JxlDecoderSetCoalescing, and I think when you set this to JXL_TRUE or not call it at all, (since then the default value is true), then the problem with the 0-duration frames will go away.
In fact I checked just that in this branch:
main...mo271:libjxl:coalescing_gimp
with the wikipedia image, and I get 248 frames just as expected.
So I suggest to do it that way. What do you think?

@mo271
Copy link
Member

mo271 commented Nov 8, 2022

@ctrlcctrlv
Copy link
Contributor Author

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.

@mo271
Copy link
Member

mo271 commented Nov 9, 2022

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...)

@Traneptora
Copy link
Contributor

Sounds like they're saying that they want the separate layers to remain separate so they can be treated as layers in GIMP.

@mo271
Copy link
Member

mo271 commented Nov 9, 2022

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.

@ctrlcctrlv
Copy link
Contributor Author

Even with coalescing set to true, each frame in the animation will be separate layers in GIMP.

Yes, but with the entire background. Not as easy to edit at all.

@alistair7
Copy link
Contributor

Another complication with having coalescing disabled is that a frame's blend_source doesn't necessarily refer to the previous frame. That's probably not a concept that Gimp's combine/replace tags can deal with, so the exported results won't look right in those cases. I'm not sure whether cjxl will ever produce a file like that from a converted GIF/APNG, but they certainly exist. Silly example attached: face_skip_frame.jxl.zip

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 blend_info.source != previous_save_as_reference, where previous_save_as_reference is stored from the previous frame's layer_info.save_as_reference ...in a similar way to how it currently rejects the more exotic blend modes.

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...

@jonsneyers
Copy link
Member

I think this points to a gap in our current API, since there are currently only two options:

  • Coalescing (default): gives only the blended frames, so you lose the crop region and transparency (i.e. only returns full-canvas sized frames with nonzero duration)
  • No coalescing: gives all frames as they are, without blending, including zero-duration frames (i.e. layers) that are kRegularFrames (the kReferenceOnly and kLfFrames ones are never returned because they are intended strictly to be used only as coding tools, not as semantically meaningful objects by themselves).

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.

@jonsneyers
Copy link
Member

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.
Also it would be good to have a way to tell the decoder not to return 'exotic' blend modes (i.e. not kReplace and not kBlend), since in many cases (like Gimp) the application will already know about replace and blend but not about the other blend modes.

@mo271
Copy link
Member

mo271 commented Nov 10, 2022

So how to best proceed here?
With the current API, I see three options

  1. set coalescing to true
  2. set coalescing to false and not merge 0 duration frames
  3. set coalescing to false and merge 0 duration frame

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.

@jonsneyers
Copy link
Member

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.

@ctrlcctrlv
Copy link
Contributor Author

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.

Screenshot_20221110_135443

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.

@mo271
Copy link
Member

mo271 commented Nov 11, 2022

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
https://github.com/mo271/libjxl/tree/coalescing_gimp (setting coalescing to true) merged?
I have a slight preference for the 2nd, since it will likely work for more files (having the drawback of not getting the layers correct for some of them).
@ctrlcctrlv
We can always do further improvements later...

@jonsneyers
Copy link
Member

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.

@ctrlcctrlv
Copy link
Contributor Author

ctrlcctrlv commented Nov 11, 2022

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 -layers Optimize after a convert from an exotic format. GIMP's plugin for that may even provide such a function.

@mo271 mo271 force-pushed the gimp_animation_decode branch from c28e358 to e627778 Compare November 11, 2022 10:28
@mo271 mo271 requested a review from jonsneyers November 11, 2022 10:30
@mo271 mo271 merged commit 660aac9 into libjxl:main Nov 11, 2022
@mo271
Copy link
Member

mo271 commented Nov 11, 2022

Many thanks again, @ctrlcctrlv!

@ctrlcctrlv
Copy link
Contributor Author

My pleasure :o)

Unused-Account added a commit to Unused-Account/libjxl that referenced this pull request Dec 7, 2022
* 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>
jonsneyers pushed a commit to jonsneyers/libjxl that referenced this pull request Apr 24, 2023
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CI:full Label to attach to a PR to run the full CI workflow and not just the regular PR workflows

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants