Closed grim7reaper closed 10 months ago
Can you post the logs from the startup of Komga? Just need the part that deals with all the startup messages.
Yup, here they are: https://gist.github.com/grim7reaper/41ceca06608ddc22717b00a1aa4bfa2c
or a bug in the test image (where does it come from?).
the internet™️
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.
You can try to find another 1x1 jxl image in a data url, see if that works better.
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)
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.
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 ?
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
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.
i suppose you can raise this to the Safari bug tracker directly, i will be closing this.
Steps to reproduce
image.jxl.enabled: true
), you can test with https://jpegxl.info/test-page/ to make sure it works correctlyConvert page #5 of book [...] from image/jxl to image/jpeg
in the log, indicating a transcodingExpected 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