|
Crixis
|
2021-03-05 04:33:20
|
I've tried
|
|
|
fab
|
2021-03-05 04:33:24
|
do you want comparisons
|
|
2021-03-05 04:33:28
|
do you have same build
|
|
2021-03-05 04:37:49
|
scope try lower qualities with the same build with your anime/manga/comics image
|
|
2021-03-05 04:39:13
|
i do not know if i use speed 7 and not 3
|
|
|
BlueSwordM
|
2021-03-05 04:45:39
|
Just use speed 7(which is the default).
|
|
2021-03-05 04:45:46
|
It's the most balanced preset overall IMO.
|
|
|
|
fab
|
2021-03-05 04:58:02
|
some files inflates
|
|
2021-03-05 04:58:07
|
also there is some upscaling
|
|
2021-03-05 04:58:41
|
so bad settings overall in term of fidelity
|
|
2021-03-05 04:59:39
|
but you solve some problems:
|
|
2021-03-05 04:59:40
|
bits per pixel
file sizes in comparison to avif
file size for a certain quality
ram usage
nhw codec usage
when wp2 floating partitioning comes out
|
|
2021-03-05 05:00:20
|
you have like an artificial quality, you destroy totally your jpgs, you use older builds with system vulnerabilities
|
|
2021-03-05 05:01:28
|
|
|
2021-03-05 05:04:00
|
i use 0.3, if you use newer build the modular like upscaling will makes file too much bigger and worse due to integral transforms
|
|
2021-03-05 05:04:12
|
but i don't understand these thing of integral transforms
|
|
2021-03-05 05:04:53
|
what are integral transforms? are they specific of an image, video codec? are simply things that transforms blocks like rectangular, square?
|
|
|
|
Deleted User
|
|
fab
question for cloudinary
|
|
2021-03-05 05:20:23
|
I think Jon has now officially been renamed. 😁
|
|
|
Jyrki Alakuijala
|
|
BlueSwordM
Just use speed 7(which is the default).
|
|
2021-03-05 05:34:16
|
Is it the default? (I usually optimize all heuristics for the default setting)
|
|
|
|
BlueSwordM
|
|
|
Jyrki Alakuijala
|
|
|
fab
|
2021-03-05 05:54:42
|
12,5 MB (13.146.858 byte) 68 FILES
7,86 MB (8.249.565 byte) 68 FILES
|
|
2021-03-05 05:55:51
|
38% REDUCTION ENCODING TO MODULAR 56% AND 61
|
|
2021-03-05 06:01:51
|
55,7 MB (58.506.216 byte)
|
|
2021-03-05 06:01:57
|
original was 66,6 mb
|
|
2021-03-05 06:02:36
|
could have used lossless jpg recompressor i only inflated file size and upscaled them
|
|
|
diskorduser
|
2021-03-05 06:10:03
|
Jxl support for imagemagick when <:SadOrange:806131742636507177>
|
|
|
|
fab
|
2021-03-05 06:11:39
|
what is the difference in tools between modular and vardct?
|
|
2021-03-05 06:12:14
|
does modular use gaborish? can you make a comparison in the whitepaper?
|
|
2021-03-05 06:13:21
|
<@!111445179587624960> build jpeg xl
|
|
2021-03-05 06:14:53
|
sorry if i talk too much
|
|
|
spider-mario
|
2021-03-05 06:23:50
|
0.3.3 incoming
|
|
2021-03-05 06:24:26
|
(pushed the changes but forgot the actual version bump to go with it, this is in progress)
|
|
|
lithium
|
2021-03-05 06:28:59
|
I saw many encoder change, that change is for non-photographic image? 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-03-05 06:30:40
|
anime will be 7 % better
|
|
2021-03-05 06:31:11
|
most images will look better I believe
|
|
2021-03-05 06:31:34
|
there is still work to do
|
|
2021-03-05 06:32:26
|
Lee, I'm particularly curious on how it works for you
|
|
2021-03-05 06:32:52
|
I think 0.3.5 will be great for your use case (if my guessing is right), but 0.3.3 might already be an improvement
|
|
2021-03-05 06:33:36
|
In 0.3.4 or 0.3.5 I will reverse the order of dct size selection to merge instead of split -- this will be better for the material you have
|
|
|
|
lithium
|
2021-03-05 06:37:11
|
I understand, i will try jxl 0.3.3, thank you very much 🙂
|
|
|
Scope
|
2021-03-05 06:46:44
|
> * Bump JPEG XL version to 0.3.3.
> * Performance improvements for small images.
Including lossless?
|
|
|
|
spider-mario
|
2021-03-05 06:50:09
|
the change that prompted me to add this line to the changelog mostly touched VarDCT, and a very little bit allocation behavior, so I wouldn’t particularly expect so
|
|
|
|
bobadingo
|
2021-03-05 06:51:06
|
A question about that recent "exif"->"Exif", "exfc"->"Exfc" box type change: Spec change or reference implementation bug?
|
|
|
_wb_
|
2021-03-05 06:52:15
|
Reference implementation bug
|
|
2021-03-05 06:53:05
|
We want to do the same thing as heif Exif boxes, so needs to be capital letter
|
|
|
|
lithium
|
2021-03-05 07:05:13
|
How to watch this, i need a account? https://www.meetup.com/mediadevs/events/276198511/
|
|
2021-03-05 07:11:14
|
ok I solved, https://discord.gg/xSFRyWy
|
|
|
|
Scope
|
2021-03-05 07:13:57
|
<https://encode.su/threads/3564-JXL-version-0-3-released?p=68920&viewfull=1#post68920>
|
|
|
|
lithium
|
2021-03-05 07:41:06
|
<@!532010383041363969>
I test my issue image in jxl 0.3.3, 0.3.3 is better than 0.3.2,
but still have some noise.
https://gitlab.com/wg1/jpeg-xl/-/issues/147#note_523423448
|
|
|
|
spider-mario
|
2021-03-05 07:51:10
|
finally tagged, apologies for the delay
|
|
|
|
Jyrki Alakuijala
|
2021-03-05 08:01:54
|
Thank you spider-mario!!
|
|
|
|
Crixis
|
|
diskorduser
Jxl support for imagemagick when <:SadOrange:806131742636507177>
|
|
2021-03-05 08:06:51
|
Not is yet supported? I think yes
|
|
|
|
_wb_
|
2021-03-05 09:13:42
|
should we do a Q&A on this discord too at some point?
|
|
|
Jim
|
2021-03-05 09:20:54
|
I thought it was always a Q&A here.
|
|
|
|
_wb_
|
2021-03-05 09:21:58
|
https://tenor.com/view/true-kramer-thats-true-true-dat-seinfeld-gif-9432807
|
|
2021-03-05 09:24:33
|
I mean more like scheduling a day/time for being together with a few more than usual, and maybe using the voice channel and screen sharing and stuff
|
|
|
Nova Aurora
|
2021-03-05 09:26:01
|
It would be cool to see what everyone's been working on
|
|
|
|
veluca
|
2021-03-05 09:52:54
|
I could tell you, but then I'd have to kill you 😛
|
|
2021-03-05 09:53:08
|
(kidding, it's not actually secret)
|
|
|
|
Jim
|
|
_wb_
I mean more like scheduling a day/time for being together with a few more than usual, and maybe using the voice channel and screen sharing and stuff
|
|
2021-03-05 11:21:56
|
https://tenor.com/view/supernatural-spn-jensen-ackles-dean-winchester-i-support-that-gif-5204032
|
|
|
Master Of Zen
|
|
_wb_
should we do a Q&A on this discord too at some point?
|
|
2021-03-05 11:51:16
|
Yep, live interaction is the best one
|
|
|
|
fab
|
2021-03-06 08:56:41
|
https://github.com/cocoon/jxl.Net can also compile that?
|
|
2021-03-06 08:56:52
|
is for old c so not sure if your computer supports it
|
|
|
|
diskorduser
|
2021-03-06 04:49:04
|
Do images encoded with s 9 take extra time for decode
|
|
|
|
Crixis
|
2021-03-06 05:02:58
|
A little, especialy modular lossless, vardct not so much
|
|
|
|
fab
|
2021-03-06 05:04:11
|
if you have a lossless recompressed jpeg xl, it will be converted to jpg (for legacy clients)
|
|
2021-03-06 05:04:41
|
if you have a vardct jxl, it will be converted to jpg (but in a different way) with a generation loss
|
|
2021-03-06 05:05:00
|
if you have a modular jxl, you need to configure a software or a client to convert to png
|
|
2021-03-06 05:05:10
|
i'm right correct me if i'm wrong
|
|
2021-03-06 05:05:15
|
<@!424295816929345538>
|
|
|
|
_wb_
|
2021-03-06 05:48:16
|
You can decode any jxl to pixels. What you do with those pixels is your business.
|
|
2021-03-06 05:48:47
|
You can also decode some jxl files to JPEG files.
|
|
|
|
Scope
|
2021-03-06 06:51:40
|
<https://www.reddit.com/r/jpegxl/comments/lyhsum/large_new_sync_to_jpegxl_gitlab_repo/>
|
|
2021-03-06 06:51:47
|
<:Thonk:805904896879493180>
|
|
|
|
Crixis
|
|
Scope
<https://www.reddit.com/r/jpegxl/comments/lyhsum/large_new_sync_to_jpegxl_gitlab_repo/>
|
|
2021-03-06 07:04:45
|
I don't understand people who don't use the latest software version
|
|
|
Pieter
|
2021-03-06 07:05:32
|
Debian Stable users, <@!424295816929345538> is coming for you.
|
|
|
|
Crixis
|
|
Pieter
Debian Stable users, <@!424295816929345538> is coming for you.
|
|
2021-03-06 07:12:46
|
snap and flatpack saved me
|
|
2021-03-06 07:13:44
|
ok, core system lib, but a testing tool from a new software? For test scope?
|
|
2021-03-06 07:14:02
|
cringe
|
|
|
|
Pieter
|
2021-03-06 07:17:24
|
Of course, I was trying to be funny.
|
|
|
|
Deleted User
|
|
Crixis
I don't understand people who don't use the latest software version
|
|
2021-03-06 07:23:23
|
I can understand it when one couldn’t revert or if there are critical issues but neither of these are the case here.. maybe just time constraints?
|
|
|
|
Jim
|
2021-03-06 07:23:42
|
? Changes don't always have to be about performance. It could be that bugs are fixed, representation is made more acceptable, new features, etc.
|
|
|
|
Deleted User
|
2021-03-06 07:24:05
|
or, you know, *critical security exploits fixed*
|
|
|
|
Jim
|
|
|
Deleted User
|
2021-03-06 07:24:35
|
(which is actually the case for jxl)
|
|
2021-03-06 07:25:37
|
when you get programs in early stages, even small updates can make a big impact so I think it’s worth it regardless..
|
|
|
|
BlueSwordM
|
2021-03-06 07:27:11
|
Besides, these bugs would also bring perhaps speed increases.
|
|
2021-03-06 07:27:22
|
Often times, fixes can just bring in negligible speedups. 😛
|
|
|
|
Jim
|
2021-03-06 07:34:44
|
Point being that expecting every change or every "large" change to deliver some noticeable speed improvement is not a good view to have.
|
|
|
|
diskorduser
|
2021-03-07 03:04:08
|
The encoded jxl is 50% larger than jpg at d 0.3. Is this normal
|
|
2021-03-07 03:09:12
|
20% more at d 0.5
|
|
2021-03-07 03:24:12
|
speed 7
|
|
|
|
Pieter
|
2021-03-07 03:29:14
|
Are you starting from a jpeg?
|
|
|
|
diskorduser
|
2021-03-07 03:29:56
|
yes
|
|
2021-03-07 03:30:58
|
`>magick identify mymind-gwoEwy3gLZQ-unsplash.jpg
mymind-gwoEwy3gLZQ-unsplash.jpg JPEG 2731x4096 2731x4096+0+0 8-bit sRGB 1.04911MiB 0.000u 0:00.000
`
|
|
|
|
Scope
|
2021-03-07 03:33:48
|
This is normal for a lossy jpg because it's not just an extra jpg compression, JXL decodes it into pixels and then encodes (it doesn't matter what lossy format it was before and what size it is, it won't affect the efficiency, or rather it will be worse than if it was a lossless image)
Or is it about lossless recompression?
|
|
|
|
diskorduser
|
2021-03-07 03:35:27
|
Makes sense. thanks
|
|
|
|
Pieter
|
2021-03-07 03:36:33
|
<@263309374775230465> If you're compressing a jpeg into jxl, you need to take into account that the jpeg compression added errors. Those errors "make sense" to jpg, and help compression, but from jxl's perspective, they're weird noise, and it has to store that noise (or at least approximate it).
|
|
|
|
Scope
|
2021-03-07 03:48:51
|
That's why JXL has jpeg lossless re-compression (it "understands" jpeg compression and the size will always be smaller, without any losses) because encoding lossy format into lossy adds more losses and it is always worse than the original, even if the new format is more modern and will be much larger in size
|
|
|
|
Pieter
|
2021-03-07 03:51:04
|
If instead you take a shared source (png, or jpeg, or rescaled/high-quality jpeg, ...) and recompress that both with jpeg and jxl, at similar quality the jxl will be smaller, or at similar size it will have better quality.
|
|
|
|
Deleted User
|
2021-03-08 08:18:14
|
Keep spam to Discord 😉
If you want to ask questions on Reddit, at least *please* make one, bigger post. Of course you can ask in comments in other posts. Just don't make new posts, if it's not something big.
|
|
|
|
_wb_
|
2021-03-08 08:23:07
|
I see reddit more as something to announce stuff (and then discuss / ask questions in the comments) than just to ask questions. I mean, it _can_ be just a question, if it's a really interesting question that will spark interesting answers and a good discussion, but it's hard to come up with such questions...
|
|
|
|
Jim
|
2021-03-08 10:05:56
|
I've noticed a lot of questions linger on Reddit with zero or fewer responses too.
|
|
|
|
Master Of Zen
|
2021-03-08 09:37:17
|
Animated JXL playback speed is different depending on zoom level
|
|
2021-03-08 09:37:21
|
|
|
2021-03-08 09:37:25
|
|
|
|
Fox Wizard
|
2021-03-08 09:52:27
|
<a:godspeed:719679385153699851>
|
|
|
|
_wb_
|
2021-03-08 10:11:16
|
That is weird. What application is doing that?
|
|
2021-03-08 10:12:03
|
Are they zooming in in both time and space or something?
|
|
|
|
Nova Aurora
|
|
_wb_
Are they zooming in in both time and space or something?
|
|
2021-03-08 10:12:35
|
https://tenor.com/view/calculation-math-hangover-allen-zach-galifianakis-gif-6219070
|
|
|
|
Crixis
|
2021-03-08 10:13:52
|
In future --new-heuristics will be better then standard or is a close way?
|
|
|
|
Nova Aurora
|
|
Master Of Zen
|
|
2021-03-08 10:14:02
|
in qview it doesn't seem to do it for me
|
|
|
|
Master Of Zen
|
|
_wb_
That is weird. What application is doing that?
|
|
2021-03-08 10:22:25
|
Gwenview
|
|
|
|
veluca
|
|
Crixis
In future --new-heuristics will be better then standard or is a close way?
|
|
2021-03-08 10:24:46
|
ideally it will be faster and better 😛 it's a long way from there though
|
|
|
|
diskorduser
|
2021-03-09 03:48:25
|
Works fine on my gwenview.
|
|
|
|
Deleted User
|
|
Master Of Zen
Animated JXL playback speed is different depending on zoom level
|
|
2021-03-09 09:39:15
|
Maybe that is a feature 😄
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
In future --new-heuristics will be better then standard or is a close way?
|
|
2021-03-09 01:29:18
|
not yet, but Luca has ideas about it -- I'm still working on the old heuristics
|
|
|
|
fab
|
2021-03-09 01:47:17
|
it changes only a bit of saving in size
|
|
2021-03-09 01:47:22
|
for rest is worse
|
|
|
|
Jyrki Alakuijala
|
2021-03-09 01:47:46
|
neither of them are great -- we know how to do those decisions better, just didn't get there yet
|
|
|
|
fab
|
2021-03-09 01:48:17
|
at less than s9 all i see is ringing with new heuristics
|
|
2021-03-09 01:48:36
|
but saving in size is better at least with pdf
|
|
2021-03-09 01:48:55
|
but pdf contains text so text to image uses more space
|
|
2021-03-09 01:49:11
|
i had an image 33 kb and 27 kb
|
|
2021-03-09 01:51:54
|
like at medium quality q 60 to q 90 the compression is good enough to me with new heuristics
|
|
2021-03-09 01:52:24
|
and ringing at most cases if use speed 9 is not bad but if you use less the image is only ringing
|
|
|
Petr
|
2021-03-09 02:29:28
|
Is there some official or "official" JXL test suite (similar to http://www.schaik.com/pngsuite) that can be used mainly by developers who want to support JXL?
|
|
|
|
_wb_
|
2021-03-09 02:30:36
|
Not yet, but we will make something like that for part 3 of the spec
|
|
2021-03-09 02:31:00
|
(conformance testing)
|
|
|
|
Petr
|
2021-03-09 02:31:48
|
Great. But why not sooner? It could prevent things like the current issue with XnView that can only display some JXL images.
|
|
|
|
_wb_
|
2021-03-09 02:35:27
|
Mostly because we have lots of other things to do :)
|
|
2021-03-09 02:44:35
|
But I agree it would be good to have at least a simple test suite that just has a few different modes: vardct, modular, with or without alpha, with or without container, weird icc profile to check color management is done, etc.
|
|
|
|
Jyrki Alakuijala
|
2021-03-09 03:29:14
|
I wonder if the fuzzer could be used to generate a simple correctness test suite, too
|
|
|
|
_wb_
|
2021-03-09 03:50:03
|
I was thinking more something like this: https://kornel.ski/en/color
|
|
2021-03-09 03:50:33
|
but then with all kinds of different jxl images that should look the same but are encoded in completely different ways
|
|
|
|
Crixis
|
|
_wb_
I was thinking more something like this: https://kornel.ski/en/color
|
|
2021-03-09 03:52:49
|
F my gamma 1.0 PNG not work
|
|
2021-03-09 03:54:30
|
firefox is a mess:
|
|
|
|
Jim
|
2021-03-09 04:45:06
|
What version are you using?
|
|
2021-03-09 04:47:04
|
I tried and it looks better. It appears exactly the same in Chrome which is odd. I know FF has bugs for not doing color rep as good as the other browsers.
|
|
|
bonnibel
|
2021-03-09 04:47:24
|
firefox 86 on android 11:
|
|
|
|
BlueSwordM
|
2021-03-09 04:48:41
|
Mine is fine on Firefox 86.
|
|
|
|
_wb_
|
2021-03-09 04:49:00
|
firefox doesn't do proper color management, especially on non-sRGB screens. On sRGB screens it is mostly OK.
|
|
|
|
Jim
|
2021-03-09 04:49:06
|
Same here on Android. On Windows there is only 1 slightly noticeable band.
|
|
|
|
bonnibel
|
2021-03-09 04:49:08
|
i'm using an hdr display, if that affects anything
|
|
|
|
_wb_
|
2021-03-09 04:49:11
|
desktop chrome is OK
|
|
|
|
BlueSwordM
|
2021-03-09 04:49:30
|
Actually, I don't an sRGB screen calibrated to sRGB.
|
|
|
|
Pieter
|
2021-03-09 04:49:35
|
Looks pretty good here (firefox on pixel 4a)
|
|
|
|
BlueSwordM
|
2021-03-09 04:49:37
|
Let me try on Wayland to see if it's any different.
|
|
2021-03-09 04:49:44
|
I think OSes and different graphical environments might make a difference.
|
|
|
|
_wb_
|
2021-03-09 04:49:57
|
mobile chrome has a mild issue
|
|
|
bonnibel
i'm using an hdr display, if that affects anything
|
|
2021-03-09 04:50:45
|
the more your display deviates from standard sRGB, the worse it will be when something is not doing proper color management
|
|
|
|
Jim
|
2021-03-09 04:50:59
|
Chrome looks fine color-wise on Android with exception to it having white lines around each section (maybe a padding/margin issue?).
|
|
|
|
bonnibel
|
2021-03-09 04:51:57
|
mine's an... _googles_ hdr10+ display
|
|
|
|
_wb_
|
2021-03-09 04:52:09
|
I see the Gamma 1.0 PNG slightly darker on android chrome
|
|
|
|
BlueSwordM
|
2021-03-09 04:53:19
|
Yeah, it's an issue on my phone too(Firefox). <:Thonk:805904896879493180>
|
|
|
|
spider-mario
|
2021-03-09 04:55:26
|
Wayland doesn’t do color management yet
|
|
2021-03-09 04:55:33
|
there is a huge thread about it here: https://discuss.pixls.us/t/wayland-color-management/10804
|
|
|
|
Pieter
|
|
Pieter
Looks pretty good here (firefox on pixel 4a)
|
|
2021-03-09 04:56:07
|
Oops, no, I was accidentally using Chrome. In Firefox it's pretty bad.
|
|
|
|
spider-mario
|
2021-03-09 04:58:06
|
for some context on the pixls.us thread, gwgill = the author of https://www.argyllcms.com/ and fhoech = the author of https://displaycal.net/ (a GUI for ArgyllCMS)
|
|
|
|
_wb_
|
2021-03-09 04:58:20
|
firefox by default only does color management if it sees an explicit ICC profile, I think
|
|
2021-03-09 04:59:55
|
which basically means they assume everyone has an sRGB screen
|
|
2021-03-09 05:00:31
|
which was OK in the 90s, but it is increasingly becoming a very problematic assumption
|
|
2021-03-09 05:02:58
|
it's kind of hard to find a new phone that _doesn't_ have a P3 screen, which is wider gamut than sRGB
|
|
|
doajc_blogger
|
2021-03-10 01:34:35
|
Is there anything stopping JPEG XL from being built for 32-bit Windows?
|
|
|
|
Nova Aurora
|
2021-03-10 02:11:15
|
I don't see why not, I'll try it
|
|
|
|
doajc_blogger
|
2021-03-10 02:13:14
|
Also, is it possible to do it for Windows with Visual Studio 2017? I couldn't make it work and I think it might need the 2019 version.
|
|
|
|
Nova Aurora
|
2021-03-10 02:17:16
|
Wow microsoft
|
|
2021-03-10 02:17:36
|
Way to make VS as annoying to use as possible
|
|
2021-03-10 02:18:20
|
I especially enjoyed the computer restarting for updates while I was cloning the repo
|
|
|
|
doajc_blogger
|
2021-03-10 02:18:32
|
You use Windows 10?
|
|
|
|
Nova Aurora
|
2021-03-10 02:18:47
|
I have a backup win10 partition
|
|
2021-03-10 02:18:58
|
I need it for work occasionally
|
|
2021-03-10 02:19:15
|
I do most of my stuff on linux
|
|
|
|
doajc_blogger
|
2021-03-10 02:19:39
|
I use Windows Embedded 8.1 Industry Pro with Update x64
|
|
|
|
Nova Aurora
|
2021-03-10 02:19:44
|
So helpful
|
|
|
|
doajc_blogger
|
2021-03-10 02:20:34
|
If your computer isn't too new, you might find that it's faster and more reliable.
|
|
|
|
Pieter
|
2021-03-10 02:21:41
|
Given that he's already using linux as his main OS, I doubt that 😉
|
|
2021-03-10 02:21:44
|
_hides_
|
|
|
|
doajc_blogger
|
2021-03-10 02:21:53
|
I meant when he needs Windows.
|
|
|
|
Nova Aurora
|
2021-03-10 02:21:56
|
Microsoft update won't work because despite microsoft 💔 linux windows can't detect grub
|
|
2021-03-10 02:22:29
|
So it interrupts 10 minutes of my day to fail and roll back
|
|
|
|
Pieter
|
2021-03-10 02:22:46
|
(i say this as someone who recently fucked up his zfs root filesystem...)
|
|
|
|
doajc_blogger
|
2021-03-10 02:24:01
|
There's an unofficial modified version of Windows 10 called Windows 10 AME that doesn't update at all. I don't use it but my mom has a laptop that's too new for anything else and doesn't even run Linux very well so I got it for her.
|
|
2021-03-10 02:24:50
|
Thanks for attempting this, <@224363555074342912>
|
|
2021-03-10 02:26:44
|
My plan is to try and use libjxl in a 32-bit program I'm writing in Visual C++ 2010. I think the best course of action is to compile it with a recent VC++ compiler and then call it as a DLL.
|
|
|
|
Nova Aurora
|
2021-03-10 02:28:28
|
What git-capable ide that's already 8gb doesn't install command line git?
|
|
2021-03-10 02:47:37
|
So
|
|
2021-03-10 02:48:00
|
What did I do wrong installing vcpkg
|
|
2021-03-10 02:48:39
|
I followed the windows instructions and it can't find the vcpkgs
|
|
|
|
doajc_blogger
|
2021-03-10 02:50:23
|
Maybe it has to be done with MinGW since Fabian posted binaries compiled with mingw64.
|
|
|
|
Nova Aurora
|
2021-03-10 02:51:58
|
GOD I LOVE USING AN OPERATING SYSTEM THAT DOESN'T COME WITH A BUILD ENVIRONMENT
|
|
2021-03-10 02:52:19
|
IT'S JUST SO USER FREINDLY!!!!
|
|
|
|
Pieter
|
2021-03-10 02:54:54
|
https://tenor.com/view/developers-gif-4458491
|
|
|
|
Nova Aurora
|
2021-03-10 02:56:44
|
When I click 'select startup item' it yells at me for not selecting a startup item
|
|
2021-03-10 02:57:14
|
https://tenor.com/view/tarzan-stop-hitting-yourself-gorilla-gif-15541480
|
|
2021-03-10 03:00:06
|
How do I get it to build now?
|
|
2021-03-10 03:00:27
|
It seems to be stuck on 'run code analysis'
|
|
2021-03-10 03:33:26
|
Sorry <@336697008356327444> I gave up trying to get visual studio to work with me
|
|
|
|
doajc_blogger
|
2021-03-10 03:33:45
|
Thanks for trying. Maybe we should ask Fabian about it.
|
|
|
|
Nova Aurora
|
2021-03-10 03:34:26
|
I don't see a reason jxl couldn't be built as 32-bit, but I don't think I'm the person that will figure it out
|
|
2021-03-10 03:39:06
|
While I'm fuming, why doesn't windows have a package manager? I have to install some things from the microsoft store, some from downloaded executables, to install VS you need to install a vs downloader, and vcpkg has to be installed by git
|
|
2021-03-10 03:39:22
|
Which isn't included
|
|
|
|
Deleted User
|
2021-03-10 04:38:34
|
There's waaaay more proprietary software for Windows, Linux is built more on FOSS
|
|
2021-03-10 04:39:06
|
How can you imagine getting e.g. Topaz DeNoise AI from repo?
|
|
|
|
Nova Aurora
|
2021-03-10 04:44:32
|
I had to download from 4 different sources.
|
|
2021-03-10 04:44:49
|
just to get microsoft software
|
|
|
|
_wb_
|
2021-03-10 06:16:04
|
Proprietary software isn't real software, it's a binary blob that happens to work in a specific environment on specific hardware during some interval of time, usually a decade or maybe two, and then becomes useless.
|
|
2021-03-10 06:16:13
|
(good morning)
|
|
|
|
Nova Aurora
|
2021-03-10 06:23:37
|
(Good evening)
|
|
|
|
Pieter
|
2021-03-10 06:29:20
|
<@794205442175402004> It's very real, just not yours.
|
|
2021-03-10 06:37:51
|
(good evening)
|
|
|
|
_wb_
|
2021-03-10 06:39:55
|
The blob thing that gets distributed is not real software. There may or may not be real software hidden somewhere. At the time of creation of the blob thing there always is real software. At the time when the blob thing stops working though... often the real software cannot be found anymore.
|
|
|
|
Pieter
|
2021-03-10 06:40:36
|
Yes, I know and I agree. I mean that whoever created the blob tends to have the source code, so to them, it's real software 😉
|
|
|
|
_wb_
|
2021-03-10 06:48:39
|
Yes. They have proprietary real software, and they ship something that is not real software but a blob. Real software is something that you can make work on various hardware and in various operating systems, fix bugs in or add functionality to. That's what makes it 'soft': like playdough you can knead it and adapt it. Blobs are more like hardware, in a way.
|
|
2021-03-10 06:50:40
|
A blob is like a nintendo game cartridge
|
|
|
sivertba
|
2021-03-10 08:13:28
|
Hi good people!
I was wondering how to best use the jxl standard for hyperspectral remote sensing. That is, compression of images with lots of color channels and a high bit depth at each color channel.
|
|
|
|
_wb_
|
2021-03-10 08:21:08
|
You want to do that losslessly or in a lossy way?
|
|
|
|
sivertba
|
2021-03-10 08:21:58
|
I would like to try both 🙂
|
|
|
|
_wb_
|
2021-03-10 09:42:49
|
The reference implementation can do an arbitrary number of channels, losslessly up to 24-bit uint per sample or up to 32-bit float.
|
|
2021-03-10 09:44:37
|
The main practical problem will be that we don't currently have any input/output format for that
|
|
2021-03-10 09:45:17
|
What do you currently use for that? If it's simple enough, we could add it to cjxl/djxl
|
|
|
|
veluca
|
2021-03-10 09:45:41
|
probably not too hard to rig up something that uses the C++ API to do it directly, I guess
|
|
|
|
Deleted User
|
2021-03-10 09:47:26
|
Question a bit related to my next one: where's easier (in terms of code itself, not compiling it) to create a GUI app, on Windows or Linux?
|
|
|
|
sivertba
|
2021-03-10 10:01:09
|
Try not to laugh now, but; Currently I have used `apng` where each color channel is a frame, or I have concatnated each color channel to make it into a large 2D `png` . a common format is something band-interleaved e.g. https://www.l3harrisgeospatial.com/docs/enviimagefiles.html Maybe this is supported as some kind of raw format?
|
|
|
|
_wb_
|
2021-03-10 10:33:29
|
we don't support it, and I don't particularly feel like writing a parser for that header format, but we could perhaps come up with a simple uncompressed representation, maybe an extension of PAM https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format
|
|
2021-03-10 10:34:27
|
We can just allow DEPTH to be more than 4, and MAXVAL to be more than 65535
|
|
2021-03-10 10:35:14
|
do you use int samples or float ones? PAM is for int but we could do something like PFM and define some special values to represent floats
|
|
2021-03-10 10:40:01
|
something like `MAXVAL 8.23` to denote big-endian binary32 floats, and `MAXVAL 5.10` to denote big-endian binary16 floats (big-endian because that's how PAM/PPM also do it for ints, maybe little-endian is more convenient but meh), in general `exp_bits.mantissa_bits` where the sign bit is implicit and the number of bytes per value is `(exp_bits + mantissa_bits + 8) / 8`
|
|
2021-03-10 10:40:53
|
let's call it `TUPLTYPE UNKNOWN` or something
|
|
2021-03-10 10:42:56
|
do you have 1 or 3 channels that represent visual data and that you want to be the thing people see when they open the jxl containing your data? or are all the channels non-visual and does it not make sense to show them in generic image viewers?
|
|
|
|
spider-mario
|
|
Nova Aurora
While I'm fuming, why doesn't windows have a package manager? I have to install some things from the microsoft store, some from downloaded executables, to install VS you need to install a vs downloader, and vcpkg has to be installed by git
|
|
2021-03-10 11:06:47
|
I think you would do yourself a favor by using msys2
|
|
2021-03-10 11:06:58
|
at least for the specific goal of building stuff
|
|
2021-03-10 11:07:33
|
thanks to msys2, I have cmake/clang/ninja/ffmpeg/git and other such stuff, and pacman -Syu to keep them up-to-date
|
|
2021-03-10 11:08:01
|
almost like on arch linux except I can also write it `pacman.exe -Syu` if I want to be provocative
|
|
2021-03-10 11:11:30
|
windows in 2021
|
|
|
|
sivertba
|
|
_wb_
we don't support it, and I don't particularly feel like writing a parser for that header format, but we could perhaps come up with a simple uncompressed representation, maybe an extension of PAM https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format
|
|
2021-03-10 11:12:56
|
I think this sounds like a good idea!
>do you use int samples or float ones?
Primarly int samples are used.
If floats were supported it would be good when used for spectral decorrelation by something like PCA as a pre-processing step before jxl. That is a way of exploiting the correlation in the color channels.
This has been shown to improve the performance of JPEG2000 for this type of images.
>do you have 1 or 3 channels that represent visual data and that you want to be the thing people see when they open the jxl containing your data?
I am not the perfect candidate to talk for the entire remote sensing community, but I will try. I think there are two viable ways to go about it. Firstly using three channels and making a "true color" image, which is just the RGB representation of that image cube. Secondly, making somthing like apng that goes through every channel would also be cool. with the second option it is more clear that it is an image cube that you are dealing with. All channels are visual.
|
|
|
|
_wb_
|
2021-03-10 11:58:22
|
Doing it as an animation could be confusing, I could imagine you may also want to have actual sequences of hyperspectral images...
|
|
2021-03-10 11:59:44
|
How many channels are we talking about here btw?
|
|
|
|
Deleted User
|
|
sivertba
I think this sounds like a good idea!
>do you use int samples or float ones?
Primarly int samples are used.
If floats were supported it would be good when used for spectral decorrelation by something like PCA as a pre-processing step before jxl. That is a way of exploiting the correlation in the color channels.
This has been shown to improve the performance of JPEG2000 for this type of images.
>do you have 1 or 3 channels that represent visual data and that you want to be the thing people see when they open the jxl containing your data?
I am not the perfect candidate to talk for the entire remote sensing community, but I will try. I think there are two viable ways to go about it. Firstly using three channels and making a "true color" image, which is just the RGB representation of that image cube. Secondly, making somthing like apng that goes through every channel would also be cool. with the second option it is more clear that it is an image cube that you are dealing with. All channels are visual.
|
|
2021-03-10 12:41:13
|
BTW please insert a space after the `>`, that'll enable quote formatting 🙂
...you know that you can edit your previous messages, right?
|
|
|
|
sivertba
|
|
_wb_
How many channels are we talking about here btw?
|
|
2021-03-10 01:53:20
|
Depending on the image source it ranges from 20 to 300 or so, so it is not static
|
|
|
|
_wb_
|
2021-03-10 01:53:45
|
300? wow that's a lot of channels
|
|
2021-03-10 01:54:22
|
we are limited to 4099 channels in jxl (3 visual ones + 4096 extra ones)
|
|
2021-03-10 01:54:42
|
so that's not a problematic limit
|
|
|
|
il1kesonic
|
2021-03-10 10:44:08
|
daddy
|
|
|
Scientia
|
2021-03-11 03:47:38
|
it's normal for a gif > jxl conversion to be 3x bigger than the original gif right?
|
|
2021-03-11 03:48:16
|
something about jpeg xl not being specifically designed for animation and not having optimizations for it?
|
|
|
Dr. Taco
|
2021-03-11 04:08:36
|
I would be shocked if any form of animation was worse than GIF without purposely trying. It's such a naive form of compression (only use 8 bits of color, any pixel that doesn't change between frames is now transparent)
|
|
|
|
Diamondragon
|
2021-03-11 05:09:50
|
JXL should never yield worse results than gif of all things. Would you share the gif?
|
|
|
|
Scientia
|
2021-03-11 05:34:29
|
yeah sure i can share the gif and the parameter
|
|
2021-03-11 05:35:11
|
so this gif with `cjxl bg05.gif testgif.jxl -s 9`
|
|
|
|
BlueSwordM
|
2021-03-11 05:40:09
|
OOOH, I just found a bug.
|
|
2021-03-11 05:40:16
|
Compress the image above above with -d >4.5...
That'll make the encoder crash.
|
|
|
|
Scientia
|
2021-03-11 05:48:20
|
So it's massive by nature at lossless?
|
|
2021-03-11 05:48:34
|
Just wondering
|
|
|
NeRd
|
2021-03-11 05:50:21
|
Although I’m not at my computer right now to test it, that image could just happen to compress really well as a GIF file with certain GIF dispose modes.
|
|
|
|
Scientia
|
2021-03-11 05:50:45
|
Probably
|
|
2021-03-11 05:50:58
|
It looks like a background + some stuff on top
|
|
2021-03-11 05:51:15
|
If jxl is interpreting each frame as all of the layers together
|
|
2021-03-11 05:51:28
|
Then that would totally explain it
|
|
|
|
NeRd
|
2021-03-11 05:52:00
|
Although I’m fairly certain JPEG XL has the potential to beat it, if it’s not able to right now, it’s probably because the encoder is still being developed
|
|
|
|
Scientia
|
2021-03-11 05:52:36
|
I think there was something about the frames in animation not being coupled or something
|
|
2021-03-11 05:52:42
|
There was a better word for it
|
|
|
|
BlueSwordM
|
2021-03-11 06:01:59
|
I think it's the nature of the image.
|
|
2021-03-11 06:02:18
|
Even using a video encoder is hard to actually do, since it doesn't encode with just 256 colors.
|
|
2021-03-11 06:02:39
|
Anyway, I think it's more interesting that it does this: https://discord.com/channels/794206087879852103/794206170445119489/819444595737231370
|
|
|
|
_wb_
|
2021-03-11 06:10:12
|
GIFs can sometimes be hard to beat because our default encode methods are very different.We can do lz77 with ANS though (but don't really try it), which should be better than the LZW GIF is using.
|
|
2021-03-11 06:11:18
|
I think the dispose method that GIF is using is something the current encoder doesn't do yet (but the bitstream can do it)
|
|
|
|
NeRd
|
2021-03-11 06:12:06
|
Out of curiosity, did you make this GIF yourself? If so, could you post the raw frames of the animation (lossless, before colour dithering)?
|
|
2021-03-11 06:18:01
|
It's actually not using any fancy dispose tricks, apart from it only storing the text and the top-right part of the image as the animation frames because that's the only bit that animates (there's most likely too much noise there to improve encoding with dispose tricks).
|
|
2021-03-11 06:18:25
|
(example stored frame)
|
|
|
|
Scientia
|
2021-03-11 06:20:54
|
I didn't make this image
|
|
2021-03-11 06:21:07
|
I was just testing jxl on some images from a website
|
|
2021-03-11 06:21:49
|
And the person who made it (who I know) probably doesn't have the raw frames either
|
|
|
|
NeRd
|
2021-03-11 06:24:44
|
I think I might be able to improve on the compression of the GIF, give me a bit and I'll post a new version which you can compare with JPEG-XL
|
|
|
|
Scientia
|
2021-03-11 06:24:55
|
This image is just particularly problematic?
|
|
|
BlueSwordM
Compress the image above above with -d >4.5...
That'll make the encoder crash.
|
|
2021-03-11 06:25:20
|
Apparently it crashes the encoder at d>4.5
|
|
|
|
Diamondragon
|
2021-03-11 06:31:42
|
|
|
2021-03-11 06:32:50
|
Used `cjxl bg05.gif -q 100 -s 9 -E 3 -I 1 bg05.jxl`
|
|
|
|
_wb_
|
2021-03-11 06:34:00
|
Crashing the encoder is an encoder bug, likely because we forgot a case
|
|
2021-03-11 06:34:12
|
Try with `-g 3`
|
|
|
|
Scientia
|
2021-03-11 06:34:30
|
I'm going to bed, but I can check this in the morning, thanks for the insight and help
|
|
|
|
Diamondragon
|
2021-03-11 06:34:34
|
365KB vs 552KB 34% savings
|
|
|
|
NeRd
|
2021-03-11 06:39:24
|
Update: bizarrely, I’m somehow struggling to make a two frame animation compress better than a 8 frame one. Give me a bit while I try to convince ImageMagick to give me a better dispose method.
|
|
|
|
Deleted User
|
|
Diamondragon
Used `cjxl bg05.gif -q 100 -s 9 -E 3 -I 1 bg05.jxl`
|
|
2021-03-11 06:40:13
|
Surprisingly I couldn't replicate your results even when using the same command. I'm using Scope's Windows build.
```PS C:\Users\zieme\Downloads> .\jpeg-xl-46093017-mingw64\cjxl .\bg05.gif -q 100 -s 9 -E 3 -I 1 .\bg05.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.3 | SIMD supported: SSE4,Scalar]
Read 1550x750 image, 57.1 MP/s
Encoding [Modular, lossless, tortoise], 2 threads.
Compressed to 980224 bytes (0.843 bpp/frame).
1550 x 750, 0.01 MP/s [0.01, 0.01], 1 reps, 2 threads.```
|
|
|
|
NeRd
|
2021-03-11 06:41:09
|
There’s effectively only two real frames of animation in the file, but the one at the start is slightly different than the other frames, and the timings of each frame vary slightly.
|
|
|
|
Diamondragon
|
|
Surprisingly I couldn't replicate your results even when using the same command. I'm using Scope's Windows build.
```PS C:\Users\zieme\Downloads> .\jpeg-xl-46093017-mingw64\cjxl .\bg05.gif -q 100 -s 9 -E 3 -I 1 .\bg05.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.3 | SIMD supported: SSE4,Scalar]
Read 1550x750 image, 57.1 MP/s
Encoding [Modular, lossless, tortoise], 2 threads.
Compressed to 980224 bytes (0.843 bpp/frame).
1550 x 750, 0.01 MP/s [0.01, 0.01], 1 reps, 2 threads.```
|
|
2021-03-11 06:48:52
|
I see the problem. I shift + right clicked on the gif, and saved image as, so I didn't get the full size image. Discord actually scaled down the gif to 800 x 387.
|
|
2021-03-11 06:49:16
|
Didn't realize it would do that.
|
|
2021-03-11 06:54:05
|
```C:\Users\User\Downloads\jpeg-xl>cjxl bg05.gif -q 100 -s 9 -E 3 -I 1 bg05.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.3 | SIMD supported: AVX2]
Read 1550x750 image, 57.0 MP/s
Encoding [Modular, lossless, tortoise], 4 threads.
Compressed to 980219 bytes (0.843 bpp/frame).
1550 x 750, 0.01 MP/s [0.01, 0.01], 1 reps, 4 threads.```
|
|
2021-03-11 06:54:22
|
More or less the same now, and much larger.
|
|
|
|
_wb_
|
2021-03-11 07:03:54
|
Try adding `-g 3`?
|
|
2021-03-11 07:09:19
|
Have to bring the kids to school now, will take a look later
|
|
|
|
Diamondragon
|
2021-03-11 07:12:10
|
```C:\Users\User\Downloads\jpeg-xl>cjxl bg05.gif -q 100 -s 9 -E 3 -I 1 -g 3 bg05.jxl
J P E G \/ |
/\ |_ e n c o d e r [v0.3.3 | SIMD supported: AVX2]
Read 1550x750 image, 55.8 MP/s
Encoding [Modular, lossless, tortoise], 4 threads.
Compressed to 1017828 bytes (0.876 bpp/frame).
1550 x 750, 0.01 MP/s [0.01, 0.01], 1 reps, 4 threads.```
|
|
|
|
_wb_
|
2021-03-11 08:08:07
|
how did that original gif get such ugly dithering? wow the unnecessary entropy and ugliness in that gradient
|
|
2021-03-11 08:29:59
|
hm, I cannot even read that gif with my version of libgif
|
|
2021-03-11 08:30:02
|
`./lib/extras/codec_gif.cc:93: JXL_FAILURE: Failed to read GIF: Image EOF detected before image complete`
|
|
2021-03-11 08:32:58
|
looks like progressive DC is broken (in the encoder) when frames are not canvas-sized
|
|
2021-03-11 08:59:54
|
made a cleaned up version of the gif, which makes the gif smaller and look better (did a 1px radius median blur to get rid of the ugly speckles, then did a bigger radius selective gaussian blur to remove some banding in the gradient)
|
|
2021-03-11 09:00:24
|
this one compresses better as a jxl
|
|
2021-03-11 09:01:24
|
(don't look at the discord preview, it is very ugly)
|
|
2021-03-11 09:04:54
|
no idea why the original gif is so hard to compress well in jxl though
|
|
|
|
veluca
|
|
_wb_
`./lib/extras/codec_gif.cc:93: JXL_FAILURE: Failed to read GIF: Image EOF detected before image complete`
|
|
2021-03-11 09:19:12
|
surprise surprise
|
|
|
|
bonnibel
|
2021-03-11 10:02:06
|
might also be a fun (base for a) text gif?
|
|
2021-03-11 10:02:10
|
<https://upload.wikimedia.org/wikipedia/commons/1/16/FullColour.gif>
|
|
2021-03-11 10:02:29
|
oh wow discord murders this gif
|
|
2021-03-11 10:02:33
|
on android at least
|
|
2021-03-11 10:02:41
|
so open in browser xP
|
|
|
|
spider-mario
|
2021-03-11 10:05:25
|
on the web too
|
|
|
|
bonnibel
|
2021-03-11 10:07:15
|
for those who cant see it, its an animated gif that exploits the fact you can have 256 colours _per frame_
|
|
|
OkyDooky
|
2021-03-11 10:20:01
|
That's really cool and surprizing (to me) that GIF can do that.
|
|
|
|
_wb_
|
2021-03-11 10:22:07
|
https://github.com/ImageOptim/gifski
|
|
2021-03-11 10:22:42
|
you can try to make the best out of an ancient format like GIF
|
|
2021-03-11 10:23:39
|
overall, it is quite astonishing that in 2021 we are still using GIF89, even though it introduces so many problematic artifacts and the compression sucks
|
|
2021-03-11 10:25:01
|
the color quantization artifacts and typically low framerate of GIF are today even part of the "GIF aesthetics" and for some people it wouldn't even be desirable if it would have smooth colors and 25 fps.
|
|
2021-03-11 10:26:18
|
we can try to make jxl better at recompressing GIF (or APNG for that matter), but in the end I think we just really need to start using video codecs in most cases
|
|
|
|
Petr
|
|
_wb_
overall, it is quite astonishing that in 2021 we are still using GIF89, even though it introduces so many problematic artifacts and the compression sucks
|
|
2021-03-11 10:26:53
|
That's why we're here to replace the ancient stuff with something new. 🙂
|
|
|
|
_wb_
|
2021-03-11 10:37:46
|
I don't really want to use jxl as a codec for animations, at least not on the web. Video codecs are more suitable for that. Browsers should really just accept video codecs in an image tag (like Safari does, you can put mp4 in an img tag and it works in Safari) so we can use h264 / vp9 / av1 for that.
|
|
2021-03-11 10:39:03
|
There also just is more software support for actual video codecs, so people don't need to do arcane stuff to produce animations.
|
|
2021-03-11 10:41:28
|
Animated WebP and APNG are around for a while now, yet adoption is low imo because 1) compression is not much better, those are still image codecs and what is gained in better compression is lost again because full color can be used (so it looks better but the files can be even larger than with GIF), 2) software support outside browsers is quite horrible.
|
|
|
|
bonnibel
|
2021-03-11 11:03:58
|
i think it might be nice to have file extension / container format that by definition means, no audio + optionally looping
|
|
2021-03-11 11:04:10
|
just to set expectations
|
|
2021-03-11 11:04:47
|
people have folders of gifs, i dont want to have a folder of video files where i have to listen to each of them in full to make sure they have no audio
|
|
2021-03-11 11:15:35
|
like heck, take webm, add a rule that says "no audio tracks allowed", add 1 bit to determine looping, call it ".gyf", done
|
|
|
|
spider-mario
|
2021-03-11 11:16:16
|
doesn’t that sound like something that would be easily solved in the tools themselves? like adding a crossed 🔈 icon to the thumbnail of audioless videos
|
|
|
|
bonnibel
|
2021-03-11 11:25:22
|
the possibility of audio is something that people are used to be able to tell just from the file extension, solutions like that add needless friction imo
|
|
|
|
_wb_
|
2021-03-11 11:28:32
|
it's weird how the lack of support for something can be a feature. I sometimes have the same thing with ppm, sometimes I convert stuff to ppm just to be sure there's no funny icc profile or exif metadata
|
|
2021-03-11 11:32:22
|
could be good to define a container / media type / extension that is basically just mp4/webm/mkv with the restriction that you can't have audio tracks, and an extra header field for looping
|
|
|
|
bonnibel
|
|
bonnibel
the possibility of audio is something that people are used to be able to tell just from the file extension, solutions like that add needless friction imo
|
|
2021-03-11 11:32:42
|
(Like, sure, you could have every graphical tool add an icon overt the thumbnail of soundless videos (necessitating you visually scan every file), or you could have file explorers add a new sortable column "audio y/n", but just indicating it via the file extension is the traditional & imo simpler solution here. it can still be pretty much entirely entirely webm or mp4 under the hood, just with- yeah what jon said)
|
|
|
|
_wb_
|
2021-03-11 11:33:34
|
for now I'd be happy if browsers would just allow video in an img tag, where it just automatically mutes audio if there is any, and automatically loops and does not show player controls
|
|
|
|
bonnibel
|
2021-03-11 11:34:52
|
(honestly the hardest part would be the name. i'd say "call it .jif" just for the pronunciation war but thats already taken i think)
|
|
|
|
il1kesonic
|
2021-03-11 04:36:45
|
ew
|
|
2021-03-11 04:36:57
|
i like jif
|
|
2021-03-11 04:37:25
|
peanut butter and female potatoes 🤤
|
|
|
|
Scientia
|
2021-03-11 05:09:15
|
It might be dumb but I thought of m4if, webif, and mkif
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
https://github.com/ImageOptim/gifski
|
|
2021-03-11 07:33:06
|
another jewel from Kornel
|
|
|
|
sivertba
|
2021-03-12 11:10:27
|
Q: Is it possible make progressive JXL priortize certain color channels?
|
|
|
|
_wb_
|
2021-03-12 11:42:41
|
Not with the current encoder. But you could do something like that, yes. In VarDCT mode, you can have passes that make arbitrary updates, so you could e.g. first have a pass that refines Y but has nothing but zeroes for X and B, then have a pass that refines X and B but has nothing new for Y. In Modular mode, you can reorder channels using no-op RCTs that just permute channels, and you can have custom Squeeze scripts that cause the residuals to be in different orders (by default it prioritizes luma a bit).
|
|
|
|
Jyrki Alakuijala
|
|
sivertba
Q: Is it possible make progressive JXL priortize certain color channels?
|
|
2021-03-12 12:01:35
|
what does prioritize mean?
|
|
|
|
sivertba
|
|
Jyrki Alakuijala
what does prioritize mean?
|
|
2021-03-12 12:23:46
|
What I mean by it; let's say you have a high density sampling in the EM spectrum, something like a 100 different colors. This can make the colors highly correlated. If you then decorrelate the colors with principal component analysis or similar the first set of "loadings" will carry more information. It makes sense to store the loadings as spatial pictures. If you can priortize the loadings by the ones that carry the most information, that would be neat
|
|
|
|
_wb_
|
2021-03-12 12:32:29
|
In your case of a 100-channel image, it might make sense to store it as a multi-layer image where the not-important channels are zeroes in the first layer and updated in later layers
|
|
|
|
Jyrki Alakuijala
|
|
sivertba
What I mean by it; let's say you have a high density sampling in the EM spectrum, something like a 100 different colors. This can make the colors highly correlated. If you then decorrelate the colors with principal component analysis or similar the first set of "loadings" will carry more information. It makes sense to store the loadings as spatial pictures. If you can priortize the loadings by the ones that carry the most information, that would be neat
|
|
2021-03-13 07:33:12
|
if that becomes a use case that requires great compression, we'd likely be better of rethinking the compression for it
|
|
2021-03-14 06:20:41
|
https://core.trac.wordpress.org/ticket/52788
|
|
2021-03-14 06:20:47
|
😄
|
|
2021-03-14 06:20:53
|
chicken and egg problem
|
|
2021-03-14 06:21:05
|
should browsers or servers add the support first
|
|
|
|
Scientia
|
2021-03-14 06:25:39
|
the ticket has a bold claim
|
|
2021-03-14 06:25:52
|
they say "it will be supported in all browsers"
|
|
2021-03-14 06:25:58
|
ideally yes
|
|
2021-03-14 06:26:23
|
but I don't have any blind faith, I don't know if that will happen any time soon
|
|
|
Orum
|
2021-03-14 06:34:51
|
servers need support for it? other than just a MIME type?
|
|
|
|
_wb_
|
2021-03-14 06:35:11
|
This is what the `Accept` http header is made for: resolving the chicken and egg problem.
|
|
2021-03-14 06:36:22
|
CMS like wordpress would need to implement jxl encode for its image transcoding, and jxl decode if it wants to handle jxl uploads.
|
|
|
|
Orum
|
2021-03-14 06:37:35
|
Yeah, unless they just want to handle it as a BLOB I suppose so
|
|
|
|
Jim
|
2021-03-14 06:39:18
|
Not sure what a ticket in WP will do. It is dependent on image libraries supporting it (ImageMagick, libgd, etc) - not sure what libraries it uses. Generally all they have to do is then add it to a list of mime types that are allowed.
|
|
|
|
_wb_
|
2021-03-14 06:40:10
|
With the cloudinary wordpress plugin you can already get jxl support in wordpress right now. But I guess not everyone wants to use that plugin...
|
|
2021-03-14 06:41:00
|
Yes, the underlying image libraries matter for this.
|
|
|
|
Jim
|
2021-03-14 06:42:22
|
If it is passed to an external service for conversion, yes, but many are skeptical about those. For one, if the service goes down they might not be able to upload images. There are also the security/privacy and performance issue of passing all images (especially large ones) to and from a third-party service.
|
|
2021-03-14 06:44:41
|
If I remember correctly, WP uses IM if it is installed (it is not on a lot of servers), otherwise it uses the built-in libgd which does not support JXL.
|
|
|
|
_wb_
|
2021-03-14 07:31:27
|
Then I guess we should get libgd to support jxl...
|
|
|
|
paperboyo
|
|
_wb_
Then I guess we should get libgd to support jxl...
|
|
2021-03-14 09:55:42
|
libgd has a colour management deficiency that is getting more problematic with new codecs: https://github.com/libgd/libgd/pull/671#issuecomment-782468004
|
|
|
Troc
|
2021-03-15 05:41:27
|
Where do I find qjpegxl.dll?
|
|
2021-03-15 05:43:11
|
For Imageglass.
|
|
|
|
diskorduser
|
2021-03-15 06:03:38
|
https://ci.appveyor.com/project/novomesk/qt-jpegxl-image-plugin/build/artifacts
|
|
2021-03-15 06:04:26
|
Sorry. It's not available in that link
|
|
|
|
Scope
|
2021-03-15 06:53:56
|
https://ci.appveyor.com/project/novomesk/qt-jpegxl-image-plugin/builds/37783607/artifacts
|
|
|
|
jido
|
2021-03-15 11:36:25
|
hi where can I find already-encoded sample images (.jxl)?
|
|
|
|
Orum
|
2021-03-16 12:23:40
|
you can make one 🤷
|
|
|
|
BlueSwordM
|
|
jido
hi where can I find already-encoded sample images (.jxl)?
|
|
2021-03-16 12:30:07
|
If you want, I can send you an image set. 😄
|
|
|
|
jido
|
|
BlueSwordM
If you want, I can send you an image set. 😄
|
|
2021-03-16 12:36:53
|
What does it focus on mainly?
|
|
|
|
BlueSwordM
|
2021-03-16 12:37:13
|
Game screenshots, real life pics, and some JXL recompression images.
|
|
2021-03-16 12:37:16
|
Nothing too fancy.
|
|
|
|
jido
|
2021-03-16 12:37:54
|
Are they from lossless or raw
|
|
|
|
BlueSwordM
|
2021-03-16 12:38:03
|
All from lossless/raw.
|
|
|
|
jido
|
2021-03-16 12:38:12
|
sounds good
|
|
|
|
BlueSwordM
|
|
jido
sounds good
|
|
2021-03-16 12:47:24
|
Here it is: https://cdn.discordapp.com/attachments/677981014974267429/821182575170027580/Pure_JXL.7z
Beware, there's a 233MP image included. That WILL gobble RAM like no other.
1,4GB for a single image lol
|
|
|
|
jido
|
2021-03-16 12:54:23
|
Thanks, they opened fine (took few seconds for the large image though)
|
|
2021-03-16 12:58:52
|
Did they take very long to compress?
|
|
|
|
BlueSwordM
|
2021-03-16 01:00:32
|
No, all of them took less than 5 seconds in total. Well, except for the 233MP one.
|
|
2021-03-16 01:00:56
|
In total = all of the images were encoded with GNU Parallel at once with 1 thread each.
|
|
|
|
_wb_
|
2021-03-16 05:59:48
|
There are some nice decode speedup / memory reductions in the pipeline by <@179701849576833024>
|
|
2021-03-16 06:00:47
|
(will not make a difference for the final memory in the application, but it does for the peak during decode)
|
|
|
Lastrosade
|
2021-03-16 09:41:09
|
Hey, I'm encoding an image and seem to be having some trouble with colors darkening out, setting -c 1 fixes it but the resulting image is 4x larger
|
|
2021-03-16 09:42:22
|
source on the left
|
|
2021-03-16 09:42:55
|
using
`cjxl --container -j -d 4 --speed=4`
`cjxl --container -j -c 1 -d 4 --speed=4`
`-c 0` (XYB) seems to be the the default
`-c 1` (None) Fixes the issue
`-c 2` (YCbCr) destroys the colors
|
|
|
|
_wb_
|
2021-03-16 10:09:32
|
-c 2 assumes the input is somehow already in YCbCr (it's there in case we ever want to add .y4m input or something), please ignore it
|
|
2021-03-16 10:11:07
|
colors darkening out is likely a viewer problem
|
|
2021-03-16 10:11:19
|
what is the original?
|
|
2021-03-16 10:13:26
|
I'm surprised -c 1 -d 4 even works. VarDCT is certainly not meant to be used with RGB...
|
|
2021-03-16 10:13:55
|
Is the original a PNG or a JPEG here?
|
|
|
|
Lastrosade
|
2021-03-16 10:19:36
|
png
|
|
2021-03-16 10:20:09
|
|
|
|
|
Scope
|
2021-03-16 10:22:16
|
Hmm, then why use `-j` and `--container`?
And in my experience I would also recommend using the default speed `-s 7` (or `-s 8`) and `-s 3` for fast encoding, the other speeds do not seem to be particularly tuned and they sometimes have strange results
|
|
|
|
Lastrosade
|
2021-03-16 10:23:14
|
I was told at some point to use --container, idk why tho, -j because I compress some jpegs too and without it the files tend to get much bigger
|
|
|
|
Scope
|
2021-03-16 10:24:23
|
Yep, without `-j` it would be lossless Jpegs
|
|
|
|
Lastrosade
|
2021-03-16 10:24:36
|
yeah that not what I want
|
|
2021-03-16 10:24:46
|
also using -s 3 doesn't fix the color problem
|
|
|
|
_wb_
|
2021-03-16 10:24:56
|
the issue is this
|
|
2021-03-16 10:25:05
|
``` png:gAMA: gamma=0.45455 (See Gamma, above)
png:sRGB: intent=0 (Perceptual Intent)```
|
|
2021-03-16 10:28:29
|
<@!604964375924834314> <@!768090355546587137> could you take a look what is going on here?
|
|
2021-03-16 10:29:31
|
it is not clear to me which interpretation is supposed to be correct here
|
|
2021-03-16 10:30:23
|
|
|
2021-03-16 10:30:38
|
that's the original PNG, opened in Apple Preview on the left and opened in Chrome on the right
|
|
|
|
Lastrosade
|
|
|
_wb_
|
2021-03-16 10:31:18
|
as you can see, there is something ambiguous about the original PNG to begin with
|
|
2021-03-16 10:33:30
|
so I am not sure if the "darker" one is correct or the "brighter" one is
|
|
|
|
Lastrosade
|
2021-03-16 10:33:53
|
I am not sure either
|
|
|
|
Scope
|
2021-03-16 10:34:04
|
Also when decoding JXL back into PNG I don't see any color differences, but in JXL itself they are noticeable in several viewers
|
|
|
|
Crixis
|
2021-03-16 10:34:51
|
to my setup decoded png is darker
|
|
|
|
_wb_
|
2021-03-16 10:34:58
|
there are probably some JXL viewers that do not properly do color management on JXLs
|
|
|
|
Lastrosade
|
2021-03-16 10:35:25
|
I think its the darker one as removing the gAMA field info makes the jxl image brighter
|
|
|
|
Crixis
|
|
Lastrosade
I think its the darker one as removing the gAMA field info makes the jxl image brighter
|
|
2021-03-16 10:35:51
|
Luck
|
|
|
|
Lastrosade
|
2021-03-16 10:35:58
|
whereas the PNGs look identical with my viewer
|
|
|
|
_wb_
|
2021-03-16 10:36:37
|
PNG is very confusing, it can have an ICC profile, a gAMA chunk, and an sRGB chunk, and I don't know how those are supposed to interact
|
|
|
|
Lastrosade
|
2021-03-16 10:37:26
|
oh I may have removed the srgb chunk too
|
|
2021-03-16 10:40:37
|
this is so confusing
|
|
|
|
Jim
|
2021-03-16 10:41:15
|
https://tenor.com/view/puppy-cute-aww-dog-confused-gif-13186042
|
|
|
|
Lastrosade
|
2021-03-16 10:42:36
|
okok so its my viewer that's borked
|
|
2021-03-16 10:42:45
|
it breaks on the png
|
|
2021-03-16 10:42:59
|
firefox/chromium/my phone views the image as the darker one
|
|
2021-03-16 10:43:38
|
so cjxl is good
|
|
2021-03-16 10:43:46
|
nomacs borked the png
|
|
|
|
Scope
|
2021-03-16 10:46:46
|
Also about -s 3 and -s 4, although this is a very low bpp, but I have noticed other images when -s 4 was worse than -s 3
https://discord.com/channels/794206087879852103/803645746661425173/816734243631005736
|
|
|
|
Jim
|
2021-03-16 10:50:26
|
https://pmt.sourceforge.io/specs/png-1.2-pdg-h20.html#C.Anc-color
> Applications desiring high color fidelity may wish to use an sRGB chunk (see the sRGB chunk specification, Paragraph 4.2.2.3) or an iCCP chunk (see the iCCP chunk specification, Paragraph 4.2.2.4).
> An application that writes the sRGB chunk should also write a gAMA chunk (and perhaps a cHRM chunk) for compatibility with applications that do not use the sRGB chunk. In this situation, only the following values may be used:
> When the iCCP chunk is present, applications that recognize it and are capable of color management [ICC] should ignore the gAMA and cHRM chunks and use the iCCP chunk instead, but applications incapable of full-fledged color management should use the gAMA and cHRM chunks if present.
>
> A file should contain at most one embedded profile, whether explicit like iCCP or implicit like sRGB.
|
|
2021-03-16 10:51:15
|
Technically, should only include an ICC or an RGB, but then in a different section implies both can exist and the application can pick?
|
|
|
|
_wb_
|
2021-03-16 10:53:26
|
it is all very confusing and it is exactly the kind of thing I hope we can avoid in jxl
|
|
|
|
paperboyo
|
|
_wb_
PNG is very confusing, it can have an ICC profile, a gAMA chunk, and an sRGB chunk, and I don't know how those are supposed to interact
|
|
2021-03-16 11:59:15
|
My understanding of the spec always was that the precedence goes like this: iCCP then sRGB then gAMA&cHRM and if nothing there – assume sRGB.
|
|
|
|
_wb_
|
2021-03-16 12:01:22
|
yes, but what if there's both sRGB and gAMA? are you supposed to just ignore the gAMA then?
|
|
|
|
paperboyo
|
2021-03-16 12:01:56
|
Yep (is my understanding).
|
|
|
|
fab
|
2021-03-16 12:04:17
|
<@!111445179587624960> do you have any builds of jxl 0.3.4 for windows?
|
|
2021-03-16 12:07:44
|
are there quality improvements for image in 0.3.4
|
|
2021-03-16 12:14:11
|
in vardct
|
|
|
|
Deleted User
|
2021-03-16 12:21:43
|
That's a good question, what's the changelog?
|
|
|
|
Scope
|
2021-03-16 12:23:07
|
```* Bump JPEG XL version to 0.3.4.
* Improved box parsing.
* Improved metadata handling.
* Performance and memory usage improvements.```
|
|
|
|
Crixis
|
2021-03-16 12:28:36
|
sadly no vardct changes
|
|
|
|
Scope
|
2021-03-16 12:35:07
|
<https://encode.su/threads/3564-JXL-version-0-3-released?p=69082&viewfull=1#post69082>
|
|
|
|
_wb_
|
2021-03-16 12:36:19
|
main focus atm is decode speed / memory / security and fixing bugs / unhandled cases in the encoder and decoder
|
|
2021-03-16 12:37:30
|
making the encoder better is less urgent than making everything 'actually work' and having a decoder that is 'worthy' for browser integration
|
|
|
|
Scope
|
2021-03-16 12:54:32
|
Yep, I think complete browser support is most important right now
Also, it is not needed to specify `-j` for Jpeg anymore if quality or distance option is selected
|
|
|
|
_wb_
|
2021-03-16 01:28:03
|
default behavior is now:
- preserve all Exif/XMP metadata in the container (for now uncompressed, we'll make it compressed by default later), use `--strip` to not preserve it
- default is `-d 1` (or `-q 90`) VarDCT for PNG input, lossless (`-d 0` or `-q 100`) for JPEG or GIF input. If another -d or -q is specified, JPEG input is interpreted as pixels and re-encoded in a lossy way (i.e. the `-j` is implicit then).
- default is to preserve JPEG bitstream reconstruction data (which allows you to get the exact same JPEG file back when doing default lossless JPEG recompression), you can strip that too with `--strip`
- djxl default with .jpg output is to reconstruct the JPEG if possible, or otherwise just make a new high-quality JPEG. If you specify `-j` or `-q <something>` then it always makes a new JPEG instead of reconstructing the original one.
|
|
|
|
paperboyo
|
|
_wb_
default behavior is now:
- preserve all Exif/XMP metadata in the container (for now uncompressed, we'll make it compressed by default later), use `--strip` to not preserve it
- default is `-d 1` (or `-q 90`) VarDCT for PNG input, lossless (`-d 0` or `-q 100`) for JPEG or GIF input. If another -d or -q is specified, JPEG input is interpreted as pixels and re-encoded in a lossy way (i.e. the `-j` is implicit then).
- default is to preserve JPEG bitstream reconstruction data (which allows you to get the exact same JPEG file back when doing default lossless JPEG recompression), you can strip that too with `--strip`
- djxl default with .jpg output is to reconstruct the JPEG if possible, or otherwise just make a new high-quality JPEG. If you specify `-j` or `-q <something>` then it always makes a new JPEG instead of reconstructing the original one.
|
|
2021-03-16 01:35:05
|
> use --strip to not preserve it [Exif metadata]
Because not all metadata is equal, eg. orientation, but mostly colour profile (ie. AdobeRGB in DCF Exif), it would be great for `--strip` to not remove that as the fact that the pixels are in AdobeRGB will be irrevocably lost. Or at least, to have the option to remove all but not that. Another option would be for that colour info to **always** be taken into account while encoding the image even when using `--strip`.
|
|
|
|
_wb_
|
2021-03-16 01:48:32
|
Do you have an example of a JPEG that uses AdobeRGB in Exif? Do browsers/viewers actually interpret that?
|
|
2021-03-16 01:48:56
|
Orientation will now be inspected by the encoder and set correctly in the jxl codestream header, so the Exif can be safely stripped
|
|
2021-03-16 01:49:23
|
colorspace in Exif still needs to be inspected too, shouldn't be too hard to add that
|
|
2021-03-16 01:49:41
|
goal is that you don't need to look at Exif to render the image correctly
|
|
|
|
paperboyo
|
|
_wb_
Do you have an example of a JPEG that uses AdobeRGB in Exif? Do browsers/viewers actually interpret that?
|
|
2021-03-16 01:49:52
|
Any JPEG straight from Canon or Nikon set to AdobeRGB. Browsers are dumb here apart from Safari last time I checked. Will have a look for an image I can freely share…
|
|
|
|
_wb_
|
2021-03-16 01:50:58
|
https://exiftool.org/TagNames/EXIF.html
|
|
2021-03-16 01:51:48
|
it's tag 0x0001, right? where the string value `R03` means the colorspace is Adobe RGB (1998), if I understand correctly?
|
|
2021-03-16 01:51:59
|
and the string value `R98` means it is sRGB
|
|
|
|
spider-mario
|
2021-03-16 01:52:25
|
it’s a bit more complicated
|
|
2021-03-16 01:52:35
|
R03 means that if the filename starts with _, then it’s Adobe RGB
|
|
2021-03-16 01:52:41
|
(yes)
|
|
|
|
_wb_
|
2021-03-16 01:52:51
|
https://tenor.com/view/kid-what-huh-what-are-you-talking-about-gif-14514932
|
|
|
|
spider-mario
|
2021-03-16 01:53:30
|
https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system
R98 means DCF 1.0, R03 means DCF 2.0
|
|
2021-03-16 01:53:48
|
and 2.0 allows the use of a filename starting with _ to indicate that the colorspace is Adobe RGB
|
|
|
|
_wb_
|
2021-03-16 01:53:55
|
oh boy
|
|
2021-03-16 01:54:03
|
who invents that stuff
|
|
2021-03-16 01:54:55
|
signaling colorspace info in the _filename_? c'mon
|
|
2021-03-16 01:57:11
|
btw there is a lot of other very weird stuff in Exif that I hope we can just ignore and nobody actually uses, at least for JPEG (I know that in TIFF all of this stuff actually does happen)
|
|
2021-03-16 01:57:34
|
like PhotometricInterpretation WhiteIsZero, that's a fun one
|
|
2021-03-16 01:58:21
|
like there's also a way to signal transfer function in Exif: 0x012d TransferFunction int16u[768]!
|
|
2021-03-16 01:58:38
|
as well as whitepoint and primaries: 0x013f PrimaryChromaticities rational64u[6]
|
|
2021-03-16 01:59:25
|
you can also signal that the sample values are complex numbers (complex int or complex float), no kidding
|
|
2021-03-16 02:00:42
|
RGB color `i, 0, 0` is an imaginary red, I suppose? <:Thonk:805904896879493180>
|
|
2021-03-16 02:02:42
|
or what to think about this beautiful Exif tag, invented by the nice people at Microsoft
|
|
|
|
spider-mario
|
2021-03-16 02:03:29
|
this is where I learned about this DCF thing: https://www.dpreview.com/forums/post/9646715
|
|
|
|
_wb_
|
2021-03-16 02:08:26
|
Exif is such a mess, with some things that are just metadata, some things that are redundant but innocent (like image dimensions and stuff, which you already know from the codestream), embedded previews (that are likely to get out of sync with the actual image), render-critical info like orientation and color space, TIFF legacy stuff, and then the huge pile of proprietary Makernotes that may or may not have been reverse engineered and often have some overlap with the 'normal' tags
|
|
|
|
spider-mario
|
2021-03-16 02:09:17
|
sometimes, there is overlap even in the standard tags
|
|
|
|
_wb_
|
2021-03-16 02:10:11
|
it's like the HTML of the mid-nineties, mixing semantical structure with style in ugly ways, making people use spacer images and <table> layouts
|
|
|
|
spider-mario
|
2021-03-16 02:10:12
|
for example, there is the legacy “ISO” tag (or “ISOSpeedRatings” depending on who you ask), which only goes up to 65535, and now also RecommendedExposureIndex and StandardOutputSensitivity which have no such limit
|
|
|
|
paperboyo
|
|
_wb_
Do you have an example of a JPEG that uses AdobeRGB in Exif? Do browsers/viewers actually interpret that?
|
|
2021-03-16 02:16:57
|
Couldn’t find one on the interwebz, so made you one: sorry my bed is a bit dirty… Latest Firefox and Chrome dumb, Safari OK.
|
|
|
|
_wb_
|
2021-03-16 02:20:33
|
hm, looks the same in safari and chrome for me
|
|
|
|
paperboyo
|
2021-03-16 02:22:13
|
Bloody discord:
|
|
2021-03-16 02:22:47
|
This better (I mean: worse in Chrome)?
|
|
|
|
spider-mario
|
2021-03-16 02:24:26
|
wouldn’t it be because the filename doesn’t start with _ anymore?
|
|
2021-03-16 02:24:48
|
what happens if you rename it?
|
|
|
|
_wb_
|
2021-03-16 02:24:53
|
chrome above, safari below
|
|
2021-03-16 02:25:23
|
renamed it to `_MG_6684.jpg`, no difference
|
|
|
|
paperboyo
|
|
spider-mario
wouldn’t it be because the filename doesn’t start with _ anymore?
|
|
2021-03-16 02:27:39
|
If browsers would look for the underscore to establish if they should honour DCF Exif ICC tag, I would switch to pigeons for mail 😜 (I transferred it from camera using some Canon soft, hence unusual filename, but I verified tag is there and there is no real ICC profile either).
|
|
|
|
spider-mario
|
2021-03-16 02:28:20
|
theoretically, they’re supposed to 😄
|
|
|
|
paperboyo
|
2021-03-16 02:30:43
|
Chrome 89 left; Safari 14 right.
|
|
2021-03-16 02:31:26
|
Try the one from the zip. Is your screen off-sRGB (if not, will be hard to see).
|
|
|
|
_wb_
|
2021-03-16 02:51:52
|
Preview at the top, Colorsync at the bottom
|
|
2021-03-16 02:53:30
|
|
|
2021-03-16 02:53:38
|
Finder on the left, Photoshop on the right
|
|
2021-03-16 02:54:08
|
Finder is funny: it actually says it is Adobe RGB (1998), but then ignores that and pretends it is sRGB for the preview image
|
|
2021-03-16 02:55:45
|
it is so silly that in 2021 we are still in this pathetic situation where so much software is doing color wrong
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
signaling colorspace info in the _filename_? c'mon
|
|
2021-03-16 04:27:07
|
while at it, include a preview of the image encoded in the filename
|
|
|
|
_wb_
|
2021-03-16 04:27:52
|
just train an AI to produce plausible previews just by looking at the filename
|
|
|
|
bonnibel
|
2021-03-16 04:33:11
|
high-appeal no-fidelity codec: it just produces 1 of 12 high-quality images prebundled with the decoder
|
|
|
|
Scope
|
2021-03-16 04:35:40
|
||https://youtu.be/aTjvmueKKrw||
|
|
|
|
Nova Aurora
|
|
Jyrki Alakuijala
while at it, include a preview of the image encoded in the filename
|
|
2021-03-16 04:35:55
|
use templeOS's text format to embed images, 3d models, and animations in your filename
|
|
|
|
Crixis
|
2021-03-16 04:38:16
|
just encode the bitstream in the file name
|
|
|
|
Jyrki Alakuijala
|
|
bonnibel
high-appeal no-fidelity codec: it just produces 1 of 12 high-quality images prebundled with the decoder
|
|
2021-03-16 04:43:49
|
7 out of the 12 hq photos should different kinds of cats, cats are a lot of entropy
|
|
|
|
bonnibel
|
2021-03-16 04:46:21
|
it's true, thats why the heat death of the universe will not be Big Freeze but Big Kity
|
|
2021-03-16 04:47:49
|
the science institute banished me to discord for my radical theories
|
|
|
anna
|
2021-03-16 11:46:42
|
does JXL support animations
|
|
|
|
Pieter
|
|
|
BlueSwordM
|
|
anna
does JXL support animations
|
|
2021-03-16 11:59:24
|
Yes it does.
|
|
|
|
Deleted User
|
2021-03-17 01:08:26
|
But good luck viewing them. ^^
|
|
|
|
diskorduser
|
2021-03-17 04:48:37
|
Does lossless jxl change colors? On imagemagick compare I see color difference. https://0x0.st/-NSu.zip (nsfw anime picture)
|
|