|
fab
|
2021-11-22 09:20:05
|
with a utility of windows like you download bulk rename utility and you do name remove jpg and you can change the name
|
|
2021-11-22 09:20:24
|
fo instagam photo you need to change the name o othewise will cash
|
|
2021-11-22 09:21:35
|
anothe situation in will throw an error per single image is when you have a corrupt jpg or with cymk color space and you do a lossless jpg transocde
|
|
2021-11-22 09:22:05
|
ex.
|
|
2021-11-22 09:22:07
|
for %i in (D:\pic\2021a\jpg\webago\*.jpg) do cjxlnoves -s 9 %i %i.jxl
|
|
2021-11-22 09:22:34
|
note that the build i execute is on C:\PATH_Programs
|
|
2021-11-22 09:23:28
|
also useful link
|
|
2021-11-22 09:23:29
|
https://www.xnview.com/en/xnviewmp/#downloads
|
|
2021-11-22 09:23:56
|
|
|
2021-11-22 09:24:38
|
https://github.com/libjxl/libjxl/blob/main/doc/software_support.md
|
|
2021-11-22 09:25:23
|
https://it.wikipedia.org/wiki/JPEG_XL
|
|
2021-11-22 09:25:38
|
|
|
2021-11-22 09:25:47
|
this is witten by me
|
|
2021-11-22 09:25:54
|
you can check with google ttanslte
|
|
2021-11-22 09:27:03
|
xnview suppot conveting but i don't advice to do use it at moment only fo eading
|
|
2021-11-22 09:27:17
|
until 1.0 api is stable
|
|
2021-11-22 09:29:45
|
For lossless from png you should do s 7 -q 100 but i don't absolutely recommend to use today
|
|
|
Quikee
that new functionality in Windows where you can run Linux compiled binaries
|
|
2021-11-22 09:32:10
|
Right
|
|
2021-11-22 09:32:26
|
I don't have It installed
|
|
2021-11-22 09:33:02
|
You just copy the binaries of libjxl
|
|
2021-11-22 09:33:29
|
Cjxl Is the only necessary
|
|
2021-11-22 09:34:06
|
But i copied all though is cjxl the one i update even with renamed names
|
|
2021-11-23 11:36:46
|
jpeg xl retains all the memories it retains the detail while avif does a first impression of image
|
|
2021-11-23 01:44:50
|
Also cavif rs has no gif support
|
|
2021-11-23 01:45:37
|
I don't know if there are reason to convert to jxl in 2022
|
|
2021-11-27 10:40:19
|
also jxl photos at 112 kb usually have high colo satuation
|
|
2021-11-27 10:40:28
|
in the medium fquencies
|
|
2021-11-27 10:40:55
|
the encode is peceptual
|
|
2021-11-27 10:40:59
|
and not macroblock
|
|
2021-11-27 10:41:18
|
but any jxl news about quality?
|
|
2021-11-27 10:42:37
|
white points are rendered better
|
|
|
diskorduser
|
2021-11-27 05:16:47
|
Spamming alone since nov 22.
|
|
|
BlueSwordM
|
|
fab
but any jxl news about quality?
|
|
2021-11-27 07:29:56
|
No.
|
|
|
Jyrki Alakuijala
|
2021-11-30 09:56:59
|
'patch clamp' resulted in Nobel Prize in Medicine in 1990s
|
|
2021-11-30 09:57:05
|
overloaded terms
|
|
|
_wb_
|
2021-11-30 10:19:23
|
Haha
|
|
2021-11-30 02:49:29
|
YAY
|
|
2021-11-30 02:49:38
|
finally managed to get apng output working
|
|
2021-11-30 03:03:21
|
ugh
|
|
2021-11-30 03:03:38
|
<@!604964375924834314> do you have any idea what this means?
```
[ RUN ] CodecTest.TestWideGamut
libpng warning: iCCP: profile 'Photoshop ICC profile': 0h: PCS illuminant is not D50
libpng error: profile '1': 0h: PCS illuminant is not D50
```
|
|
2021-11-30 03:06:24
|
ok nevermind, i'll just make such warnings non-fatal
|
|
2021-12-01 10:23:24
|
> Hi,
>
> I'm sorry if this is not the right way to reach out, but I have a concern/suggestion regarding JPEG XL.
>
> In a lot of cases, it's important to easily know that an image file is lossless. This is why PNGs are so nice, you can simply check the extension - That's part of what intrigued me about FLIF when I discovered it. A JXL file, however, can be either lossless or lossy.
>
> Why:
>
> One use case would be when distributing music to streaming services. When you upload your cover artwork, you can only select .png files, so you can't accidentally submit a lossy file. If they were to allow JPEG XL files, they would have to do extra checking to only allow lossless files. They'll have to communicate this to users if they try to upload a lossy JXL file, and users would then have to make sure that their file is a lossless JXL file.
>
> Clearly, this is a bad user experience. A regular person may know that a .jpg file and a .png file are different types of images, but not how a lossless .jxl differs from a lossy .jxl, and how to deal with that.
>
> Another use case is simply archiving/storing files, you may want to make sure everything is lossless in that case. It's much easier to deal with if you can check a file extension to determine that it's lossless.
>
> How:
>
> I assume the format would just need a single bit somewhere that determines whether it's lossless, to make sure the two formats aren't identical. The file extension could be something like .ljxf.
|
|
2021-12-01 10:24:48
|
this seems to be a recurring concern that people have about a format that can do both lossy and lossless
|
|
2021-12-01 10:27:03
|
maybe we should add some indication to jxlinfo to distinguish 3 cases:
- XYB: lossy
- jbrd: recompressed jpeg
- RGB: possibly lossless
|
|
|
|
Deleted User
|
2021-12-01 10:28:20
|
https://github.com/FLIF-hub/FLIF/issues/551#issuecomment-974823668
|
|
|
|
_wb_
|
2021-12-01 10:28:44
|
there obviously is no guarantee in any format that an image is "lossless", nothing stops you from converting a crappy q20 jpeg to png
|
|
|
Fraetor
|
2021-12-01 11:16:57
|
With the possible exception of using images to encode non-image data (something I've done with PNGs in the past), it is perceived closeness to the original that matters, rather than true pixel to pixel likeness.
|
|
2021-12-01 11:19:20
|
So that q20 JPEG can be the "correct" image, as long as it looks as intended by the original creator.
|
|
2021-12-01 11:25:05
|
But I will admit, a lot of image sources will have two options: a middling quality JPEG and a lossless PNG, which does lead to the current perceptions.
|
|
2021-12-01 11:26:02
|
I think this is mainly an issue to be fixed with those providing the images though, by clearly communication which images are closer to the original.
|
|
|
|
Deleted User
|
|
_wb_
> Hi,
>
> I'm sorry if this is not the right way to reach out, but I have a concern/suggestion regarding JPEG XL.
>
> In a lot of cases, it's important to easily know that an image file is lossless. This is why PNGs are so nice, you can simply check the extension - That's part of what intrigued me about FLIF when I discovered it. A JXL file, however, can be either lossless or lossy.
>
> Why:
>
> One use case would be when distributing music to streaming services. When you upload your cover artwork, you can only select .png files, so you can't accidentally submit a lossy file. If they were to allow JPEG XL files, they would have to do extra checking to only allow lossless files. They'll have to communicate this to users if they try to upload a lossy JXL file, and users would then have to make sure that their file is a lossless JXL file.
>
> Clearly, this is a bad user experience. A regular person may know that a .jpg file and a .png file are different types of images, but not how a lossless .jxl differs from a lossy .jxl, and how to deal with that.
>
> Another use case is simply archiving/storing files, you may want to make sure everything is lossless in that case. It's much easier to deal with if you can check a file extension to determine that it's lossless.
>
> How:
>
> I assume the format would just need a single bit somewhere that determines whether it's lossless, to make sure the two formats aren't identical. The file extension could be something like .ljxf.
|
|
2021-12-02 05:52:48
|
But FLIF also supported lossy encoding.
|
|
|
|
_wb_
|
2021-12-02 05:53:12
|
any lossless codec can be used in a lossy way
|
|
2021-12-02 05:54:27
|
in PNG too: you can e.g. use the AvgN+W predictor/filter in PNG, and then clear the lsb of the residuals
|
|
2021-12-02 05:55:47
|
great for compression, visual artifacts are OK (every pixel has at most an off-by-one, and most gradients are still smooth)
|
|
|
|
Hello71
|
2021-12-03 04:50:00
|
or pngquant
|
|
|
|
_wb_
|
2021-12-03 04:51:03
|
I spent an afternoon on making lossless -e 1 a bit faster: https://github.com/libjxl/libjxl/pull/946
|
|
2021-12-03 04:54:56
|
there's still room for a similar speed improvement, but that will involve getting rid of unnecessary buffer copying and conversion from int to float and back to int that we're currently doing (because most of the internal code expects buffers to be in `float`, so we basically do `* (1.0f / 255.f) * 255.f + 0.5f` on every pixel (or different multipliers in case it's not 8-bit) which is obviously a bit silly
|
|
|
Scope
|
2021-12-03 05:19:56
|
No changes in decoding?
|
|
|
|
_wb_
|
2021-12-04 11:01:28
|
That PR is just encoder-only stuff. For decode speedup, the render pipeline <@179701849576833024> is working on should help. Especially if we eventually make an int16 based pipeline (doing everything with int16 buffers instead of float ones, say for lossy and lossless images up to 12-bit), we could use that to avoid the unnecessary conversion from int to float and back to int that we currently have also in lossless decoding.
|
|
2021-12-04 11:05:31
|
For the fastest lossless setting, both encoder and decoder are probably spending at least 25% of the time doing avoidable buffer copying and conversions from uint to 0..1 float and back
|
|
|
improver
|
2021-12-05 07:05:30
|
|
|
2021-12-05 07:05:41
|
how is `FrameType` encoded <:Thonk:805904896879493180>
|
|
2021-12-05 07:23:23
|
guessing enum
|
|
|
|
_wb_
|
2021-12-05 07:24:22
|
Best to check the code
|
|
2021-12-05 07:24:47
|
It might be just u(2)
|
|
|
|
improver
|
2021-12-05 07:25:14
|
why is spec unclear aaaaaaaaa
|
|
2021-12-05 07:25:37
|
also code for this is obfuscated af
|
|
|
|
_wb_
|
2021-12-05 07:26:10
|
Check the rust code then :)
|
|
|
|
improver
|
2021-12-05 07:26:25
|
it's obfuscated af too
|
|
2021-12-05 07:27:00
|
this doesn't tell me wtf encoding is
|
|
2021-12-05 07:27:26
|
not there either
|
|
2021-12-05 07:28:05
|
trying to follow wtf UnconditionalCoder is leads to some spaghetti hell
|
|
|
|
_wb_
|
2021-12-05 07:30:54
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/frame_header.cc#L43
|
|
2021-12-05 07:31:07
|
It's effectively a u(2)
|
|
|
|
improver
|
|
|
_wb_
|
2021-12-05 07:31:43
|
In the second edition we'll just put u(2) in the table
|
|
|
|
improver
|
2021-12-05 07:31:46
|
wait isn't this select unless it's U32
|
|
2021-12-05 07:32:48
|
hmm i see from that code line
|
|
2021-12-05 07:33:49
|
it's effectively u(2), but it's U32(...) really, however idk what rust stuff is there though
|
|
|
|
_wb_
|
2021-12-05 07:33:55
|
It's U32 with four explicit Val(), so that's just u(2). This was not clear in the first edition of the spec
|
|
|
|
improver
|
2021-12-05 07:34:15
|
is rust stuff even correct there
|
|
2021-12-05 07:34:46
|
because it makes me think that it'll do select as it's not explicitly marked as U32Coder
|
|
2021-12-05 07:35:10
|
and select would work on RegularFrame but would do wrong stuff on other types
|
|
2021-12-05 07:35:16
|
so maybe it wasn't caught
|
|
|
|
_wb_
|
2021-12-05 07:35:33
|
Good point
|
|
2021-12-05 07:36:20
|
The rust impl is still very premature, libjxl is correct in case of doubt
|
|
|
|
veluca
|
|
improver
is rust stuff even correct there
|
|
2021-12-05 08:53:35
|
Totally possible, reading the frame header is 100% not well tested
|
|
|
|
improver
|
2021-12-06 03:31:12
|
ExtraChannelType also doesn't specify encoding.. atleast in FDIS. I'd assume u(4) since max val seems to be 15 but it could be enum too...
|
|
2021-12-06 03:32:09
|
|
|
2021-12-06 03:39:12
|
oh. it's actual enum
|
|
2021-12-06 05:05:37
|
so uhh enable or skip?
|
|
2021-12-06 05:06:06
|
oh. zero comes first
|
|
2021-12-06 05:06:10
|
confusing
|
|
2021-12-06 05:08:51
|
kinda waste to use U64 for this field tbh
|
|
|
|
_wb_
|
2021-12-06 06:21:16
|
U64 is not u(64)
|
|
2021-12-06 06:23:23
|
The idea is that we could add more flags in later extensions (without using the full extension mechanism)
|
|
2021-12-06 06:24:56
|
The 0 value for flags is the value that we thought was most useful as a default - that way you get short encodings
|
|
|
|
improver
|
|
Kasper
|
2021-12-06 06:00:01
|
Hey, I have a suggestion/concern about JPEG XL.
In a lot of cases, it's important to know with high confidence that an image was losslessly converted simply by looking at the file extension. This was already brought up here: https://www.reddit.com/r/jpegxl/comments/oxp5df/does_anyone_else_think_it_would_be_annoying
Unless this changes, I'm most likely going to continue using PNG for storing my personal (and my company's) files, and I suspect many others will do the same. Even if somebody does create a lossy PNG, it's much more likely that they did so knowingly.
|
|
2021-12-06 06:01:25
|
Lastly, just wanna say that JPEG XL is looking great, and I appreciate everyone working on it!
|
|
|
|
Fraetor
|
|
Kasper
Hey, I have a suggestion/concern about JPEG XL.
In a lot of cases, it's important to know with high confidence that an image was losslessly converted simply by looking at the file extension. This was already brought up here: https://www.reddit.com/r/jpegxl/comments/oxp5df/does_anyone_else_think_it_would_be_annoying
Unless this changes, I'm most likely going to continue using PNG for storing my personal (and my company's) files, and I suspect many others will do the same. Even if somebody does create a lossy PNG, it's much more likely that they did so knowingly.
|
|
2021-12-06 06:01:43
|
This was discussed a bit higher up in this channel:
https://discord.com/channels/794206087879852103/794206170445119489/915729829402411068
|
|
|
|
Kasper
|
2021-12-06 06:03:08
|
Ah, that was actually from my email! I'll have a read through the messages there
|
|
2021-12-06 06:12:08
|
Still would say a separate file extension is the most useful approach to this, would love to hear more opinions
|
|
|
|
_wb_
|
2021-12-06 06:42:05
|
File extensions are just a convention, they are part of the name
|
|
2021-12-06 06:42:38
|
You can rename a jpeg to .png or a png to .jpg and most likely they will still display just fine in any viewer
|
|
2021-12-06 06:46:43
|
Nothing stops you from calling your losslessly encoded jxl files .ljxl and the lossy ones .jxl
|
|
2021-12-06 06:46:54
|
Or .lossless.jxl and .lossy.jxl
|
|
2021-12-06 06:47:11
|
Or .orig.jxl and .d1.jxl
|
|
|
spider-mario
|
2021-12-06 06:47:47
|
I think I might have gone for jxll
|
|
2021-12-06 06:47:57
|
and maybe jxlo, or just jxl
|
|
|
|
_wb_
|
2021-12-06 06:49:14
|
I dunno if multiple extensions really help
|
|
|
monad
|
2021-12-06 06:49:14
|
Personally, I've been considering .jpg.jxl or .jjxl for recompressed JPEGs. Former is surely more readable, but gotta save those bytes, right? ;)
|
|
2021-12-06 06:49:34
|
Just for my own use cases, of course.
|
|
|
|
_wb_
|
2021-12-06 06:49:41
|
.jpg.jxl is clear
|
|
2021-12-06 06:50:19
|
Everything depends on your workflow
|
|
2021-12-06 06:51:52
|
A losslessly encoded 8-bit image can be more lossy than a low-distance lossy image from a high bit depth original
|
|
|
|
Kasper
|
|
_wb_
Nothing stops you from calling your losslessly encoded jxl files .ljxl and the lossy ones .jxl
|
|
2021-12-06 09:36:49
|
If people see/get a file with an unconventional extension, they would be confused though
|
|
2021-12-06 09:38:22
|
If I rename a `.png` to `.xpng`, it doesn't show an image preview, and it doesn't even let me open it in the macOS Preview app without 3 extra steps and a warning
|
|
2021-12-06 09:41:08
|
And if a website requires you to upload an `.ljxl` file, they'll have to look up what that even is and maybe never find out, it's just way too confusing
|
|
|
|
Deleted User
|
2021-12-06 09:56:22
|
The first few bytes tell you that it's a JXL file. Also, it is quite common to see WebP files ending with .jpg on the web.
|
|
|
|
_wb_
|
2021-12-06 09:59:03
|
A website that requires the extension to be .png or the file to be a PNG is just inviting people to upload screenshots of their jpegs and waste bandwidth
|
|
|
w
|
2021-12-06 09:59:19
|
apng in png, literally anything in HEIF...
|
|
2021-12-06 10:00:28
|
imo extension is basically container territory
|
|
|
Pigophone
|
2021-12-06 10:10:51
|
I can see the appeal of having a different extension for lossless, for example matroska does that for vp8/9: mkv/webm
file pickers only working with file extensions is a bit limiting, but that's not going to change any time soon ...
|
|
|
|
w
|
2021-12-06 10:19:54
|
matroska doesnt do that for lossless
|
|
2021-12-06 10:20:00
|
webm is just matroska for web
|
|
|
|
Pigophone
|
2021-12-06 10:21:18
|
> for vp8/9
|
|
2021-12-06 10:21:32
|
webm limits what the container can support in software
|
|
2021-12-06 10:21:42
|
similar to what ljxl would be
|
|
|
|
w
|
2021-12-06 10:21:45
|
right
|
|
2021-12-06 10:21:52
|
and mp4 is avc, hevc, and av1
|
|
2021-12-06 10:22:07
|
and aac, ac3, and flac
|
|
|
|
Pigophone
|
2021-12-06 10:22:39
|
yes containers do exist that is correct
|
|
|
|
w
|
2021-12-06 10:22:41
|
like how heif is heic and avif and avcf
|
|
2021-12-06 10:23:07
|
therefore extension doesnt mean anything
|
|
|
Cool Doggo
|
|
Pigophone
webm limits what the container can support in software
|
|
2021-12-06 10:23:14
|
but what does that have to do with lossless vs lossy?
|
|
|
|
w
|
2021-12-06 10:23:27
|
vp9 can be lossy and lossless
|
|
|
|
Pigophone
|
2021-12-06 10:23:36
|
has nothing to do with lossless and lossy
|
|
|
|
w
|
2021-12-06 10:23:36
|
doesnt solve the problem
|
|
2021-12-06 10:24:02
|
nobody complained about lossless vs lossy video
|
|
2021-12-06 10:24:19
|
why should people care about lossless vs lossy images
|
|
2021-12-06 10:24:21
|
xd
|
|
|
|
Kasper
|
|
_wb_
A website that requires the extension to be .png or the file to be a PNG is just inviting people to upload screenshots of their jpegs and waste bandwidth
|
|
2021-12-06 10:24:38
|
streaming services like Spotify and Apple Music want uncompressed images and audio, usually people won't screenshot their cover art to convert it to a PNG
|
|
|
|
w
|
2021-12-06 10:25:03
|
apple music serves cover art as jpg in webp
|
|
|
|
Kasper
|
2021-12-06 10:25:18
|
yes, but the original that you submit is not
|
|
|
|
Pigophone
|
2021-12-06 10:25:38
|
spotify doesn't even send the full album art to the client
when I use my offline music on spotify, I get wayyy higher detailed pics from id3 album art
|
|
2021-12-06 10:25:53
|
not that this matters for the topic on hand
|
|
|
|
Cool Doggo
|
2021-12-06 10:26:08
|
theres still nothing stopping someone from just converting a jpeg to png if it was originally a jpeg and they need a png
|
|
|
|
w
|
|
w
apple music serves cover art as jpg in webp
|
|
2021-12-06 10:26:11
|
it could be that they dont care about the extension, as they should
|
|
|
|
Kasper
|
2021-12-06 10:26:31
|
I'm talking about what you send to them though, which they resize/convert to what they show users
|
|
|
|
Pigophone
|
2021-12-06 10:26:50
|
I think this whole thing is still just a UX problem
users currently, at this point, know jpg = bad and png = good but large filesize
|
|
|
|
Kasper
|
|
Cool Doggo
theres still nothing stopping someone from just converting a jpeg to png if it was originally a jpeg and they need a png
|
|
2021-12-06 10:27:00
|
absolutely, but in that case the intentions are clear
|
|
|
|
w
|
2021-12-06 10:27:08
|
it's like the transparent png meme
|
|
|
|
Pigophone
|
2021-12-06 10:27:19
|
yep, getting the png you want is not guaranteed, sometimes you want transparent images, so again you go search for png: but not all png are transparent
|
|
2021-12-06 10:27:36
|
should another extension for pngs with alpha channel be made? probably not lol
|
|
2021-12-06 10:28:05
|
all stems from file pickers being rudimentary `*.png` and not being able to filter anything more
|
|
|
|
w
|
2021-12-06 10:28:36
|
and that just makes people convert jpg to png
|
|
|
|
Pigophone
|
2021-12-06 10:28:38
|
you can have plugins for windows to add custom columns to explorer, and then filter on those, btw
|
|
|
|
w
|
2021-12-06 10:29:07
|
and converting jpg to png is more lossy
|
|
|
|
Pigophone
|
2021-12-06 10:29:25
|
i think in a perfect world that would be fine
concerned about getting a lossy jxl? enable the column in windows, filter for lossy, and you're good
|
|
|
|
_wb_
|
2021-12-06 10:58:53
|
i'd rather get a d0.5 jxl encoded from a high bit depth source than a lossless 8-bit jxl
|
|
2021-12-06 10:59:13
|
or a 20 MP lossy one rather than a 5 MP lossless
|
|
2021-12-06 11:03:12
|
having metadata about what happened to an image since capture can be useful; there's a JPEG adhoc group working on that (called JPEG Fake Media, https://jpeg.org/jpegfakemedia/index.html, because of course they want to ride hype trains)
|
|
2021-12-06 11:03:51
|
but different extensions aren't going to help much
|
|
|
|
monad
|
|
Kasper
If people see/get a file with an unconventional extension, they would be confused though
|
|
2021-12-06 11:23:24
|
Thus, it's up to users what makes sense. It's possible some convention becomes popular if enough people find utility in this at-a-glance info. But files not under your control are prone to manipulation and you can't just trust the file extension or metadata and use that to assume a certain relationship with some original representation.
|
|
|
|
Kasper
|
2021-12-06 11:29:23
|
It's not really about preventing manipulation, you can of course screenshot a JPG if you want to. The point is to have a good UX for dealing with ideally-lossless files and prevent accidental loss when it's unwanted
|
|
|
|
improver
|
2021-12-07 12:28:06
|
tbh i can only see possibility of having .ll.jxl, .orig.jxl or something like that convention, rather than .jxll or .ljxl, because quite low importance combined with .jxl already being convention. i think its registered for IANA that way too. also i dont think there is significant precedent of any other popular format doing extensions this way, and a few actually intentionally using fewer extensions (.webp is the same for lossy/lossless, also .avifs -> .avif) though these formats arguably aren't fit to be used for mastering workflows.
|
|
2021-12-07 12:28:34
|
there is also thing that windows by default hides extensions
|
|
2021-12-07 12:29:53
|
so not using extension but instead convention like .ll.jxl could be more visible there
|
|
2021-12-07 12:30:50
|
alternative would be windows showing .ljxl thumbnails somehow differently
|
|
2021-12-07 12:39:46
|
i can kinda see benefit of having master jxl extension for specialised workflows of stuff like editing with photoshop, gimp, etc, but i kinda don't see much benefit of having that tied solely to modular encoding: post-mastering stuff could compromise resolution, quality and color depth even if modular is still used for encoding
|
|
|
|
Kasper
|
2021-12-07 12:51:51
|
perhaps it could be a different thing entirely: A "Lossless JPEG XL" container which is not a valid `.jxl`, but it contains a `jxl` inside it. Then if you decide to export an `.ljxl`, the encoder will only be able to generate the `.ljxl` losslessly
|
|
2021-12-07 12:54:27
|
then if you want to have a lossless `.jxl` you still can, but without the guarantee of it being generated losslessly
|
|
|
|
Fraetor
|
2021-12-07 01:07:25
|
If you do that, don't you lose the benefit of jxl being a universal format though?
|
|
|
|
monad
|
2021-12-07 01:19:37
|
In encoding, you just need a lossless checkbox (or distance/quality slider with informative description in the case d0=lossless). I'm convinced the average user doesn't know the implications of JPEG vs PNG and many can't even tell you they're image formats, but I'd like to think professionals and savvy users will adapt to JXL just like anything else.
|
|
|
|
Kasper
|
|
Fraetor
If you do that, don't you lose the benefit of jxl being a universal format though?
|
|
2021-12-07 01:23:04
|
I don't really think so. It would be a separate format which provides a guarantee of lossless encoding, which is something `.jxl` doesn't provide anyway
|
|
|
|
Cool Doggo
|
2021-12-07 01:24:14
|
are you saying it doesnt have lossless at all?
|
|
|
|
monad
|
2021-12-07 01:24:18
|
GIF guarantees lossless encoding. I wouldn't say it's practical.
|
|
|
|
Fraetor
|
|
Kasper
I don't really think so. It would be a separate format which provides a guarantee of lossless encoding, which is something `.jxl` doesn't provide anyway
|
|
2021-12-07 01:25:39
|
You can generally guarantee that a recompressed JPEG is the same as the original. And modular being used is a go indicator otherwise.
|
|
|
|
Kasper
|
|
Cool Doggo
are you saying it doesnt have lossless at all?
|
|
2021-12-07 01:25:39
|
like `.jxl` could be losslessly encoded, but `.ljxl` guarantees lossless encoding
|
|
|
The_Decryptor
|
2021-12-07 01:26:22
|
Sounds like a job for FLIF
|
|
|
|
Fraetor
|
2021-12-07 01:26:42
|
If its just file extension, then that could just be a setting with whatever produces the file. I personally still prefer `*.ll.jxl` as it would maintain compatibility with existing viewers.
|
|
|
|
Kasper
|
|
monad
GIF guarantees lossless encoding. I wouldn't say it's practical.
|
|
2021-12-07 01:27:07
|
how so? Isn't that the same as PNG?
|
|
|
|
Cool Doggo
|
2021-12-07 01:27:21
|
png can use lossy encoding as stated before but it doesnt need a separate extension for it
|
|
2021-12-07 01:27:40
|
if the goal is for the average user to tell them apart, most of them dont know what file extensions are
|
|
|
|
Fraetor
|
|
Kasper
how so? Isn't that the same as PNG?
|
|
2021-12-07 01:28:17
|
GIF has other drawbacks, like very limited colour pallets, and lack of colourspace information.
|
|
|
|
Kasper
|
|
The_Decryptor
Sounds like a job for FLIF
|
|
2021-12-07 01:29:07
|
yeah perhaps
|
|
|
|
Fraetor
|
2021-12-07 01:34:36
|
I think I still stand by my statement that as long as an image is "good enough" quality, whether it is truly lossless doesn't really matter.
|
|
|
|
Kasper
|
|
Cool Doggo
if the goal is for the average user to tell them apart, most of them dont know what file extensions are
|
|
2021-12-07 01:35:17
|
the goal is to prevent accidental loss for average users, in cases where lossless is important, and to make it easy for anyone to tell if a file is encoded losslessly
|
|
|
|
Cool Doggo
|
2021-12-07 01:35:56
|
again though, what makes you think the average user will know the difference between .ljxl and .jxl
|
|
|
|
Fraetor
|
2021-12-07 01:36:51
|
I think that is more of a UX thing then. Like the upload box returning an error if a low quality image is uploaded. I guess that could be inferred from the modularness?
|
|
|
|
w
|
2021-12-07 01:36:56
|
isnt it better to not know if it is lossless or not
|
|
2021-12-07 01:37:02
|
to avoid accidental loss
|
|
|
|
Kasper
|
2021-12-07 01:37:04
|
maybe they won't, but in that case they at least can learn to check the file extension
|
|
|
|
Fraetor
|
2021-12-07 01:37:16
|
Is there a way to tell at what distance an image was encoded at?
|
|
|
|
Kasper
|
2021-12-07 01:37:21
|
the alternative is learning that the file was encoded in the wrong quality and somehow figuring out what to do about that
|
|
|
|
Fraetor
|
2021-12-07 01:37:36
|
Like with JPEG you could tell the quality by looking at the quantisation tables.
|
|
|
|
w
|
2021-12-07 01:37:44
|
because the jpeg straight from the camera would be less lossy than a png
|
|
|
|
Kasper
|
|
Fraetor
I think that is more of a UX thing then. Like the upload box returning an error if a low quality image is uploaded. I guess that could be inferred from the modularness?
|
|
2021-12-07 01:37:58
|
It is all about UX, yes
|
|
|
|
Fraetor
|
2021-12-07 01:46:45
|
What can be done to tell the difference between this
|
|
|
|
embed
|
2021-12-07 01:46:49
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/917592940703006750/d0.jxl
|
|
|
|
Fraetor
|
2021-12-07 01:46:54
|
and this.
|
|
|
|
embed
|
2021-12-07 01:46:57
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/917592980221751366/d20.jxl
|
|
|
|
monad
|
2021-12-07 01:51:11
|
If this is really about the average user and not about individual/company needs, it sounds like a problem that doesn't actually exist. The average user doesn't care. They take screenshots on their phone instead of saving image files from web pages. If you ask for a high quality image, they'll look at the image visually, not at the file format. They'll only care what a PNG is if you actually refuse uploads of their JPEGs.
|
|
|
|
Pigophone
|
2021-12-07 01:54:46
|
user tries to upload jpg to service, service says "please only use png for lossless!", user googles "convert jpg to png online", then uploads "lossless" png to service...
|
|
|
|
Fraetor
|
2021-12-07 01:55:20
|
That does seem like a risk.
|
|
|
|
monad
|
2021-12-07 01:55:45
|
You ask them for the original image, all bets are off. You're likely receive something they download from their Facebook profile.
|
|
|
|
Kasper
|
|
monad
If this is really about the average user and not about individual/company needs, it sounds like a problem that doesn't actually exist. The average user doesn't care. They take screenshots on their phone instead of saving image files from web pages. If you ask for a high quality image, they'll look at the image visually, not at the file format. They'll only care what a PNG is if you actually refuse uploads of their JPEGs.
|
|
2021-12-07 01:55:50
|
average in terms of how technically savvy they are then
|
|
|
|
Fraetor
|
2021-12-07 01:55:52
|
Especially if the person uploading images is a different one to the one creating them, which I imagine is the case most of the time.
|
|
|
|
Cool Doggo
|
|
Fraetor
That does seem like a risk.
|
|
2021-12-07 01:56:18
|
(you havent seen enough discord stickers)
|
|
|
|
Fraetor
|
2021-12-07 01:57:05
|
If you only have a high quality lossy, and not the source psd or whatever, you are going to have to work from that.
|
|
|
|
Kasper
|
|
Pigophone
user tries to upload jpg to service, service says "please only use png for lossless!", user googles "convert jpg to png online", then uploads "lossless" png to service...
|
|
2021-12-07 01:59:09
|
that's the worst case scenario. Otherwise it's "oh, I'll make sure to export it as png instead of jpg"
|
|
|
|
Cool Doggo
|
2021-12-07 01:59:36
|
that is not a "worst case scenario" that happens all the time
|
|
|
|
Kasper
|
2021-12-07 02:00:10
|
it's still the worst case scenario
|
|
2021-12-07 02:00:47
|
which is fine, can't do anything about that
|
|
|
|
Fraetor
|
2021-12-07 02:01:46
|
Bringing it back to something relevant to jxl, I think it would be good to have a way to tell what quality a jxl file was compressed at, and particularity if it was lossless. I just wonder if this can already be inferred from the bitstream.
|
|
|
|
Cool Doggo
|
2021-12-07 02:02:52
|
https://discord.com/channels/794206087879852103/794206170445119489/915730747711696937
|
|
|
|
Fraetor
|
2021-12-07 02:03:39
|
Is VarDCT always lossy? (excluding JPEG recompression)
|
|
2021-12-07 02:03:58
|
So do you only apply these if the image is modular?
|
|
|
|
monad
|
2021-12-07 02:06:55
|
More detailed: <https://www.reddit.com/r/jpegxl/comments/oxp5df/comment/h7p99pl/>
|
|
|
|
Fraetor
|
2021-12-07 02:07:20
|
Thanks.
|
|
|
|
_wb_
|
2021-12-07 06:28:11
|
Lossless is a property of a workflow, not of a file format. If a user does not keep track of what they're doing, there is no way to avoid accidents like opening `original-photo.jpg`, doing editing in gimp/photoshop, saving the result as `edited-original.png`, also saving a lower-quality png8 web version as `web-version.png`, then later opening the latter one, adjust something a bit, save the result as `edited-version2.png`.
|
|
2021-12-07 06:31:21
|
That is why editors have their own formats like XCF and PSD and make a somewhat artificial distinction between "saving" an image and "exporting" an image - it helps to avoid such workflow accidents.
|
|
|
|
Kasper
|
2021-12-07 07:21:46
|
indeed
|
|
|
lithium
|
2021-12-07 08:00:21
|
Sorry for little off topic,
What cjxl target distance can call slight lossy?(near-lossless, like webp near-lossless 40 and 60.),
get 1 generation loss, but can use full jxl vardct function and potential.
|
|
|
|
_wb_
|
2021-12-07 08:41:11
|
How tall is a small tree?
|
|
2021-12-07 08:41:57
|
Some people will say 2 meters, others will say 10 cm
|
|
|
|
monad
|
|
lithium
Sorry for little off topic,
What cjxl target distance can call slight lossy?(near-lossless, like webp near-lossless 40 and 60.),
get 1 generation loss, but can use full jxl vardct function and potential.
|
|
2021-12-07 08:49:51
|
Luca suggested 0.1 before https://discord.com/channels/794206087879852103/794206170445119489/882011102362345542
|
|
|
|
lithium
|
2021-12-07 08:50:39
|
If use maxButteraugli or 9-norm for quality standard?
I guess d 0.3 probably can guarantee quality? and don't have surprise situation.
oh I see, thank you ๐
|
|
|
|
monad
|
2021-12-07 08:55:13
|
Jyrki suggested using 6-norm in comparing with human evaluation https://discord.com/channels/794206087879852103/840831132009365514/900641563233906689 <https://github.com/libjxl/libjxl/issues/202#issuecomment-867049100>
|
|
2021-12-07 08:58:56
|
If my assumption is right that BT == butteraugli, here is a comparison against humans https://discord.com/channels/794206087879852103/805176455658733570/897584775148224523
|
|
|
|
lithium
|
2021-12-07 09:04:56
|
oh no...
> veluca: results can be summarized in "all metrics suck" xD but some more numbers...
|
|
|
|
_wb_
|
2021-12-07 09:41:40
|
to be fair, those correlation numbers are for the results of AI-based codecs, which have been trained to fool metrics basically
|
|
2021-12-07 09:41:56
|
for classical codecs metrics are somewhat more useable
|
|
2021-12-07 09:42:37
|
(though still you can't really use metric X to compare results of encoder A and B if A optimizes for X and B doesn't)
|
|
|
Traneptora
|
2021-12-07 05:35:28
|
I'm getting larger files with distance=0.2 effort=9 than I am with distance=0.2 effort=7
|
|
2021-12-07 05:35:56
|
is this somewhat ordinary or is this due to a bug?
|
|
2021-12-07 05:36:05
|
the imagery in this case is synthetic (mostly screenshots of a video game), VarDCT mode
|
|
2021-12-07 05:45:33
|
```
leo@gauss ~/archive/2021-09 $ find -name '*.png' -print0 | while read -r -d $'\0' finput; do cjxl --distance=0.2 --effort=9 --num_threads=4 "$finput" "${finput%.png}.jxl"; done
...
JPEG XL encoder v0.7.0 ea2612d6 [AVX2]
Read 2400x1080 image, 24.8 MP/s
Encoding [Container | VarDCT, d0.200, tortoise | 273-byte Exif], 4 threads.
Compressed to 912445 bytes (2.816 bpp).
2400 x 1080, 0.07 MP/s [0.07, 0.07], 1 reps, 4 threads.
Including container: 912770 bytes (2.817 bpp).
leo@gauss ~/archive/2021-09 :) $ find -name '*.jxl' -exec stat -c%s {} + | total
135009049
leo@gauss ~/archive/2021-09 :) $ hprint <<<135009049
128.75 Mi
leo@gauss ~/archive/2021-09 $ find -name '*.png' -print0 | while read -r -d $'\0' finput; do cjxl --distance=0.2 --effort=7 --num_threads=4 "$finput" "${finput%.png}.jxl"; done
...
JPEG XL encoder v0.7.0 ea2612d6 [AVX2]
Read 2400x1080 image, 32.6 MP/s
Encoding [Container | VarDCT, d0.200, squirrel | 273-byte Exif], 4 threads.
Compressed to 839075 bytes (2.590 bpp).
2400 x 1080, 7.28 MP/s [7.28, 7.28], 1 reps, 4 threads.
Including container: 839400 bytes (2.591 bpp).
leo@gauss ~/archive/2021-09 :) $ find -name '*.jxl' -exec stat -c%s {} + | total
124213304
leo@gauss ~/archive/2021-09 :) $ hprint <<<124213304
118.46 Mi
```
|
|
2021-12-07 05:46:32
|
why would effort=7 produce more efficient encoding of the same distance=
|
|
|
|
fab
|
2021-12-07 06:22:46
|
Can you send me the First output
|
|
2021-12-07 06:22:52
|
What it looks like
|
|
2021-12-07 06:23:12
|
I don't know what High vmaf should look like
|
|
|
|
Traneptora
|
|
|
fab
|
2021-12-07 06:24:46
|
thanks beautiful image
|
|
2021-12-07 06:24:57
|
if you also have the speed to upload oiginal
|
|
|
|
Cool Doggo
|
|
Traneptora
is this somewhat ordinary or is this due to a bug?
|
|
2021-12-07 06:40:10
|
from my experience higher effort doesn't necessarily mean it is the same quality just at a lower file size, the e9 might be bigger but also look better
|
|
|
|
Traneptora
|
2021-12-07 06:40:33
|
at d0.2 and e7 I personally could not tell a difference from the source
|
|
2021-12-07 06:40:48
|
even when zooming in and squinting at my monitor
|
|
2021-12-07 06:40:59
|
so "look better" to me doesn't quite matter in this context
|
|
2021-12-07 06:41:15
|
I'd hope that butteraugli distance is designed to mitigate that issue tho
|
|
|
|
Cool Doggo
|
2021-12-07 06:42:40
|
yes at d0.2 it probably doesnt matter ยฏ\\_(ใ)\_/ยฏ
|
|
|
|
Traneptora
|
2021-12-07 06:42:58
|
I'll stick with 0.7 then
|
|
2021-12-07 06:43:11
|
I tried d=0.2 modular as well and it was far slower for no benefit
|
|
2021-12-07 06:43:18
|
like it was essentially the same as doing d=0 modular lossless
|
|
2021-12-07 06:43:36
|
it's unfortunate how slow modular is compared to VarDCT
|
|
|
|
_wb_
|
2021-12-07 07:47:47
|
The main difference between e7 and e8+ in VarDCT mode is that at e8+ it does Butteraugli iterations to ensure that every block actually hits the target distance
|
|
2021-12-07 07:49:10
|
At lower effort, it uses heuristics that will appromixate the target on average, but might overshoot or undershoot locally or depending on the image contents.
|
|
2021-12-07 07:50:33
|
With cjxl I think you have to use -m -q 90 (or whatever number) to do lossy modular. I don't think -m -d X does anything different than just -m
|
|
2021-12-07 07:51:28
|
And yes, if you're going to do d0.2, it doesn't matter much if you use e7 or e8+
|
|
2021-12-07 07:52:56
|
At d1 it matters more: for some images, -e 7 -d 1 can have some artifacts because the actual distance could be 1.5 or more, while with -e 8 -d 1 it's more likely that the actual distance will be close to 1
|
|
2021-12-07 07:54:11
|
So just to clarify: in vardct mode, encode effort mostly means "spend more time on ensuring quality", not so much "spend time on improving compression density".
|
|
2021-12-07 07:54:51
|
Though it does both, and generally the density will be better (on a corpus level, not per image)
|
|
|
yurume
|
2021-12-09 07:50:33
|
so one of my friends needed to archive a potentially large number of facial images near-losslessly, so I naturally suggested to use modern image formats including jxl
|
|
2021-12-09 07:51:29
|
after some testing one concluded that avif (q70) was a best fit for one's job, that's not surprising
|
|
2021-12-09 07:52:04
|
what made me amused was that jxl d1.0 was not enough at least for one's task, even worse than libjpeg q80 (!!!)
|
|
2021-12-09 07:52:48
|
it turns out that not just facial features but also hair features had to be preserved, and jxl d1.0 at the default parameters didn't give a good result
|
|
2021-12-09 07:54:06
|
one handed me this example, where individual hair threads are heavily warped (not just aliasing artifacts)
|
|
2021-12-09 07:55:30
|
the same image with higher brightness & contrast
|
|
2021-12-09 07:56:22
|
according to that test the following parameters are roughly acceptable for one: libjpeg q80 (>>1.4bpp), webp q90 (~1.4bpp), jxl d0.5 e7--8, avif q70 (~0.9bpp)
|
|
|
|
improver
|
2021-12-09 07:57:26
|
d1.0 is totally not for near-lossless use
|
|
|
|
yurume
|
2021-12-09 07:57:40
|
so my question is that: yeah it might not be a typical use case, but is there any sort of suggestion to reduce this kind of artifacts while keeping the roughly same size target?
|
|
2021-12-09 07:58:06
|
it's correct, but keep in mind that avif q70 was deemed acceptable
|
|
2021-12-09 07:58:27
|
so one needed a particular aspect of near-losslessness, which avif provides at much lower quality and jxl apparently didn't
|
|
|
|
improver
|
2021-12-09 08:00:22
|
what bpp is jxl in that? if it's same (~0.9bpp) then i guess that'd be fine..?
|
|
|
|
yurume
|
2021-12-09 08:01:28
|
one didn't tell that, but presumably much larger than 0.9bpp?
|
|
2021-12-09 08:01:40
|
I'll ask again
|
|
|
improver
what bpp is jxl in that? if it's same (~0.9bpp) then i guess that'd be fine..?
|
|
2021-12-09 08:04:19
|
d0.5 e7 (acceptable): 1.8bpp, d1.0 e7: 1.08bpp, d1.0 e8 (both unacceptable): 1.05bpp
|
|
2021-12-09 08:05:14
|
my first guess was that the viewing distance will probably matter, but I'm no expert of jxl parameter tuning
|
|
2021-12-09 08:06:05
|
(one also noted that libjxl at e7--8 was far slower than other solutions, but understood that libjxl is still at the beta stage and might still be fine for the archival use)
|
|
|
|
improver
|
2021-12-09 08:16:51
|
this looks kinda bad
|
|
2021-12-09 08:16:57
|
i wonder if this is because area is dark
|
|
|
|
lithium
|
2021-12-09 08:47:22
|
I think for sharp line area, probably can try higher epf for this case.
> cjxl -d 0.8 -e 8 --epf=3
|
|
|
|
yurume
|
2021-12-09 09:16:21
|
oh, so -d 1.0 only uses --epf=1 internally...
|
|
|
|
_wb_
|
2021-12-09 09:50:24
|
maybe it's a colorspace issue. if you're going to display the image a lot brighter than the input, then you should do the brightening before encoding, not after decoding
|
|
|
|
lithium
|
2021-12-09 09:51:00
|
I also have some high contrast sharp line tiny artifacts issue for non-photo content(drawing).
for now higher epf and effort value have some help,
but I think if jxl can improve those content quality and implement some features, that will be great.
|
|
|
|
w
|
2021-12-09 09:57:52
|
the solution is d0
|
|
|
|
lithium
|
2021-12-09 10:06:05
|
lossless is great, but I guess high quality lossy(near-losslessly) also a reasonable option.
|
|
|
|
yurume
|
|
_wb_
maybe it's a colorspace issue. if you're going to display the image a lot brighter than the input, then you should do the brightening before encoding, not after decoding
|
|
2021-12-09 10:07:00
|
for the record it was not for the display purpose, it was going to be fed into other things that I can't publicly share
|
|
2021-12-09 10:08:00
|
maybe one was particularly concerned with that artifact due to the uncertainty of the future processing
|
|
|
|
_wb_
|
2021-12-09 10:08:03
|
maybe it can help to set a higher intensity target
|
|
2021-12-09 10:08:42
|
the jxl encoder assumes that the image it gets is the image that will be shown, and adjusts perceptual compression based on that
|
|
2021-12-09 10:09:30
|
if you're going to adjust the brightness or colors afterwards, you can make compression artifacts visible that weren't visible before
|
|
|
|
yurume
|
|
_wb_
maybe it can help to set a higher intensity target
|
|
2021-12-09 10:24:55
|
one tried this and also `--epf=3` and reported that only the higher intensity target worked, at the expense of bpp (expected, but still oops)
|
|
|
|
fab
|
2021-12-09 10:37:57
|
libjxl encoder will impove in quality
|
|
|
|
Cool Doggo
|
|
yurume
one handed me this example, where individual hair threads are heavily warped (not just aliasing artifacts)
|
|
2021-12-09 11:21:06
|
can you show the q80 jpeg for this example?
|
|
|
|
lithium
|
2021-12-09 12:59:43
|
Cool, look like higher intensity really help for reduce tiny artifacts,
I think I will always use --intensity_target=4000 on my RGB24 content.
|
|
|
|
fab
|
2021-12-09 01:00:54
|
No it will make your picture hdr
|
|
2021-12-09 01:00:58
|
Avoid
|
|
|
|
spider-mario
|
2021-12-09 01:26:00
|
intensity_target is not primarily meant as a rate control parameter
|
|
2021-12-09 01:26:14
|
it means โthe image is meant to be displayed at <n> cd/mยฒโ
|
|
2021-12-09 01:26:32
|
and for a typical SDR photo, you donโt actually want _n_ to be 4000
|
|
2021-12-09 01:27:49
|
the intensity target actually gets saved in the jxl metadata, you can see it with jxlinfo
|
|
2021-12-09 01:28:52
|
it also affects the scale of the XYB data
|
|
|
Orum
|
2021-12-09 02:37:25
|
it might not be *intended* as that, but I don't know of another way to get JXL to allocate more bits to dark areas (while keeping overall size the same)
|
|
2021-12-09 02:37:48
|
I always use a very high intensity target or the dark areas turn to mud
|
|
|
|
lithium
|
2021-12-09 03:52:59
|
I understand intensity target not a rate control parameter,
but I notice when I use higher intensity target(4000) can reduce those tiny artifacts for drawing content,
I don't know why increase intensity target will affect those tiny artifacts.
> cjxl -d 0.3 -e 8 --intensity_target=4000 --epf=3 --num_threads=12
> non-photo(drawing) png RGB24 8 bitdepth (icc profile adobe RGB 1998)
|
|
|
|
spider-mario
|
|
Orum
it might not be *intended* as that, but I don't know of another way to get JXL to allocate more bits to dark areas (while keeping overall size the same)
|
|
2021-12-09 04:01:35
|
by not intended, I also mean that it is not just used as that
|
|
2021-12-09 04:02:01
|
if you output to PQ and display that as HDR, the problem will be apparent
|
|
|
|
BlueSwordM
|
2021-12-09 04:10:44
|
4000 is a bit extreme though.
400 is better most of the time for SDR content.
|
|
2021-12-09 04:11:07
|
I'm wondering if a low luma AQ-mode switch could be worked into JXL's aq-modes.
|
|
|
|
lithium
|
2021-12-09 04:21:59
|
Thank you for your help ๐
For now I get some issue on dark red area, and increace intensity target can reduce tiny artifacts,
400 is a good value, but I guess maybe I need find a better value to reach better quality.
|
|
|
novomesk
|
2021-12-09 04:31:18
|
One PR waiting here: https://github.com/jxl-community/jxl-community.github.io/pull/2
|
|
|
|
_wb_
|
|
spider-mario
by not intended, I also mean that it is not just used as that
|
|
2021-12-09 04:48:28
|
maybe we need an encode option that sets the intensity target for the purpose of the perceptual distance computation without setting it as the actual display intensity
|
|
|
|
spider-mario
|
2021-12-09 04:49:50
|
that does sound like an option
|
|
|
|
Hello71
|
2021-12-09 05:27:22
|
could be handled by jxltran ๐
|
|
|
|
spider-mario
|
2021-12-09 05:58:21
|
I am not actually sure it could, could it? it also affects the XYB scaling
|
|
|
|
Deleted User
|
2021-12-09 07:27:24
|
I guess a flag that disables some perceptual optimizations would be better for this case.
|
|
|
|
lithium
|
2021-12-10 07:54:08
|
# jxl intensity_target and non-photo(drawing) test
|
|
2021-12-10 07:56:02
|
I guess increase intensity_target can help reduce error?
|
|
2021-12-10 01:01:35
|
What's XYB scaling? intensity_target option will control this value?
|
|
|
|
spider-mario
|
2021-12-10 01:50:43
|
what I mean by that is that with a higher intensity target, the image is represented by higher XYB values
|
|
2021-12-10 01:50:47
|
(but not linearly so)
|
|
2021-12-10 01:51:24
|
i.e. the light in the image is actually scaled in its XYB representation
|
|
|
|
lithium
|
2021-12-10 02:24:50
|
Thank you for your reply ๐
On previous test, I try to reduce those tiny artifacts for drawing content(RGB24),
so I use c 1(None) on vardct mode, without color transform can reduce tiny artifacts and increase file size,
but will create other issue.
This time, I try higher intensity target for drawing content(RGB24),
I think intensity target 4000 really can reduce those tiny artifacts and let pixel more like original image.
Maybe those tiny artifacts will happen on lower XYB values?
and drawing content need higher XYB values to preserve colors?
|
|
|
|
_wb_
|
2021-12-10 02:45:21
|
I think what will help more for drawings is to use flat(ter) quantization matrices than the ones we currently use.
|
|
2021-12-10 02:45:52
|
That and somehow using patches of modular more effectively
|
|
|
|
fab
|
|
|
lithium
|
2021-12-10 06:32:24
|
It's possible use flat and steep quantization matrices in same time for different block?
|
|
|
|
_wb_
|
2021-12-10 06:37:10
|
Only if it's done in separate layers
|
|
2021-12-10 06:37:58
|
Though you could also e.g. make the 8x8 tables flat and the 8x16 tables steep
|
|
|
|
lithium
|
2021-12-10 06:46:18
|
Cool, I really look forward 2022 jxl separate improvement.<:BlobYay:806132268186861619>
|
|
|
|
Deleted User
|
2021-12-14 05:41:54
|
I hate jxl because it doesn't produce the abhorrent and distorted results jpegs do when compressed. Not as funny to look at. 0/10
|
|
|
|
_wb_
|
2021-12-14 06:12:35
|
We can make funny glitch art, just need to disable the error detection
|
|
|
Fox Wizard
|
2021-12-14 06:20:45
|
Yeah, we all know JPEG is superior and has very high quality (mozjpeg q2 tune hvs-psnr)
|
|
2021-12-14 06:22:26
|
Sad, jxl doesn't even seem to be able to get that small <:Cheems:884736660707901470>
|
|
2021-12-14 06:26:08
|
Heh, optimizing makes it almost 2% smaller, surprising since mozjpeg was used
|
|
|
|
_wb_
|
|
Fox Wizard
Sad, jxl doesn't even seem to be able to get that small <:Cheems:884736660707901470>
|
|
2021-12-14 06:39:02
|
What happens if you losslessly recompress that jpeg?
|
|
|
|
Fox Wizard
|
2021-12-14 06:40:18
|
Very big reduction in size :p
|
|
2021-12-14 06:40:50
|
4.79KB --> 2.36KB
|
|
2021-12-14 06:40:51
|
Nice
|
|
|
eddie.zato
|
2021-12-14 11:50:46
|
I disagree, jxl is fun <:CatSmile:805382488293244929>
|
|
2021-12-14 11:54:56
|
`-q` is random between `85.0` and `95.0`
|
|
|
|
Fox Wizard
|
2021-12-14 12:03:18
|
Lol
|
|
2021-12-14 12:03:25
|
And now with WebP and avif <:KekDog:884736660376535040>
|
|
|
|
Orum
|
2021-12-14 03:44:33
|
does jxl have an embedded checksum?
|
|
|
|
veluca
|
2021-12-14 03:46:37
|
kinda sorta
|
|
2021-12-14 03:46:41
|
sometimes
|
|
2021-12-14 03:46:56
|
why would it be useful?
|
|
|
|
Orum
|
2021-12-14 03:54:52
|
no, I was hoping it didn't
|
|
|
|
_wb_
|
2021-12-14 04:33:19
|
you want to glitch it?
|
|
2021-12-14 04:34:36
|
when using ANS, encode side you start with an arbitrary start state, then encode everything in reverse order, and the end state is then put in the bitstream and will be the start state for the decoder
|
|
2021-12-14 04:36:55
|
when the decoder is done, its end state can be checked to see if it matches what the encoder started with (we just start from the same arbitrary start state for all ANS streams)
|
|
2021-12-14 04:37:31
|
every group has an independent ANS stream, so that basically gives us error detection per 256x256 region
|
|
2021-12-14 04:39:30
|
you can build a djxl with FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION defined, that will disable the ANS end state check
|
|
2021-12-14 04:40:11
|
a bit more might be needed if you want it to happily decode glitched files
|
|
2021-12-14 04:40:50
|
I think it also checks if the group size matches the size given in the TOC exactly (up to byte padding)
|
|
2021-12-14 04:42:04
|
<@!179701849576833024> maybe we need to also disable those checks in the fuzzing builds? just make it power through any corrupt file, basically?
|
|
|
|
Orum
|
|
_wb_
you can build a djxl with FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION defined, that will disable the ANS end state check
|
|
2021-12-14 06:24:16
|
thanks, I'll give this a try
|
|
|
|
veluca
|
2021-12-14 06:30:49
|
I think we don't check that
|
|
|
|
_wb_
|
2021-12-14 06:36:41
|
Well we do have https://github.com/libjxl/libjxl/blob/main/lib/jxl/dec_bit_reader.h#L237
|
|
2021-12-14 06:37:42
|
Which will fail when reading more than the group bytes, I assume
|
|
2021-12-14 06:38:16
|
And I think we also check that padding bits are zero
|
|
2021-12-14 06:44:49
|
Not sure if we check that all group bytes are actually consumed though
|
|
|
|
veluca
|
2021-12-15 09:52:24
|
pretty sure we don't ๐
|
|
|
|
_wb_
|
2021-12-15 09:58:54
|
so if you glitch a jxl, if the ANS reader as a result tries to overread a group it will cause failure, but if it underreads it it will be fine (assuming a fuzzing build that doesn't check ANS state)
|
|
|
|
veluca
|
|
|
fab
|
2021-12-15 12:39:51
|
When Will we have complete jpeg xl standard?
|
|
|
|
_wb_
|
2021-12-15 12:44:22
|
we already have it, part 1 was approved very recently, and part 2 was approved in October
|
|
2021-12-15 12:45:34
|
parts 3 and 4 are not really the spec โ 3 describes how to check if your decoder conforms, and 4 gives an example implementation (which is just a .zip with a snapshot of libjxl)
|
|
|
|
fab
|
2021-12-15 06:50:25
|
|
|
2021-12-15 06:50:33
|
why this file is slow to decode?
|
|
2021-12-15 06:51:06
|
i poduced it with latest libjxl
|
|
|
|
_wb_
|
2021-12-15 06:59:21
|
What encode options did you use?
|
|
|
|
fab
|
2021-12-15 07:05:41
|
s seven d one
|
|
2021-12-15 07:05:55
|
i think
|
|
2021-12-15 07:06:01
|
no i didn't encode now
|
|
2021-12-15 07:06:16
|
yes s sevwen d one
|
|
2021-12-15 07:34:32
|
wb
|
|
2021-12-15 07:35:43
|
So normal jxl decoding with another lossless transcode file did 28 mpx/s on i3 330m four threads
|
|
2021-12-15 07:36:12
|
But for this Image i had 1,4 mpx
|
|
2021-12-15 07:36:25
|
And 3,8 mpxz max
|
|
2021-12-15 07:36:48
|
This lossy transcoded from a png s 7 d 1
|
|
|
|
BlueSwordM
|
|
_wb_
What encode options did you use?
|
|
2021-12-15 08:23:35
|
He seems to have used `-e 7 -d 1.0`
|
|
2021-12-15 08:23:38
|
So, defaults.
|
|
|
|
fab
|
2021-12-15 08:24:04
|
|
|
2021-12-15 08:24:13
|
with vey latest commit
|
|
2021-12-15 08:24:17
|
situation impove
|
|
|
|
_wb_
|
2021-12-15 08:30:46
|
the speed difference is probably due to use of patches - modular decode is slower than vardct decode
|
|
2021-12-15 08:31:26
|
you can encode with -e 6 or --patches=0 if you want to get more consistent decode speeds (at the expense of compression density)
|
|
|
|
Traneptora
|
2021-12-16 11:27:40
|
Who here wrote the Jpeg XL GIMP export plugin?
|
|
2021-12-16 11:27:46
|
I found a (minor) bug in the UI
|
|
|
|
improver
|
2021-12-16 11:32:27
|
xiota did a lot of changes to it iirc
|
|
2021-12-16 11:33:03
|
but then if we're talking about the one which got upstreamed then its someone else
|
|
|
|
Scope
|
2021-12-16 11:33:12
|
and novomesk
|
|
|
|
Traneptora
|
2021-12-16 11:33:40
|
I just noticed that if you toggle "Lossless Mode" on, it checks the box "avoid XYB colorspace" which is correct behavior
|
|
2021-12-16 11:33:44
|
but if you *leave* lossless mode on
|
|
2021-12-16 11:33:56
|
and then check and then uncheck "advanced settings"
|
|
2021-12-16 11:34:15
|
it leaves the lossless mode toggle set, but unchecks "avoid xyb" which makes it not lossless
|
|
2021-12-16 11:34:51
|
It's a minor UI bug, but I figure I'd report it
|
|
|
|
novomesk
|
|
Traneptora
and then check and then uncheck "advanced settings"
|
|
2021-12-16 01:52:45
|
That's the GIMP 2.10.x plug-in from libjxl repo.
|
|
|
|
Traneptora
|
2021-12-16 02:10:50
|
I see. I probably won't be able to take a look at it today
|
|
2021-12-16 02:11:13
|
or in the near future
|
|
2021-12-16 02:11:22
|
today my goal is to finish the FFmpeg plugin
|
|
|
|
JendaLinda
|
2021-12-22 10:42:49
|
Would it be possible to get a JPEG image from JXL, if the original JPEG was transcoded without the reconstruction data (was stripped)? I assume the original data of the actual image are still intact.
I'm just wondering if it's necessary to save all the original JPEG headers if I don't care about the exact file structure, just the image itself.
|
|
|
|
veluca
|
2021-12-22 10:43:32
|
possible, yes
|
|
2021-12-22 10:43:38
|
implemented, no
|
|
|
|
JendaLinda
|
2021-12-22 10:53:34
|
I thought so. It seems that the decoder would have t do some checks, because without the reconstruction data it can't tell the image was transcoded from JPEG. Am I right?
|
|
|
|
veluca
|
2021-12-22 11:04:49
|
correct
|
|
|
|
_wb_
|
2021-12-22 01:32:24
|
It has to be ycbcr or rgb (not xyb), use vardct with only 8x8 dct, raw quant table with integer values, any other constraints to in principle output it as a jpeg?
|
|
2021-12-22 01:34:52
|
I'm kind of in favor of having a "default/implicit jbrd box" that corresponds to whatever default libjpeg-turbo would do with those coeffs (i.e. encode it in a baseline sequential way with fixed huffman tables and no special garbage)
|
|
|
perk
|
|
|
embed
|
2021-12-23 01:01:01
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/923560818979782706/button.jxl
|
|
|
|
perk
|
|
|
embed
|
2021-12-23 01:01:10
|
https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F794206170445119489%2F923560855268905050%2Fanibutton.jxl
|
|
|
|
_wb_
|
2021-12-23 01:02:38
|
nice ๐
|
|
|
|
perk
|
2021-12-23 01:04:21
|
Best viewed with neither netscape nor internet explorer
|
|
|
|
_wb_
|
2021-12-23 01:04:27
|
has a bit of a 90s vibe, haha
|
|
|
|
perk
|
2021-12-23 01:05:00
|
that's the idea
|
|
|
|
fab
|
2021-12-25 08:22:06
|
Best jxl audio 288 kbps
|
|
2021-12-25 08:23:48
|
Is only one Channel
|
|
2021-12-25 08:23:59
|
So is 144 kbps
|
|
2021-12-25 08:24:05
|
The one i encoddd
|
|
|
190n
|
2021-12-25 08:25:03
|
<:PepeGlasses:878298516965982308>
|
|
|
|
fab
|
2021-12-25 08:26:14
|
for %i in (C:\Users\Utente\Documents\dfdf\*.png) do cjxl -s 5 -d 0.817 --intensity_target=243 --epf=1 --noise=1 --gaborish=1 --faster_decoding=4 --patches=0 -I 0.351 %i %i.jxl
for %i in (C:\Users\Utente\Documents\dfdf\*.jxl) do djxl %i %i.png
|
|
2021-12-25 08:27:12
|
is a 13 mb build so is fomn doomnine is not the oiginal diff simd
|
|
|
|
Cool Doggo
|
2021-12-25 08:27:17
|
it sounds better than i would expect but some parts are *bad*
|
|
|
|
fab
|
2021-12-25 08:27:38
|
i notice the end i do not hea the bass dop
|
|
2021-12-25 08:28:32
|
Jaimaika doom9 build not the original
|
|
2021-12-25 08:29:10
|
Ah this is the left Channel of the Song
|
|
2021-12-25 08:42:56
|
but has a very wide frequency response
|
|
2021-12-25 08:47:46
|
at 2:01 i'm heaing atifacts after a sixth listens
|
|
2021-12-25 08:50:36
|
i'll tuy for %i in (C:\Users\Utente\Documents\vt\*.png) do cjxlh -s 8 -d 0.551 -I 0.6 --intensity_target=243 --epf=0 --faster_decoding=2 %i %i.jxl
|
|
2021-12-25 09:12:29
|
340 kbps reference encoder
|
|
2021-12-25 09:12:36
|
Turn low your volume
|
|
2021-12-25 09:12:55
|
It sounds awful too low
|
|
2021-12-25 09:13:29
|
And rms and Dynamic range are according to foobar same as original
|
|
|
|
monad
|
2021-12-26 08:12:40
|
I don't get it.
|
|
|
|
fab
|
2021-12-26 08:41:59
|
It hasnt so many autotune
|
|
2021-12-26 08:42:16
|
It is a bit too clipped
|
|
2021-12-26 08:42:42
|
But is because they are making to sound better
|
|
2021-12-26 08:43:04
|
The autotune Will be added in the High frequencies
|
|
2021-12-26 08:43:14
|
I choosed a bad master
|
|
2021-12-26 08:43:40
|
But anyway it was only to test
|
|
2021-12-26 08:43:48
|
Im not an audiophile
|
|
|
|
Cool Doggo
|
|
monad
I don't get it.
|
|
2021-12-26 06:50:45
|
it's an audio file that was converted to a PNG, compressed as a jxl, and then converted back to an audio file
|
|
|
|
monad
|
2021-12-27 10:18:20
|
I get it.
|
|
2021-12-27 10:22:52
|
A while ago, I did some superficial tests with lossless text compression in JXL and found it worse than PNG.
|
|
|
|
_wb_
|
2021-12-27 11:46:12
|
Did you try -e 9 -I 0 -P 0 -g 3 ?
|
|
|
|
Traneptora
|
2021-12-28 03:19:00
|
Alright, would anybody like to to some ~test~ing~
|
|
2021-12-28 03:30:17
|
https://github.com/thebombzen/FFmpeg/tree/libjxl
|
|
|
|
BlueSwordM
|
|
Traneptora
Alright, would anybody like to to some ~test~ing~
|
|
2021-12-28 04:10:30
|
Yes.
|
|
2021-12-28 04:10:39
|
What testing would you like for me to do?
|
|
|
|
monad
|
|
_wb_
Did you try -e 9 -I 0 -P 0 -g 3 ?
|
|
2021-12-28 07:44:18
|
Nope, just tried generally good parameters for images.
|
|
|
|
_wb_
|
2021-12-28 09:42:05
|
For text, you really need lz77 matching, which is something cjxl doesn't really do in most settings while png always does it
|
|
|
|
Traneptora
|
|
BlueSwordM
What testing would you like for me to do?
|
|
2021-12-28 01:22:35
|
see above github link. FFmpeg libjxl wrapper
|
|
2021-12-28 01:24:56
|
You can get a decent compression ratio with XZ on PCM if you do --delta=4
|
|
|
|
Hello71
|
2021-12-28 03:14:14
|
are animations supported now?
|
|
|
|
Traneptora
|
|
Hello71
are animations supported now?
|
|
2021-12-28 04:53:18
|
No, and they won't be for the time being
|
|
2021-12-28 04:53:44
|
seeing as I have a hard time getting samples because cjxl doesn't support anything written by apngasm
|
|
2021-12-28 04:54:32
|
more specifically, the big issue is that it's not possible to read a Jpeg XL ToC without implementing an ANS decoder, which will take a few thousand lines of code
|
|
2021-12-28 04:54:46
|
since the TOC is encoded with ANS
|
|
2021-12-28 04:55:13
|
(or rather, the permutatation function is encoded with ANS and the permutation function's existence is very common)
|
|
2021-12-28 04:55:54
|
in theory, it shouldn't matter since all I need to do is add the lengths together, but in general it's not possible to determine the length of an ANS-encoded stream without decoding it
|
|
2021-12-28 04:56:21
|
and the embedded ICC profile and permutation map are both ANS-encoded and occur before the TOC
|
|
2021-12-28 04:56:59
|
at least, this is what I gathered from talking to <@!179701849576833024>
|
|
2021-12-28 04:57:15
|
but the end result is that frame boundaries are going to be impossible to implement in the parser
|
|
2021-12-28 04:57:55
|
and since Jpeg XL spec allows *anything* to be concatenated at the end of a Jpeg XL file, including other valid Jpeg XL files, reading a sequence of Jpeg XL files from a pipe, concatenated, won't work either (it will be interpreted as one Jpeg XL file with crap at the end)
|
|
|
|
veluca
|
2021-12-28 04:59:25
|
I'm working on APNG support, it's not entirely trivial :D (and I'm slowed down by relatives :P)
|
|
|
|
Traneptora
|
2021-12-28 04:59:35
|
yea, which is great, and I appreciate it
|
|
2021-12-28 04:59:46
|
but it means that animated Jpeg XLs will have to wait for another time though
|
|
2021-12-28 04:59:59
|
I'd rather get what I can merged now
|
|
2021-12-28 05:01:16
|
because I have a parser, at least I can read from standard input now, which is nice
|
|
2021-12-28 05:01:27
|
and I can even parse and streamcopy jpegxl if libjxl is disabled
|
|
2021-12-28 05:01:43
|
the eventual goal is an internal decoder is implemented
|
|
2021-12-28 05:02:28
|
which will simplify these matters somewhat
|
|
2021-12-28 05:02:36
|
but I don't want the parser to depend on libjxl, only the decoder
|
|
|
|
BlueSwordM
|
2021-12-28 05:08:58
|
Hey. As long as we get JXL support before native AVIF support in ffmpeg, I'll be happy.
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
2021-12-29 08:19:38
|
๐ Just playing around with JXL while researching some things and it looks really neat! I'm thinking people in here would be able to help me with something. I've trying to find a good image format (lossy) for sending images over HF data links (very very very limited bandwidth) - and I'm targetting ~ 3KB of space. So far the best I've come up with is GIFs with limited colour palletes. Any ideas?
|
|
|
Nova Aurora
|
|
xssfox (vk3fur/vk4xss/she/her)
๐ Just playing around with JXL while researching some things and it looks really neat! I'm thinking people in here would be able to help me with something. I've trying to find a good image format (lossy) for sending images over HF data links (very very very limited bandwidth) - and I'm targetting ~ 3KB of space. So far the best I've come up with is GIFs with limited colour palletes. Any ideas?
|
|
2021-12-29 08:24:46
|
GIF isn't very efficent, PNG doesn't have that much lossy performance, AVIF and HEIC have very large headers which make them not very suitable for this application, which narrows down the options to webp, jpeg-xl, and jpeg (maybe j2k) in common use. What kind of images?
|
|
|
|
190n
|
2021-12-29 08:27:07
|
anything can be 3kb if it's low enough resolution (well except avif/heic maybe)
|
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
2021-12-29 08:27:27
|
my use case is photos. I've only just started playing with jpeg-xl so I'll see how it compares to some of my previous tests I've done, and yeah I've run into the header issues a bit
I am tempted to ensure that the image format (size, ect. are pre known) so that headers can be placed at the remote size
|
|
|
190n
anything can be 3kb if it's low enough resolution (well except avif/heic maybe)
|
|
2021-12-29 08:27:44
|
yup, just trying to get the best quality out of those 3kb :P
|
|
|
|
190n
|
|
xssfox (vk3fur/vk4xss/she/her)
my use case is photos. I've only just started playing with jpeg-xl so I'll see how it compares to some of my previous tests I've done, and yeah I've run into the header issues a bit
I am tempted to ensure that the image format (size, ect. are pre known) so that headers can be placed at the remote size
|
|
2021-12-29 08:30:20
|
that last bit is an interesting thought. iirc AVIF still outperforms JXL at low quality so if you really can fix the header on both ends (or maybe generate the full header given much less information, like only resolution) it might be the best choice
|
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
2021-12-29 08:31:46
|
Cool! I'll checkout AVIF
|
|
2021-12-29 08:33:10
|
here's the jpg/gif comparision I ran recently. It's a little hand wavy, and some what cherry picked but wanting to see if I can squeeze just a little bit more detail out of it
|
|
|
|
190n
|
2021-12-29 08:33:39
|
other thing to maybe think about is speed since AVIF is fairly slow and this sounds like a project with not the most powerful CPUs? but if it's low enough resolution to fit in 3kB, AVIF might be plenty fast <:kekw:808717074305122316>
|
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
2021-12-29 08:34:43
|
should be fine, in my case I'm using a pi4 and image transmision is taking like, 10-15 minutes in some cases, so if it takes a minute thats fine
|
|
|
|
_wb_
|
2021-12-29 08:35:11
|
What is the expected image content?
|
|
2021-12-29 08:35:46
|
And can a human do QA or do you need a fully automated solution?
|
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
2021-12-29 08:36:15
|
human can do QA. usually photos taken from a phone
|
|
2021-12-29 08:40:00
|
ohhh I'm liking my initial avif tests! thanks!
|
|
2021-12-29 08:42:46
|
avif bottom right corner, for basically the same file size โค๏ธ
|
|
2021-12-29 08:43:15
|
(using imagemagick)
|
|
|
|
190n
|
2021-12-29 08:45:00
|
oh i didn't know imagemagick could encode avif ๐
|
|
|
|
_wb_
|
2021-12-29 08:45:59
|
Headerless avif is probably the best approach for this particular use case - extremely low bpp, human can be involved in encoding
|
|
2021-12-29 08:49:37
|
You could try jxl with downsampling too, something like `cjxl -resampling 4 -d 8`, but I don't think it will do better than avif at such extremely low qualities
|
|
|
|
190n
|
2021-12-29 08:49:56
|
given that most of my avif encoding experience is with a 1482 byte limit i _really_ wish "headerless avif" was a real thing <:kekw:808717074305122316>
|
|
|
|
xssfox (vk3fur/vk4xss/she/her)
|
|
_wb_
You could try jxl with downsampling too, something like `cjxl -resampling 4 -d 8`, but I don't think it will do better than avif at such extremely low qualities
|
|
2021-12-29 08:52:07
|
yeah I fiddled with this, but didn't get great results
|
|
2021-12-29 08:52:37
|
I'll play with headerless avif, but that'll have to wait until I'm not travelling. I like the results so far though!
|
|