|
_wb_
|
2021-12-29 08:56:01
|
"Naked av1" isn't even completely headerless
|
|
|
monad
|
|
monad
Nope, just tried generally good parameters for images.
|
|
2021-12-29 09:52:41
|
Actually, I think I did about this much before but didn't keep the results. Maybe not totally superficial, not totally comprehensive.
|
|
|
|
sebseb
|
|
Traneptora
https://github.com/thebombzen/FFmpeg/tree/libjxl
|
|
2021-12-29 02:13:45
|
if you i have a step by step installing, i can try it (debian 10 of 11 )
|
|
|
Traneptora
|
|
sebseb
if you i have a step by step installing, i can try it (debian 10 of 11 )
|
|
2021-12-29 02:35:58
|
Clone the repo, switch to the libjxl branch
|
|
2021-12-29 02:36:20
|
alternatively add my repo as an upstream to an existing ffmpeg clone
|
|
2021-12-29 02:36:34
|
then fetch, then switch to libjxl
|
|
2021-12-29 02:37:07
|
after that just `./configure --enable-libjxl` followed by `make`
|
|
2021-12-29 02:37:57
|
you won't need to install it, can just do `./ffmpeg_g -i lenna.jxl` or equivalent
|
|
|
|
Hello71
|
2021-12-29 03:57:27
|
or shove https://github.com/thebombzen/FFmpeg/compare/master...libjxl.patch into quilt or whatever it is
|
|
|
|
Traneptora
|
2021-12-29 06:35:02
|
well, I sent my final patches to the ML, let's get some fingers crossed
|
|
|
fab
|
2021-12-30 11:23:44
|
for %i in (C:\Users\Utente\Videos\ma\*.png) do cjxl -d 3.446 -s 8 --epf=0 --intensity_target=280 -I 0.9 --photon_noise=ISO1059 --faster_decoding=4
--gaborish=0 --dots=0 %i %i.jxl
|
|
2021-12-30 11:31:09
|
I hadn't RAM for this
|
|
|
nathanielcwm
|
|
fab
I hadn't RAM for this
|
|
2021-12-30 03:26:21
|
oof how much u have rn?
|
|
|
|
fab
|
2021-12-30 03:29:03
|
24 seconds a photo with that commit i posted in offtopic
|
|
2021-12-30 03:29:27
|
634mb RAM. Per 2400x1080 images
|
|
2021-12-30 03:29:48
|
4 threads same i3 330.
|
|
2021-12-30 03:30:28
|
Im at 2h 25 i did 529 images
|
|
2021-12-30 03:33:47
|
|
|
2021-12-30 03:33:59
|
Close zoom of the artifacts
|
|
2021-12-30 03:34:14
|
140392 bytes
|
|
2021-12-30 03:46:17
|
|
|
2021-12-30 03:46:31
|
Original quality
|
|
2021-12-30 03:46:44
|
Jpg
|
|
2021-12-30 03:47:11
|
827 kb 847283 byte
|
|
|
Master Of Zen
|
2021-12-30 07:35:27
|
Quick question, what is the process for first block in Intra coding?(Not JXL specific)
Is that just DC? So it's get average -> match with best DC mode -> get residual -> code all of that until you have enough neighboring blocks for directional prediction modes?
|
|
|
|
_wb_
|
2021-12-30 07:39:32
|
Jxl does not do any directional prediction (amongst others to avoid dependencies between groups, which complicates and limits parallel decoding)
|
|
2021-12-30 07:41:47
|
In av1, I imagine the first block just doesn't use any directional prediction (and in general, first row of blocks and first column of blocks can only really predict from left or from top)
|
|
|
|
Master Of Zen
|
|
_wb_
Jxl does not do any directional prediction (amongst others to avoid dependencies between groups, which complicates and limits parallel decoding)
|
|
2021-12-30 07:46:47
|
does that comes with coding efficiency trade off?
Is dependency only main flaw of directional modes?
|
|
|
|
_wb_
|
2021-12-30 07:49:01
|
We tried directional prediction and could only get some benefits at low quality
|
|
2021-12-30 07:49:34
|
At higher quality it didn't help much at all
|
|
|
|
Master Of Zen
|
2021-12-30 07:50:35
|
Yeah, that what I though also, you can get quite big residuals if you try to achieve high quality, which negates the point
|
|
|
|
_wb_
|
2021-12-30 07:51:24
|
For the bitrates targeted by video codecs, it is useful
|
|
2021-12-30 07:52:02
|
For still images, not so much
|
|
2021-12-30 07:54:51
|
I think it's one of the main causes of the "vectorized look" that you can get with av1 (and heic, and to some extent with webp)
|
|
2021-12-30 07:55:16
|
Also known as the "oil painting" look, or smudging artifacts
|
|
2021-12-30 07:56:32
|
For some non-photographic content it is nice though, like manga. The artifacts are similar to the drawing style, so not problematic visually
|
|
|
|
Master Of Zen
|
2021-12-30 08:02:20
|
Makes sense
|
|
|
Rally
|
2021-12-31 04:23:53
|
hmm, I tried opening a jxl-art generated JXL file with XnViewMP and its not generating it correctly, any ideas why that's the case?
|
|
|
improver
|
2021-12-31 04:51:02
|
if using windows try infanview
|
|
|
|
_wb_
|
2021-12-31 05:04:36
|
Old versions of libjxl didn't do upsampling correctly
|
|
|
|
Rally
|
|
improver
if using windows try infanview
|
|
2021-12-31 05:11:17
|
works, thanks!
|
|
|
|
fab
|
2022-01-01 12:21:06
|
Svt av1 crf 50 preset 8 Is equivalent to
|
|
2022-01-01 12:21:18
|
43.017 jpeg xl s 8
|
|
|
|
Traneptora
|
2022-01-01 03:33:48
|
Is there a "test" or "print info" option in `djxl`
|
|
|
spider-mario
|
2022-01-01 03:35:29
|
there is a separate `jxlinfo` in `examples`
|
|
2022-01-01 03:35:39
|
(which nowadays is built directly in the build folder, not in `examples/`)
|
|
|
|
Traneptora
|
2022-01-01 04:29:10
|
is there any way we could possible have that functionality added to djxl?
|
|
2022-01-01 04:29:38
|
I'm not sure there's any way to get the tools to just tell me about a jxl or test for its integrity
|
|
2022-01-01 04:30:00
|
(decoding to stdout or /dev/null also fails because it can't automatically determine the output file type by extension)
|
|
2022-01-01 04:35:40
|
for example, `djpeg` in both turbojpeg and mozjpeg has `-targa` as an output option to give you consistent output
|
|
2022-01-01 04:39:53
|
I know many tools like `gzip` or `xz` have a `-t` option to just test
|
|
2022-01-01 04:40:18
|
`xz -l` lists information and `xz -t` tests integrity by decoding and checking for issues but not writing the decoded output anywhere
|
|
|
|
spider-mario
|
|
Traneptora
(decoding to stdout or /dev/null also fails because it can't automatically determine the output file type by extension)
|
|
2022-01-01 04:56:52
|
you don’t need to supply an output file name at all
|
|
2022-01-01 04:57:13
|
if you just write `djxl img.jxl`, it will decode it to pixels in memory and not write the result anywhere
|
|
2022-01-01 04:57:27
|
(unless we removed that feature?)
|
|
|
Fraetor
|
|
spider-mario
(unless we removed that feature?)
|
|
2022-01-01 04:58:20
|
It still exists.
|
|
|
|
Traneptora
|
2022-01-01 05:00:21
|
```
JPEG XL decoder v0.7.0 61f9ed0 [SSSE3,Scalar]
Usage: tools/djxl INPUT OUTPUT [OPTIONS...]
INPUT
the compressed input file
OUTPUT
the output can be PNG with ICC, JPG, or PPM/PFM.
```
|
|
2022-01-01 05:00:24
|
this is not documented
|
|
2022-01-01 05:00:31
|
(output of `djxl --help`)
|
|
2022-01-01 05:01:14
|
it should say something like "Omit the output file in order to test the integrity without writing the decoded pixels."
|
|
2022-01-01 05:01:23
|
or equivalent that is less clunky
|
|
|
|
Fraetor
|
2022-01-01 05:01:29
|
Could probably do with being added to the manpage as well:
```
DJXL(1) DJXL(1)
NAME
djxl - decompress JPEG XL images
SYNOPSIS
djxl [options...] input.jxl [output]
DESCRIPTION
djxl decompresses a JPEG XL image or animation. The output format is determined by the extension of the output
file, which can be .png, .jpg, .ppm, .pfm. If the JPEG XL input file contains an animation, multiple output
files will be produced, with names of the form "output-framenumber.ext".
OPTIONS
-h, --help
Displays the options that djxl supports.
-j, --pixels_to_jpeg
By default, if the input JPEG XL contains a recompressed JPEG file, djxl reconstructs the exact original
JPEG file if the output file has the .jpg (or .jpeg) filename extension. This flag causes the decoder to
instead decode the image to pixels and encode a new (lossy) JPEG in this case.
-q quality, --jpeg_quality=quality
When decoding to .jpg, use this output quality. This option implicitly enables the --pixels_to_jpeg
option.
EXAMPLES
# Decompress a JPEG XL file to PNG
$ djxl input.jxl output.png
# Reconstruct a losslessly-recompressed JPEG file
$ djxl lossless-jpeg.jxl reconstructed.jpeg
SEE ALSO
cjxl(1)
12/31/2021 DJXL(1)
```
|
|
|
|
Traneptora
|
2022-01-01 05:02:01
|
manpage at least has brackets around `[output]`
|
|
2022-01-01 05:02:29
|
I personally think options should go before arguments on principle, so I don't like `djxl INPUT OUTPUT [OPTIONS]` and would rather it say something like
|
|
2022-01-01 05:02:39
|
`djxl [options...] input [output]` just like in the manpage
|
|
2022-01-01 05:02:49
|
or equivalent
|
|
|
|
Fraetor
|
2022-01-01 05:03:21
|
Both work, but it should probably be consistent between the documentation.
|
|
|
|
Traneptora
|
|
spider-mario
there is a separate `jxlinfo` in `examples`
|
|
2022-01-01 05:04:26
|
`jxlinfo` does not print frame info
|
|
2022-01-01 05:05:07
|
it just reports
```frame:
still frame, unnamed```
|
|
2022-01-01 05:05:52
|
in particular, it won't even say whether it's VarDCT or Modular
|
|
2022-01-01 05:06:54
|
although decoding the frame header apparently requires ANS which is <:PortDoll:631220337564188692>
|
|
2022-01-01 05:06:56
|
unfortunate
|
|
|
|
_wb_
|
2022-01-01 05:38:14
|
We could expose that info in the libjxl frame header info
|
|
2022-01-01 05:38:59
|
It's not quite clear where to draw the line between "internal only info" and "externally relevant, to be exposed info"
|
|
|
lithium
|
2022-01-03 08:44:15
|
Look like higher intensity_target(2000) and lower target distance(d0.5,0.3) will affect separate option border issue.
|
|
|
Scope
|
2022-01-03 03:26:39
|
<https://github.com/libjxl/libjxl/pull/1032/commits/2ca2ca610a76b69fdd6bbf730043e12dddea739d>
Also, speaking of transparency changes, is fjxl not very efficient at compressing images with transparency or is there some other thing?
Like here:
https://de.catbox.moe/o0mc76.png
|
|
2022-01-03 03:26:43
|
|
|
|
|
_wb_
|
2022-01-03 03:27:30
|
My guess here is: needs palette, and benefits from more lz77 than just RLE
|
|
2022-01-03 03:29:25
|
QOI has the pixel cache thing that kind of acts like a 32-color palette, so that helps
|
|
2022-01-03 03:30:22
|
I'm still on holidays for the rest of the weem but afterwards I might at some point add palette detection to fjxl
|
|
2022-01-03 03:31:20
|
It should be possible to do palette if possible without too much slowdown
|
|
|
|
Scope
|
2022-01-03 03:32:49
|
Hmm, also a quick switch to an efficient mode for palette compression would also be useful for the rest of the slower speeds, like from `-e 1` to `-e 7`
And it could also make `-e 3` as a mode with very fast and good compression for most content
|
|
2022-01-03 03:44:38
|
Also it would be good to make some kind of fast mode for `-e 3`, like only 8 bit or like in PIK, because currently PIK is faster and more efficient
|
|
|
|
_wb_
|
2022-01-03 03:46:55
|
Specialized code paths could help
|
|
|
|
Traneptora
|
2022-01-04 12:30:35
|
why are all the dependencies added as submodules?
|
|
2022-01-04 12:31:14
|
it seems unnecessary to pull libpng when my system has it installed
|
|
2022-01-04 12:31:50
|
most other libraries just require you to install the various dependencies yourself unless they're very primitive and small (e.g. lodepng)
|
|
2022-01-04 12:32:14
|
like, sjpeg, most systems come with a system libjpeg installed as a jpeg decoder
|
|
2022-01-04 12:32:33
|
we should make sjpeg an optional dep
|
|
2022-01-04 12:32:48
|
having to download them all even if we're using the system version is sort of frustrating
|
|
2022-01-04 12:33:28
|
and why is *zlib* of all things repacked
|
|
2022-01-04 12:34:09
|
all unix systems come with zlib as an essential library
|
|
2022-01-04 12:34:16
|
and windows comes with an equivalent (or maybe even zlib itself)
|
|
|
|
_wb_
|
2022-01-04 12:37:52
|
It should use system libpng/zlib in normal builds
|
|
|
|
Traneptora
|
2022-01-04 12:38:15
|
the issue is, if you clone libjxl and try to build, it'll refuse until you grab the dependencies
|
|
|
|
_wb_
|
2022-01-04 12:38:27
|
We only have it as a submodule for msan builds, because system libpng is not indtrumented for msan
|
|
|
|
Traneptora
|
2022-01-04 12:38:38
|
why not just use the WIC decoder
|
|
2022-01-04 12:38:43
|
windows has native support for zlib and png
|
|
2022-01-04 12:39:56
|
for zlib, in case we'd like to homebrew our own primitive PNG decoder/encoder
https://docs.microsoft.com/en-us/windows/win32/cmpapi/-compression-portal
for PNG, if not
https://docs.microsoft.com/en-us/windows/win32/wic/-wic-lh
|
|
|
|
_wb_
|
2022-01-04 12:40:18
|
WIC is not exactly portable
|
|
|
|
Traneptora
|
2022-01-04 12:40:30
|
It isn't, it's only for windows
|
|
2022-01-04 12:40:48
|
so you don't have to pull in a libpng dependency
|
|
2022-01-04 12:41:18
|
in either case, what frustrates me most tbh is that the dependency grabber grabs literally all of the deps, even the ones you don't need
|
|
2022-01-04 12:41:50
|
it's a little annoying to clone libpng when I won't end up doing anything with the repo
|
|
|
|
_wb_
|
2022-01-04 12:42:04
|
Yes, that seems unnecessary
|
|
|
|
Traneptora
|
2022-01-04 12:42:11
|
at the very least it should be a shallow clone
|
|
2022-01-04 12:42:32
|
which only downloads the last commit
|
|
|
|
_wb_
|
2022-01-04 12:43:04
|
My git skills are quite limited, but feel free to suggest improvements
|
|
|
|
Traneptora
|
|
_wb_
My git skills are quite limited, but feel free to suggest improvements
|
|
2022-01-04 01:13:25
|
append `--depth 1 --recommend-shallow` to the git line in `./deps.sh`
|
|
2022-01-04 01:13:53
|
so it reads
|
|
2022-01-04 01:13:55
|
```sh
git -C "${MYDIR}" submodule update --init --recursive --depth 1 --recommend-shallow
```
|
|
|
_wb_
My git skills are quite limited, but feel free to suggest improvements
|
|
2022-01-05 02:34:47
|
https://github.com/libjxl/libjxl/pull/1075
|
|
|
Jyrki Alakuijala
|
|
lithium
Look like higher intensity_target(2000) and lower target distance(d0.5,0.3) will affect separate option border issue.
|
|
2022-01-07 10:48:15
|
What is the separate option border issue?
|
|
|
lithium
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?
|
|
2022-01-07 10:55:27
|
If we are pixel-peeking (zooming) to see these defects, we could make a butteraugli version that 2x or 4x the pixels before using butteraugli -- that way we could model the zooming and likely get butteraugli-guided compression to work better with zooming
|
|
|
|
lithium
|
|
Jyrki Alakuijala
What is the separate option border issue?
|
|
2022-01-07 02:10:13
|
Thank you for your reply 🙂
jxl separate option is from Jon PR466,
> https://github.com/libjxl/libjxl/pull/466
This option can segment image and apply two different lossy algorithm for this image,
but for now Modular patch frame and VarDCT frame have visible issue on merge border.
> Experimental new encode option: use a heuristic to segment the image in a 'non-photographic' frame
> (encoded as one big Modular patch) and a 'photographic' frame (encoded with VarDCT).
|
|
|
Jyrki Alakuijala
If we are pixel-peeking (zooming) to see these defects, we could make a butteraugli version that 2x or 4x the pixels before using butteraugli -- that way we could model the zooming and likely get butteraugli-guided compression to work better with zooming
|
|
2022-01-07 02:10:26
|
I usually use general zoom(1x) to watch those image, but sometime still can see some tiny error.
I think on lower distance(d0.5,0.3) whole image is look really good for non-photo content,
but for specific area(like high contrast sharp line,border) have some visible tiny error,
in previous test, I think increase intensity target can reduce those error,
(I guess specific area(like high contrast sharp line,border) error will spread to other area,
and increase those error area )
But I think jxl separate option probably a better method,
reduce visible tiny error and still have good compression ratio,
and also can avoid DCT worst case for some manga content.
|
|
|
|
JendaLinda
|
|
_wb_
It's not quite clear where to draw the line between "internal only info" and "externally relevant, to be exposed info"
|
|
2022-01-08 03:25:28
|
Exposing more information about the frames would be very useful. Not only the compression scheme (Modular, VarDCT) but also the color space (XYB, RGB, YCbCr, grayscale) and if possible, lossy/lossless indication would be also nice. The jxlinfo tool should be also able to at least list all included boxes if container is used.
|
|
|
w
|
2022-01-08 07:28:34
|
Lossy/lossless indicator doesn't really make sense
|
|
2022-01-08 07:28:46
|
maybe instead cjxl can tag the encoder settings
|
|
|
|
_wb_
|
2022-01-08 07:56:04
|
Could add a metadata box containing cjxl version and cmd line flags and whatever other stuff people think is worth storing (timestamp of encode? timestamp of original input file?)
|
|
2022-01-08 07:56:34
|
It would not be part of the standard itself though, just something a tool can do
|
|
|
|
JendaLinda
|
2022-01-08 11:01:47
|
Metadata isn't reliable. I would rather have a tool to obtain as much information as possible from the jxl datastream itself. In this stage jxl seems to be quite opaque. I believe more tinkers would like to see more clearly into jxl internals.
|
|
|
|
Fraetor
|
2022-01-08 11:03:33
|
TBF, I think the modular/VarDCT+colourspace mostly indicates whether it was lossless or not.
|
|
2022-01-08 11:04:16
|
like Modular RGB could have a note of "Probably lossless"
|
|
|
|
JendaLinda
|
2022-01-08 11:08:09
|
I understand it's not possible to get the exact information if the compression was lossy or lossless, that's not a big deal. Just exposing all available information about the bitstream would be enough for user to be able to read them and interpret them.
|
|
2022-01-08 11:18:56
|
The question is, if it's reasonable to include that in the API or create a special tool for reading detailed information from jxl files.
|
|
|
Sam
|
2022-01-08 11:41:09
|
i don't know if anyone has done this already but i did an attempt at making a jpeg xl web button! (if anyone still uses those)
|
|
|
|
w
|
2022-01-08 11:46:00
|
I didn't think someone else would make a button https://discord.com/channels/794206087879852103/794206170445119489/923560819093016617
|
|
|
|
Sam
|
2022-01-08 11:47:14
|
oh cool!!
|
|
2022-01-08 11:47:42
|
we also happened to go for slightly different sizes/styles so they don't really overlap :)
|
|
|
|
w
|
2022-01-08 11:48:36
|
yeah the different sizes is interesting
|
|
|
|
improver
|
2022-01-09 02:44:38
|
<https://commons.m.wikimedia.org/wiki/File:JPEG_XL_logo.svg#mw-jump-to-license> says PD because its too simple lol
|
|
|
|
_wb_
|
2022-01-09 07:25:03
|
TBH, I don't think the JPEG committee really cares about the copyright on the logos. What they care about is that nobody is making it look like they represent the JPEG committee or that the JPEG committee approves something, when that's not the case.
|
|
2022-01-09 07:26:22
|
So it's more about the context and how such a logo (or a derived logo) is used, than about the copyright license per se. At least that's my impression.
|
|
2022-01-09 07:29:49
|
Concretely: if you'd put such a web button on a page to show you like the codec or you made some application that uses it or something like that, nobody will complain. If you put it on something to make it look like it's an official statement by ISO/IEC JTC1 SC29 WG1, that's something else.
|
|
|
|
improver
|
2022-01-09 07:34:55
|
i wanna make jpeg qoi logo just for troll reasons now...
|
|
|
|
_wb_
|
2022-01-09 07:56:38
|
Haha
|
|
2022-01-09 07:57:07
|
What about a jpeg bmp logo :)
|
|
|
|
JendaLinda
|
2022-01-09 12:45:32
|
In my testing, I've discovered that it might be worth to optimize JPEG images before transcoding them to JXL (using jpegtran or Irfanview's lossless JPEG transformations). Despite the jxlc box being exactly the same regardless of the optimization, the size of the jbrd box correlates to the size of the original JPEG file.
The same image, with no metadata, the optimized JPEG file results in smaller JXL file than the unoptimized one.
|
|
|
|
Fraetor
|
2022-01-09 12:58:22
|
The only thing with that is that you then don't get the bit exact same file back at the end.
|
|
2022-01-09 12:58:55
|
And if you just want to minimise size you are best off just using `--strip` to remove the jbrd box entirely.
|
|
2022-01-09 01:00:14
|
You can still reconstruct a pixel exact jpeg from that, but not bit exact.
|
|
|
|
JendaLinda
|
2022-01-09 01:38:59
|
I couldn't find a way to reconstruct a JPEG file if the jbrd is missing. So at this point, it seems that jbrd box is necessary to be able to recunstruct a JPEG file at all.
Anyway, I found the difference in the file size interesting. I was curious how JXL handles differently optimized JPEG files. After all, the optimization method is specific to JPEG, so it shouldn't make a difference, but it does for some reason. I have all my JPEG optimized alredy, so I "unoptimized" one to try it. And voila, cjxl produced a bigger jxl file.
|
|
|
|
_wb_
|
2022-01-09 01:41:03
|
The jbrd contains all info that is not image data or exif/xmp
|
|
2022-01-09 01:42:33
|
E.g. padding bits in jpeg can have any value. If they're all zeroes (as is the case with jpegtran output), it's fine, but if they're something else, they have to be stored somewhere...
|
|
|
|
JendaLinda
|
2022-01-09 01:58:47
|
I see, the JFIF marker is also clearly visible in the jbrd box. All tested files were produced by jpegtran, just with different settings.
|
|
|
Orum
|
2022-01-09 03:51:03
|
``` -P K, --predictor=K
[modular encoding] predictor(s) to use: 0=zero, 1=left, 2=top, 3=avg0, 4=select, 5=gradient, 6=weighted, 7=topright, 8=topleft, 9=leftleft, 10=avg1, 11=avg2, 12=avg3, 13=toptop predictive average 14=mix 5 and 6, 15=mix everything. Default 14, at slowest speed default 15``` ...but when I try `-P 15` I get `Invalid predictor value 15, must be less than 14.`
|
|
2022-01-09 03:51:41
|
which is odd, because `-P 14` works just fine (like it should), so the error is wrong on two accounts
|
|
2022-01-09 03:55:35
|
will open an issue on github
|
|
|
|
Scope
|
2022-01-09 03:55:38
|
https://github.com/libjxl/libjxl/pull/613
|
|
|
|
Orum
|
2022-01-09 03:55:51
|
oh, it's already fixed <:BlobYay:806132268186861619>
|
|
|
RockPolish
|
2022-01-09 04:08:08
|
Hello everyone, wondering if there is a way to make djxl write the decoded pixels to stdout instead of to a file? I've been trying to load .jxl images in Python (and one WIP library for this on github did not work for me), and it seems wasteful to have to call djxl to write to a .png, then load that .png in Python, and then delete that temporary file. That extra step could be nicely avoided if djxl can just output the raw pixels (but then it'd also have to give the width/height I guess) - or any other way that people have been able to neatly load jxl images in Python? Sorry if this is a common question, I searched but couldn't find much about it
|
|
|
|
Fraetor
|
2022-01-09 04:11:41
|
We probably just need python bindings for libjxl.
|
|
|
|
_wb_
|
2022-01-09 04:49:01
|
Yes, that would be a better idea than system calls
|
|
|
|
RockPolish
|
2022-01-09 05:01:05
|
I agree, my idea was that the stdout thing could be good enough "for now" and work for any language, not just Python - it's not super clean though
|
|
2022-01-09 05:01:43
|
I would be very happy if I could load jpeg xl images in Python, from the bit of testing I've done (losslessly from .png to .jxl), the size reduction ranges from "quite nice" to "extremely nice" with the images I'm trying
|
|
|
|
_wb_
|
2022-01-09 05:05:05
|
Libjxl bindings for all popular languages should be something that can happen quickly after the 1.0 release
|
|
|
|
Hello71
|
2022-01-09 08:02:40
|
https://github.com/libjxl/libjxl/issues/542
|
|
2022-01-09 08:04:16
|
also note that png encoding is (normally) much slower than jxl decoding; even if the disk i/o is free, just encoding the png is a major bottleneck
|
|
2022-01-09 08:05:34
|
also, python surely has imagemagick bindings, and imagemagick supports jxl now. depending on platform, it might be more difficult to install libjxl plus imagemagick with jxl compared to libjxl alone though
|
|
|
|
RockPolish
|
2022-01-09 08:14:31
|
thanks for the link, and thanks for the info, I didn't know imagemagick supported jxl, I'll try it out
|
|
|
|
_wb_
|
2022-01-09 08:53:50
|
We should probably add pam support (ppm but also supporting alpha), as well as decoding just the icc profile
|
|
2022-01-09 08:54:47
|
So you can do something like `djxl foo.jxl --format=pam -` to get uncompressed output on stdout
|
|
|
|
RockPolish
|
2022-01-09 09:22:03
|
that would be great, I'll stay tuned
|
|
|
|
improver
|
2022-01-09 10:29:03
|
> is scheduled to be published on 2022-01-07 (if there are no delays).
did delays happen
|
|
|
|
_wb_
|
2022-01-09 10:51:25
|
I would be surprised if delays didn't happen, knowing ISO a bit. Plus the holidays...
|
|
|
|
Hello71
|
2022-01-10 03:33:53
|
theoretically, i think bit-exact jpeg recompression could use jxl lossless "recursively" for embedded thumbnail/preview image. is this implemented, unimplemented, not in spec, or cannot work as described?
|
|
2022-01-10 03:35:49
|
if thumbnail image occupies say 10 kB, and jxl recompression can save 30%, then it would save 3 kB per image, assuming jpeg is not brotli compressible
|
|
|
|
veluca
|
2022-01-10 03:52:37
|
I'd say it's unimplemented, not in spec, and probably a bit of a pain to actually do that way
|
|
2022-01-10 03:53:31
|
might be easier to move the JPEG-preview into a JPEG-recompressed JPEG XL-preview with a second jpeg reconstruction box
|
|
2022-01-10 03:53:39
|
but honestly, I don't think it's really worth the effort
|
|
|
|
JendaLinda
|
2022-01-10 03:59:05
|
I think it would be better to ditch the original thumbnail and generate a new one if needed.
|
|
|
|
Hello71
|
2022-01-10 04:00:57
|
but then it won't be bit-exact
|
|
2022-01-10 04:04:53
|
oh, i see
|
|
2022-01-10 04:05:08
|
but then it *probably* won't be bit-exact
|
|
2022-01-10 04:07:26
|
unless you know the exact scaling algorithm of the original producer (i wonder if there's useful forensic data there)
|
|
|
|
JendaLinda
|
2022-01-10 04:11:05
|
If you need the bit exact file, the original thumbnail has to be saved as is. In the original file, the thumbnail is embedded as another complete JPEG file.
|
|
|
|
Hello71
|
2022-01-10 04:11:35
|
hm, i think 10k is an overestimate of the average. looking at my corpus, exif thumbnail and photoshop thumbnail are normally between 4k and 16k, but strongly right-tailed. it's flashpix previewimages that are huge for some reason
|
|
|
|
JendaLinda
|
2022-01-10 04:13:40
|
And there are also JFIF thumbnails, which are uncompressed bitmaps.
|
|
|
|
Hello71
|
2022-01-10 04:14:15
|
yeah but does anyone actually use that
|
|
|
|
JendaLinda
|
2022-01-10 04:15:14
|
I have no idea, but their support would have to be implemented as well. They're in the specs after all.
|
|
|
|
Hello71
|
2022-01-10 04:16:54
|
i'm just talking about optimizing compression; in that context we just shove everything we don't understand into generic jpeg reconstruction data
|
|
|
|
JendaLinda
|
2022-01-10 04:21:31
|
Personally, I've just removed all thumbnails. I can generate new ones whenever I need them. I've also baked rotation into the image data, because EXIF is unreliable. And I've optimized the files, so there's no garbage data in them. I don't need the exact files, as long as the image data are preserved. But that's a personal preference.
|
|
|
|
lithium
|
2022-01-11 03:49:52
|
If separate picture high contrast sharp line to one frame and apply modular on this frame,
another colors plane frame apply vardct,
this separate picture method is a good idea?
> https://github.com/Mukosame/Anime2Sketch
|
|
|
Kagamiin~ Saphri
|
|
lithium
If separate picture high contrast sharp line to one frame and apply modular on this frame,
another colors plane frame apply vardct,
this separate picture method is a good idea?
> https://github.com/Mukosame/Anime2Sketch
|
|
2022-01-11 06:07:40
|
Hmm, how would the color layer be obtained and how would it be combined?
|
|
|
|
Jyrki Alakuijala
|
|
lithium
If separate picture high contrast sharp line to one frame and apply modular on this frame,
another colors plane frame apply vardct,
this separate picture method is a good idea?
> https://github.com/Mukosame/Anime2Sketch
|
|
2022-01-11 10:56:55
|
Yes, but I should do such things in the encoder by default ...
|
|
|
|
Hello71
|
|
JendaLinda
Personally, I've just removed all thumbnails. I can generate new ones whenever I need them. I've also baked rotation into the image data, because EXIF is unreliable. And I've optimized the files, so there's no garbage data in them. I don't need the exact files, as long as the image data are preserved. But that's a personal preference.
|
|
2022-01-12 03:33:29
|
unfortunately removing thumbnails is not always safe, even ignoring the actual thumbnail data; some very poorly designed makernotes or other data may be corrupted with improper thumbnail removal
|
|
2022-01-12 03:35:11
|
now, only a fool would put thumbnail before absolute-offset makernotes, but of course only a fool would make absolute-offset makernotes in the first place
|
|
|
|
JendaLinda
|
2022-01-12 06:40:51
|
Absolute offsets will break if you do any changes to the file structure. There is no way jxl would be able to optimize all weird thumbnail formats. The only way is to store all non standard data as a one big blob. There are even files including data outside the JPEG markers.
|
|
2022-01-12 06:44:37
|
For me, the only useful metadata is a timestamp. I've kept the whole EXIF, even I don't really need most of the EXIF data. If makernotes were making me troubles, I would have just removed makernotes and called it a day.
|
|
|
|
lithium
|
|
Jyrki Alakuijala
Yes, but I should do such things in the encoder by default ...
|
|
2022-01-12 03:01:03
|
Thank you for your reply
I don't know which method is better,
Jon mention some different method about detection image features.
> wb
> it will probably be a somewhat different approach - not really separating the image into two parts,
> but generalizing patches and dot detection into something that doesn't just try to detect text (repeated letters)
> and small ellipses (dot detection), but more generally image features that are better not DCT-encoded.
> https://discord.com/channels/794206087879852103/794206087879852106/921411954529157140
|
|
|
Kagamiin~ Saphri
Hmm, how would the color layer be obtained and how would it be combined?
|
|
2022-01-12 03:02:33
|
Thank you for your reply
jxl have a magic option call `--separate`, but still on very experiment status,
I guess probably can apply this method on different separate frame?
> https://github.com/libjxl/libjxl/pull/466
|
|
|
|
wayfarer3130
|
2022-01-12 04:18:34
|
I'm adding support for medical use of JPEG-XL for the IHE DICOM group. When encapsulated into a DICOM file, the format limits each encoded part to 4 gb, and requires a way to distnguish "next part" from "start of new image". I was thinking of using the ISOBMF format, but I don't know where to look to figure out how to distinguish the start of a new image from a jxlp box. What I'm looking for is a set of bytes that I can use to distinguish jxlp boxes from start of image identifiers.
|
|
|
|
_wb_
|
2022-01-12 04:40:57
|
in jpeg xl files there is always only one image (which can have multiple frames)
|
|
2022-01-12 04:42:33
|
I assume in DICOM you can have multiple images?
|
|
|
|
wayfarer3130
|
2022-01-12 04:58:23
|
No, in DICOM you only have multiple frames, each of which is stored in a separate compressed object - that is as independent JXL instances each encoded separately. Logically they should be encoded in the same JPEG-XL object, but right now that is a step too far.
|
|
2022-01-12 04:58:44
|
So yes, think of it as multiple images, each with exactly one frame.
|
|
|
|
_wb_
|
2022-01-12 05:43:37
|
then every jxl object will either start with the naked codestream signature (0xFF0A) or with the container signature (which is longer)
|
|
|
|
wayfarer3130
|
2022-01-12 10:23:49
|
Is either signature ever the same as the start of a jxlp box? If not, then I can simply say that anything except the naked codestream or the container signature is a continuation marker, and require the breaks between parts to start at a jxlp section (which I'd still like a signature for if possible)
|
|
|
|
_wb_
|
2022-01-13 06:19:18
|
Well there's no guarantee that entropy-coded data doesn't accidentally contain a sequence of bytes that looks like a signature.
|
|
2022-01-13 06:26:46
|
But assuming/requiring that what gets embedded in dicom is either a full naked codestream or a full jxlp box from a container, like you said, it's as follows:
Start of new jxl image:
- FF 0A (naked codestream, cannot have continuation)
- 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A (container, can have continuation)
Continuation (jxlp box):
- 4 arbitrary bytes (big endian uint32 size, or 0 for 'until eof') followed by "jxlp" in ascii text.
|
|
|
|
Traneptora
|
2022-01-13 11:44:22
|
<@!179701849576833024> thanks
|
|
2022-01-13 12:02:02
|
ugh
|
|
2022-01-13 12:02:09
|
```
Generating C API documentation
/home/leo/Programs/AUR/libjxl-git/src/libjxl/lib/include/jxl/encode.h:824: error: documented empty return type of JxlEncoderInitExtraChannelInfo (warning treated as error, aborting now)
```
|
|
2022-01-13 12:02:21
|
is this an AUR package issue or are other people experiencing this too?
|
|
|
|
improver
|
2022-01-13 01:23:06
|
ive reported that on gh
|
|
2022-01-13 04:17:03
|
its prob because doxygen on arch is very recent and spews more warnings than older version
|
|
2022-01-13 04:17:38
|
and for whatever reason its specified in cmakefile to treat warnings as errors
|
|
2022-01-13 04:19:17
|
thats why i consider "treat warnings as errors" settings by default stupid, it breaks very easily on toolset changes
|
|
2022-01-13 04:20:07
|
should only be set for CI builders really
|
|
|
|
wayfarer3130
|
|
_wb_
But assuming/requiring that what gets embedded in dicom is either a full naked codestream or a full jxlp box from a container, like you said, it's as follows:
Start of new jxl image:
- FF 0A (naked codestream, cannot have continuation)
- 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A (container, can have continuation)
Continuation (jxlp box):
- 4 arbitrary bytes (big endian uint32 size, or 0 for 'until eof') followed by "jxlp" in ascii text.
|
|
2022-01-13 04:20:08
|
Thank you - the continuation is exactly what I needed, will add that to the standards document.
|
|
|
|
_wb_
|
|
improver
thats why i consider "treat warnings as errors" settings by default stupid, it breaks very easily on toolset changes
|
|
2022-01-13 04:26:44
|
it's useful because breaking will be much more noticeable than not breaking, and warnings are usually not innocent. But I agree that for a release, it's probably better to allow warnings.
|
|
|
|
improver
|
2022-01-13 04:43:16
|
much more noticeable for people trying to build your stuff in a way what doesn't allow them to build your stuff, and yet days and days after it was broke no one fixed it and except for me no one even reported. so no it doesn't help noticeability, it just demotivates users building your stuff
|
|
2022-01-13 04:45:10
|
cost / benefit ratio is too large and there is already strategy with better, pretty much guaranteed noticeability and no demotivational cost - putting that setting in CI scripts
|
|
2022-01-13 04:46:10
|
so i believe its fair to call decision to treat warnings as errors by default plain stupid
|
|
2022-01-13 04:51:45
|
its kinda irritating that some people push for that without analysing costs. not to mention it's semantically wrong, warnings are separate category for a reason
|
|
|
|
_wb_
|
2022-01-13 06:07:38
|
Makes sense - feel free to make a pull request to do the warning-is-error only for CI and not for normal builds
|
|
|
|
veluca
|
2022-01-13 06:18:22
|
isn't it that way already?
|
|
2022-01-13 06:18:30
|
pretty sure it is
|
|
|
|
improver
|
2022-01-13 06:46:36
|
yes, for C++ stuff. not for doxygen stuff though
|
|
|
|
veluca
|
2022-01-13 06:54:44
|
huh
|
|
2022-01-13 06:54:49
|
that could use some fixing
|
|
|
|
improver
|
2022-01-13 07:32:02
|
https://github.com/libjxl/libjxl/pull/1095 yeah
|
|
|
|
Scope
|
2022-01-13 08:40:03
|
<https://www.reddit.com/r/jpegxl/comments/s37802/how_can_i_use_the_fastlossless_encoder/>
Also, would it be more convenient to have a separate repository for FJXL?
Unless it's probably more difficult for reviews, but I think it's easier for other people to discuss, make changes, and use
|
|
|
|
fab
|
2022-01-13 08:44:39
|
Fjxl and fpnge aren't the same
|
|
2022-01-13 08:44:42
|
?
|
|
2022-01-13 08:44:58
|
Fpng i knew is made by Richard
|
|
|
|
Scope
|
2022-01-13 08:48:40
|
FJXL for JXL, FPNG and FPNGE for PNG
|
|
|
|
fab
|
2022-01-13 09:18:05
|
Thanks
|
|
|
|
lithium
|
|
lithium
If separate picture high contrast sharp line to one frame and apply modular on this frame,
another colors plane frame apply vardct,
this separate picture method is a good idea?
> https://github.com/Mukosame/Anime2Sketch
|
|
2022-01-16 10:31:34
|
I was wrong, I test this separate method on photoshop
(separate picture high contrast sharp line),
but look like this method also happen some border issue...😢
I think Jon method probably a better choose,
but I don't understand how to detect not suitable DCT features for non-photo picture.
|
|
|
|
Jyrki Alakuijala
|
2022-01-19 02:15:01
|
how to code without artefacts
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 08:48:55
|
<@!179701849576833024> What needs to be called before `JxlDecoderProcessInput()` in order to decode a codestream created by `FastLosslessEncode()` ?
|
|
|
|
veluca
|
2022-01-20 08:50:27
|
I'd say the same as any other JPEG XL image - you can follow the example in https://github.com/libjxl/libjxl/blob/main/examples/decode_oneshot.cc
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 08:55:07
|
Weird. Decoding dies with the following code, which works when an image is encoded using the code in encode_oneshot.com.
|
|
2022-01-20 08:55:40
|
Decoder snippet
|
|
|
|
veluca
|
2022-01-20 08:56:24
|
that's curious - how does it die?
|
|
|
|
_wb_
|
2022-01-20 08:58:43
|
could be that FastLosslessEncode() always produces an RGBA image
|
|
2022-01-20 08:59:30
|
which you might not be prepared for, since this code is not getting the `num_comps` from the bitstream
|
|
2022-01-20 09:01:40
|
it can be useful to build libjxl with debug messages enabled ( `-DJXL_DEBUG_WARNING -DJXL_DEBUG_ON_ERROR`)
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 09:05:17
|
`ext/libjxl/lib/jxl/decode.cc:2117: invalid signature
terminate called after throwing an instance of 'std::runtime_error'
what(): Decoder error`
|
|
|
|
veluca
|
2022-01-20 09:08:55
|
huh. this sounds like it's getting the wrong input...
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 09:09:55
|
It is getting the contents of `codestream` in `FastLosslessEncode(pixels, width, width * 4, height, &codestream);`
|
|
2022-01-20 09:14:31
|
> could be that FastLosslessEncode() always produces an RGBA image
<@!794205442175402004> That is just an artifact of the experimental code, right?
|
|
|
|
_wb_
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 09:37:25
|
<@!179701849576833024> did you ever try the output of `FastLosslessEncode` with `DecodeJpegXlOneShot`?
|
|
|
|
veluca
|
2022-01-20 09:44:15
|
No, just with djxl, but it should be the same in theory...
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 09:47:50
|
Doesn't djxl use different header reading logic?
|
|
|
|
veluca
|
2022-01-20 09:52:49
|
it does, but it should at least be equivalent 🙂
|
|
|
|
_wb_
|
2022-01-20 10:14:03
|
What are the first two bytes of the codestream? Should be 0xFF0A
|
|
|
|
Pierre-Anthony Lemieux
|
|
|
veluca
|
2022-01-20 10:34:56
|
that looks very wrong
|
|
2022-01-20 10:35:06
|
think you could share the code that produced it?
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 10:36:51
|
``` unsigned char* data =
stbi_load(filepath.c_str(), &width, &height, &num_comps, 0);
...
this->cb_.size = FastLosslessEncode(pixels, width, width * 4, height,
&this->cb_.codestream);```
|
|
|
|
_wb_
|
2022-01-20 10:39:28
|
And cb_.codestream is an unsigned char*?
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 10:40:27
|
```
struct CodestreamBuffer {
uint8_t* codestream;
size_t size;
};
```
|
|
2022-01-20 10:40:48
|
(waiting for the obvious mistake to come out 🙂
|
|
|
|
_wb_
|
2022-01-20 10:41:25
|
Yes this looks like some obvious-in-retrospect thing
|
|
|
|
veluca
|
2022-01-20 10:42:23
|
... couldn't say what's the issue though, except if you end up not using cb_ after all for the decoder
|
|
2022-01-20 10:42:27
|
can you send the whole file?
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 10:49:20
|
https://github.com/sandflow/libench/blob/main/src/main/cpp/ojph_codec.cpp
|
|
2022-01-20 10:49:55
|
(trying to come up with an automated test bench for lossless codecs)
|
|
|
|
veluca
|
2022-01-20 10:51:49
|
ah, you're missing a return in encodeRGBA8
|
|
|
|
Pierre-Anthony Lemieux
|
2022-01-20 10:53:48
|
ok. that was dumb.
|
|
2022-01-20 10:54:11
|
feel free to suggest enhancements to the build and the code.
|
|
2022-01-20 10:55:57
|
works good now.
|
|
|
|
Scope
|
2022-01-22 10:24:15
|
If somebody on Windows and AVX2 CPU wants to test JXL builds with different compilers, I have added various builds and write a simple CMD which also has a timer, it can be used as `C_Bench.cmd Image.png` (or drop the image on the cmd), but if the image is very big, it will take long time to bench or it is possible to reduce `--num_reps` in cmd file
MP/s in JXL or Global Time in the timer, this is basically what needs to be compared
Alternatively, it is possible to compare builds manually, they are in different folders with the relevant names
|
|
|
The_Decryptor
|
2022-01-23 03:00:26
|
I'm having some issues with 10bit PNM files and cjxl
|
|
2022-01-23 03:00:52
|
I can open this image in GIMP and IM fine, but roundtripping it through cjxl/djxl just gives me a black square
|
|
|
Fox Wizard
|
2022-01-23 06:39:45
|
When I saw lossless I thought it doesn't make that much of a difference, but then I saw lossy performance... not twice as fast for me, but still a very decent difference
|
|
|
|
Scope
|
2022-01-23 06:47:10
|
Yes, for lossless it depends much more on the image, on some the difference is hardly noticeable
|
|
2022-01-23 06:47:49
|
Also on slower encoding settings
|
|
|
|
Fox Wizard
|
2022-01-23 06:54:18
|
Hm, really seems to depend a lot on the image. In another image it was about twice as fast for lossless. I like how there's such an extreme speed improvement just by using a different compiler
|
|
|
|
Scope
|
|
|
Fox Wizard
|
2022-01-23 07:11:59
|
<a:FurretSpeed:832307660035850310>
|
|
|
BlueSwordM
|
|
Fox Wizard
<a:FurretSpeed:832307660035850310>
|
|
2022-01-23 07:27:11
|
<a:speed:765057909317959710>
|
|
|
|
_wb_
|
2022-01-24 08:58:16
|
If you have a 1-bit image, you can use a single horizontal (or vertical) squeeze step and then apply palette on the resulting 2 channels to get a half-sized 2-bit image, I checked the math, it works
|
|
2022-01-24 08:59:31
|
You cannot use the same trick to get from a 2-bit image to a bitpacked 4-bit image though: you would get 22 palette entries, not 16, due to the tendency term in squeeze
|
|
2022-01-24 09:00:22
|
(also you do need to pad the dimensions to become even, but that's not really an issue)
|
|
2022-01-24 10:21:47
|
Ah, there _is_ a way to do more bitpacking
|
|
2022-01-24 10:22:36
|
so doing squeeze on 1-bit images does this:
0,0 -> 0,0
0,1 -> 0,-1
1,0 -> 1,1
1,1 -> 1,0
|
|
2022-01-24 10:23:15
|
problem is that the second channel gets 3 values, so cannot just recursively apply squeeze on it
|
|
2022-01-24 10:24:28
|
but if you introduce a dummy extra channel that is just all zeroes, you can apply RCT
|
|
2022-01-24 10:24:59
|
(you need the extra channel because RCT requires 3 same-sized channels)
|
|
2022-01-24 10:26:53
|
with an RCT that subtracts the first channel from the second, you get only 2 distinct values in the second channel too
|
|
2022-01-24 10:30:09
|
then you can apply squeeze again on both channels to get 4 channels, apply rct again twice to get the residuals to only 2 distinct values again, etc
|
|
2022-01-24 10:30:43
|
that scheme works recursively, and it can be used both horizontally and vertically
|
|
2022-01-24 10:31:39
|
so you can take any NxM macroblock of 1-bit values and bitpack it into NM-bit macropixels
|
|
2022-01-24 10:34:47
|
with special-casing in the decoder to recognize such a weird sequence of e.g. Squeeze, RCT, Squeeze, RCT, RCT, Palette to do the unpacking in a way more efficient way than naively undoing each transform in sequence, it could be efficient too
|
|
2022-01-24 10:36:56
|
2D bitpacking of e.g. 2x2 1-bit pixels into 4-bit macropixels likely compresses better than the usual 1D bitpacking of 8x1 1-bit pixels into 8-bit macropixels, at least according to my gut feeling
|
|
2022-01-24 10:41:13
|
could in principle even pack 6x5 1-bit pixels into 30-bit macropixels...
|
|
2022-01-24 10:42:40
|
that's probably a bad idea, but 4x4 pixels into 16-bit macropixels could perhaps work well
|
|
2022-01-24 10:48:16
|
<@532010383041363969> so the jxl bitstream does in fact allow bit packing, just not directly, you need a fancy chain of modular transforms and a dummy extrachannel to do it. But it can in principle be done.
|
|
|
|
Scope
|
2022-01-24 05:11:23
|
Fix ANS code generation at faster speeds
<https://github.com/libjxl/libjxl/pull/1112>
So it only affects for `-e 1`?
|
|
|
cpc2
|
2022-01-24 05:25:59
|
Hi, I've seen that the image in the jxl website is only 117 bytes despite having a pretty good quality. But if I open it on irfanview and save it again as jxl the resulting file is dozens of kb. Is that image in the main page encoded in some special way or is the encoder in irfanview inefficient?
(Ps I don't have much knowledge of how it works)
|
|
2022-01-24 05:26:15
|
this image
|
|
|
|
Scope
|
2022-01-24 05:27:20
|
<#824000991891554375>
|
|
|
|
veluca
|
|
Scope
Fix ANS code generation at faster speeds
<https://github.com/libjxl/libjxl/pull/1112>
So it only affects for `-e 1`?
|
|
2022-01-24 05:30:11
|
only, no. mostly, yes 😛
|
|
|
|
_wb_
|
|
cpc2
Hi, I've seen that the image in the jxl website is only 117 bytes despite having a pretty good quality. But if I open it on irfanview and save it again as jxl the resulting file is dozens of kb. Is that image in the main page encoded in some special way or is the encoder in irfanview inefficient?
(Ps I don't have much knowledge of how it works)
|
|
2022-01-24 05:52:14
|
It is a hand-crafted bitstream. Don't expect any jxl encoder to get even close to that density. I doubt the search space the libjxl encoder is looking in even includes such encodings...
|
|
|
|
cpc2
|
2022-01-24 05:54:47
|
ahh i see, thanks!
|
|
|
|
_wb_
|
2022-01-24 06:04:47
|
Actually interesting exercise to run cjxp -m -e 9 - g 3 -I 1 on jxl art to see how close it gets to figuring out the MA tree
|
|
|
|
cpc2
|
2022-01-24 06:12:15
|
one other doubt I had is that i talked about jxl in another server and said it can save around 20% of the size converting losslessly from jpeg, but a guy tried it in a converter website (https://jpegxl.io/) and the result was somehow bigger. Is that site converting it wrong somehow?
|
|
|
|
Diamondragon
|
|
cpc2
one other doubt I had is that i talked about jxl in another server and said it can save around 20% of the size converting losslessly from jpeg, but a guy tried it in a converter website (https://jpegxl.io/) and the result was somehow bigger. Is that site converting it wrong somehow?
|
|
2022-01-24 06:15:25
|
I don't think that site is doing lossless. Try using this: https://github.com/libjxl/libjxl/releases/download/v0.6.1/jxl-x64-windows-static.zip
|
|
|
|
fab
|
|
Diamondragon
I don't think that site is doing lossless. Try using this: https://github.com/libjxl/libjxl/releases/download/v0.6.1/jxl-x64-windows-static.zip
|
|
2022-01-24 06:16:28
|
just les effo and olde build less than 0.6
|
|
|
Scope
Fix ANS code generation at faster speeds
<https://github.com/libjxl/libjxl/pull/1112>
So it only affects for `-e 1`?
|
|
2022-01-24 06:16:47
|
no, only new heuistic change
|
|
2022-01-24 06:16:53
|
by one single byte
|
|
2022-01-24 06:16:59
|
no compaed of image
|
|
|
|
Diamondragon
|
2022-01-24 06:17:01
|
unzip, move this jpg into the folder, type 'cmd' in the address bar in windows explorer, and hit enter. Then, do this:
|
|
2022-01-24 06:17:57
|
cjxl [image name].jpg [image name].jxl
|
|
|
|
cpc2
|
2022-01-24 06:19:14
|
👌 thanks, gonna try
|
|
2022-01-24 06:19:31
|
so by doing it in a lossy way it somehow grows in size
|
|
|
|
fab
|
2022-01-24 06:19:38
|
at s 8 is active
|
|
2022-01-24 06:21:20
|
it changes in different way
|
|
2022-01-24 06:21:46
|
i'll try comparing the images visually without posting the results
|
|
|
|
_wb_
|
|
cpc2
so by doing it in a lossy way it somehow grows in size
|
|
2022-01-24 06:26:43
|
Yes, since it wastes bits trying to preserve jpeg artifacts if you encode from pixels.
|
|
|
|
cpc2
|
|
Diamondragon
cjxl [image name].jpg [image name].jxl
|
|
2022-01-24 06:27:08
|
yup, just did it and went from 2.41mb to 2.03mb
|
|
|
_wb_
Yes, since it wastes bits trying to preserve jpeg artifacts if you encode from pixels.
|
|
2022-01-24 06:27:30
|
ahh i see 👌
|
|
|
|
_wb_
|
2022-01-24 06:34:33
|
Any codec that does lossy transcoding either adds extra loss (more artifacts on top of the ones that are already there), or will get larger than the original file. Only the lossless jpeg transcoding mode of jxl can avoid that. But you need to give it the original jpeg file, not just the decoded pixels (which is likely what jpegxl.io does)
|
|
|
|
Scope
|
|
veluca
only, no. mostly, yes 😛
|
|
2022-01-24 06:59:44
|
It is strange, but the result is a little worse on the Manga set
|
|
|
|
_wb_
|
2022-01-24 07:06:03
|
At what speed?
|
|
|
|
Scope
|
2022-01-24 07:08:31
|
`-e 1/2`
|
|
2022-01-24 07:09:34
|
But, on other sets a little better or almost the same, mostly better on photo-type images
|
|
|
|
_wb_
|
2022-01-24 07:13:29
|
Interesting...
|
|
|
|
Deleted User
|
|
_wb_
Any codec that does lossy transcoding either adds extra loss (more artifacts on top of the ones that are already there), or will get larger than the original file. Only the lossless jpeg transcoding mode of jxl can avoid that. But you need to give it the original jpeg file, not just the decoded pixels (which is likely what jpegxl.io does)
|
|
2022-01-24 07:15:51
|
Or both! <:kekw:808717074305122316>
|
|
|
|
veluca
|
|
Scope
But, on other sets a little better or almost the same, mostly better on photo-type images
|
|
2022-01-24 07:54:47
|
can't imagine why xD
|
|
|
|
Scope
|
2022-01-24 07:57:47
|
Sometimes `-e 2` is also slightly worse (like 0.1%), even when `-e 1` is better (compared to older versions)
|
|
|
Justin
|
2022-01-25 09:50:26
|
It should already!
|
|
2022-01-25 09:50:33
|
You can tick it under the expert settings. "JPEG transcode".
|
|
2022-01-25 09:50:54
|
Let me know if you experience any issues.
|
|
2022-01-25 09:57:37
|
|
|
|
username
|
|
Justin
You can tick it under the expert settings. "JPEG transcode".
|
|
2022-01-25 10:45:43
|
that seems a bit counterintuitive is there any reason why it isn't the default for jpeg images?
|
|
|
|
Scope
|
2022-01-26 07:27:17
|
> Do not run filters on color channels using their padded dim
<https://github.com/libjxl/libjxl/pull/1120>
Is it somehow helpful to eliminate boundaries for separate encoding?
|
|
|
|
_wb_
|
2022-01-26 08:17:35
|
Nah, we weren't doing edge cases (on the very right and bottom edges of the whole image) exactly correctly w.r.t. the spec, so that has to be fixed
|
|
|
|
Justin
|
|
username
that seems a bit counterintuitive is there any reason why it isn't the default for jpeg images?
|
|
2022-01-26 08:22:42
|
No, there isn't. I'll enable it by default in the next push. Thanks for the feedback! Highly appreciated
|
|
|
|
lithium
|
2022-01-26 08:51:13
|
A little curious, If I don't misread Jyrki Alakuijala comment,
probably Jyrki Alakuijala don't like separate image and use different algorithm method?
I still can't figure it out this comment...
> Jyrki Alakuijala
> Detecting and using different approaches is a dirty trick that tries to circumvent unnecessary deficiencies -- the system should always just work
> When detecting and using different approaches for compression density, then it is ok
> It is not equally ok as a method to suppress visible artefacts
> https://discord.com/channels/794206087879852103/930838798911291472/933363934889672764
update:
> Detecting and using different approaches is a dirty trick that tries to circumvent unnecessary deficiencies
> -- the system should always just work
vardct can implement some feature to process better for high contrast sharp edge.
> When detecting and using different approaches for compression density, then it is ok
> It is not equally ok as a method to suppress visible artefacts
For DCT worst case will change to another compress algorithm to get better compression.
I try to figure it out this comment, probably like this?
|
|
|
|
Justin
|
|
username
that seems a bit counterintuitive is there any reason why it isn't the default for jpeg images?
|
|
2022-01-26 10:40:52
|
it's live. 🙂
|
|
2022-01-26 02:16:15
|
There's a repo, but it's still private, since we push a lot currently without documenting (yes, I know..😆 ). It will be public in some months, just like avif.io 🙂
That spam algorithm thing looks weird, especially since I did little to no marketing for this website besides some twitter postings and rare news in this discord. Thanks for letting me know!
|
|
|
Koromaru Korüko
|
2022-01-26 02:17:52
|
<@!439539398657441832> what are you using for the page? workers, service workers, or client wasm?
|
|
2022-01-26 02:20:17
|
dont @ me, i dont run the site XD
|
|
|
|
Justin
|
|
Koromaru Korüko
<@!439539398657441832> what are you using for the page? workers, service workers, or client wasm?
|
|
2022-01-26 02:22:19
|
It's client WASM. Planning to add offline support some time with workers, but since this is a fun project with almost no income like avif.io and I don't have the dev skills required, most tasks are paused.
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:23:02
|
client wasm is offline ....
workers are the things that connect to your website to offload the task onto your servers.
|
|
|
|
Justin
|
|
Koromaru Korüko
client wasm is offline ....
workers are the things that connect to your website to offload the task onto your servers.
|
|
2022-01-26 02:23:21
|
I think that is perfect evidence for my lacking skills 😛
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:23:40
|
well then
|
|
2022-01-26 02:23:50
|
i need proper use cases for encoding
|
|
2022-01-26 02:24:01
|
so i can implement actually usefull functions in wasm_extras
|
|
|
|
Justin
|
2022-01-26 02:24:08
|
Ye right! I remember creating some stack exchange replies with links to articles. Nothing spammy though. But it's whatever
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:24:40
|
can you send me a few use cases that you have, and any ideas or suggestions on how the functions should look. I'll then see about implementing them.
|
|
2022-01-26 02:24:57
|
simple stuff, like data xy in data z out
|
|
|
|
Justin
|
|
Koromaru Korüko
can you send me a few use cases that you have, and any ideas or suggestions on how the functions should look. I'll then see about implementing them.
|
|
2022-01-26 02:26:17
|
would publishing the repo instead help as well?
|
|
2022-01-26 02:26:32
|
Ye, most likely the self promotion aspect, that makes sense. 🙂 I think self promotion is fine in a sense, if it flows with the narrative and provides quality. But it's whatever.
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:26:42
|
the repo is a fork and its currently planned once its got a decent interface
|
|
2022-01-26 02:27:20
|
to be merged with the official libjxl repo
|
|
2022-01-26 02:28:22
|
as for publishing, no rush, and tbh no real clue, as I would have to read over half your code base to figure out what/how you even do jxl
|
|
2022-01-26 02:29:24
|
it would be easier if you just give some suggestions.
the only limit would be i don't want to directly interface with files and the likes, as on browser its not impossible but not exactly good.
|
|
|
|
Justin
|
2022-01-26 02:31:22
|
Ye, right. I remember we had a talk with Jon once about progress tracking the conversion process. But then again, I'm way out of suggesting any technical or functional improvements at this point, since this is way beyond my skills.
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:32:16
|
status tracking is a bit of a no go, for browser js
|
|
2022-01-26 02:32:21
|
as its forced single threaded
|
|
2022-01-26 02:32:41
|
I mean, I could implement a callback..
|
|
|
|
Justin
|
2022-01-26 02:33:08
|
@FYI Published it https://github.com/justinschmitz97/jpegxl/
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:33:30
|
love the commit names XD
|
|
|
|
Justin
|
2022-01-26 02:33:48
|
ye, don't whip me pls
|
|
2022-01-26 02:34:07
|
I'll do better now.
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:36:32
|
hehe
|
|
2022-01-26 02:36:50
|
what do you think would be better, a functional interface or an object based interface?
|
|
|
|
Justin
|
|
Koromaru Korüko
what do you think would be better, a functional interface or an object based interface?
|
|
2022-01-26 02:38:21
|
By "you", you refer to this whole chatroom, right? 😄
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:38:45
|
na, i don't usually work directly with javascript so i don't know what the general preference is
|
|
2022-01-26 02:39:25
|
for me personally i prefer using functional interfaces when interfacing with other languages
|
|
2022-01-26 02:39:47
|
as it removes the need to manage objects.
|
|
|
|
Justin
|
2022-01-26 02:40:25
|
https://tenor.com/view/futurama-fry-unsure-squint-hmm-gif-5346260
|
|
2022-01-26 02:40:27
|
Ehhh. yes.. yes of course. Sorry, out of my expertise. 😄
|
|
|
|
Koromaru Korüko
|
2022-01-26 02:40:54
|
aight, no worry
|
|
|
|
Deleted User
|
2022-01-26 02:57:09
|
I typically just override the old code... <:YEP:808828808127971399>
|
|
|
|
Justin
|
|
I typically just override the old code... <:YEP:808828808127971399>
|
|
2022-01-26 03:03:41
|
you lunatic!
|
|
|
|
Deleted User
|
2022-01-26 03:10:58
|
I like to live dangerous. ;)
|
|
|
|
cpc2
|
|
Justin
Let me know if you experience any issues.
|
|
2022-01-26 11:13:47
|
https://github.com/justinschmitz97/jpegxl/issues/1 submitted an issue because the jpeg transcode feature doesn't seem to work (perhaps happened when moving the checkmark from expert settings to the approach section)
|
|
|
|
lithium
|
2022-01-27 07:05:54
|
A little curious, libjxl 1.0 will be ready end of February,
It's mean non-photo content quality and feature improvement will happen on March?<:BlobYay:806132268186861619>
|
|
|
|
fab
|
2022-01-27 07:23:20
|
Wait i send you a screenshot
|
|
|
|
Justin
|
|
cpc2
https://github.com/justinschmitz97/jpegxl/issues/1 submitted an issue because the jpeg transcode feature doesn't seem to work (perhaps happened when moving the checkmark from expert settings to the approach section)
|
|
2022-01-27 10:24:39
|
Looked into it, but I have no clue why this is happening 😦
|
|
|
|
lithium
|
2022-01-29 03:01:48
|
Transform RGB or ycbcr color space to XYB color space,
It's possible add new compress error in this process?
I notice if I use XYB + default intensity target will heppen some tiny artifacts,
when I use intensity target 4000 can reduce those tiny artifacts,
but when I use c1 those tiny artifacts is gone, but I think probably have some other issue on c1.
> cjxl -d 0.5 -e 8 --epf=3
> cjxl -d 0.5 -e 8 --epf=3 --intensity_target=4000
> cjxl -d 0.5 -e 8 --epf=3 -c 1
> https://discord.com/channels/794206087879852103/930838798911291472/935908292100784138
|
|
|
|
fab
|
2022-01-29 03:34:28
|
could you build cjxlng with brotlidec please
|
|
2022-01-29 07:32:35
|
please help
|
|
2022-01-29 07:32:45
|
for %i in (C:\Users\Utente\Pictures\e\*.jpg) do cjxl_ng %i %i.jxl
|
|
2022-01-29 07:32:51
|
i have installed package botli
|
|
2022-01-29 07:33:07
|
i want
|
|
2022-01-29 07:33:09
|
i 0.019 s 8 use new heuristics cjxlng d 0.88
|
|
2022-01-29 07:33:23
|
ffom latest build
|
|
2022-01-29 08:13:54
|
what is the command fo msys
|
|
2022-01-29 08:14:01
|
is the clang pacman
|
|
2022-01-29 08:14:03
|
o nomal one
|
|
|
|
Traneptora
|
2022-01-30 02:05:39
|
I'm getting a build error with git master
|
|
2022-01-30 02:05:42
|
```
[ 65%] Building CXX object lib/CMakeFiles/ac_strategy_test.dir/jxl/ac_strategy_test.cc.o
In file included from /home/leo/Programs/libjxl/lib/jxl/ac_strategy_test.cc:13:
/usr/include/hwy/tests/test_util-inl.h:517:3: error: statement not allowed in constexpr function
HWY_ASSERT(max_pow2 != 0);
^
/usr/include/hwy/base.h:144:3: note: expanded from macro 'HWY_ASSERT'
do { \
^
1 error generated.
```
|
|
2022-01-30 02:05:47
|
is this an upstream bug in Highway?
|
|
2022-01-30 02:06:28
|
I git cloned the repo (recursively), and configured it as such
|
|
2022-01-30 02:06:51
|
```bash
export CC=clang
export CXX=clang++
unset CFLAGS
unset CXXFLAGS
cmake -B build -DCMAKE_BUILD_TYPE:STRING='Release' -DJPEGXL_FORCE_SYSTEM_BROTLI:BOOL='true' -DJPEGXL_FORCE_SYSTEM_GTEST:BOOL='true' -DJPEGXL_FORCE_SYSTEM_HWY:BOOL='true' -DJPEGXL_BUNDLE_LIBPNG:BOOL='NO' -DJPEGXL_BUNDLE_GFLAGS='NO' -Wno-dev
make -C build
```
|
|
2022-01-30 02:07:09
|
highway is git master
|
|
|
|
veluca
|
2022-01-30 02:08:15
|
sounds like an hwy problem yes
|
|
|
|
Traneptora
|
2022-01-30 02:08:39
|
in the short term, can I work around it by not building the tests?
|
|
2022-01-30 02:08:57
|
or is `ac_strategy_test.cc` not really a test but a main file
|
|
|
|
veluca
|
2022-01-30 02:09:05
|
it's a test
|
|
2022-01-30 02:09:10
|
can totally skip tests yes
|
|
|
|
Traneptora
|
2022-01-30 02:10:38
|
I'll add `-DBUILD_TESTING:BOOL='false'` for now
|
|
|
|
lithium
|
2022-01-31 02:36:15
|
`libjxl` `basic_info.uses_original_profile = JXL_TRUE` equal to `cjxl` `-c 1` ?
|
|
|
|
_wb_
|
2022-01-31 04:18:41
|
yes, should be
|
|
|
|
lithium
|
2022-01-31 05:18:19
|
In my test `-c 1` can remove tiny artifacts for non-photo content,
but will happen some strange rectangle artifacts, and file size will bigger than XYB.
I just think maybe those tiny artifacts happen on XYB transform?
|
|
2022-02-01 08:08:15
|
Look like cjxl -d 0.5 -e 8(XYB) + slight bilateral filter will better than use -c 1 for my use case,
but I think apply bilateral filter probably not a good idea.
> https://discord.com/channels/794206087879852103/930838798911291472/937979858598903829
|
|
|
|
fab
|
2022-02-03 08:17:18
|
wb how to conve
|
|
2022-02-03 08:17:23
|
with cjxlng
|
|
2022-02-03 08:17:45
|
|
|
2022-02-03 08:17:55
|
|
|
2022-02-03 09:23:18
|
|
|
2022-02-03 09:23:29
|
some thumbnail look good some look bad
|
|
2022-02-03 09:24:10
|
Effort 8
|
|
2022-02-03 09:24:25
|
Jamaika build unfortunately
|
|
|
diskorduser
|
2022-02-04 03:25:59
|
Use lossless mode
|
|
|
Sage
|
|
fab
|
|
2022-02-04 03:30:57
|
if you're compressing that entire column as an image and you want it to look anywhere near good you should probably use patches for lossy
|
|
|
|
fab
|
2022-02-04 05:03:03
|
I don't know about this encoder
|
|
2022-02-04 05:03:24
|
I know latest version is fixed size
|
|
2022-02-04 05:03:33
|
Only one quality per Speed
|
|
|
diskorduser
Use lossless mode
|
|
2022-02-04 05:21:49
|
Png don't compress
|
|
2022-02-04 05:22:07
|
The image was generated with cjpeg hdr
|
|
2022-02-04 05:22:31
|
Old 4 month commit
|
|
2022-02-04 05:22:40
|
But i have compiled it now
|
|
2022-02-04 05:22:49
|
02 february 2022
|
|
2022-02-04 05:23:09
|
Fixed quality again
|
|
2022-02-04 05:23:13
|
Lossy to lossy
|
|
|
|
diskorduser
|
2022-02-04 05:23:20
|
Pngs made with cjpeg? Whaaat
|
|
|
|
fab
|
2022-02-04 05:23:33
|
Jpg to jxl
|
|
2022-02-04 05:23:40
|
Jpg hdr to jxl
|
|
2022-02-04 05:23:48
|
Cjxlng
|
|
2022-02-04 05:23:53
|
Fixed quality
|
|
2022-02-04 05:23:55
|
S8
|
|
2022-02-04 05:24:04
|
-effort 8
|
|
|
|
diskorduser
|
2022-02-04 05:24:59
|
If you're converting jpg to jxl, probably it's lossless conversion. You don't have to worry about it. Right?
|
|
|
|
fab
|
2022-02-04 05:25:21
|
No cjxlng only has a quality per speed
|
|
2022-02-04 05:25:25
|
That isnt d1
|
|
2022-02-04 05:25:39
|
Unless you touch lossy modular mode
|
|
2022-02-04 05:25:54
|
Who f don't know if is Active
|
|
2022-02-04 05:26:35
|
I downloaed a last compiled from jamaika from 1 day ago
|
|
2022-02-04 05:26:40
|
02gcc
|
|
2022-02-04 05:26:45
|
Not 3101gcc
|
|
2022-02-04 05:27:06
|
That was s8 cjxlng
|
|
2022-02-04 05:27:40
|
I didnt make show the name of build
|
|
|
|
diskorduser
|
2022-02-04 05:28:10
|
jpg to jxl is a lossless conversion. You shouldn't add -d 1.
|
|
|
|
fab
|
2022-02-04 05:28:44
|
Yes but this is s 8 cjxlng
|
|
2022-02-04 05:28:47
|
Not d1
|
|
2022-02-04 05:28:50
|
Is fixed quality
|
|
2022-02-04 05:29:03
|
The size vsries
|
|
2022-02-04 05:29:12
|
This was 335 kb
|
|
|
|
diskorduser
|
2022-02-04 05:29:12
|
Why are you using "cjxlng"?
|
|
|
|
fab
|
2022-02-04 05:29:19
|
And 6500 height
|
|
|
diskorduser
Why are you using "cjxlng"?
|
|
2022-02-04 05:29:42
|
For neomelodic or Sanremo or even Sicilian faces
|
|
2022-02-04 05:29:47
|
It looks good
|
|
2022-02-04 05:30:04
|
But it has some blur as i showed
|
|
2022-02-04 05:30:25
|
The inna love bizzarre thumbnail picture is all blirred
|
|
2022-02-04 05:30:40
|
Still not lossless
|
|
|
|
diskorduser
|
2022-02-04 05:30:44
|
If you have jpg, you should just use cjxl and do lossless conversion.
|
|
|
|
fab
|
2022-02-04 05:30:51
|
But lossless is enough for me
|
|
|
diskorduser
If you have jpg, you should just use cjxl and do lossless conversion.
|
|
2022-02-04 05:31:09
|
This some people say it retrocessed
|
|
2022-02-04 05:31:32
|
Or is only 16 percent with 40% picture
|
|
2022-02-04 05:31:46
|
But to me is false data
|
|
2022-02-04 05:32:06
|
Still i don't use since 3 months
|
|
|
diskorduser
If you have jpg, you should just use cjxl and do lossless conversion.
|
|
2022-02-04 05:32:14
|
Dkd OK
|
|
|
|
_wb_
|
2022-02-04 06:07:04
|
cjxlng is WIP
|
|
|
|
Sage
|
|
_wb_
cjxlng is WIP
|
|
2022-02-04 07:42:43
|
what's it for?
|
|
|
|
_wb_
|
2022-02-04 07:50:30
|
It's a cjxl that uses the library api
|
|
|
|
fab
|
2022-02-09 04:02:16
|
—d 0.815 —s 9 ——use_new_heuristics
—q 45.11 —s 8 ——use_new_heuristics (new encode
—d 0.3 —s 9 ——epf=2 ——gaborish=1 ——photon_noise=ISO55 ——target_intensity=256 -p (default
|
|
2022-02-09 04:02:38
|
the poblem is that cjxl can't choose those
|
|
2022-02-09 04:02:45
|
so a new encode has to be made
|
|
2022-02-09 04:02:51
|
like cjxlng
|
|
2022-02-09 09:04:18
|
|
|
2022-02-09 09:05:10
|
john in my opinion the image beatrix supercars should scale bette at low bpp
|
|
2022-02-09 09:05:51
|
like at
|
|
2022-02-09 09:05:56
|
D 0.222 s 6 i 0.615 with old cjxlng
|
|
2022-02-09 09:07:13
|
https://www.sendspace.com/file/luh1vg
|
|
|
|
Jyrki Alakuijala
|
2022-02-16 12:05:04
|
I have created https://github.com/libjxl/libjxl/pull/1178 to reduce the redness blurring at low distances
|
|
2022-02-16 12:05:43
|
probably the 'right thing' would be to have another parameter that indicates if the use is going to be at high zoom levels
|
|
2022-02-16 12:05:53
|
but we can also think that very low distances implicitely indicate it
|
|
|
|
fab
|
2022-02-16 12:26:44
|
Anyone for a build
|
|
2022-02-16 12:26:57
|
Win64 win 7
|
|
2022-02-16 12:39:19
|
scope ae you acgtive
|
|
2022-02-16 01:27:35
|
https://music.youtube.com/playlist?list=PLic8c70Da8qhatUbUXmWF7lZOxsETCjmj&feature=share
|
|
2022-02-16 01:28:06
|
I guess this are the images where jxl has more difficulties
|
|
2022-02-16 01:32:19
|
|
|
2022-02-16 01:32:32
|
Like if you tell jxl encode this
|
|
2022-02-16 01:32:46
|
Probably the artifacts won't be bad
|
|
2022-02-16 01:33:03
|
But if the neomelodic are mixed with INNA
|
|
2022-02-16 01:33:12
|
Then is more complex
|
|
2022-02-16 01:33:24
|
Text is also important for me
|
|
2022-02-16 01:33:37
|
I posted it in benchmarks
|
|
2022-02-16 02:34:06
|
<@!532010383041363969> how to download the build in github
|
|
2022-02-16 02:34:11
|
do i need peemium github
|
|
2022-02-16 02:34:45
|
i'm waiting fo the checks
|
|
|
|
Jyrki Alakuijala
|
2022-02-16 02:34:45
|
I don't know, I'm using git without experience or substantial understanding of it
|
|
|
|
Koromaru Korüko
|
|
Jyrki Alakuijala
I don't know, I'm using git without experience or substantial understanding of it
|
|
2022-02-16 02:41:52
|
this is everyone who uses git...
|
|
2022-02-16 02:42:13
|
if the option isn't in my GUI it doesn't exist
|
|
|
|
fab
|
2022-02-16 03:00:44
|
https://github.com/libjxl/libjxl/runs/5217664268
|
|
2022-02-16 03:00:50
|
why this is a job
|
|
2022-02-16 03:01:04
|
and not a run
|
|
2022-02-16 03:01:19
|
|
|
2022-02-16 03:02:36
|
ah i saw the eo
|
|
2022-02-16 03:02:42
|
the mistake
|
|