|
spider-mario
|
2021-01-27 10:06:27
|
I guess I had fun
|
|
|
raysar
|
|
Master Of Zen
follow build instructions and compile 👍
|
|
2021-01-27 10:18:06
|
Or somebody can share it over internet because compilation in windows is horrible and have always problems 😫
|
|
2021-01-27 10:20:01
|
If you want to do some tests, it's a picture of mine, nikon 14bits in png 16bits srgb. I have the 24mpx version with noise.
|
|
|
|
spider-mario
|
2021-01-27 10:34:29
|
the windows version builds quite well with msys2 + mingw-w64
|
|
2021-01-27 10:35:02
|
or are you having problems with that too?
|
|
|
|
Deleted User
|
|
raysar
Hello, where do you find the cjpexl.exe binary? You compile it? I don't find any website sharing it. There is only sources on the gitlab. :/
|
|
2021-01-27 10:45:01
|
https://discord.com/channels/794206087879852103/794206170445119489/803365469150380063
|
|
|
_wb_
Same here
|
|
2021-01-27 10:48:32
|
I guess I better enable "strict transformations" so people don't use up my credits converting superior image formats to gif ;P
|
|
|
|
raysar
|
2021-01-27 11:56:58
|
thank you, i miss theses messages (https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=67989&viewfull=1#post67989)
|
|
2021-01-28 01:45:11
|
I have read options (cjpegxl.exe -v -v -h), i see the param --override_bitdepth works in lossless mode (for example to choose 14bits) but in lossy picture seem to be always in 8bits. (file zise is the same in bit depth 4 to 14 :D)
The encoder did not support lossy with an bit depth other than 8 ? Maybe this work is for the future?
|
|
|
lonjil
|
2021-01-28 01:47:30
|
lossy is always 32 bit floating point afaik
|
|
|
|
raysar
|
2021-01-28 01:55:49
|
So here, if i read value of each pixel the a is a precision more than 256 value per color? Source file is 14bits, -d 0.1 -s 8
Lossless jxl give 5.5 MB, better loss give 1.2MB, the gap is so huge :/
|
|
|
|
lonjil
|
2021-01-28 01:57:56
|
`mo`?
|
|
|
|
raysar
|
2021-01-28 01:58:09
|
if i do the same with the same image in 8bit, result is the same size.
|
|
2021-01-28 01:59:00
|
sorry (MByte)
|
|
|
|
lonjil
|
2021-01-28 02:02:37
|
lossy should be a fair bit smaller
|
|
|
|
raysar
|
2021-01-28 02:08:00
|
8bits: 1 282 732 Byte 16bits: 1 259 132 Byte, lol (I convert 16bits png in 8bits png with paint.net)
|
|
|
|
lonjil
|
2021-01-28 02:08:05
|
<@!231086792315633664> I downloaded your lossy jxl file but I can't even decode it.
|
|
2021-01-28 02:08:44
|
could you maybe upload the original PNG? And which version of jxl are you on?
|
|
|
|
raysar
|
2021-01-28 02:09:44
|
the png is up in the thread, and i use the binary linked here few hours ago.
|
|
|
|
lonjil
|
|
|
raysar
|
2021-01-28 02:12:03
|
image glass decode it wrong, but it works on imagemagick viewer and nomacs.
|
|
|
|
lonjil
|
2021-01-28 02:26:39
|
<@!231086792315633664> I can confirm that there is a lot more than 256 values per channel in the lossy JXL
|
|
2021-01-28 02:27:58
|
Original has 63514 unique values in the green channel.
Lossy JXL has 46536.
|
|
2021-01-28 02:28:31
|
wait sorry other way around 😅
|
|
|
raysar
I have read options (cjpegxl.exe -v -v -h), i see the param --override_bitdepth works in lossless mode (for example to choose 14bits) but in lossy picture seem to be always in 8bits. (file zise is the same in bit depth 4 to 14 :D)
The encoder did not support lossy with an bit depth other than 8 ? Maybe this work is for the future?
|
|
2021-01-28 02:36:50
|
actually I just noticed. You said `cjpegxl.exe`. That is the old name, so you're using a pretty old version.
|
|
|
|
raysar
|
2021-01-28 02:59:41
|
it's a mistake, i would write cjxl.exe ^^ i verify it's a 24-12-2020 compiled, i see an other from 23-01-2021
|
|
|
Master Of Zen
|
|
raysar
it's a mistake, i would write cjxl.exe ^^ i verify it's a 24-12-2020 compiled, i see an other from 23-01-2021
|
|
2021-01-28 03:08:52
|
>32-01-2021 <:monkaS:654081051848605726>
|
|
|
Nova Aurora
|
2021-01-28 03:28:49
|
The 32 of January?
|
|
|
|
lonjil
|
2021-01-28 03:31:36
|
no this is america the 1st day of the 32nd month
|
|
|
|
Nova Aurora
|
2021-01-28 03:34:06
|
But isn't that ISO 8601 Data elements and interchange formats – Information interchange – Representation of dates and times?
|
|
2021-01-28 03:34:59
|
nope that would be written 2021-01-32
|
|
2021-01-28 05:58:08
|
mmm ISO always making things so short and concise
|
|
|
_wb_
|
2021-01-28 08:43:38
|
not sure how much ISO "inside info" I am supposed to / allowed to share publicly but I put some in the <#803379415106584626> channel
|
|
|
|
Deleted User
|
2021-01-28 08:53:10
|
<@!794205442175402004> it's better to say sorry than to ask for permission 😄
|
|
2021-01-28 09:00:44
|
So by 21/04 we should have:
1. jxl file format is FDIS
2.conformance testing is in place
3. reference software is in place
4. api is stabilized
5.libjxl 1.0 released
6.......
7. PROFIT (browser adoption) 😎
|
|
|
|
_wb_
|
2021-01-28 09:43:09
|
Conformance is not a huge priority for us since we are not aware of anyone wanting to make a from-scratch decoder. Hardware decoders are unlikely (hw encoders is something else, but conformance only applies to decoding), and there seems to be little incentive to make another software decoder if the existing one already has speed and robustness as important targets.
|
|
2021-01-28 09:43:49
|
File format is de facto already done, we just need time to convert the code to spec, basically :)
|
|
2021-01-28 09:45:17
|
API stable enough for integration should happen well before April.
|
|
2021-01-28 09:45:45
|
Libjxl 1.0 I don't expect by April, I think we'll be at 0.4 or so by then...
|
|
|
improver
|
2021-01-28 09:55:12
|
|
|
2021-01-28 09:55:27
|
is this path currently implemented by reference encoder? how efficient it will be?
|
|
2021-01-28 09:56:10
|
tho.. well i guess efficiency wise it'll be the same as regular jpg
|
|
2021-01-28 09:56:52
|
in that case, is jpeg-compatible encoding implemented in general?
|
|
|
|
_wb_
|
2021-01-28 09:57:19
|
For now you can just do mozjpeg or guetzli and encode the result with cjxl
|
|
2021-01-28 09:57:53
|
But better results can probably be obtained by taking into account how jxl will do the recompression
|
|
|
|
improver
|
2021-01-28 09:59:19
|
hmm. i guess jpg-compat mode keeps some data to restore checksum compatible original. which could be cut out in this case
|
|
|
|
_wb_
|
2021-01-28 10:03:05
|
Yes, we should add an option to cjxl to skip that part if you don't care about it, should shave off some bytes
|
|
2021-01-28 10:04:25
|
But could also do e.g. better DC precision without costing much in the jxl size
|
|
2021-01-28 10:12:07
|
roughly speaking, you can currently get ~20% size saving by doing mozjpeg-as-jxl, and ~50% size saving by doing pixels-as-jxl (not representable as an old jpeg), for same visual quality. I think with some tricks we could get ~30% size savings by doing jpeg-compatible-jxl which can still be converted to an old jpeg (without the size savings then of course).
|
|
|
|
Deleted User
|
|
_wb_
Libjxl 1.0 I don't expect by April, I think we'll be at 0.4 or so by then...
|
|
2021-01-28 10:30:11
|
people like the sound of 1.0. they fell more confortable with a software if the version is > 1.0
|
|
|
lithium
|
2021-01-28 10:39:33
|
In my opinion, mozjpeg didn't work very well(maxButteraugli) above quality 90,
if you want more fidelity, recommend use libjpeg in quality 90~95 area.
|
|
|
|
_wb_
|
2021-01-28 10:39:57
|
mozjpeg does 4:2:0 by default so you need to disable that for high fidelity
|
|
2021-01-28 10:40:03
|
`-sample 1x1` iirc
|
|
2021-01-28 10:40:38
|
but still, it's indeed mostly aiming at a somewhat lower quality
|
|
|
|
lithium
|
2021-01-28 10:40:42
|
yes, i always yuv 444
|
|
|
|
_wb_
|
2021-01-28 10:40:51
|
I recommend guetzli for high fidelity, mozjpeg for medium fidelity
|
|
2021-01-28 10:41:38
|
in production, guetzli is too slow so we use normal libjpeg-turbo for the higher qualities in cloudinary
|
|
|
|
lithium
|
2021-01-28 10:46:33
|
Trellis Quantization will affect image quality, not always a good idea
|
|
2021-01-28 10:47:47
|
like sjpeg https://github.com/webmproject/sjpeg, get high psnr but maxButteraugli not very well.
|
|
2021-01-28 10:49:16
|
Agree, guetzli is too slow, libjpeg-turbo is a good choose.
|
|
|
|
improver
|
2021-01-28 10:51:20
|
i was thinking about jpeg-compatible encoding mode a bit more. could transparency be encoded that way, and could such transparency be replaced with static color when converted to jpeg?
|
|
2021-01-28 10:53:34
|
i think there was mentioned before that transparency can be added, but for something not fully transparent (eg with alpha channel), how would that work when coded to jpg
|
|
2021-01-28 10:56:00
|
i assume one could render it with desired solid color background, and then add alpha to that, but since solid color is already applied, for non-0 non-1 alpha pixels there would need to be something to either undo that or override these pixels for jxl display use case
|
|
2021-01-28 10:58:43
|
but idk if such complexity would make sense. might be saner to just not do alpha in such situation. i was thinking for thumbnail (for possibly alphaed images) generation use case. one can render with solid background, but that's annoying for site themability
|
|
|
|
_wb_
|
2021-01-28 11:00:26
|
we can do alpha either premultiplied or not premultiplied. In this case, premultiplied would be best, the JPEG would then have a black background
|
|
|
|
improver
|
2021-01-28 11:00:55
|
black is not always the most desirable color though
|
|
|
|
_wb_
|
2021-01-28 11:01:13
|
other background colors seem tricky to do without bleeding it into the semi-transparent pixels
|
|
|
|
improver
|
|
Jim
|
2021-01-28 11:02:21
|
Can just call that the dark theme.
|
|
|
|
_wb_
|
2021-01-28 11:04:18
|
In any case, the jpeg would not really be the same as the jxl so I dunno how useful it would be
|
|
2021-01-28 11:05:06
|
Maybe we could embed the jpeg in an svg and add the alpha mask as a png in the svg, I think that can work
|
|
|
|
improver
|
2021-01-28 11:06:08
|
that sounds actually interesting.
|
|
|
|
Jim
|
2021-01-28 11:07:06
|
Wouldn't that have a performance impact? I see a lot of "svg causes slow performance" issues.
|
|
|
|
_wb_
|
2021-01-28 11:07:37
|
that's mostly svgs with lots of curves to render, in this case it would be a "fake" svg that just contains raster images
|
|
|
|
improver
|
2021-01-28 11:07:37
|
depends on site. if not many images, it could be okay
|
|
2021-01-28 11:09:14
|
i have feeling that for big amount of images it could be slower too but would need to measure that. but then, if browser supporting jxl opens that combo, then alpha is applied twice
|
|
2021-01-28 11:10:58
|
so just pre-apply black background before encoding to jxl
|
|
|
|
Master Of Zen
|
2021-01-28 02:40:12
|
That's
|
|
2021-01-28 02:40:17
|
That's really impressive
|
|
2021-01-28 02:40:21
|
https://slow.pics/c/dsY8HeuE
|
|
2021-01-28 02:40:29
|
VVC vs JXL
|
|
2021-01-28 02:40:33
|
`vencapp --profile main10_stillpic --tier high --preset slower --qpa 0 -i ch.yuv -o ch.h266 --qp 32 -f 1 -s 4096x2160 -c yuv420_10`
|
|
2021-01-28 02:40:36
|
|
|
2021-01-28 02:40:46
|
Just wow
|
|
|
BlueSwordM
|
2021-01-28 02:46:06
|
Was this encoded from a video stream or a still image? It might be that for a single image, VVC would actually do quite a bit worse.
It still looks great though.
However, I wonder how we can push JXL further.
|
|
|
|
_wb_
|
2021-01-28 02:46:06
|
agreed, that vvc image has really good appeal for that bitrate
|
|
2021-01-28 02:47:45
|
different encoder techniques are needed to make jxl do something nice at such low bitrates
|
|
2021-01-28 02:49:00
|
this is 0.03 bpp
|
|
2021-01-28 02:49:29
|
750:1 compression
|
|
2021-01-28 02:51:56
|
the vvc image looks amazing for that bitrate, but of course it does turn all the skin into plastic and removes all the subtle texture and noise
|
|
|
|
Master Of Zen
|
|
BlueSwordM
Was this encoded from a video stream or a still image? It might be that for a single image, VVC would actually do quite a bit worse.
It still looks great though.
However, I wonder how we can push JXL further.
|
|
2021-01-28 03:22:47
|
it's still picture from chimera 4k
|
|
|
|
BlueSwordM
|
2021-01-28 03:24:10
|
Oh, so it's a single frame encoded from a video stream.
Very impressive from VVC, but I wonder how it would do without reference from the other images. 🤔
VVIF when? 😆
|
|
|
|
Master Of Zen
|
|
BlueSwordM
Oh, so it's a single frame encoded from a video stream.
Very impressive from VVC, but I wonder how it would do without reference from the other images. 🤔
VVIF when? 😆
|
|
2021-01-28 03:24:55
|
It's single image, that got encoded with jpeg xl and vvc
|
|
2021-01-28 03:25:39
|
I posted both vvc (35.28KB) image and jxl (42.05KB) image
|
|
|
Lastrosade
|
|
BlueSwordM
Oh, so it's a single frame encoded from a video stream.
Very impressive from VVC, but I wonder how it would do without reference from the other images. 🤔
VVIF when? 😆
|
|
2021-01-28 03:25:42
|
The source is not a video its a single image taken from a video
|
|
|
|
BlueSwordM
|
2021-01-28 03:26:04
|
I understand now. Thank you.
|
|
|
Troc
|
2021-01-28 04:03:06
|
Yo, is there a list of image viewing softwares that can view jpg xl?
|
|
|
|
_wb_
|
2021-01-28 04:08:11
|
not yet, but you can take a look in <#803663417881395200>
|
|
|
|
lonjil
|
2021-01-28 04:39:54
|
With the qt-jpegxl-image-plugin, most Qt based image viewers will work.
|
|
2021-01-28 04:40:05
|
For example I'm using Gwenview.
|
|
2021-01-28 04:40:14
|
Though the plugin doesn't handle all JXL files correctly.
|
|
|
Orum
|
2021-01-28 04:41:20
|
are you on the latest version of it?
|
|
|
|
lonjil
|
2021-01-28 04:44:49
|
Haven't updated in a while.
|
|
|
|
Orum
|
2021-01-28 04:45:27
|
they fixed a lot of decoding issues a few weeks back
|
|
|
|
Troc
|
2021-01-28 04:47:36
|
I use Honeyview. Is there something that's not terribly different?
|
|
2021-01-28 04:47:45
|
I require a dark mode frame.
|
|
2021-01-28 04:47:57
|
Ability to zoom with mouse wheel.
|
|
2021-01-28 04:48:10
|
It's also cool to be able to open image editor from viewer.
|
|
2021-01-28 04:48:20
|
And the viewer needs to be faster than Windows default.
|
|
|
fab
|
2021-01-28 04:52:47
|
|
|
2021-01-28 04:53:16
|
what i used to do with cjxl before bitstream changes
|
|
2021-01-28 04:53:44
|
when modular was too slow
|
|
|
|
raysar
|
2021-01-28 05:24:58
|
the -p option for progressive decoding, multiply file size by 3 ... with a quality gain. If i up the -d, image is horrible for the same file size than non -p option.
Have you the same?
|
|
2021-01-28 05:26:14
|
Have you a real multicore encoding? --num_threads did not works for me, only one thread.
|
|
|
|
_wb_
|
2021-01-28 05:32:58
|
What version are you using?
|
|
2021-01-28 05:33:15
|
And what platform/compiler?
|
|
|
|
raysar
|
2021-01-28 05:33:37
|
when i use -s 9 encoding speed, file size increases in relation to -s 8 (111KB vs 136KB) 🙃
|
|
2021-01-28 05:34:31
|
these 23-01-2021 compilation https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=67989&viewfull=1#post67989
|
|
|
|
_wb_
|
2021-01-28 05:34:36
|
Different speed setting produces different image, with lossy
|
|
|
|
raysar
|
2021-01-28 05:35:21
|
yes -s3 -s4 -s5 -s6 -s7 -s8 size decrease, and -s9 size increases ^^
|
|
|
|
_wb_
|
2021-01-28 05:37:29
|
Progressive should not make that much difference
|
|
2021-01-28 05:37:47
|
A few percent is normal, 3x is a bug
|
|
|
|
raysar
|
2021-01-28 05:44:24
|
You have not this bug on you computer?
|
|
2021-01-28 05:46:02
|
cjxl.exe .\mousse.png .\mousse1.jxl -d 2.7 -s 8
|
|
2021-01-28 05:46:46
|
cjxl.exe .\mousse.png .\mousse2.jxl -d 2.7 -s 8 -p
|
|
|
|
_wb_
|
2021-01-28 05:50:31
|
Can you send the png? Want to try to reproduce this
|
|
|
|
lonjil
|
2021-01-28 05:55:04
|
I think it's the image here: https://discord.com/channels/794206087879852103/794206170445119489/804113516118278175
|
|
|
|
raysar
|
|
raysar
If you want to do some tests, it's a picture of mine, nikon 14bits in png 16bits srgb. I have the 24mpx version with noise.
|
|
2021-01-28 05:55:11
|
it's here, i do the same with this png converted in 8bits, with same result.
|
|
2021-01-28 06:01:10
|
i'm comparing this 110KB to this avif 111KB, it's a litle blur, but it's way better than jxl with square artifacts and color artifacts. I'm searching solution for better result.
(imagemagick) convert.exe .\mousse.png -quality 70% .\mousse1.avif
|
|
2021-01-28 06:12:15
|
--epf 3 upgrade quality of artifacts 🙂 --noise 1 too, is there a "negative noise" to blur image against adding noise? 😄
|
|
|
|
_wb_
|
2021-01-28 06:23:47
|
something got broken in --progressive_dc it seems, we'll have to fix that
|
|
2021-01-28 06:24:03
|
for now you can do --progressive_ac only instead of -p, that should still be fine
|
|
|
|
BlueSwordM
|
2021-01-28 06:24:48
|
Also, --noise=1 definitely helps in this picture: https://discord.com/channels/794206087879852103/794206170445119489/804360221996744714
|
|
2021-01-28 06:26:51
|
One thing that would help is if it would be possible would be to adjust the synthesized noise strength, like how you can do it in AV1.
|
|
2021-01-28 06:33:23
|
Woah. modular performs quite a bit better on this image.
|
|
|
|
Deleted User
|
2021-01-28 06:36:32
|
I would also like to add a wish regarding --noise: An automatic mode which only applies noise on gradients. x)
|
|
|
|
raysar
|
2021-01-28 06:37:19
|
--resampling 2 is a bit hardcore for blurring picture 😄 it's not possible to have 1.1 ? 😄
|
|
|
|
Deleted User
|
|
_wb_
Well, we do have splines in jxl, currently unused in the encoder but implemented in the decoder
|
|
2021-01-28 06:38:03
|
Glad to hear. I was about to ask you about that, but you responded before my question 😉
But why exactly Catmull-Rom splines?
|
|
|
|
_wb_
|
2021-01-28 06:40:49
|
Noise is global but luma-modulated. Could of course combine a noise frame with a non-noise frame...
|
|
2021-01-28 06:41:52
|
No idea why splines are what they are, <@604964375924834314> do you know?
|
|
|
|
spider-mario
|
2021-01-28 06:43:38
|
they have potentially desirable properties, in particular they go through each control point, unlike Bezier curves
|
|
2021-01-28 06:43:53
|
if you look at this illustration from Wikipedia: https://en.wikipedia.org/wiki/File:Catmull-Rom_examples_with_parameters..png
those in JXL are of the centripetal kind
|
|
2021-01-28 06:44:30
|
which follows the point quite tightly (more than chordal) but without cusps (unlike uniform)
|
|
|
|
veluca
|
|
raysar
--resampling 2 is a bit hardcore for blurring picture 😄 it's not possible to have 1.1 ? 😄
|
|
2021-01-28 06:52:23
|
we can do a combination of --resampling 2 and a correction layer on top, but didn't implement that yet...
|
|
|
|
Deleted User
|
|
lonjil
Another much lamer one: Opus is supported for embedded audio on all Discord platforms, as Opus is used for voice chat. But, Discord doesn't show the music player for the .opus extension. If you upload an Opus file with the name as .mp3, it always works.
|
|
2021-01-28 07:00:50
|
By the way, Opus is kinda like JPEG XL: it also was conceived from two separate codecs (SILK and CELT) that are complementary and their connection is better than simple sum of them (in Hybrid mode linear prediction-based SILK codes 0-8 kHz speech and CELT cheaply codes higher freqs). It also is state-of-the-art, covers almost all usages (except ultra-low bitrate speech - codec2, and lossless audio - FLAC) and is called, not without a reason, "the Swiss Army Knife of Audio Codecs".
Seems like we're participating in birth of "the Swiss Army Knife of Image Codecs" 😁
|
|
|
|
lonjil
|
2021-01-28 07:02:02
|
I hope so!
|
|
|
|
spider-mario
|
2021-01-28 07:04:40
|
yes, what opus managed to achieve in terms of quality vs. bitrate while still maintaining very low latency is very impressive
|
|
|
|
raysar
|
2021-01-28 07:13:04
|
What is impressive is that it is very little used by people and software. (and people think dolby are good codecs :/)
|
|
|
|
Nova Aurora
|
2021-01-28 07:13:45
|
It's used a lot on backend and invisible applications
|
|
2021-01-28 07:13:59
|
discord and almost all other VC systems
|
|
2021-01-28 07:14:01
|
youtube
|
|
2021-01-28 07:14:08
|
Webm
|
|
|
|
Deleted User
|
2021-01-28 07:14:18
|
Signal and WhatsApp use Opus, too
|
|
|
|
raysar
|
2021-01-28 07:15:03
|
yes, but not push to musician, music software ! and video software
|
|
|
|
Nova Aurora
|
2021-01-28 07:16:03
|
Spotify I uses it for some things I think
|
|
|
|
raysar
|
2021-01-28 07:16:04
|
people download youtube music on website,converting them to mp3 or aac ...
|
|
|
Fox Wizard
|
2021-01-28 07:17:30
|
~~SoundCloud uses opus and mp3... but SoundCloud is kinda 💩~~
|
|
|
|
Deleted User
|
|
Nova Aurora
Spotify I uses it for some things I think
|
|
2021-01-28 07:18:29
|
Spotify uses Vorbis, an earlier work of Opus' authors (also quite good).
|
|
|
raysar
people download youtube music on website,converting them to mp3 or aac ...
|
|
2021-01-28 07:18:59
|
AAAAARGH
|
|
|
|
raysar
|
2021-01-28 07:19:25
|
vorbis is always worst than mp3, mp3 encoder is insanely optimized
|
|
|
|
Deleted User
|
|
raysar
vorbis is always worst than mp3, mp3 encoder is insanely optimized
|
|
2021-01-28 07:20:08
|
Nope, despite all of the optimizations in LAME it's still beaten by Vorbis because of better bitstream. And don't forget about Aoyumi's Vorbis tunings. You're talking with Hydrogenaud.io member 😉
|
|
|
|
Fox Wizard
|
|
raysar
people download youtube music on website,converting them to mp3 or aac ...
|
|
2021-01-28 07:20:57
|
It's so cursed, but true <a:sadd:714292010982441001>
|
|
2021-01-28 07:21:29
|
There are so many "YouTube to mp3" websites and many claim to be high quality D:
|
|
|
|
_wb_
|
|
raysar
cjxl.exe .\mousse.png .\mousse2.jxl -d 2.7 -s 8 -p
|
|
2021-01-28 07:21:36
|
Thanks for this, helped us catch an encoder bug in modular with xyb and 16-bit input images
|
|
|
|
Deleted User
|
2021-01-28 07:24:22
|
<@!794205442175402004> oh, by the way you're here:
```ziemekz@ZiemekLaptop:~/jpeg-xl/build/tools$ ./cjxl DSCN0276.jpg DSCN0276.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.2.0 | SIMD supported: SSE4,Scalar]
Read 4608x3456 image, 91.8 MP/s
Encoding [JPEG, lossless transcode, squirrel], 2 threads.
Failed to compress to JPEG.```
|
|
|
|
_wb_
|
2021-01-28 07:25:36
|
Cmyk?
|
|
|
|
Deleted User
|
2021-01-28 07:25:40
|
How can I send you a JPG that causes this? Straight out-of-camera, Nikon Coolpix P900.
|
|
|
|
_wb_
|
2021-01-28 07:25:56
|
Oh not cmyk
|
|
2021-01-28 07:26:16
|
How large is it?
|
|
|
|
Deleted User
|
2021-01-28 07:26:42
|
3.38 MiB
|
|
|
|
_wb_
|
2021-01-28 07:27:05
|
Just send here? Or does discord recompress?
|
|
|
|
Deleted User
|
2021-01-28 07:27:20
|
They probably recompress
|
|
|
|
spider-mario
|
2021-01-28 07:27:21
|
Discord takes images ≤8 MB as-is
|
|
2021-01-28 07:27:49
|
(don’t know if they mean actual MB or MiB)
|
|
|
Toggleton
|
|
spider-mario
(don’t know if they mean actual MB or MiB)
|
|
2021-01-28 07:28:43
|
8388157 Byte is the limit. We did test that on the AV1 community server <:staiyLol:490451745458225162>
|
|
|
|
spider-mario
|
2021-01-28 07:28:45
|
from what I remember, they don’t even strip EXIF
|
|
|
|
Fox Wizard
|
2021-01-28 07:28:55
|
Discord doesn't compress anything, however the upload limit is 8MB for free, 50MB for Nitro Classic (5 bucks a month) and 100MB for Nitro (10 bucls a month). Discord tends to resize images taken with it's built in camera function though
|
|
|
|
Deleted User
|
2021-01-28 07:29:26
|
Nope, checksums don't match
|
|
|
|
spider-mario
|
2021-01-28 07:29:38
|
even when clicking the “Original” link below?
|
|
|
|
Nova Aurora
|
2021-01-28 07:29:51
|
I still have that image fail on me
|
|
|
|
Fox Wizard
|
2021-01-28 07:29:54
|
Think it removes it for "privacy" and "security"
|
|
|
|
Nova Aurora
|
2021-01-28 07:30:14
|
even if checksums don't match
|
|
|
|
Jim
|
2021-01-28 07:30:48
|
Zip or tar it should be fine.
|
|
|
|
Deleted User
|
|
Nova Aurora
I still have that image fail on me
|
|
2021-01-28 07:30:53
|
It failed for you, too? On the latest encoder?
|
|
|
|
Nova Aurora
|
2021-01-28 07:31:06
|
On the one I compiled a few days ago
|
|
|
|
Deleted User
|
2021-01-28 07:31:22
|
Ok, now it should do the job...
|
|
|
Nova Aurora
On the one I compiled a few days ago
|
|
2021-01-28 07:33:09
|
Same for me, it's based on the code jpegxl-bot authored 1 week ago
|
|
|
|
raysar
|
2021-01-28 07:35:30
|
maybe an other bug on 16bits files, --noise 1 increases file size against --noise 0 ^^, only with the 24mpx file http://dl.free.fr/vTVr656wy (it's a 14bits picture on 16bit png for tests)
|
|
|
|
_wb_
|
|
Ok, now it should do the job...
|
|
2021-01-28 07:41:37
|
<@179701849576833024> here is a jpeg that does not encode, any idea why?
|
|
|
|
fab
|
2021-01-28 07:42:54
|
why some jpeg of whatsapp don't lossless recompress?
|
|
2021-01-28 07:43:11
|
0.2 i used
|
|
2021-01-28 07:43:23
|
the 24/12/2020 version
|
|
2021-01-28 07:44:41
|
https://gitlab.com/wg1/jpeg-xl/-/commit/31c71b0f61123a40789b0b8f54feb70e5995420e
|
|
2021-01-28 07:44:55
|
win64 sse4.1
|
|
2021-01-28 07:45:17
|
windows 7;
|
|
|
|
Nova Aurora
|
2021-01-28 07:45:21
|
can you provide the jpeg?
|
|
|
|
fab
|
2021-01-28 07:45:44
|
no they're personal and i don't think i have them
|
|
2021-01-28 07:45:51
|
the problem maybe is 4:2:0
|
|
2021-01-28 07:46:19
|
i heard that some colorspace are not supported yet there is a bug in the issues
|
|
2021-01-28 07:47:39
|
i'm trying with new build
|
|
|
|
_wb_
|
2021-01-28 07:48:10
|
420 or 422 are ok
|
|
2021-01-28 07:48:15
|
Cmyk is not supported
|
|
|
|
Jim
|
|
_wb_
<@179701849576833024> here is a jpeg that does not encode, any idea why?
|
|
2021-01-28 07:48:33
|
If I disable lossless transcoding it works fine. Also works fine after opening and re-saving the JPG in an editor. Seems there is something about that JPG that may be corrupt or not correctly encoded?
|
|
|
|
fab
|
2021-01-28 07:49:01
|
|
|
2021-01-28 07:49:32
|
is a photo of a cake
|
|
2021-01-28 07:49:38
|
i can check the color space
|
|
|
|
_wb_
|
2021-01-28 07:49:45
|
Could be something weird in the non-image bits that we don't handle
|
|
|
|
fab
|
2021-01-28 07:50:16
|
is only for whatsapp photos
|
|
2021-01-28 07:50:29
|
at least for me
|
|
|
|
veluca
|
2021-01-28 07:50:30
|
not quite sure to be honest - I didn't really check whatsapp pictures
|
|
2021-01-28 07:50:47
|
one repro case could help 🙂
|
|
|
|
Nova Aurora
|
2021-01-28 07:56:30
|
I get this trying to convert it
|
|
2021-01-28 07:56:32
|
|
|
|
|
Jim
|
2021-01-28 07:59:11
|
Hm, odd. It "encoded" but I tried to open the jxl file and was unreadable...
|
|
|
|
fab
|
2021-01-28 08:00:04
|
are you joking the image is 123 kb
|
|
2021-01-28 08:00:13
|
how you got lossless transcode at half?
|
|
2021-01-28 08:01:13
|
i tried with both 0.2
|
|
2021-01-28 08:01:22
|
24/12 and 21/01
|
|
|
|
Orum
|
2021-01-28 08:01:32
|
lossless jpg transcoding resulted 50% size?
|
|
|
|
Jim
|
2021-01-28 08:02:05
|
Oh, that is odd. Somehow I downloaded a smaller file? I redownloaded it and it was bigger. This one failed to encode a jxl.
|
|
|
|
fab
|
2021-01-28 08:02:20
|
ok
|
|
2021-01-28 08:02:51
|
it look like there is an enhancement of exposure
|
|
|
|
Jim
|
2021-01-28 08:03:05
|
The previous one was like 70kb, this one is 123kb.
|
|
|
|
fab
|
2021-01-28 08:03:08
|
maybe not i think that's original
|
|
2021-01-28 08:03:20
|
try saving with paint
|
|
2021-01-28 08:03:25
|
and encoding it
|
|
|
|
Nova Aurora
|
2021-01-28 08:03:46
|
decoding to another format and transcoding worked, it looks like this is entirely with the jxl lossless
|
|
|
|
fab
|
2021-01-28 08:04:20
|
paint is best jpg encoder
|
|
|
|
Jim
|
2021-01-28 08:05:07
|
Resaving in paint worked, just like it did with the other camera pic. The paint image is about twice the size (I think it saves as 100% by default).
|
|
|
|
fab
|
2021-01-28 08:05:58
|
yes 220,3 kb
|
|
2021-01-28 08:06:11
|
but the saved paint lossless encode to jxl
|
|
|
|
Jim
|
2021-01-28 08:06:24
|
Nevermind, the jxl that was encoded was unreadable.
|
|
|
|
fab
|
2021-01-28 08:07:48
|
no it decodes to me
|
|
|
|
Nova Aurora
|
2021-01-28 08:08:22
|
doing the same with krita yields a useful JXL
|
|
|
|
fab
|
|
|
Jim
|
2021-01-28 08:08:41
|
Mine doesn't. The one from the camera worked fine, but this one is not opening.
|
|
|
|
fab
|
2021-01-28 08:08:53
|
aq is the original jpg saved to jpg paint (win 7)
|
|
2021-01-28 08:09:25
|
the problem is does the original jpg encodes to jxl lossless recompressor?
|
|
|
|
Nova Aurora
|
|
|
fab
|
2021-01-28 08:10:27
|
is the file corrupted or there is some whatsapp encode settings that isn't urrently supported like 4:2:0
|
|
|
|
Jim
|
2021-01-28 08:11:08
|
For me, disabling lossless encode produces a readable file. With lossless transcode the jxl is unreadable.
|
|
|
|
Nova Aurora
|
2021-01-28 08:11:18
|
but anything that involves running it though any other encoder/decoder works fine
|
|
|
|
fab
|
2021-01-28 08:11:33
|
yes with jpg paint encoder it works
|
|
|
|
Nova Aurora
|
2021-01-28 08:12:29
|
qt jpeg, krita, libjepg-turbo, Jxl lossy transcode, chormium, squoosh, gimp and firefox could encode and decode with it
|
|
|
|
Jim
|
2021-01-28 08:13:46
|
Here are my results:
- Lossless encode direct from source: failed to read
- Without lossless encode direct from source: produces readable jxl
- Lossless encode after re-encoding from Paint: Produces unreadable jxl
- Without lossless encode from Paint: Produces readable jxl
|
|
|
|
fab
|
2021-01-28 08:14:25
|
wb what is the result
|
|
2021-01-28 08:14:43
|
corrupted file at the sending, at copying
|
|
2021-01-28 08:14:54
|
or some whatsapp files are unreadable because are 4:2:0
|
|
|
|
_wb_
|
2021-01-28 08:15:42
|
Must be something weird in the non-image parts of the jpeg that we cannot properly represent for some reason
|
|
|
|
fab
|
2021-01-28 08:15:53
|
you scanned the file
|
|
|
|
_wb_
|
2021-01-28 08:16:19
|
I am not at a computer, only at phone, cannot check
|
|
|
|
fab
|
2021-01-28 08:16:25
|
is this image 4:2:0
|
|
2021-01-28 08:16:30
|
so maybe is this
|
|
2021-01-28 08:16:34
|
because is not implemented
|
|
|
|
_wb_
|
2021-01-28 08:16:35
|
420 is fine
|
|
|
|
fab
|
2021-01-28 08:16:47
|
so it works with djxl
|
|
|
|
_wb_
|
2021-01-28 08:16:49
|
Only 411 is an issue
|
|
2021-01-28 08:17:01
|
422 and 420 are fine
|
|
|
|
fab
|
2021-01-28 08:17:29
|
|
|
2021-01-28 08:18:08
|
big endian motorola mm
|
|
2021-01-28 08:18:13
|
xnview new version i checked
|
|
2021-01-28 08:18:18
|
i can't use imagemagick
|
|
|
|
Jim
|
2021-01-28 08:20:09
|
xnview support jxl?
|
|
|
|
fab
|
2021-01-28 08:23:32
|
is a jpg
|
|
2021-01-28 08:23:41
|
the one from whatsapp
|
|
|
|
Jim
|
|
|
raysar
|
|
Jim
xnview support jxl?
|
|
2021-01-28 10:19:32
|
only old jxl
|
|
|
|
Deleted User
|
|
Ok, now it should do the job...
|
|
2021-01-29 12:15:09
|
Any bets why this image can't be encoded?
|
|
|
|
Nova Aurora
|
2021-01-29 01:37:27
|
metadata that the lossless encoder attempts to replicate but libjpeg ignores.
|
|
|
_wb_
different encoder techniques are needed to make jxl do something nice at such low bitrates
|
|
2021-01-29 03:10:21
|
where are you getting the vvc encoder?
|
|
|
|
Master Of Zen
|
|
Nova Aurora
where are you getting the vvc encoder?
|
|
2021-01-29 04:37:51
|
Probably that's question to me) https://github.com/fraunhoferhhi/vvenc
|
|
|
|
_wb_
|
2021-01-29 08:11:10
|
decode api is now stable: 0.3 was released! https://gitlab.com/wg1/jpeg-xl/-/releases#v0.3
|
|
|
|
fab
|
2021-01-29 08:35:14
|
the image i sent works?
|
|
2021-01-29 08:35:35
|
sorry if it isn't a professional image
|
|
2021-01-29 08:35:46
|
and if i don't open a bug
|
|
2021-01-29 08:36:07
|
but i don't want people edit the image
|
|
2021-01-29 09:06:33
|
anyone has jpeg xl 0.3 for sse4.1 win64
|
|
2021-01-29 09:06:40
|
maybe scope or jamaika
|
|
|
|
Orum
|
2021-01-29 09:12:42
|
hey, maybe browsers will *finally* work on supporting it now 😄
|
|
|
|
Deleted User
|
|
_wb_
decode api is now stable: 0.3 was released! https://gitlab.com/wg1/jpeg-xl/-/releases#v0.3
|
|
2021-01-29 10:06:46
|
Yaaaay! 😃 Time to update your slides, I guess 😉
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.ga0e56e11b0_0_8
|
|
|
|
_wb_
|
2021-01-29 10:31:40
|
Right! done 🙂
|
|
|
Scope
|
2021-01-29 11:48:53
|
<https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=67989&viewfull=1#post67989>
`jpeg-xl-mingw64-0.3-35ad23dd`
|
|
|
|
Jim
|
2021-01-29 11:55:57
|
Nice, thanks.
|
|
2021-01-29 11:56:14
|
|
|
2021-01-29 11:56:36
|
Why such a big difference in size? The uncompressed versions are roughly the same size... 🤔
|
|
|
|
Scope
|
2021-01-29 11:57:49
|
Solid compression
|
|
|
|
Jim
|
2021-01-29 12:00:16
|
0.3 must be using jxl compression 😆
|
|
|
|
Scope
|
2021-01-29 12:07:38
|
`cjxl.exe 1.png 1.jxl -q 100 -s 9`
```Encoding [VarDCT, d1.000, tortoise]```
VarDCT? 🤔 Has there been a change in the cli for the lossless compression options?
|
|
|
|
Jim
|
2021-01-29 12:18:53
|
I think lossless can only be used with JPG files.
|
|
2021-01-29 12:19:49
|
Also, the DCT is not the same as the output compression format (lossless vs lossy).
|
|
|
|
Orum
|
2021-01-29 12:20:07
|
yeah, `-q 100` should be equivalent to `-d 0`, not `-d 1`
|
|
|
|
Jim
|
2021-01-29 12:20:56
|
I don't think so, you can still have a 100% quality lossy image which is not the same as an actual lossless image.
|
|
|
|
Orum
|
2021-01-29 12:21:48
|
in 0.2.0 it says: `100 = mathematically lossless.`
|
|
2021-01-29 12:21:59
|
so unless that changed, it should be lossless
|
|
|
|
Jim
|
2021-01-29 12:25:17
|
|
|
2021-01-29 12:25:34
|
I don't think mathematically lossless and visually lossless are the same.
|
|
2021-01-29 12:27:05
|
In most modern encoders you can have a 100% lossy image, a completely lossless image, or a slightly lossy lossless image (I suppose it's slightly above a 100% lossy but not quite as lossless as a completely lossless image).
|
|
|
|
Master Of Zen
|
2021-01-29 12:27:23
|
<@!794205442175402004> Is it intended that -q 100 now is not lossless?
```
> cjxl Chimera_DCI4k5994p_HDR_P3PQ_035005.png -q 100 cd.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.0 | SIMD supported: AVX2,SSE4,Scalar]
Read 4096x2160 image, 6.5 MP/s
Encoding [VarDCT, d1.000, squirrel], 6 threads.
Compressed to 496777 bytes (0.449 bpp).
4096 x 2160, 19.58 MP/s [19.58, 19.58], 1 reps, 6 threads.
> ```
|
|
|
|
Orum
|
|
Jim
I don't think mathematically lossless and visually lossless are the same.
|
|
2021-01-29 12:28:11
|
they aren't, but anything that is mathematically lossless is also visually lossless
|
|
2021-01-29 12:28:47
|
and if `-q 100` is supposed to be mathematically lossless, it should be using `-d 0`
|
|
|
|
Master Of Zen
|
2021-01-29 12:29:03
|
`-d 0` errors out
|
|
2021-01-29 12:29:10
|
```
> cjxl Chimera_DCI4k5994p_HDR_P3PQ_035005.png -d 0 cd.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.0 | SIMD supported: AVX2,SSE4,Scalar]
Read 4096x2160 image, 12.5 MP/s
Encoding [VarDCT, d0.000, squirrel], 6 threads.
Failed to compress to VarDCT.```
|
|
|
|
Orum
|
2021-01-29 12:29:53
|
yeah, it's not switching to modular compression for some reason
|
|
|
|
Jim
|
2021-01-29 12:30:09
|
Personally, I would expect `-q 100` as a 100% lossy image.
|
|
|
|
Master Of Zen
|
2021-01-29 12:30:45
|
```
> cjxl Chimera_DCI4k5994p_HDR_P3PQ_035005.png -q 30000 cd.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.0 | SIMD supported: AVX2,SSE4,Scalar]
Read 4096x2160 image, 12.5 MP/s
Encoding [VarDCT, d-2690.900, squirrel], 6 threads.
Failed to compress to VarDCT.```
|
|
|
|
Orum
|
2021-01-29 12:30:45
|
You mean visually lossless? That's fine, as long as the help states that
|
|
|
|
Master Of Zen
|
2021-01-29 12:30:49
|
<:cmon:798146744936300556>
|
|
|
|
Orum
|
2021-01-29 12:31:03
|
but the help clearly says mathematically lossless
|
|
|
|
Master Of Zen
|
|
Jim
Personally, I would expect `-q 100` as a 100% lossy image.
|
|
2021-01-29 12:31:13
|
I expect -q 30000 to be 30k% lossy <:whatisthis:672847617796997165>
|
|
|
|
Jim
|
2021-01-29 12:32:17
|
It says you can't go above 100.... but I'd like to know what `-inf` is... 🤔 An empty file? 😆
|
|
|
|
lonjil
|
2021-01-29 12:32:26
|
<@172952901075992586> but it literally says perfectly lossless, so one would expect that
|
|
|
|
Orum
|
2021-01-29 12:32:55
|
I know when I was testing out negative values going too low resulted in a larger file
|
|
2021-01-29 12:33:19
|
like it was wrapping, but the description implies it's a float
|
|
|
|
Scope
|
2021-01-29 12:33:21
|
I think it's a bug, if I specify `-m` it works as before
`cjxl 1.png 1.jxl -q 100 -s 9 -m`
```Encoding [Modular, lossless, tortoise]```
|
|
|
|
Orum
|
2021-01-29 12:33:56
|
bug report it, and wait for 0.3.1
|
|
|
|
Jim
|
2021-01-29 12:34:28
|
`-m` isn't even in the docs. Not documented or deprecated?
|
|
|
|
Orum
|
2021-01-29 12:34:52
|
you using `-h -v`?
|
|
|
|
_wb_
|
2021-01-29 12:35:36
|
you need to do `-q 100 -m` for now until the fix is in
|
|
|
|
Scope
|
2021-01-29 12:35:46
|
Yep, `-h -v` or `-h -v -v -v`
``` -m, --modular
Use the modular mode (lossy / lossless).```
|
|
|
|
_wb_
|
2021-01-29 12:35:53
|
it's a bug, my fault
|
|
|
|
Jim
|
2021-01-29 12:35:55
|
Ah, didn't know there was an extended help.
|
|
|
|
_wb_
|
2021-01-29 12:36:37
|
I fixed https://gitlab.com/wg1/jpeg-xl/-/issues/94 but accidentally broke -q 100 in doing it
|
|
2021-01-29 12:41:42
|
will try to get it fixed asap, sorry about this
|
|
|
|
Orum
|
2021-01-29 12:47:02
|
We're the QA team 😉
|
|
|
|
Jim
|
2021-01-29 12:56:28
|
AKA the "what did you screw up now" team 😆
|
|
|
|
Deleted User
|
2021-01-29 01:32:41
|
Is it correct behavior that -j doesn't use the nice filtering you get with the lossless transcoding?
|
|
|
|
_wb_
|
2021-01-29 01:36:41
|
what nice filtering?
|
|
|
|
Deleted User
|
2021-01-29 01:37:12
|
Something against banding, let me look it up...
|
|
2021-01-29 01:38:47
|
ah, I think I found the answer myself^^
|
|
2021-01-29 01:39:06
|
The nice filtering is the loop filter.
|
|
2021-01-29 01:40:51
|
Hmn, ok, -b doesn't seem to be supported anymore.
|
|
2021-01-29 01:42:00
|
<@!794205442175402004> Anyway to activate the loop filter in cjxl?
|
|
|
|
_wb_
|
2021-01-29 01:46:21
|
it's automatically activated depending on distance target, iirc
|
|
|
|
Deleted User
|
2021-01-29 01:54:19
|
It's just that jpg --ll--> jxl --ll--> png --q93--> jxl results in a better and slightly smaller image than jpg --j93--> jxl.
|
|
2021-01-29 01:55:00
|
But no big deal going the complicated route.
|
|
|
|
_wb_
|
2021-01-29 02:00:14
|
oh, could be that we do something slightly different when decoding a VarDCT image than when decoding a jpeg to pixels...
|
|
2021-01-29 02:00:51
|
in the long route you're using the jxl implementation of DCT and YCbCr to RGB etc
|
|
2021-01-29 02:01:07
|
in the short route I think it's just libjpeg-turbo
|
|
2021-01-29 02:05:37
|
different implementations of IDCT, chroma upsampling and color conversion give different results and it is likely that ours is better / more accurate (we use 32-bit float for everything, while libjpeg-turbo likely does things with integer arithmetic at least after IDCT, which means larger rounding errors)
|
|
|
|
Deleted User
|
2021-01-29 02:08:16
|
So -j is using libjpeg-turbo?
|
|
|
|
_wb_
|
2021-01-29 02:15:47
|
well I guess whatever libjpeg you have on your system, could also be original libjpeg or mozjpeg
|
|
|
|
fab
|
2021-01-29 02:17:17
|
-j is still jxl vardct?
|
|
2021-01-29 02:17:27
|
or it could be modular?
|
|
2021-01-29 02:19:09
|
still in this 27/01 build the image doesn't read
|
|
2021-01-29 02:19:24
|
is only the images i received with my old phone
|
|
2021-01-29 02:19:44
|
or even the whatsapp images received with newer versions and phones can have this error?
|
|
2021-01-29 02:20:15
|
does it matter or the important is that it lossless recompress photographic serious quality images?
|
|
|
|
_wb_
|
2021-01-29 02:20:40
|
cjxl -j means "read the jpeg as pixels", while the default behavior is "read the jpeg as dct coefficients to be stored like that"
|
|
|
|
fab
|
2021-01-29 02:20:54
|
what are the new features included should i check with -v
|
|
2021-01-29 02:22:26
|
vardct works with the image i sent yesterday
|
|
2021-01-29 02:49:02
|
cjxl -s 3 -d 0.490 --epf=3 --num_reps=7 C:\Users\User\Documents\a.png C:\Users\User\Documents\a4.jxl
|
|
2021-01-29 02:49:06
|
is this command right?
|
|
2021-01-29 02:49:16
|
do i need to risk more or wait for better heuristics or for any dev who does auto optimization of what butteraugli to choose or/with other settings?
|
|
2021-01-29 02:50:48
|
|
|
2021-01-29 02:51:47
|
i'll test with one repetition
|
|
2021-01-29 02:52:21
|
why is same size?
|
|
2021-01-29 02:52:40
|
|
|
|
|
Jim
|
2021-01-29 02:53:28
|
It appears to only be doing 1 rep for both.
|
|
|
|
fab
|
2021-01-29 02:53:33
|
maybe is a test encoder
|
|
2021-01-29 02:53:40
|
so some functions are disabled by developers
|
|
2021-01-29 03:02:04
|
quality is impressive even at -s 4 -q 99.2 is high
|
|
2021-01-29 03:02:19
|
but at less smoothes
|
|
|
|
Jim
|
2021-01-29 03:04:22
|
I would assume the closer you get to 100 the less that really needs to be done by the encoder to achieve a quality image.
|
|
|
|
fab
|
2021-01-29 03:04:44
|
what quality you found transparent
|
|
2021-01-29 03:04:52
|
on the images you tested with 0.3.0
|
|
|
|
Jim
|
2021-01-29 03:05:11
|
You mean with transparency?
|
|
|
|
fab
|
2021-01-29 03:05:18
|
not overly smoothed
|
|
|
|
Jim
|
2021-01-29 03:07:04
|
For me it seems like 80 is great for lossy. Has some artifacts but hardly noticeable, and still seem to get about 15%-20% lower file size than JPG.
|
|
|
|
fab
|
2021-01-29 03:07:44
|
a.png is original
|
|
2021-01-29 03:07:50
|
is whatsapp screenshots
|
|
2021-01-29 03:07:58
|
so q50 made it lossier with png
|
|
2021-01-29 03:08:04
|
|
|
2021-01-29 03:08:11
|
|
|
2021-01-29 03:08:38
|
i got x3 less file size
|
|
2021-01-29 03:08:45
|
to png
|
|
2021-01-29 03:08:48
|
1:3
|
|
|
|
Jim
|
2021-01-29 03:08:58
|
Yeah, I noticed one you start going below 60 there is a switchover where jpg will get better quality.
I haven't done much with lossless so I don't have an opinion on it yet. I know it gets much lower file sizes than png at same quality.
|
|
2021-01-29 03:11:24
|
For me, lossless is things like vector-like images, icons, clipart, drawings, etc. I rarely handle photographic images in lossless.
|
|
|
|
fab
|
2021-01-29 03:33:09
|
|
|
2021-01-29 03:33:18
|
-s 4 -q 99.2
|
|
2021-01-29 03:33:48
|
0.3 libjxl
|
|
2021-01-29 03:34:25
|
could have save those images on lossless recompressor
|
|
2021-01-29 03:35:53
|
20.17%
|
|
2021-01-29 03:37:50
|
not sure of the results
|
|
2021-01-29 03:49:12
|
but anyway i should wait until someone makes better GUIs and optimizers and not choose random butteraugli
|
|
|
|
BlueSwordM
|
2021-01-29 03:51:08
|
I would just use -s 7 for most content, and -s 8 for photographic images and if I have more time to wait, that's all.
|
|
|
|
fab
|
2021-01-29 03:57:19
|
-q 81.82 -s 6
|
|
2021-01-29 03:57:22
|
i will try
|
|
2021-01-29 04:00:37
|
|
|
2021-01-29 04:15:43
|
yes viewed with xnview -s 7 looks better
|
|
|
|
BlueSwordM
|
2021-01-29 04:24:14
|
If you think the images are too blurry, stop setting --epf=3 and use --noise=1.
|
|
2021-01-29 04:24:21
|
Let the encoder decided for filtering. 😛
|
|
|
|
raysar
|
2021-01-29 04:26:53
|
i don't understand the -p progressive option , in the spec there is the possibility to have different layer of decoding. In this encoder, what is the configuration, or how can we verify the structure of the file? ^^
|
|
|
|
fab
|
2021-01-29 04:27:17
|
|
|
2021-01-29 04:36:11
|
amazing good
|
|
2021-01-29 04:39:58
|
i don't know it performs with spotify screenshots from pc
|
|
2021-01-29 04:40:10
|
if wp2 is more efficient for that
|
|
2021-01-29 04:40:19
|
that is interesting
|
|
|
|
raysar
|
2021-01-29 04:46:32
|
Did the encoder works in multicore at home? Only one core for me :/
|
|
|
|
fab
|
2021-01-29 06:08:48
|
-D 0.093 -S 8
|
|
2021-01-29 06:08:52
|
is that option possible
|
|
|
|
raysar
|
2021-01-29 06:47:31
|
the limit is -d 0.100
|
|
|
|
fab
|
2021-01-29 06:49:10
|
cavif rs 0.6.6 94.8 -s 5
|
|
2021-01-29 06:49:23
|
-q 88 -s 5 --epf=3 jxl 0.3
|
|
2021-01-29 06:49:26
|
best efficiency
|
|
2021-01-29 06:50:06
|
i will try to recompress more
|
|
2021-01-29 06:50:10
|
in browser jpeg
|
|
2021-01-29 06:52:05
|
probably uses with screenshots
|
|
2021-01-29 06:52:12
|
or high quality photographic images
|
|
2021-01-29 06:53:16
|
and wp2 quality 0 also
|
|
2021-01-29 06:53:31
|
maybe it works only for that image
|
|
2021-01-29 06:53:35
|
probably yes
|
|
2021-01-29 06:53:36
|
|
|
|
|
_wb_
|
2021-01-29 06:58:36
|
we could probably go higher fidelity than -d 0.1, but if you want to go **that** high fidelity (way beyond what humans can see), why not just go lossless?
|
|
|
|
fab
|
2021-01-29 06:58:37
|
maybe i should posted this in av1 server
|
|
|
|
_wb_
|
2021-01-29 07:17:08
|
`./lib/jxl/jpeg/enc_jpeg_data_reader.cc:269: DHT marker: no Huffman table found`
is what I get with that image
|
|
2021-01-29 07:18:10
|
<@!179701849576833024> is that a JPEG with a default Huffman table (missing explicit Huffman table) and do we not handle that?
|
|
2021-01-29 07:46:04
|
ugh
|
|
2021-01-29 07:46:11
|
```$ hd IMG-20190608-WA0001.jpg |grep "ff c4"
000000b0 03 11 01 ff c4 00 30 00 01 01 00 03 01 01 00 00 |......0.........|
00003520 41 1f ff c4 00 02 ff da 00 0c 03 01 00 02 00 03 |A...............|
000056d0 f3 cf 3c f3 cf 3f ff c4 00 2f 11 00 02 02 00 05 |..<..?.../......|
000066d0 e7 21 e7 6c c3 6f fd b9 89 f9 31 9f ff c4 00 2b |.!.l.o....1....+|
000072c0 bf eb 94 7e 2a df ff c4 00 42 10 00 02 01 02 04 |...~*....B......|
0000e7b0 c7 d8 ff c4 00 2c 10 01 00 02 01 03 03 03 03 04 |.....,..........|
00014bf0 f7 f4 75 83 d1 ff c4 00 2b 10 01 00 02 02 02 02 |..u.....+.......|
```
|
|
2021-01-29 07:46:26
|
that JPEG has 7 DHT markers, one of which is empty
|
|
2021-01-29 07:49:31
|
we should be able to handle that though, we can represent/reconstruct empty DHT markers
|
|
2021-01-29 07:52:20
|
so probably the encoder just needs to chill and relax instead of panicking when it sees an empty DHT
|
|
|
|
veluca
|
2021-01-29 07:58:27
|
Can we, actually? I'm not sure...
|
|
2021-01-29 07:58:44
|
I mean, worst case we can cheat and make it intermarker data
|
|
2021-01-29 07:59:08
|
Why would you ever want an empty dht marker though?
|
|
|
|
Jim
|
2021-01-29 09:06:13
|
Wonder why any encoder would do that. Also wonder why Paint resave only partially fixed the issue.
|
|
2021-01-29 09:08:54
|
I used to get that periodically when I was working with Photoshop. About 1 in 1000 images I would get would end up with a "corrupt file" or "missing marker" error. Resaving in Paint always fixed it... at least enough that Photoshop could read it.
|
|
|
|
raysar
|
|
_wb_
we could probably go higher fidelity than -d 0.1, but if you want to go **that** high fidelity (way beyond what humans can see), why not just go lossless?
|
|
2021-01-29 09:09:59
|
because jxl is the ultimate file format, need to have ultimate params options :D
And there is for me a big gap in size between lossless 16bits file and lossy -d 0.1 file.
The aim is to store camera raw file and reduce file size without loosing the ability to remove picture noise and rescue high and low light after jxl conversion.
After bayer conversion, jxl lossless is bigger than the original raw :/ (it's normal, because there is 4x more pixels)
(i'm thinking if there is a way to store bayer picture in jxl? like DNG :D)
|
|
|
|
lonjil
|
2021-01-29 09:22:22
|
Jon mentioned one way of possibly doing it earlier, but of course there is no tooling for it yet.
|
|
|
|
_wb_
|
2021-01-29 09:25:10
|
We have extra channels, so could store R avgG B in main img and deltaG in an extra channel. Just need to define file format metadata for the layout of the bayer pattern and any other stuff needed to interpret the data.
|
|
|
veluca
Can we, actually? I'm not sure...
|
|
2021-01-29 09:28:17
|
We can store up to 2^6 or so DHT markers, and I think they can be empty, not sure though. If not, can indeed cheat and encode as intermarker data. So many silly jpeg encoders, ugh...
|
|
|
|
veluca
|
2021-01-29 09:43:56
|
I'm quite sure they cannot be empty, we store dht marker switches by putting is_last on a given table...
|
|
|
|
_wb_
|
2021-01-29 09:54:42
|
Right, will have to cheat with intermarker data
|
|
|
Pieter
|
2021-01-29 10:39:20
|
<@794205442175402004> _ Any pretty jxl glitch art?
|
|
|
|
veluca
|
2021-01-29 10:51:36
|
way too many such things over the years 😄
|
|
|
|
spider-mario
|
2021-01-29 11:09:28
|
some of them quite trippy
|
|
|
|
Pieter
|
2021-01-29 11:36:55
|
Indubitably.
|
|
|
|
Master Of Zen
|
|
Pieter
<@794205442175402004> _ Any pretty jxl glitch art?
|
|
2021-01-29 11:41:52
|
https:/twitter.com/Zen_zur/status/1343928335622172673
|
|
2021-01-29 11:42:58
|
That's plugin issue
|
|
|
|
veluca
|
2021-01-29 11:45:40
|
mh... I don't think that makes it to my top 10 😄
|
|
|
|
Pieter
|
2021-01-29 11:51:34
|
With FLIF (before it had that name) we had lots of very trippy images.
|
|
|
|
veluca
|
2021-01-30 12:37:55
|
I suppose you didn't really develop an image codec if you couldn't fill a folder with very funny wrongly decoded images 😛
|
|
|
|
Pieter
|
2021-01-30 01:16:19
|
A way of creating them artificially is to take a valid image, introduce a bitflip, and disable as many sanity checks in the decoder until it works.
|
|
|
|
Master Of Zen
|
|
veluca
I suppose you didn't really develop an image codec if you couldn't fill a folder with very funny wrongly decoded images 😛
|
|
2021-01-30 06:14:40
|
As they say: You can't make eggs without breaking bitstream at least a couple times)
|
|
|
666666t
|
2021-01-30 06:58:01
|
|
|
2021-01-30 06:58:03
|
😔
|
|
2021-01-30 06:58:22
|
ah, to long for the day when jxl stuff is actually packaged :p
|
|
|
|
raysar
|
2021-01-30 08:10:38
|
did you know how to send jxl params with imagemagick convert/mogrify tool? i don't find the full documentation.
https://imagemagick.org/script/convert.php
|
|
|
|
_wb_
|
|
Pieter
<@794205442175402004> _ Any pretty jxl glitch art?
|
|
2021-01-30 09:31:15
|
oooh yes. I'm going to create a channel for that.
|
|
2021-01-30 09:31:33
|
<#805007249465671682>
|
|
|
|
lithium
|
2021-01-30 10:33:02
|
Hello,
If non-photographic image that features high contrast sharp edges and smooth area,
i should enable or disable which flag can let image better?(--noise --dots --patches --gaborish --epf),
And if loop filter-adaptive quantization not suitable in non-photographic image,
which speed(-s) can reduce adaptive quantization and keep other benefit?
|
|
|
|
_wb_
|
2021-01-30 10:43:26
|
I'd disable gaborish and noise. Epf should be good for this, depending on what kind of fidelity you're aiming for (it's more useful for low fidelity than for high fidelity). Dots and patches should be fine (though probably don't help much unless you have things like text with
repeated glyphs, or star skies). At speed 8 (kitten) perceptual iterations are done that probably work better for photo than for non-photo, so I'd stick to default speed (7 / squirrel). Generally speaking, faster speed settings mean less adaptive quantization and variable blocksizes, which is generally worse but if you have atypical images it might be better.
|
|
|
|
lithium
|
2021-01-30 10:45:54
|
epf level recommend use --epf=3 ? or 2 is better?
|
|
|
|
_wb_
|
2021-01-30 10:51:46
|
higher level can get rid of more dct ringing/noise, but shouldn't be needed if you have a high enough quality target (low enough distance) – normally the default epf should be reasonable, but of course maybe on a specific image you may want to try different things
|
|
|
|
lithium
|
2021-01-30 11:08:17
|
disable --noise=1 produce many noise on some image, --gaborish=1 and --epf=3 is fine,
in cavif-0.6.6 those area(high contrast sharp edges and smooth) is compress better than jpeg xl vardct,
but other area jpeg xl vardct is better.
|
|
|
bonnibel
|
2021-01-30 11:15:46
|
(I love the animal names for speeds btw. They're cute touches)
(~~and not in an annoying way like when corps try to get all cute with their error pages and changelogs and EULAs~~)
|
|
|
|
_wb_
|
2021-01-30 11:24:35
|
i still wonder if a wombat is really faster than a squirrel though
|
|
2021-01-30 11:25:13
|
|
|
2021-01-30 11:25:34
|
ok it checks out
|
|
2021-01-30 11:25:34
|
|
|
|
|
Fox Wizard
|
2021-01-30 11:25:37
|
<a:godspeed:719679385153699851>
|
|
|
|
_wb_
|
2021-01-30 11:26:10
|
are kittens that much slower than cats though?
|
|
2021-01-30 11:26:34
|
|
|
2021-01-30 11:26:40
|
google does not know a speed for kittens
|
|
|
|
bonnibel
|
2021-01-30 11:26:45
|
There's only one way to find out
requesting funding for a few hundred elaborate animal races
|
|
|
|
Fox Wizard
|
2021-01-30 11:27:52
|
I like how different websites have different information
|
|
2021-01-30 11:28:25
|
Guess we'll never know how fast squirrels really are <a:sadd:714292010982441001>
|
|
|
|
spider-mario
|
|
lithium
disable --noise=1 produce many noise on some image, --gaborish=1 and --epf=3 is fine,
in cavif-0.6.6 those area(high contrast sharp edges and smooth) is compress better than jpeg xl vardct,
but other area jpeg xl vardct is better.
|
|
2021-01-30 02:14:42
|
right, we haven’t yet completely fine-tuned noise parameter heuristics
|
|
2021-01-30 02:15:01
|
so far, we have focused more on the generation of noise given the parameters, since changing that would be an incompatible format change
|
|
2021-01-30 02:16:27
|
we wanted noise that would look natural, so we experimented a bit with uniform, triangular, gaussian, and different ways to high-pass filter it a bit
|
|
|
|
Deleted User
|
2021-01-30 02:20:12
|
Could some dev try to explain what kind of changes are to be expected in the future and which things would be impossible with a frozen bitstream?
|
|
|
|
_wb_
|
2021-01-30 03:08:43
|
The bitstream is frozen
|
|
2021-01-30 03:09:25
|
So e.g. we cannot change the context modeling anymore, it is what it is
|
|
|
|
Jim
|
|
Could some dev try to explain what kind of changes are to be expected in the future and which things would be impossible with a frozen bitstream?
|
|
2021-01-30 03:23:21
|
That should mean anything that won't affect the actual encoded format. So, pretty much anything as far as the decoder goes (new features, performance improvements, completing features that have yet to be solidified). For the encoder that could mean completing features that have not been completed (obviously staying within the limits of what the file container/bit format can do) or performance improvements. I know Jon has said in a few places there are features that they plan on adding that have not gotten much focus yet, so I'm sure there are plenty of items on the list that could be added/improved upon if you are seeking to contribute.
As far as impossible... changing the format of the encoded data. Changing how the container works.
|
|
|
|
_wb_
|
2021-01-30 03:37:06
|
There are coding tools the decoder can decode but the encoder isn't using them yet, or not yet to their full potential. These things we put in the spec because we expect they will be useful for future encoder improvements.
|
|
2021-01-30 03:37:49
|
For example, we can do up to 256x256 DCT, but I think the current encoder does not huge such huge transforms
|
|
2021-01-30 03:38:48
|
Blocks can be aligned to any multiple of 8 offset, but the encoder currently only uses natural alignment (e.g. 32x32 blocks only at a multiple of 32 offset)
|
|
|
|
Deleted User
|
2021-01-30 03:38:58
|
But decoder should be able to decode that successfully, if I e.g. read the spec and prepare the file manually in a hex editor 😛
|
|
|
|
_wb_
|
2021-01-30 03:39:02
|
Splines are not used by the encoder
|
|
2021-01-30 03:39:05
|
Yes
|
|
2021-01-30 03:39:23
|
The decoder can decode that, and we did test these things
|
|
2021-01-30 03:39:48
|
But it's not used by the normal encoder atm, or only in a limited way
|
|
2021-01-30 03:40:59
|
Patches are only detected if they are repeated and close enough to a region of solid color - there could be other useful uses of patches
|
|
2021-01-30 03:46:01
|
Layers could be used to mix modular and vardct, or to e.g. make a big-block+noise base layer with a small-block selective correction layer on top of it. The encoder is not doing any such fancy stuff (yet).
|
|
2021-01-30 03:46:04
|
Etc etc
|
|
|
|
Deleted User
|
|
_wb_
The decoder can decode that, and we did test these things
|
|
2021-01-30 03:47:03
|
Do you have any test .jxl files that can test spline decoding?
|
|
|
|
_wb_
|
2021-01-30 03:48:04
|
I don't have one nearby but we will produce them to create conformance testing bitstreams...
|
|
|
|
lithium
|
|
spider-mario
right, we haven’t yet completely fine-tuned noise parameter heuristics
|
|
2021-01-30 03:50:53
|
Thank you very much for your help, <@!794205442175402004> and <@!604964375924834314>
Look like discrete cosine transform on smooth area can't process very well,
If i hope vardct mode process high contrast sharp edges and smooth area can keep smooth(like avif), what should i do?
// some information
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68459&viewfull=1#post68459
|
|
|
Skeebadoo
|
2021-01-30 04:46:13
|
One thing that bothers me a little is... how will I be able to tell if it's a lossless or lossy jxl?
|
|
2021-01-30 04:46:33
|
With png there was no question about it
|
|
2021-01-30 04:46:52
|
So let's say jxl gets widely adopted and I open a jxl file in a browser
|
|
2021-01-30 04:47:20
|
And there's no easy way to tell if it's mathematically lossless or lossy compression
|
|
2021-01-30 04:47:38
|
Unless I read the file's metadata
|
|
|
|
_wb_
|
2021-01-30 04:48:20
|
Lossy png is a thing too you know
|
|
|
|
Skeebadoo
|
2021-01-30 04:48:30
|
But almost unheard of!
|
|
|
|
_wb_
|
2021-01-30 04:48:52
|
People use png8 all the time to save bytes
|
|
2021-01-30 04:49:04
|
There are fancier tricks too
|
|
|
|
Skeebadoo
|
2021-01-30 04:49:40
|
I was always convinced that there's just the 0 - 9 compression level like with flac
|
|
|
|
_wb_
|
2021-01-30 04:50:00
|
Not to mention people who take a crappy jpeg and save it as png
|
|
|
|
Skeebadoo
|
2021-01-30 04:50:21
|
And you'd have to do some digging to make a lossy png
|
|