Decoding webp failed., Status: 3(BITSTREAM_ERROR)]

ToxicMushroom commented 3 years ago

Problem:

With both shipped linux binaries and latest linux binaries (I overwrote the shipped once) the imageReader throws this exception which originates from the binary itself and should probably be handled, I supplied a png ByteArray into the loader here.

Info:

64 bit linux vps running ubuntu 20.0.4 JVM in docker (image is from: buildpack-deps:disco-scm but with jdk 16 installed on top)

Stacktrace:


com.sksamuel.scrimage.ImageParseException: Image parsing failed due to: [java.io.IOException: [Decoding of /tmp/input5778849180991877017webp failed., Status: 3(BITSTREAM_ERROR)]]
    at com.sksamuel.scrimage.nio.ImageReaders.lambda$read$0(ImageReaders.java:54)
    at java.base/java.util.Optional.orElseThrow(Optional.java:403)
    at com.sksamuel.scrimage.nio.ImageReaders.read(ImageReaders.java:50)
    at com.sksamuel.scrimage.nio.ImageReaders.read(ImageReaders.java:35)
    at com.sksamuel.scrimage.nio.ImmutableImageLoader.load(ImmutableImageLoader.java:101)
    at com.sksamuel.scrimage.nio.ImmutableImageLoader.fromBytes(ImmutableImageLoader.java:70)
    at me.melijn.melijnbot.commands.image.WebpCommand.execute(WebpCommand.kt:39)
    at me.melijn.melijnbot.commands.image.WebpCommand$execute$1.invokeSuspend(WebpCommand.kt)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
    at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1434)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:295)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)```

sksamuel commented 3 years ago

This happens if none of the readers can load the image. Is the webp support on the classpath ?

ToxicMushroom commented 3 years ago

yes they are in the classpath, when debugging they're being used but I'm on windows, I'll try debugging on linux in a few minutes

sksamuel commented 3 years ago

Basically it iterates through the loaders until it finds one that works, and if none do, it throws the errors. So if this is failing, then none of the loaders working - and if you supplied a PNG it means the png loader didn't like it. The error is not great.

ToxicMushroom commented 3 years ago

So if this is failing, then none of the loaders working - and if you supplied a PNG it means the png loader didn't like it.

The png works fine if there's no webp-support btw

sksamuel commented 3 years ago

Right interesting, are you making a fat jar ?

On Wed, 26 May 2021 at 13:23, ToxicMushroom @.***> wrote:

So if this is failing, then none of the loaders working - and if you supplied a PNG it means the png loader didn't like it.

The png works fine if there's no webp-support btw

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sksamuel/scrimage/issues/228#issuecomment-849015957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSGTJ5KGS66AG374PHGTTPU4DDANCNFSM45NHHY6Q .

ToxicMushroom commented 3 years ago

yes, It's made using gradle shadowjar. I just tried it on my laptop with fedora and it worked fine with both supplied and my own overwritten webp binaries. So it's just failing on my vps for some reason

sksamuel commented 3 years ago

Do you think it's caused by the multiple binaries?

On Wed, 26 May 2021 at 14:14, ToxicMushroom @.***> wrote:

yes, It's made using gradle shadowjar. I just tried it on my laptop with fedora and it worked fine with both supplied and my own overwritten webp binaries. So it's just failing on my vps for some reason

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sksamuel/scrimage/issues/228#issuecomment-849049816, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSGWXVQG44ZU5D5GQRLTTPVB7ZANCNFSM45NHHY6Q .

ToxicMushroom commented 3 years ago

new info, it also throws the error when running in docker on my laptop with fedora. Maybe it doesn't register all loaders due to some issue with my docker container. Can I log all registered image loaders ?

sksamuel commented 3 years ago

It's likely to be because of the far jar. You probably need to set it so that it merges service files. For example, if you are using shadow jar on gradle then this explains it: https://imperceptiblethoughts.com/shadow/configuration/merging/#merging-service-descriptor-files

And whatever you are using if you're using maven will have the same option somewhere.

On Wed, 26 May 2021 at 15:01, ToxicMushroom @.***> wrote:

new info, it also throws the error when running in docker on my laptop with fedora. Maybe it doesn't register all loaders due to some issue with my docker container. Can I log all registered image loaders ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sksamuel/scrimage/issues/228#issuecomment-849078889, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFVSGVEEFURQJVRUXUDD7TTPVHRRANCNFSM45NHHY6Q .

ToxicMushroom commented 3 years ago

It's likely to be because of the far jar. You probably need to set it so that it merges service files. For example, if you are using shadow jar on gradle then this explains it: https://imperceptiblethoughts.com/shadow/configuration/merging/#merging-service-descriptor-files And whatever you are using if you're using maven will have the same option somewhere.

Yes this solved it 👍 Thanks

sksamuel / scrimage