gotson / komga

Media server for comics/mangas/BDs/magazines/eBooks with API, OPDS and Kobo Sync support
https://komga.org
MIT License
4.1k stars 243 forks source link

JXL support isn't detected #1375

Closed grim7reaper closed 10 months ago

grim7reaper commented 10 months ago

Steps to reproduce

Expected behavior

I expect Komga WebReader to correctly detect JXL support and avoid unecessary transcoding

Actual behavior

JXL support is not detected, and fallback to JPEG occurs

Logs

No response

Komga version

v1.9.2-master

Operating system

ArchLinux

Installation method

Docker

Other details

Issues seems to be coming from the image used here: https://github.com/gotson/komga/blob/7dd05a5037695790054779927147eca6662e2d45/komga-webui/src/functions/check-image.ts#L32

Could be a bug in the browser (but I think they're using the standard jxl C library, not sure about the version though) or a bug in the test image (where does it come from?).

Acknowledgements

DieselTech commented 10 months ago

Can you post the logs from the startup of Komga? Just need the part that deals with all the startup messages.

grim7reaper commented 10 months ago

Yup, here they are: https://gist.github.com/grim7reaper/41ceca06608ddc22717b00a1aa4bfa2c

gotson commented 10 months ago

or a bug in the test image (where does it come from?).

the internet™️

grim7reaper commented 10 months ago

or a bug in the test image (where does it come from?).

the internet™️

Hum, could be a wrong/invalid image then.

Doesn't display in Safari at least (whereas other JXL images does), which would explain why the function wrongly believe JXL isn't supported.

gotson commented 10 months ago

You can try to find another 1x1 jxl image in a data url, see if that works better.

grim7reaper commented 10 months ago

Not a 1x1 image, but this one should do the trick (coming from here):

data:image/jxl;base64,/wr4GRAJ2GMQALwAphlKo1aMlGIkfRJyhwAA2tTJweKeArk3AP4HmpEIzb+h3HE2YsiXMcQ+WALBAQA=

But if you really want a 1x1 (which is a bit larger as I couldn't use Modular for it...), there is this one:

data:image/jxl;base64,/woAkAEB2ABrTgsAgAqVUcYNXs71fPmhw2LaxnWGttq2AAAAAB7AvxLGZnthkJBwBBsXTdwcVHP7gMhQSQI=

From my testing, seems like Safari actually has an issue decoding some images using Modular (but not all: the spline above is working), couldn't pinpoint what was the issue exactly though...

That being said, VarDCT seems to always work (and I expect my collection to mainly use VarDCT as this is the mode used for lossless reencode of JPEG, as explained here)

gotson commented 10 months ago

But if you really want a 1x1 (which is a bit larger as I couldn't use Modular for it...), there is this one:

where is this coming from ?

From my testing, seems like Safari actually has an issue decoding some images using Modular (but not all: the spline above is working), couldn't pinpoint what was the issue exactly though...

What's Modular ? If Safari cannot decode, it might be a Safari issue then.

gotson commented 10 months ago

jxlinfo with the current image (data:image/jxl;base64,/woIELASCAgQAFwASxLFgkWAHL0xqnCBCV0qDp901Te/5QM=):

JPEG XL image, 2x2, (possibly) lossless, 8-bit RGB+Alpha
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative

data:image/jxl;base64,/wr4GRAJ2GMQALwAphlKo1aMlGIkfRJyhwAA2tTJweKeArk3AP4HmpEIzb+h3HE2YsiXMcQ+WALBAQA=

jxlinfo:

JPEG XL image, 320x320, (possibly) lossless, 8-bit RGB
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative

data:image/jxl;base64,/woAkAEB2ABrTgsAgAqVUcYNXs71fPmhw2LaxnWGttq2AAAAAB7AvxLGZnthkJBwBBsXTdwcVHP7gMhQSQI=

jxlinfo:

JPEG XL image, 1x1, lossy, 8-bit RGB
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative

Could it be that Safari cannot handle JXL with alpha ?

gotson commented 10 months ago

I just tested on my mac with Firefox Nightly, it can correctly open the existing data url, and the webreader correctly requests JXL images (once image.jxl.enabled is set to true).

Safari doesn't work, so i would say that's a Safari issue.

I confirmed that by trying to load the JXL image directly from the API into Safari (something like http://localhost:25600/api/v1/books/0E048VBY4YVQR/pages/1), and Safari fails to load the JXL image.

This is the test image i am using: IMG_20200308_194050.jxl.zip

grim7reaper commented 10 months ago

But if you really want a 1x1 (which is a bit larger as I couldn't use Modular for it...), there is this one:

where is this coming from ?

1x1 PNG from GIMP, then encoded to JXL with cjxl (in lossy, since the lossless doesn't work for some reason)

From my testing, seems like Safari actually has an issue decoding some images using Modular (but not all: the spline above is working), couldn't pinpoint what was the issue exactly though...

What's Modular ? If Safari cannot decode, it might be a Safari issue then.

One way to encode the pixel, cf here.


The current test image is (using jxl-info which gives a bit more info than the standard jxlinfo):

JPEG XL image (BareCodestream)
  Image dimension: 2x2
  Bit depth: 8 bits
  Color encoding:
    Colorspace: RGB
    White point: D65
    Primaries: sRGB
    Transfer function: sRGB
Frame #0 (keyframe)
  Modular (maybe lossless)
  Frame type: Regular
  2x2; (0, 0)

Thought the issue was Modular (since every image using VarDCT works) but that's not it (spline.jxl also uses Modular and is correctly rendered). Not an alpha issue either, since the test images with alpha on https://jpegxl.info/test-page/ are rendered perfectly (only the animated one doesn't work)

So yes, there is clearly a Safari issue involved, but cannot pinpoint it :/

On the other hand, seems like "most" JXL works (at least the ones used in the CBZ) so it's a bit sad to be blocked by the test image (but it's not really wrong, I agree) + Firefox on iOS is just a Safari skin so cannot workaround like that.

gotson commented 10 months ago

i suppose you can raise this to the Safari bug tracker directly, i will be closing this.