|
Traneptora
|
2023-04-03 07:21:12
|
Yes, but it's not binary-compatible with other operating systems
|
|
2023-04-03 07:21:26
|
you can't run a C# program compiled for windows on other platforms
|
|
2023-04-03 07:21:41
|
whereas you can run java code compiled for the JVM on any platform with a JVM
|
|
|
gameplayer55055
|
2023-04-03 07:21:44
|
old c# isn't truly cross platform
|
|
|
Traneptora
whereas you can run java code compiled for the JVM on any platform with a JVM
|
|
2023-04-03 07:21:59
|
true
|
|
|
_wb_
|
2023-04-03 07:32:50
|
Also C predates Linux by two decades so C isn't a Linux thing. It's just the oldest language that is still in widespread use (algol, fortran, lisp and cobol are older but none of them are still quite as mainstream as c)
|
|
|
|
gameplayer55055
|
2023-04-03 07:34:29
|
unix philosophy?
|
|
|
Yari-nyan
|
2023-04-03 07:57:19
|
how do i set the decode speed level with cjxl? i haven't found the option for that, but it's an option in darktable (and some other) tools i've seen
|
|
|
spider-mario
|
|
Traneptora
you can't run a C# program compiled for windows on other platforms
|
|
2023-04-03 08:23:03
|
you can if it only uses parts of .NET that Mono supports
|
|
2023-04-03 08:23:19
|
(or .NET Core)
|
|
2023-04-03 08:24:06
|
it’s not so different in principle from the JVM
|
|
2023-04-03 08:24:32
|
it’s just that it used to be that the primary implementation was Windows-only
|
|
|
|
Traneptora
|
|
spider-mario
you can if it only uses parts of .NET that Mono supports
|
|
2023-04-03 08:26:37
|
I mean running it under wine doesn't really count
|
|
|
|
spider-mario
|
2023-04-03 08:26:43
|
it’s not wine
|
|
|
|
Traneptora
|
2023-04-03 08:26:54
|
isn't that what Mono is?
|
|
|
|
spider-mario
|
2023-04-03 08:26:57
|
https://en.wikipedia.org/wiki/Mono_(software)#Code_Execution_Engine
|
|
|
|
_wb_
|
|
Yari-nyan
how do i set the decode speed level with cjxl? i haven't found the option for that, but it's an option in darktable (and some other) tools i've seen
|
|
2023-04-03 08:27:23
|
Check cjxl -v -v -h, it should be somewhere there
|
|
|
|
Traneptora
|
2023-04-03 08:27:45
|
oh, I was under the impression mono was what wine used to run dotnet stuff
|
|
2023-04-03 08:27:53
|
guess I was wrong
|
|
|
|
spider-mario
|
2023-04-03 08:28:00
|
wine can’t run .NET executables, so it tells you to use mono for those
|
|
2023-04-03 08:28:09
|
and is maybe able to call it on its own
|
|
|
|
Yari-nyan
|
|
_wb_
Check cjxl -v -v -h, it should be somewhere there
|
|
2023-04-03 08:28:38
|
double verbose? i've already tried with just one -v
|
|
|
|
spider-mario
|
2023-04-03 08:28:53
|
yes, the number of `-v` is meaningful
|
|
|
|
Yari-nyan
|
2023-04-03 08:29:17
|
quirky
|
|
2023-04-03 08:29:50
|
found it
|
|
2023-04-03 08:30:05
|
```
--faster_decoding=0|1|2|3|4
Favour higher decoding speed. 0 = default, higher values give higher speed at the expense of quality```
|
|
|
|
Traneptora
|
2023-04-03 08:30:29
|
~~hydrium mode: -5~~
|
|
|
pshufb
|
|
Jyrki Alakuijala
some of it is manual, but often I used the tools/optimizer/simplex_fork.py to run a tweaked Nelder-Mead algorithm to find good parameter values -- it is a universal autotweaker
|
|
2023-04-03 09:04:38
|
thank you
|
|
|
Jyrki Alakuijala
|
2023-04-04 01:02:13
|
the tools/optimizer/simplex_fork.py is a really nice tool -- we have used it for butteraugli, jpegli, jpeg xl, pik, and many secret projects -- if you ever need to tweak a system, use it, it is much easier than more general machine learning and often equally effective
|
|
2023-04-04 01:02:39
|
https://github.com/libjxl/libjxl/pull/2355 improves 0.16 % and makes DZgas' difficult images slightly better again
|
|
|
|
_wb_
|
2023-04-04 04:49:59
|
I used it for ssimulacra2 too
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 09:25:34
|
regarding .NET and popularity of programming language -- https://www.tiobe.com/tiobe-index/ can be interesting to look at
|
|
|
|
gameplayer55055
|
2023-04-05 09:29:37
|
.net just works and its compiled but has cool features
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 09:30:37
|
every engineer has their favorite system -- some are most productive with Delphi or Fortran, some are super-passionate about Go or Rust etc. -- this has been always so and likely will always be
|
|
2023-04-05 09:31:18
|
some feel that the world will end or great evils will happen unless some system is implemented using a particular language
|
|
2023-04-05 09:32:41
|
during my career I have seen this kind of enthusiasm linked with C, C++, XML, Java, Go, Rust, C#, .NET, Smalltalk, Lisp, SQL
|
|
2023-04-05 09:33:28
|
in the end for practical projects the implementation language matters surprisingly little in my experience -- but of course the interfacing needs to be there so that people can use the environment they are most productive in
|
|
2023-04-05 09:36:31
|
I don't know .NET but as a philosophical position I don't use single-provider solutions to build my competence on -- I don't want a single provider the pull the rug from under my feet in case they fail or become greedy, or decide to move on to 'even better solutions'
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
during my career I have seen this kind of enthusiasm linked with C, C++, XML, Java, Go, Rust, C#, .NET, Smalltalk, Lisp, SQL
|
|
2023-04-05 09:54:56
|
XML is markup language for configs
.NET is a platform
SQL is query language
<:AngryCry:805396146322145301>
|
|
2023-04-05 09:55:56
|
btw .NET
c++ has no platform that ensures it works the same way on <:Windows:806135372298977342> <:Linux_Tux:806135372739510282> and <:Apple:806136610659237888>
|
|
2023-04-05 09:57:14
|
good example: strsep. on windows you dont have it
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 09:58:18
|
just considering them as social phenomena in engineering -- there was a short phase when some part of the engineering society (possibly even a majority) was hypnotized with XML and thought that it will remove all problems in software engineering
|
|
|
|
gameplayer55055
|
2023-04-05 09:58:38
|
i want just to `dotnet add package Joint.Photographers.Experts.XL` <:trolw:1015162529225392128>
|
|
|
|
Traneptora
|
2023-04-05 09:58:50
|
oh yea, the XML craze
|
|
2023-04-05 09:58:53
|
that was a thing
|
|
|
|
gameplayer55055
|
|
Traneptora
oh yea, the XML craze
|
|
2023-04-05 09:58:57
|
XML is bloat
|
|
|
|
Traneptora
|
2023-04-05 09:59:08
|
I'm very glad json has replaced it in popularity
|
|
|
|
gameplayer55055
|
2023-04-05 09:59:09
|
but very readable by human
|
|
|
|
Jyrki Alakuijala
|
|
gameplayer55055
i want just to `dotnet add package Joint.Photographers.Experts.XL` <:trolw:1015162529225392128>
|
|
2023-04-05 09:59:22
|
this is perfectly reasonable request of course
|
|
|
|
gameplayer55055
|
2023-04-05 09:59:45
|
btw HTML also has changed the paradigm. see the all tags we never use now but these are in place
|
|
|
|
Traneptora
|
2023-04-05 09:59:46
|
probably would be Experts.Photographers.Joint tho <:kek:857018203640561677>
|
|
|
|
gameplayer55055
|
|
Traneptora
probably would be Experts.Photographers.Joint tho <:kek:857018203640561677>
|
|
2023-04-05 09:59:56
|
it isnt java
|
|
|
|
Traneptora
|
2023-04-05 10:00:12
|
package names being backwards is fairly common in other languages too
|
|
|
|
gameplayer55055
|
2023-04-05 10:00:56
|
reverse URL or idk (com.google.shitapp?)
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:00:59
|
some engineers in my previous employment wanted to get .NET in their resume (around 2002) and they butchered a perfectly reasonable C++ architecture and inserted a .NET system into it -- a 1.0 runtime system that was soon after deprecated by Microsoft
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
some engineers in my previous employment wanted to get .NET in their resume (around 2002) and they butchered a perfectly reasonable C++ architecture and inserted a .NET system into it -- a 1.0 runtime system that was soon after deprecated by Microsoft
|
|
2023-04-05 10:01:41
|
btw microsoft influences good refactor job by punishing devs with updates. unlike java legacy code
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:01:43
|
those engineers moved on to other companies as .NET experts and the rest of the people were left with the hybrid monster architecture that was based on a legacy .NET solution
|
|
|
|
gameplayer55055
|
2023-04-05 10:02:06
|
backwards compatibility is double edge sword
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:02:13
|
agreed
|
|
|
|
Traneptora
|
2023-04-05 10:02:29
|
luckily I don't have any need for IE6 compat with my personal website
|
|
2023-04-05 10:02:32
|
so I just don't
|
|
|
|
gameplayer55055
|
|
Traneptora
luckily I don't have any need for IE6 compat with my personal website
|
|
2023-04-05 10:02:39
|
you arent a bank tho
|
|
|
|
Traneptora
|
2023-04-05 10:02:45
|
that's true, I am not
|
|
|
|
gameplayer55055
|
2023-04-05 10:02:55
|
<:TrollWhat:954801999948435466>
|
|
2023-04-05 10:03:03
|
silverlight
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:03:10
|
I am a client of one of the biggest banks in the world, UBS
|
|
|
|
Traneptora
|
2023-04-05 10:03:22
|
although you probably don't work on their web UI
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:03:29
|
they have now twice decided that the UI to my bank should be turned into Chinese
|
|
|
|
gameplayer55055
|
2023-04-05 10:03:48
|
we had executables in browser full of vulnerabilities
now we have people want scripts in highload instead
|
|
|
|
veluca
|
|
Jyrki Alakuijala
they have now twice decided that the UI to my bank should be turned into Chinese
|
|
2023-04-05 10:03:49
|
huh never had that
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:04:04
|
google ads also has done it twice
|
|
|
|
Traneptora
|
2023-04-05 10:04:10
|
how do you mean? like that the website be translated? that doesn't sound like such a bad thing
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:04:33
|
it is difficult to find your way to language settings if your mobile app is in chinese
|
|
2023-04-05 10:04:44
|
with browser you can translate of course
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
it is difficult to find your way to language settings if your mobile app is in chinese
|
|
2023-04-05 10:04:56
|
find something Ф
|
|
2023-04-05 10:05:10
|
something Ф means language on chinese
|
|
|
|
Traneptora
|
2023-04-05 10:05:15
|
but I meant, a simple location-based check to serve either the Chinese or the English language version of a website sounds like a big plus for accessibility for Chinese speakers
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:05:44
|
I think it was because I lived in kanton Zurich (ZH) and ZH somehow relates to chinese language codes
|
|
|
|
Traneptora
|
2023-04-05 10:05:57
|
oh, you mean, a bug caused the app to serve the Chinese version by accident
|
|
|
|
gameplayer55055
|
|
Traneptora
but I meant, a simple location-based check to serve either the Chinese or the English language version of a website sounds like a big plus for accessibility for Chinese speakers
|
|
2023-04-05 10:05:58
|
why not to use accept-language or idk
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:06:00
|
I never visited China or otherwise indicated a connection
|
|
|
|
Traneptora
|
2023-04-05 10:06:07
|
I see what you mean
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:06:26
|
someone just regexp'ed ZH in the client data (including address) and decided that it is an ask for the UI language
|
|
|
|
Traneptora
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:07:07
|
but there are 1000 fun bugs in e-banking
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
but there are 1000 fun bugs in e-banking
|
|
2023-04-05 10:07:31
|
one of them is called India
|
|
2023-04-05 10:08:17
|
btw would you believe me if i say ukraine has a bank with working 3d secure (popup like 2fa to confirm the purchase)
|
|
|
|
Traneptora
|
2023-04-05 10:08:31
|
I read an article by a south korean security expert that was posted here a few months ago. apparently south korean online banking sites require you to install anti-keylogging software in order to use them, but the software itself is vulnerable and a proof-of-concept lets you access passwords entered in another tab
|
|
|
|
gameplayer55055
|
|
Traneptora
I read an article by a south korean security expert that was posted here a few months ago. apparently south korean online banking sites require you to install anti-keylogging software in order to use them, but the software itself is vulnerable and a proof-of-concept lets you access passwords entered in another tab
|
|
2023-04-05 10:09:10
|
use f***ing webauthn
|
|
|
|
Jyrki Alakuijala
|
|
Traneptora
I read an article by a south korean security expert that was posted here a few months ago. apparently south korean online banking sites require you to install anti-keylogging software in order to use them, but the software itself is vulnerable and a proof-of-concept lets you access passwords entered in another tab
|
|
2023-04-05 10:09:56
|
security is difficult
|
|
|
|
gameplayer55055
|
2023-04-05 10:10:07
|
using passwords is asking for something 12345 date of birth
|
|
2023-04-05 10:10:27
|
2fa is sometimes annoying
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:10:30
|
my bank uses a QR code for login
|
|
|
|
gameplayer55055
|
2023-04-05 10:10:32
|
webauthn is perfect
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:10:41
|
QR codes are also used for paying the bills
|
|
|
|
gameplayer55055
|
2023-04-05 10:10:42
|
aka touch id
|
|
|
|
Traneptora
|
2023-04-05 10:10:44
|
security *is* difficult, but it's a bit ridiculous to require third-party device-driver level software to access an online banking website
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
my bank uses a QR code for login
|
|
2023-04-05 10:10:57
|
my bank uses them for oauth2
|
|
2023-04-05 10:11:19
|
ukraine uses smth like oauth2 to request documents
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:11:27
|
but the same QR code app is not applicable for bills and login, and some other bug within the depths of the ebanking system blocks me to use the app to scan bills with the other app
|
|
|
|
Traneptora
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:12:59
|
in some countries banks require additional codes, like a branch code or a VO_CODE (Russia previously), and if you don't remember to add the code, the money will be returned, whatever is left after doing the currency conversions twice
|
|
|
|
Traneptora
|
2023-04-05 10:13:27
|
in the united states you have account numbers *and* routing codes
|
|
|
|
gameplayer55055
|
2023-04-05 10:13:35
|
IBAN?
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:13:46
|
some developing countries don't need these fancy codes if you allow them to do currency conversions, but they take 5 % or so for the conversion -- it is better to do in the civilized end
|
|
|
|
gameplayer55055
|
2023-04-05 10:13:56
|
oh
|
|
|
Jyrki Alakuijala
some developing countries don't need these fancy codes if you allow them to do currency conversions, but they take 5 % or so for the conversion -- it is better to do in the civilized end
|
|
2023-04-05 10:14:08
|
my bank has a tick: allow double currency conversion
|
|
|
|
Traneptora
|
2023-04-05 10:14:39
|
you still need the routing code in the United States even if it's domestic and there's no currency conversion
it's how the banking system finds the bank with the associated account number
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:15:30
|
about 10 years ago Finnish banks claimed to be forced to send a notification if you run out of money and they asked 5 euro for the notification -- it was a funky "beat the poor some more" idea
|
|
|
|
Traneptora
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
about 10 years ago Finnish banks claimed to be forced to send a notification if you run out of money and they asked 5 euro for the notification -- it was a funky "beat the poor some more" idea
|
|
2023-04-05 10:16:01
|
:DDDDDD
|
|
|
|
Traneptora
|
2023-04-05 10:16:10
|
"I'm going to charge you for having no money" is always something that felt very cringe
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:16:28
|
it obviously made people quite angry
|
|
|
|
Traneptora
|
2023-04-05 10:16:35
|
it still is legal in the US
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:16:56
|
they needed to do massive amounts of user support to maintain that idea -- I think parliament made it illegal soon after
|
|
2023-04-05 10:17:34
|
ebanking maintenance happens quite often and you are unable to record new bills or observe the amount you have on the account using stale info -- it just doesn't work at all during maintenance
|
|
|
|
Traneptora
|
2023-04-05 10:17:58
|
sounds about right
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:18:00
|
and then there is the 'unknown error has happened, try again later' idea from UBS, which is about 3 % of all activity
|
|
2023-04-05 10:18:27
|
the kantonal banks have slightly more stable information systems
|
|
2023-04-05 10:19:00
|
one would think that banking is old enough concept that it could have been solved by now
|
|
|
|
Traneptora
|
2023-04-05 10:19:20
|
good customer experience is simply not a high priority
|
|
2023-04-05 10:19:25
|
otherwise it would be done
|
|
|
|
gameplayer55055
|
2023-04-05 10:20:06
|
interesting to learn that not only my country has problems
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:20:09
|
I think they don't hire or attract the right kind of engineers
|
|
|
|
gameplayer55055
|
|
Jyrki Alakuijala
I think they don't hire or attract the right kind of engineers
|
|
2023-04-05 10:20:36
|
why doing this if you have income
|
|
2023-04-05 10:20:46
|
if you have less income - increase fees
|
|
2023-04-05 10:20:55
|
why doing expensive refactor
|
|
2023-04-05 10:21:37
|
https://tenor.com/view/scrooge-scroogemcduck-donaldduck-ducktales-ebenezerscrooge-gif-4803444
|
|
|
|
Jyrki Alakuijala
|
2023-04-05 10:21:42
|
there is a person in our village who is the 'Switzerland's banking king' -- his company produces a software that is used by a big bank (IIRC, Basel kantonal bank)
|
|
|
|
gameplayer55055
|
2023-04-05 10:26:39
|
lol
|
|
2023-04-05 10:26:53
|
single point of failure?
|
|
|
username
|
2023-04-07 03:52:56
|
does jpeg-xl have any similar progressive animation decoding capabilities like flif? https://flif.info/animation.html
|
|
|
|
_wb_
|
2023-04-07 05:02:35
|
No, frames are not interlaced like that. It's a memory nightmare to do that, only works if you can keep the whole uncompressed animation in memory.
|
|
|
|
Traneptora
|
2023-04-07 10:55:47
|
iirc they can reference previous frames but up to 4 are saved as a reference
|
|
|
|
gameplayer55055
|
2023-04-08 02:03:57
|
macos, Finder displays previews cropped. any ideas?
|
|
2023-04-08 02:04:03
|
macos, Finder displays previews cropped. any ideas?
|
|
2023-04-08 02:08:08
|
maybe because its too big?
|
|
|
|
Deleted User
|
2023-04-09 10:51:59
|
https://bitcointalk.org/index.php?topic=5448018.0 "Buying an ISO standard: ISO/IEC 18181 (the JPEG XL one, all parts). I will pay $50 in BTC for PDF copies of the ISO standard ISO/IEC 18181."
|
|
|
Foxtrot
|
2023-04-09 11:41:17
|
Makes me think, what exactly is the benefit of JPEG XL being ISO standard? Being paid is disadvantage, so what are the advantages? For example when compared to AVIF which is not ISO but specs are free.
|
|
|
|
gameplayer55055
|
2023-04-09 11:42:17
|
lol
|
|
2023-04-09 11:42:21
|
is it an NFT
|
|
2023-04-09 11:42:25
|
or actual patent right
|
|
|
|
_wb_
|
2023-04-09 01:35:48
|
Patents have nothing to do with it, ISO just uses copyright to put their stuff behind a paywall
|
|
2023-04-09 01:40:43
|
The benefit of being an ISO standard is that it's a widely recognized standardization organization that is recognized by all national standardization bodies (ANSI, DIN, JIS, etc), with established procedures for voting on changes, reporting defects, etc. (procedures that are a bit outdated imo in how they work technically, but relatively OK in terms of being fair and not giving too much power to single entities like a big company or a big country).
|
|
2023-04-09 01:42:43
|
So that imo gives ISO standards more 'seriousness' (or 'prestige' if you want) than just some random ad hoc industry standard.
|
|
2023-04-09 01:43:55
|
That said, I wish JPEG would use ITU instead of ISO as their main standards org, and for something like jxl maybe even IETF.
|
|
|
improver
|
2023-04-09 01:45:35
|
mfw prestigious file format
|
|
|
|
_wb_
|
2023-04-09 01:46:14
|
The paywall is very annoying and imo does way more harm than good. The thing is that ISO is in the end just a private for-profit company based in Switzerland that needs to have some kind of business model to generate income/profit. Which is silly, I don't think this is how international standards orgs should be, but it is what it is.
|
|
|
|
Foxtrot
|
2023-04-09 01:46:18
|
So, AV1 has Google and other big companies to push it, so it don't have to bother with standardization. But JPEG XL dont have such big companies on its side, so it has to use ISO to give itself recognition.
|
|
|
|
improver
|
2023-04-09 01:47:10
|
it smells a bit of science journal kind of situation tbh
|
|
2023-04-09 01:47:36
|
which is.. just not a good model for standards
|
|
2023-04-09 01:47:41
|
especially digital
|
|
|
|
Foxtrot
|
2023-04-09 01:50:44
|
If I recall correctly, authors of articles/studies in scientific journals often can send you copy free of charge if you ask them (or just original draft?). I dont know if something similar applies to ISO.
|
|
|
|
_wb_
|
2023-04-09 01:52:33
|
AOM is an industry alliance of a bunch of big companies, and I suppose they don't want to work with ISO because 1) the process is kind of slow, 2) they want to make something royalty-free, and the ISO working group that does video (MPEG) doesn't exactly have a great track record on that, and 3) they probably don't want to have people like academics from arbitrary national bodies having a say in how they design their stuff. An ad hoc industry alliance works better if you want to move quickly and have nobody interfere with how you want to do things.
|
|
|
|
Foxtrot
|
2023-04-09 01:53:21
|
Thanks for explanation.
|
|
|
|
_wb_
|
|
improver
it smells a bit of science journal kind of situation tbh
|
|
2023-04-09 01:55:38
|
Yeah it's quite similar, except the annoying thing is that a spec is not a paper with a clear set of authors (who have the right to also put the paper on their own website if they want to), but the 'author' is a subcommittee of ISO (SC29 in this case) and I am "just an editor", so I cannot just take the pdf and put it on my website or ISO will sue me for copyright infringement.
|
|
|
|
Traneptora
|
2023-04-09 01:57:37
|
if I had to guess, someone is paying BTC for the PDFs because they want to strip the watermarks and redistribute them
|
|
2023-04-09 01:57:51
|
which is definitely copyright infringement
|
|
|
|
Foxtrot
|
2023-04-09 01:59:03
|
they could just buy it themselves... why this roundabout way
|
|
2023-04-09 01:59:41
|
if they successfully removed all watermarks and identification, it wouldn't be traceable
|
|
|
|
Traneptora
|
2023-04-09 02:00:00
|
not sure
|
|
|
|
Foxtrot
|
2023-04-09 02:00:25
|
well, I am just speculating, I never bought any ISO standard
|
|
|
MSLP
|
|
_wb_
That said, I wish JPEG would use ITU instead of ISO as their main standards org, and for something like jxl maybe even IETF.
|
|
2023-04-09 02:12:09
|
Do you have insight why JPEG, JPEG 2000 & JPEG XR were also released by ITU, but JPEG XS and XL not?
|
|
|
|
_wb_
|
|
MSLP
Do you have insight why JPEG, JPEG 2000 & JPEG XR were also released by ITU, but JPEG XS and XL not?
|
|
2023-04-09 02:16:05
|
I don't really know. I think they stopped doing the joint ITU thing because it's just too much extra work (you need to do everything twice, and it's tricky to keep both versions in sync), and in the past it was worth it because the ITU version was publicly available, but now ISO forces ITU to put their version behind a paywall too...
|
|
2023-04-09 02:20:39
|
If they would _only_ make it an ITU standard and not an ISO one, that would be nice. But the way things are now, JPEG is mainly a working group of ISO (JTC1/SC29/WG1) and the J in JPEG is quite weak right now, with only some indirect involvement in ITU's SG16
|
|
2023-04-09 02:22:02
|
So not making their standards ISO standards is not really an option for WG1...
|
|
|
Foxtrot
they could just buy it themselves... why this roundabout way
|
|
2023-04-09 02:22:37
|
$50 is cheaper than whatever ISO is charging atm.
|
|
|
|
Foxtrot
|
2023-04-09 02:23:55
|
> Yes I know it costs more than that. Get creative.
choosing begger
|
|
|
|
_wb_
|
2023-04-09 02:25:08
|
Anyway, the stuff behind the paywall is quite useless anyway. The drafts for the second editions of 18181-1 and 18181-2 are better. For 18181-3 you can also just look at https://github.com/libjxl/conformance, and 18181-4 is basically an outdated version of https://github.com/libjxl/libjxl in a zip file with some ISO boilerplate text.
|
|
|
|
Foxtrot
|
2023-04-09 02:31:27
|
In todays world you have to make a lot of things according to ISO standards. But to know these standards you have to pay.
I imagine if you had to pay to get to know country laws you have to follow 😄
|
|
|
|
_wb_
|
2023-04-09 02:34:11
|
this open letter is still out there: https://www.theregister.com/2021/07/31/iso_paywall_battle/
|
|
2023-04-09 02:34:28
|
https://docs.google.com/document/d/12Gmy2s4Nmkw6VDv2B6b5K1DLYhPrTUqSntrlmYzJpNw/edit
|
|
|
|
MSLP
|
|
_wb_
If they would _only_ make it an ITU standard and not an ISO one, that would be nice. But the way things are now, JPEG is mainly a working group of ISO (JTC1/SC29/WG1) and the J in JPEG is quite weak right now, with only some indirect involvement in ITU's SG16
|
|
2023-04-09 02:35:18
|
Comparing the situation with OpenDocument, where it was making a well-established format an ISO standard really differs from JPEG XL where a new format was developed, so I guess that's how things have to be.
I guess, comparing to non-ISO independent formats, being ISO stsndarized has a potential for adoption in some other fields, mainly "governmental" like medical, official archives or aerial land mapping.
Browser developers decide for themselves anyway.
|
|
|
|
_wb_
|
2023-04-09 02:38:00
|
sure, for something like archival, being an ISO standard is basically a guarantee that it's a format that somehow can still be opened in 100 years, while with ad-hoc formats you risk having files that will be hard to decipher in the distant future
|
|
|
|
Quikee
|
2023-04-10 01:44:53
|
hm.. PDF 2.0 spec was also behind ISO paywall and is now made freely available. How did they do it? PDF association putting pressure on ISO?
|
|
2023-04-10 01:47:18
|
Looking at it they just bought it off from ISO?
|
|
|
|
Deleted User
|
2023-04-10 03:21:38
|
https://www.pdfa.org/resource/iso-32000-pdf/ "As of April 5, 2023, PDF’s latest and most up-to-date core specification, PDF 2.0, including Amendment 1, is available from the PDF Association at at no cost thanks to sponsorship support provided by Adobe, Apryse and Foxit.
Read the press-release and download the bundle of ISO 32000-2 with ISO TS 32001 and ISO TS 32002 at no cost!" ... however, clicking download, it writes "PDF Association members who login to pdfa.org before adding to their cart receive a 10% discount on ISO documents."
|
|
2023-04-10 03:24:59
|
https://www.pdfa.org/sponsored-standards/ - the "press release", indeed leading to $0, but requiring to login
|
|
2023-04-10 03:26:49
|
there was some discussion about JPEG XL in PDF 2.0 in the past, but I cannot find anything now...?
|
|
2023-04-10 03:37:36
|
https://www.pdfa.org/wp-content/uploads/2021/06/pdf-heic-1.pdf
|
|
2023-04-10 03:38:28
|
https://www.reddit.com/r/jpegxl/comments/zwc5ro/is_it_possible_to_use_jpeg_xl_images_in_pdfs/
|
|
2023-04-10 03:39:58
|
https://www.youtube.com/watch?v=cY5QNN946QI to the slides above
|
|
2023-04-10 03:48:15
|
I wasn't able to find anything after this Rene Rebe (CEO of ExactCODE) talk 2 years ago (?)
|
|
2023-04-10 04:15:49
|
https://pdfraster.org/ - also 2022, the same talk
|
|
|
|
_wb_
|
2023-04-10 06:48:03
|
PDF, like Unicode and C++ and several other ISO standards also has a non-profit organization behind it, and if I understand correctly it's the non-profit org that develops the standards, keeps the copyright, and there is a separate fast-track process in ISO to make such 'externally developed' standards also an ISO standard.
|
|
2023-04-10 06:51:25
|
I think ISO only allows that for 'big' and already well-established standards, so they can have more 'big name' standards in their portfolio. I don't know if it would also work for something like jxl...
|
|
|
zamfofex
|
2023-04-10 07:07:15
|
That almost feels contradictory. They only allow well known standards to be written by a separate organization because they want for well known standards to be theirs. 🤔
|
|
|
|
Traneptora
|
2023-04-10 01:56:01
|
just merged a commit into FFmpeg that lets jpegli-encoded XYB jpegs be decoded with libavcodec :)
|
|
2023-04-10 01:56:10
|
the B-subsampling in the RGB channel threw it off, but now it works
|
|
|
jonnyawsom3
|
2023-04-10 02:58:46
|
If I recall the B-subsampling was going to be removed so the XYB Jpegs can be transcoded to JXL properly
|
|
|
|
improver
|
2023-04-10 03:40:02
|
that's still a good change though
|
|
|
|
Traneptora
|
2023-04-11 02:12:51
|
yes that
|
|
2023-04-11 02:13:39
|
FFmpeg doesn't do icc color management tho, but the pixel receiver does
|
|
|
|
jonnyawsom3
|
2023-04-11 02:57:07
|
My phone got me excited for a second, I opened the camera and read `JPG-L` as `JPGXL` :P
|
|
|
gb82
|
2023-04-11 06:42:09
|
How do u decode jpegli jpegs to rgb PNGs? Can ffmpeg just do it?
|
|
|
|
spider-mario
|
2023-04-11 08:53:21
|
rgb as in “not xyb+icc”?
|
|
|
|
Jyrki Alakuijala
|
|
Traneptora
just merged a commit into FFmpeg that lets jpegli-encoded XYB jpegs be decoded with libavcodec :)
|
|
2023-04-11 08:55:09
|
Wow. Thank you ❤️
|
|
2023-04-11 08:55:48
|
did you try mjpegli -- how did the quality/density appear to you?
|
|
|
|
Traneptora
|
|
gb82
How do u decode jpegli jpegs to rgb PNGs? Can ffmpeg just do it?
|
|
2023-04-11 09:39:48
|
FFmpeg lacks a cms engine that can handle xyb jpeg's ICC profile atm, tho ive got a pending patch in libplacebo to fix that
|
|
|
Jyrki Alakuijala
did you try mjpegli -- how did the quality/density appear to you?
|
|
2023-04-11 09:40:38
|
I have not, what is mjpegli?
|
|
|
yoochan
|
2023-04-11 09:41:40
|
motion jpeg li ?
|
|
|
|
Traneptora
|
|
gb82
How do u decode jpegli jpegs to rgb PNGs? Can ffmpeg just do it?
|
|
2023-04-11 09:53:58
|
if you're looking for a CLI solution, you can run:
```
convert input-xyb.jpg -depth 16 xyb.tiff
tificc -w16 xyb.tiff srgb.tiff
convert srgb.tiff -depth 16 sRGB.png
```
|
|
2023-04-11 09:54:33
|
I've got a pending patch in libplacebo that'll let you do it directly from FFmpeg though
|
|
2023-04-11 10:04:55
|
a GUI solution involves simply opening the XYB JPEG in GIMP
|
|
2023-04-11 10:05:01
|
and exporting as PNG
|
|
2023-04-11 10:06:03
|
GIMP manages colors correctly
|
|
|
derberg
|
2023-04-11 10:40:31
|
https://media.discordapp.net/attachments/184821797307285504/1095289645237018634/Fensterfoto_2023-04-11_12-09-51_Xfce4-terminal.png
This is kinda shocking (in a positive way?) to me.
I took a screenshot of my two monitors by using flameshot and saved it as JXL (supported thanks to kimageformats).
Then I converted that to PNG (which looks average in terms of size for a screenshot) and back to JXL with (almost — ignoring one digit -e 10 percent improvements that take hours) the best options I have found for screenshots so far (`cjxl -q 100 -m 1 -e 9 --brotli_effort 11 -E 3 -I 100 -g 3 -j 1 in.png out.jxl` which outputs JXL images that are on average 47% the size of my PNG screenshots).
But the resulting file is still way bigger than the JXL created by flameshot.
|
|
2023-04-11 10:40:35
|
In fact, this folder contains over 150k of converted screenshots of different dimensions— most of them converted from PNG files made by xfce4-screenshooter by using the best options I had for 0.6.1 and 0.7 — and it is smaller than most of those:
https://media.discordapp.net/attachments/184821797307285504/1095293292398256229/image.png?width=961&height=627
|
|
2023-04-11 10:45:13
|
(files in the middle of the scroll bar area are about 500K btw.)
|
|
2023-04-11 10:48:03
|
Will run -e 10 on that file but I doubt it will get any close.
So there really is some improvement to be made, huh?
<:Hypers:808826266060193874>
|
|
|
|
Traneptora
|
|
derberg
https://media.discordapp.net/attachments/184821797307285504/1095289645237018634/Fensterfoto_2023-04-11_12-09-51_Xfce4-terminal.png
This is kinda shocking (in a positive way?) to me.
I took a screenshot of my two monitors by using flameshot and saved it as JXL (supported thanks to kimageformats).
Then I converted that to PNG (which looks average in terms of size for a screenshot) and back to JXL with (almost — ignoring one digit -e 10 percent improvements that take hours) the best options I have found for screenshots so far (`cjxl -q 100 -m 1 -e 9 --brotli_effort 11 -E 3 -I 100 -g 3 -j 1 in.png out.jxl` which outputs JXL images that are on average 47% the size of my PNG screenshots).
But the resulting file is still way bigger than the JXL created by flameshot.
|
|
2023-04-11 10:55:52
|
run jxlinfo -v on the flameshot jxls
|
|
2023-04-11 10:56:15
|
it's likely they're lossy with a low distance
|
|
|
|
derberg
|
2023-04-11 10:59:35
|
Ah
|
|
2023-04-11 10:59:43
|
```
JPEG XL image, 3648x1079, lossy, 8-bit RGB
num_color_channels: 3
num_extra_channels: 0
have_preview: 0
have_animation: 0
Intrinsic dimensions: 3648x1079
Orientation: 1 (Normal)
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative
```
|
|
|
|
veluca
|
2023-04-11 11:32:48
|
yup, thought so
|
|
|
|
gb82
|
|
Traneptora
if you're looking for a CLI solution, you can run:
```
convert input-xyb.jpg -depth 16 xyb.tiff
tificc -w16 xyb.tiff srgb.tiff
convert srgb.tiff -depth 16 sRGB.png
```
|
|
2023-04-11 01:28:53
|
thank u :) will try it out
|
|
2023-04-11 01:37:45
|
ok it definitely works but ssimu2 is still giving it low scores - xyb jpegli gets 50 from the png, rgb gets 80
|
|
2023-04-11 01:38:44
|
on second thought, I don't think it is wrong considering the jpegli discoloration...
|
|
2023-04-11 01:40:37
|
https://slow.pics/c/YO8L54iT
|
|
|
|
_wb_
|
2023-04-11 02:11:21
|
ssimulacra2 hates small color shifts like that
|
|
2023-04-11 02:49:28
|
I wonder what causes the shift in the first place — is it still there when doing accurate decoding (using jpegli itself)?
|
|
|
|
gb82
|
2023-04-11 04:13:04
|
I don’t know how to test that
|
|
|
|
Traneptora
|
|
gb82
I don’t know how to test that
|
|
2023-04-11 04:50:38
|
one possible way to do that is to use `cjxl input-xyb.jpg intermediate.jxl && djxl --bits_per_sample=16 intermediate.jxl intermediate.png`
|
|
2023-04-11 04:50:52
|
ideally `djxl` will be able to read jpeg files but atm it cannot
|
|
2023-04-11 04:51:42
|
speaking of which is there already an issue for djxl to read jpeg files?
|
|
|
|
_wb_
|
2023-04-11 05:04:36
|
I would prefer if libjxl can do it, not just djxl
|
|
|
|
Traneptora
|
|
_wb_
I would prefer if libjxl can do it, not just djxl
|
|
2023-04-11 05:36:43
|
https://github.com/libjxl/libjxl/issues/2371
|
|
|
|
gb82
|
|
Traneptora
one possible way to do that is to use `cjxl input-xyb.jpg intermediate.jxl && djxl --bits_per_sample=16 intermediate.jxl intermediate.png`
|
|
2023-04-11 07:06:13
|
Alright, I'll keep an eye out.
|
|
|
Kejchi
|
2023-04-12 02:45:06
|
I was listening to YouTube and suddenly heard JXL
https://youtu.be/W3wlKh0JebA?t=494
|
|
|
|
Jyrki Alakuijala
|
2023-04-12 10:07:42
|
duplicates are ok -- if nothing else it indicates interest in the issue
|
|
2023-04-12 10:09:42
|
I'm looking to improve epf-filtering control field -- with all the tiling, different resolution images etc. my indexing is confused and got a segfault, need to gdb for the first time in 3 years or so...
|
|
|
|
Traneptora
|
2023-04-12 12:28:33
|
it appears JPEGLI jpegs are missing the EOI marker, is this intentional or should I open an issue?
|
|
2023-04-12 12:31:41
|
nvm, it appears that got fixed
|
|
|
190n
|
|
Kejchi
I was listening to YouTube and suddenly heard JXL
https://youtu.be/W3wlKh0JebA?t=494
|
|
2023-04-12 03:25:04
|
imagine a fuse filesystem that saved every jpeg on disk as a jxl and decompressed them as needed
|
|
|
|
jonnyawsom3
|
2023-04-12 07:06:38
|
Not really related, but reminded me of the XPRESS16K filesystem compression in Windows 10/11, I've been using it for a while and it's saved over 100GB on a 2TB drive
|
|
|
|
Traneptora
|
2023-04-13 09:43:38
|
woot, `mpv` now supports xyb JPEGs :)
|
|
2023-04-13 09:45:19
|
via libplacebo
|
|
|
DZgas Ж
|
2023-04-13 10:13:36
|
What programs are there to check for reading jpeg xl. When transmitting over the network. For example, a progressive image with sequential loading and decoding, what would it be visually
|
|
|
monad
|
2023-04-14 12:15:51
|
There is this for the browser: <https://google.github.io/attention-center/>
|
|
|
|
yoochan
|
2023-04-14 07:49:03
|
it doesn't work well on firefox but it does on chrome with the flag
|
|
|
|
_wb_
|
2023-04-14 07:49:33
|
firefox hasn't implemented any progressive yet (though some of the forks have merged the patch to make it work)
|
|
2023-04-14 07:51:34
|
chrome has some progressive decoding but not the full thing — the bitstream allows more stuff to be shown, but a trade-off was made in the chrome integration to avoid re-painting too often, which can be bad for total decode speed.
|
|
|
|
yoochan
|
2023-04-14 07:56:52
|
If I would like to truncate a jpegxl file so that it stops exactly at the end of the first (n-th ?) pass of progressiveness, is there an easy way ?
|
|
2023-04-14 07:57:54
|
I was wondering if it would be easy to produce thumbnails (server side) with this method
|
|
|
|
_wb_
|
2023-04-14 08:09:38
|
It could be done but we need to make the tools to make it easy. Note however that such thumbnails would likely have a higher quality than needed and it would not be as effective as lossy downscaled images. On the other hand, if the full image will be shown too, the truncated jxl can be reused while a separate thumbnail cannot.
|
|
|
|
yoochan
|
2023-04-14 08:13:15
|
yes, I was think about the reuse ! 🙂 could be fun ! Could the position of the end of progressive blocks be deduced by reading the header ? If so, I'll try myself, could be a good small step top start
|
|
|
|
_wb_
|
2023-04-14 08:47:54
|
Yes, the TOC in the frame header has the offsets
|
|
|
|
jonnyawsom3
|
2023-04-14 10:01:32
|
Might not be useful or even related, but this is where I landed when following the same idea
https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
|
|
|
|
yoochan
|
2023-04-14 11:15:11
|
yes, range requests works well, what could be missing is the capacity to properly resume an already partially downloaded file, from javascript, and still render the truncated or complete file with the polyfill 🙂
|
|
|
|
DZgas Ж
|
|
monad
There is this for the browser: <https://google.github.io/attention-center/>
|
|
2023-04-14 12:36:25
|
This site is crooked, it displays images not 1 to 1 and scales them. I can't check my 768x40000 images
|
|
|
monad
There is this for the browser: <https://google.github.io/attention-center/>
|
|
2023-04-14 01:16:45
|
delete style in head solved all the problems
|
|
|
|
Traneptora
|
2023-04-14 03:24:58
|
Also, those who are trying to convert XYB jpegs to sRGB pngs can now do so with FFmpeg in one pass, provided you have git master of both FFmpeg and of libplacebo
|
|
|
|
gb82
|
|
Traneptora
Also, those who are trying to convert XYB jpegs to sRGB pngs can now do so with FFmpeg in one pass, provided you have git master of both FFmpeg and of libplacebo
|
|
2023-04-14 08:30:05
|
:D
|
|
2023-04-14 08:30:10
|
https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php
|
|
2023-04-14 08:30:23
|
also if you view this page in Waterfox, none of the HDR images work properly
|
|
2023-04-14 08:30:27
|
Thorium does a fine job
|
|
|
|
Traneptora
|
|
gb82
:D
|
|
2023-04-14 08:30:57
|
discovered another bug preventing this.... :p
|
|
|
|
gb82
|
2023-04-14 08:31:07
|
oh, what happened?
|
|
|
|
Traneptora
|
2023-04-14 08:32:58
|
idk, explicitly requesting srgb with the filter makes lcms2 whine but playing it on an srgb monitor works fine. idk
|
|
2023-04-15 03:21:49
|
<@171381182640947200> I'm checking out the above ^ HDR test page and it appears not to work well with your extension
|
|
2023-04-15 03:24:14
|
|
|
|
|
zamfofex
|
2023-04-15 03:29:02
|
It doesn’t support different color profiles at all! I don’t think libjxl has an inbuilt way to convert images to sRGB. (And in any case, it wouldn’t support HDR, as I don’t think that’s actually possible without having a custom PNG/JPEG/WebP/whatever encoder.)
|
|
|
|
Traneptora
|
|
It doesn’t support different color profiles at all! I don’t think libjxl has an inbuilt way to convert images to sRGB. (And in any case, it wouldn’t support HDR, as I don’t think that’s actually possible without having a custom PNG/JPEG/WebP/whatever encoder.)
|
|
2023-04-15 03:30:08
|
libjxl gives you the pixels in whatever space you request them in
|
|
2023-04-15 03:30:16
|
so if you request them in sRGB, that's the space it'll give them to you in
|
|
2023-04-15 03:32:23
|
on the command-line, you can do something like this
|
|
2023-04-15 03:32:25
|
```
djxl 20140606_102418_IMGP0297.jxl --color_space=RGB_D65_SRG_Rel_SRG test.png
```
|
|
2023-04-15 03:32:34
|
at the very least, it will look correct to people on SDR monitors
|
|
|
|
_wb_
|
2023-04-15 03:33:03
|
HDR is not going to work in firefox or its forks, I think it internally has pixel buffers that are always 8-bit and they'll need to do some work to make HDR work (for any format)
|
|
|
|
Traneptora
|
2023-04-15 03:33:33
|
at the very least it should request 8-bit sRGB from libjxl so it looks correct as an SDR image
|
|
|
|
_wb_
|
2023-04-15 03:34:22
|
Or maybe display P3?
|
|
|
|
Traneptora
|
2023-04-15 03:34:54
|
something like that, but I don't know if firefox has an API that allows it to tell extensions what color space the output image is in
|
|
2023-04-15 03:34:58
|
so sRGB is probably a bit safer
|
|
2023-04-15 03:35:28
|
P3 atm is sort of relegated to apple-land
|
|
|
|
_wb_
|
2023-04-15 03:36:28
|
Oh right, if the extension uses the sdr image canvas then I suppose that is sRGB and there isn't really a way to make it anything else
|
|
|
|
Traneptora
|
2023-04-15 03:37:02
|
it *should* correctly display it as sRGB though
|
|
|
w
|
2023-04-15 03:37:08
|
how can an hdr image "look correct" as an sdr image?
|
|
|
|
Traneptora
|
2023-04-15 03:37:24
|
"correct" is relative and subjective, clearly, but atm it's not doing any kind of tone mapping
|
|
2023-04-15 03:37:41
|
or any kind of gamut mapping it looks like
|
|
2023-04-15 03:38:14
|
generally this is a Hard Problem but some solutions are clearly better than others
|
|
|
|
zamfofex
|
2023-04-15 03:51:45
|
Maybe I’m stupid (very likely), but from reading the documentation, it seems I need a `JxlCmsInterface`, and I’m not sure how to acquire a sensible default for it, if there is any.
|
|
|
|
spider-mario
|
2023-04-15 04:15:19
|
the internal API has `jxl::GetCms()`, though we currently don’t expose it
|
|
|
|
Traneptora
|
|
Maybe I’m stupid (very likely), but from reading the documentation, it seems I need a `JxlCmsInterface`, and I’m not sure how to acquire a sensible default for it, if there is any.
|
|
2023-04-15 09:32:03
|
if you don't set it, it uses the default
|
|
2023-04-15 09:32:07
|
which is lcms2 iirc but I'm not sure
|
|
|
|
zamfofex
|
2023-04-16 03:13:29
|
That is not what the documentation says, though: <https://github.com/libjxl/libjxl/blob/79946c2e12cc3e1e018a8411c75c32e02546baf8/lib/include/jxl/decode.h#L827-L867> (Unless I’m looking at the wrong function.)
|
|
|
|
Traneptora
|
2023-04-16 03:22:20
|
oh, huh
|
|
2023-04-16 03:22:47
|
cms is not required tho for XYB -> sRGB tho
|
|
|
|
Yari-nyan
|
2023-04-16 11:23:01
|
i noticed that fast_lossless turns 16 bit depth PNGs into 8 bit depth JPEG XLs, despite the readme claiming it can do up to 16 bit
|
|
2023-04-16 11:23:14
|
is there something i'm missing?
|
|
|
|
veluca
|
|
Yari-nyan
i noticed that fast_lossless turns 16 bit depth PNGs into 8 bit depth JPEG XLs, despite the readme claiming it can do up to 16 bit
|
|
2023-04-16 12:04:26
|
I think fast\_lossless\_main.cc only reads 8-bit png, use cjxl -e 1 if you want 16 bit 🙂
|
|
|
|
Jyrki Alakuijala
|
|
Traneptora
cms is not required tho for XYB -> sRGB tho
|
|
2023-04-17 08:48:59
|
would be rather nice if there was a way to make XYB be the most usual way to store, transport and display images -- like the new sRGB
|
|
|
|
_wb_
|
2023-04-17 09:08:36
|
The main problem I see with that is that 8-bit XYB is not good enough. So it requires larger buffer sizes than what is typically used now.
|
|
|
|
spider-mario
|
2023-04-17 09:09:07
|
is it not?
|
|
|
|
_wb_
|
2023-04-17 09:41:04
|
I think 8-bit XYB has more noticeable banding than 8-bit sRGB, I might be wrong though. I suppose if xyb jpegs look OK for slow gradients when using default libjpeg-turbo (which decodes to 8-bit) then it might be good enough...
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
The main problem I see with that is that 8-bit XYB is not good enough. So it requires larger buffer sizes than what is typically used now.
|
|
2023-04-17 11:18:17
|
I don't immediately see how XYB would lead to more banding -- unless it is just for an increased number of conversions between say sRGB and XYB
|
|
|
|
Traneptora
|
2023-04-17 11:43:56
|
Most monitors are in some sort of nonlinear space
|
|
2023-04-17 11:44:25
|
I find 8-bit linear images have banding issues when everything is done in 8 bit
|
|
|
|
_wb_
|
2023-04-17 12:00:11
|
yes, 8-bit is certainly not enough for linear. XYB is not linear though, so in that regard it should be fine.
|
|
2023-04-17 12:01:40
|
but just like YCbCr, it's a luma-chroma-chroma space, which means not the whole cube of 256^3 colors is actually used
|
|
2023-04-17 12:03:13
|
for both dark and bright colors, X and B have a limit range close to neutral (0, however you represent that in 8-bit ints)
|
|
2023-04-17 12:03:25
|
only in the mid range can X and B use their full range
|
|
2023-04-17 12:04:52
|
so while you have 16m colors in 8-bit RGB, in 8-bit XYB (or YCbCr, YCoCg, Lab, or anything else that is luma-chroma-chroma) you effectively have fewer colors, probably something like 3-4 million
|
|
|
elfeïn
|
2023-04-17 08:06:52
|
It seems the decoder is covered extensively but not the encoder. Is it just the inverse of the decoding outlined in the ascii docs?
|
|
|
|
Traneptora
|
|
elfeïn
It seems the decoder is covered extensively but not the encoder. Is it just the inverse of the decoding outlined in the ascii docs?
|
|
2023-04-17 10:19:21
|
when you say covered, wdym? documented?
|
|
|
|
elfeïn
|
|
Traneptora
when you say covered, wdym? documented?
|
|
2023-04-17 11:38:43
|
Well the spec explains how the decoder works but not the encoder. Brain power is low today lol so not sure what to do
|
|
|
|
Traneptora
|
|
elfeïn
Well the spec explains how the decoder works but not the encoder. Brain power is low today lol so not sure what to do
|
|
2023-04-17 11:48:15
|
that's because it's specified in terms of the decoding
|
|
2023-04-17 11:48:31
|
to encode, you do it in reverse, but the format is specified specifically as a decoder
|
|
|
|
elfeïn
|
2023-04-18 12:03:52
|
Ah
|
|
2023-04-18 12:03:56
|
Sus
|
|
|
|
zamfofex
|
2023-04-18 12:04:57
|
That’s how most specs are written. It is meant to specify the format, not how to implement it. It’s just easy enough to specify how to decode it.
|
|
2023-04-18 12:06:36
|
Some specs will just provide a grammar and some prose explaining its semantics, rather than a parser/decoder per se.
|
|
2023-04-18 12:07:37
|
Once you understand how the format works, it is up to *you* to figure out how to write an implementation.
|
|
|
|
elfeïn
|
|
|
_wb_
|
2023-04-18 05:07:10
|
All codecs specs are written by describing how to decode. That's the part that requires standardization. Encoding can be left to just "encoders have to produce a bitstream that can be decoded". They are rarely standardized. Different encoders can do different things, and that's a good thing: this is what allows encoder improvements, different trade-offs between compression and speed, different quality settings, etc.
|
|
|
|
username
|
|
username
it seems that even with the unmerged patches something isn't quite right about the color management with JXL in firefox
|
|
2023-04-18 07:14:29
|
<@288069412857315328> it seems like something with color management isn't quite right with your JXL patches merged into firefox with "gfx.color_management.mode" set to a value of 2 any idea of what the problem is or what can be done to fix it?
|
|
|
|
w
|
2023-04-18 07:15:13
|
for that test in mode 2, everything else is wrong
|
|
|
|
username
|
2023-04-18 08:06:21
|
interesting I think I remember you mentioning this before at some point
|
|
2023-04-18 08:08:16
|
how is everything else in mode 2 wrong? I thought the point of it was it would only do color management for images with embedded ICC color profiles?
|
|
|
|
w
|
2023-04-18 08:21:58
|
the other formats have an option for no color management
|
|
2023-04-18 08:22:02
|
jxl image has no option for no color management
|
|
2023-04-18 08:22:32
|
i guess it's not technically wrong
|
|
|
|
elfeïn
|
2023-04-18 08:23:00
|
What does that mean?
|
|
2023-04-18 08:23:08
|
Jxl spec requires specifying channels?
|
|
|
|
username
|
|
w
jxl image has no option for no color management
|
|
2023-04-18 08:35:55
|
I don't know how libjxl or firefox handle color management stuff internally but what do you you mean by this? because when the mode is set to 0 in firefox then the JXL gets rendered without color management like the other images/formats
|
|
|
|
w
|
2023-04-18 08:36:27
|
iirc mode 2 is do nothing if there's no profile
|
|
2023-04-18 08:36:31
|
but jxl images all have profile
|
|
|
|
username
|
2023-04-18 08:37:08
|
ohh that makes more sense
|
|
2023-04-18 08:40:52
|
although it seems like in libjxl somewhere can understand if something has a icc profile
|
|
|
|
_wb_
|
2023-04-18 08:42:00
|
mode 2 is just wrong — W3C specifies that images without profile should be treated as sRGB, while firefox does "do nothing" on images without profile, which boils down to "assume they are in display space", which means the image will look different depending on your display space
|
|
2023-04-18 08:42:47
|
jxl is defined so that all images do have a clearly defined color space - there is no way to _not_ signal what color space an image is in
|
|
2023-04-18 08:43:43
|
though the color space can be defined either via an explicit ICC profile or via a more concise enumerator - but those are just two different ways to signal it, the point is that there is no way to _not_ signal it
|
|
2023-04-18 08:46:44
|
unlike JPEG and PNG which do allow storing pixels without signaling what colorspace they're in (which according to W3C means they should be interpreted as sRGB, but historically it has also meant Rec.709 and lots of software treats untagged pixels as "don't care, just assume no color management is needed")
|
|
2023-04-18 08:46:57
|
and unlike GIF which does not even allow signaling the colorspace at all
|
|
|
|
w
|
|
_wb_
mode 2 is just wrong — W3C specifies that images without profile should be treated as sRGB, while firefox does "do nothing" on images without profile, which boils down to "assume they are in display space", which means the image will look different depending on your display space
|
|
2023-04-18 09:05:27
|
tbf that is what mode 1 does, but why mode 2 is default - who knows
|
|
|
|
_wb_
|
|
w
tbf that is what mode 1 does, but why mode 2 is default - who knows
|
|
2023-04-18 09:37:28
|
I assume some misguided idea that avoiding color management is OK in this case, and obviously not doing color management is better for performance than doing it...
|
|
|
|
Foxtrot
|
2023-04-18 11:21:23
|
not defining color space seems to me like saying that length of something is 6
mm, cm, inch, km, miles? who knows 😄
|
|
|
|
jonnyawsom3
|
2023-04-18 12:24:17
|
More like we don't know if it's age, capacity, temperature, price
We know the value, just not what it means
|
|
|
Eugene Vert
|
2023-04-18 12:33:25
|
Finally done with the splines for jxl-oxide, yay
|
|
2023-04-18 12:33:44
|
But i'm a bit confused. comparing using `compare -metric mse` with the libjxl output on random jxl art gives an error of 1e-7 is this normal for splines?
|
|
|
|
spider-mario
|
2023-04-18 12:51:45
|
I don’t think we have formally verified but I wouldn’t be surprised
|
|
|
|
Jyrki Alakuijala
|
2023-04-18 01:35:18
|
worked for about a week, failed trice in smoothing control field improvements and finally got a 0.1 % improvement in ac strategy 😄 https://github.com/libjxl/libjxl/pull/2397 -- not sure if I should be proud or disappointed
|
|
|
|
yoochan
|
2023-04-18 01:57:16
|
you can be proud to be disappointed
|
|
|
|
DZgas Ж
|
|
|
Traneptora
|
|
Eugene Vert
But i'm a bit confused. comparing using `compare -metric mse` with the libjxl output on random jxl art gives an error of 1e-7 is this normal for splines?
|
|
2023-04-18 04:46:50
|
keep in mind that there's a certain tolerance and 1e-7 is within the tolerance
|
|
2023-04-18 04:47:03
|
note that for 16-bit output that's within half a pixel
|
|
|
|
yoochan
|
2023-04-18 05:20:18
|
If I understood properly, spline are not generated by the present encoder, but what made you believe it was useful to add them to the format ? did you made some kind of experiments to assess the relevance of such a feature ? or was it more an intuition that it could offer new possibilities ?
|
|
|
|
spider-mario
|
2023-04-18 05:26:48
|
we experimented a bit, but without an encoder to generate them, we (I) had to generate them by hand, which limited the extent of the testing we could do
|
|
|
|
Eugene Vert
|
2023-04-18 05:27:29
|
One potential use of splines is to encode vector layers from photoshop/gimp/krita
|
|
2023-04-18 05:30:07
|
Or simply convert vector graphics to jxl, for example svg -> jxl: https://grass.moe/splines/
|
|
|
|
yoochan
|
2023-04-18 05:36:00
|
ok, thanks ! I saw it advertised as something which could be used for hairs, but I would be curious to learn if any compression can be made this way 🙂
|
|
|
|
_wb_
|
2023-04-18 05:56:40
|
It can be useful for any curved line-like image feature, since DCT is notoriously bad at doing thin lines — if you want to do thin lines with DCT, you basically have to bump up quality a lot to avoid ringing artifacts, to the point that it can even become less effective than lossless in some cases.
|
|
2023-04-18 05:57:18
|
But making an encoder that extracts splines is not trivial.
|
|
2023-04-18 06:00:40
|
We mostly put splines in the bitstream as a 'future proofing' thing. At some point there will be encoders that make good use of splines, and they will get nice compression and quality benefits from that.
|
|
|
|
MSLP
|
2023-04-18 06:16:04
|
Regarding splines, It has been said here, that there's a limit on their use in the decorder.
What order-of-magnitude is that limit?
|
|
|
|
_wb_
|
2023-04-18 06:21:06
|
|
|
2023-04-18 06:21:30
|
That's what we intend to put in the spec, still pending approval though...
|
|
2023-04-18 06:24:53
|
Basically those limits should not be very limiting, as long as you only use splines for their intended purpose (thin lines). If you use them for very thick (blurry) stuff like in some jxl art, to the extent that many pixels have to be repainted many times to render all splines, it does become a limit — we have to put some limit to it to prevent DoS attacks, since otherwise you can make small jxl files that will take ages to decode
|
|
2023-04-18 06:26:33
|
Roughly speaking in Level 5 you can paint every pixel once on average with splines, and in Level 10 you can paint every pixel 64 times on average (in both cases with a hard cap so for huge images the effective limit will be lower)
|
|
2023-04-18 06:27:21
|
You can always just have multiple frames so it's not a real limitation, but it does limit the amount of work a decoder has to decode a frame of a given dimension
|
|
|
|
Eugene Vert
|
|
_wb_
Roughly speaking in Level 5 you can paint every pixel once on average with splines, and in Level 10 you can paint every pixel 64 times on average (in both cases with a hard cap so for huge images the effective limit will be lower)
|
|
2023-04-18 06:39:42
|
That's strange, for this small thin spline i'm getting total_estimated_area of 1373719425800
|
|
2023-04-18 06:40:22
|
(The number is from djxl)
|
|
|
|
_wb_
|
2023-04-18 07:01:34
|
Hm, that doesn't seem right...
|
|
2023-04-18 07:02:22
|
Could be a bug in how we compute that
|
|
2023-04-18 07:05:01
|
<@179701849576833024> any idea?
|
|
|
|
veluca
|
2023-04-18 07:06:39
|
Not on the top of my head 🤣
|
|
2023-04-18 07:07:07
|
Seems weird though, probably needs some investigation
|
|
|
|
_wb_
|
|
Eugene Vert
That's strange, for this small thin spline i'm getting total_estimated_area of 1373719425800
|
|
2023-04-18 07:22:57
|
Do you have the jxl_from_tree source for that?
|
|
|
|
Eugene Vert
|
2023-04-18 07:24:05
|
```
Width 1920
Height 1080
Bitdepth 8
Spline
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
50 50
100 150
150 150
EndSpline
- Set 0
```
|
|
|
|
_wb_
|
2023-04-18 07:27:53
|
https://jxl-art.surma.technology/?zcode=4wrPTCnJUDAyMODySM1MzygBM50yS1JSC4DiFlzBBTmZealchgoGFEEugwE3gGIvmBoomBpwGRoYKBiCaFMI7ZqXAg0jLl2F4NQSBQMA
|
|
2023-04-18 07:30:57
|
The estimated area is computed by taking manhattan distance between control points (which should give an upper bound to the actual length of the curve) and multiplying by some upper bound on the spline thickness derived directly from the quantized sigma dct coeffs to avoid relying on float math to define what is a valid bitstream
|
|
2023-04-18 07:35:00
|
So here that manhattan distance should be 200 and that width estimate should be some small number like 16 or something, I would expect/assume
|
|
|
|
Eugene Vert
|
2023-04-18 07:42:27
|
manhattan_distance: 200
width_estimate: 6868597129
|
|
|
|
jonnyawsom3
|
2023-04-18 07:43:29
|
So only off by a few hundred million xD
|
|
|
|
_wb_
|
2023-04-18 07:46:48
|
Something going wrong in that width estimate code then, I suppose. Good catch!
Also: does djxl actually decode that image? Because then it looks like it's not properly checking the limits either...
|
|
|
|
Eugene Vert
|
2023-04-18 07:47:16
|
I disabled the limit on mine djxl)
|
|
|
|
_wb_
|
2023-04-18 07:48:07
|
Please open an issue about this on github, this is certainly a bug that needs to be fixed before 1.0 and preferably just asap
|
|
|
|
Eugene Vert
|
2023-04-18 08:16:57
|
Done)
https://github.com/libjxl/libjxl/issues/2400
|
|
|
BlueSwordM
|
|
_wb_
It can be useful for any curved line-like image feature, since DCT is notoriously bad at doing thin lines — if you want to do thin lines with DCT, you basically have to bump up quality a lot to avoid ringing artifacts, to the point that it can even become less effective than lossless in some cases.
|
|
2023-04-18 08:36:31
|
There's also the alternative of having a perfect edge deringing tool that also doesn't remove detail 😂
|
|
|
|
Traneptora
|
2023-04-18 08:38:44
|
If the Frames don't fully cover the image canvas, what color will the resulting gaps be?
|
|
2023-04-18 08:39:04
|
will it be all zeroes, or is that undefined behavior?
|
|
|
|
_wb_
|
2023-04-18 08:54:31
|
All zeroes
|
|
2023-04-18 08:54:46
|
So transparent if the image has alpha, or black otherwise
|
|
|
|
Traneptora
|
2023-04-18 08:57:00
|
I don't remember, is this specified?
|
|
2023-04-18 08:57:02
|
if not it should be
|
|
|
|
_wb_
|
2023-04-18 08:59:55
|
I think it is, but I should check to be sure.
|
|
|
|
gb82
|
2023-04-19 04:01:33
|
https://www.reddit.com/r/AV1/comments/12re20c/why_browsers_will_probably_skip_jpegxl_imo/
|
|
2023-04-19 04:01:56
|
Not sure how worth it it is to respond
|
|
|
Demez
|
2023-04-19 04:14:42
|
it misses the fact that JPEG XL can and will improve a lot over time, just like JPEG did, and only talks about AVx improving
|
|
2023-04-19 04:15:59
|
also it mentions webp being improved, but that still uses VP8, so
(edit: nvm that was just a comment that said that)
|
|
|
|
jonnyawsom3
|
2023-04-19 04:59:45
|
I left my take on it anyway, think I managed to stay relatively neutral while still making a case
<https://www.reddit.com/r/AV1/comments/12re20c/comment/jgueg5c/>
|
|
|
|
Demez
|
2023-04-19 05:05:45
|
it also doesn't mention anything about progressive decoding, which i think is a must have for internet image formats, there are plenty of people with bad internet connections, and plenty of dead zones for wireless networks in the worlds, and it's just useful for giant images
|
|
|
|
username
|
2023-04-19 05:19:35
|
I don't have a reddit account to respond in that post however I do have some things to say directed at it
|
|
|
|
jonnyawsom3
|
2023-04-19 05:43:11
|
I just find it amusing they said AV1 could learn from JXL technology when wb mentioned earlier that AV1 was almost part of the base for JXL. Oh how the turns table
|
|
|
|
username
|
2023-04-19 05:46:35
|
I don't understand how AVx/AOM can learn from JXL? feature editions of AVx are not going to have lossless jpeg transcoding or a fully featured lossless side
|
|
2023-04-19 05:46:49
|
AOM are making video codecs not image codecs
|
|
2023-04-19 05:46:58
|
and I don't really see that changing
|
|
2023-04-19 05:51:38
|
and if every like 6 years or so (not exact) browsers just add whatever the next big video codec is then why are images seen in such a different light?
|
|
2023-04-19 05:52:43
|
also some of the things in that post is saying that JXL not having as much limitations as other formats is a bad thing‽‽‽‽‽‽
|
|
2023-04-19 05:54:09
|
why is it a bad thing for something to be future proof‽ why do we keep having to move to something different every decade or a half? it just causes fragmentation
|
|
2023-04-19 06:20:51
|
if the argument in that post is that it's a big thing to support something because that means you have to support it forever and they are also saying that JXL doesn't have enough limitations then aren't those 2 things kinda conflicting? because if something doesn't have that many limitations and is future proof then that means in the future the decision to forever support something else won't come around since the thing added in the past wouldn't have even run into the problems of being too limited to need something new to replace it
|
|
|
|
jonnyawsom3
|
2023-04-19 07:11:10
|
|
|
2023-04-19 07:11:11
|
> it wouldn't make sense because they are so different. But a future version of AVx that uses techniques from JPEG-XL would make sense.
Contradicting themselves in the very next sentence
|
|
2023-04-19 07:16:19
|
I mean, they're not wrong, but I also think they replied to the wrong comment
|
|
|
|
afed
|
2023-04-19 07:23:48
|
I haven't heard that jxl has ever used av1/avif as the main codebase, maybe it's confusing with webp2?
also video based codecs are very different compared to image codecs and a lot of things are not needed for video that are needed for images, so it is doubtful that anything will be improved or taken from jxl specifically for images, maybe just some universal things like xyb
|
|
|
|
jonnyawsom3
|
2023-04-19 07:36:20
|
<https://discord.com/channels/794206087879852103/806898911091753051/1097898825345159228>
|
|
|
|
afed
|
2023-04-19 07:36:20
|
the main point (though in many ways not true) is that video based codecs have no cost to support and add to browsers, and new code is bad and insecure
- also there is hardware support (which is basically useless and not used for static images)
- limits are good because more than avif/webp limits people don't need and it's useless (which is also not true)
- and even if the current codec is no good for images, it will always be improved in av2, av3, av4, etc. and it will be free, just need to put it in a heif container and everyone will get the improvements automatically, etc.
|
|
2023-04-19 07:43:01
|
as far as I can see it is about proposals for jpeg xl as a standard from the jpeg group, which considered a lot of existing and developing/experimental formats, but not for the current jpeg xl as a code or team
|
|
|
|
username
|
2023-04-19 07:46:41
|
for the whole thing about hardware decoding I want bring up that WebP was designed in a way where it could be hardware decoded and it was also based on a a video format which did have hardware decoding support on many gpus (VP8) however no one ever ended up implementing hardware decoding for WebP at all
|
|
|
|
afed
|
2023-04-19 07:56:22
|
yeah, because this has more problems than advantages, hw decoders are designed for frame sequences, not for different static frames
|
|
2023-04-19 08:03:55
|
this is fine for animation or for one giant image, but it also requires extra limitations on the lowest capability of all existing hw decoders, otherwise it will be useless, like not all hw decoders can handle higher resolution or something besides yuv420
|
|
|
|
jonnyawsom3
|
|
afed
as far as I can see it is about proposals for jpeg xl as a standard from the jpeg group, which considered a lot of existing and developing/experimental formats, but not for the current jpeg xl as a code or team
|
|
2023-04-19 08:21:16
|
Yeah, that's my point, it was proposed but rejected
|
|
|
|
gb82
|
2023-04-19 08:25:05
|
Do people not understand that lossy WebP was in many ways inferior to JPEG? Why is it so frequently cited in a way that implies it was in any way a JPEG successor?
|
|
|
|
Traneptora
|
|
gb82
Do people not understand that lossy WebP was in many ways inferior to JPEG? Why is it so frequently cited in a way that implies it was in any way a JPEG successor?
|
|
2023-04-19 08:44:31
|
I think people don't understand that lossy WebP has no real benefits over JPEG with good encoders (e.g. mozjpeg, jpegli)
|
|
2023-04-19 08:44:39
|
It does outperform TurboJPEG in quality/bpp
|
|
2023-04-19 08:45:05
|
I also think people see massively recompressed JPEGs and think that's "what JPEG is"
|
|
|
|
Jyrki Alakuijala
|
|
Traneptora
I think people don't understand that lossy WebP has no real benefits over JPEG with good encoders (e.g. mozjpeg, jpegli)
|
|
2023-04-19 09:05:40
|
in my tests WebP is ok for jpeg quality 75 and below ((but likely similar benefits would have been obtained with JPEG if some filtering would have been added))
|
|
2023-04-19 09:06:29
|
users think that WebP quality 85 is the same as JPEG quality 85, but WebP quality 85 is closer to JPEG quality 80 -- that makes people to unintentionally downgrade the quality
|
|
2023-04-19 09:06:57
|
ideally when a new generation of codecs is applied, part of the savings would go to speeding things up, making the transfer cheaper, and another part would go to quality
|
|
|
|
Traneptora
|
2023-04-19 09:07:05
|
That's consistent with my understanding that video-codec-I-frame-based formats tend to perform better at lower bpp
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:07:17
|
this doesn't seem to be the focus of WebP and AVIF deployments that I have seen so far
|
|
2023-04-19 09:07:51
|
it is "faster, cheaper, but looks a bit worse but no one will notice" ideas
|
|
2023-04-19 09:08:34
|
I personally think we should make the web look much better, not worse -- but many dev advocates people are speaking even about quality 30
|
|
2023-04-19 09:09:10
|
I think they have read image processing books, where the quality refers to adobe photoshop quality -- where quality 30 is about the same as libjpeg quality 85
|
|
|
|
Traneptora
|
2023-04-19 09:09:12
|
I think AVIF proponents who suggest quality-30 and the like are intentionally doing so because it's where AVIF excells in the quality/bpp ratio curve
|
|
2023-04-19 09:09:36
|
I find it less likely that they're doing so because it's adobe-photoshop-quality
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:09:40
|
I think they really do believe that people would benefit from the quality 30 images
|
|
|
|
Traneptora
|
2023-04-19 09:09:55
|
one thing that I have noticed with WebP is that because lossless is essentially just a different codec wrapped together, sometimes sites that "optimize" images sent to them will turn lossless WebPs into lossy WebPs, even if they don't convert PNGs to JPEGs
|
|
2023-04-19 09:10:08
|
which is poor design
|
|
2023-04-19 09:10:17
|
but discord does so for its previews
|
|
|
|
Jyrki Alakuijala
|
|
|
Traneptora
|
2023-04-19 09:10:38
|
if you provide a PNG to discord, it will downsize it for the inline preview but it will still be PNG
|
|
2023-04-19 09:10:45
|
so at the very least you avoid generation loss
|
|
2023-04-19 09:10:53
|
but lossless webps become lossy webp previews
|
|
2023-04-19 09:11:43
|
JPEG XL also has two codecs wrapped in one (although they are more heavily linked than in WebP) so I could potentially see this as an issue in the future
|
|
2023-04-19 09:12:47
|
Especially considering that to determine if lossy encoding techniques were used, you have to use heuristics like "modular mode, not XYB encoded, no squeeze, no delta palette" and guess that means lossless was most likely
|
|
2023-04-19 09:13:19
|
whereas with WebP you just look to see if it's using the lossless mode in the header
|
|
2023-04-19 09:15:18
|
Something I proposed to Jon in the spec is to add a Normative extension that adds some metadata about encoding options used
It would be legal to omit it (like all extensions) but it could in theory allow a parser to immediately determine certain bits of info, like "lossless" without reading any frame header
|
|
2023-04-19 09:15:43
|
especially considering that a Patches frame is usually first, and modular, even if the primary frame is VarDCT
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:16:25
|
WebP lossless can be lossy too aka near-lossless
|
|
2023-04-19 09:17:02
|
Rich Geldreich (from lzham fame) made a lossy PNG encoder with fuzzy LZ77 matching
|
|
|
|
Traneptora
|
2023-04-19 09:17:21
|
Isn't that pre-filtered lossless though? like there's no lossy coding techniques used in WebP lossless
|
|
2023-04-19 09:17:52
|
it's just image data is filtered before lossless compression, unless I misunderstand
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:18:08
|
it is adaptive quantization
|
|
2023-04-19 09:18:45
|
if the monotonicity is not changed and the surroundings have certain characteristics, then we quantize more there
|
|
|
|
Traneptora
|
2023-04-19 09:19:05
|
I see, and sometimes that quant might change a pixel value?
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:19:11
|
it is implemented as a pre-filter at least for non-spatially-predicted values
|
|
2023-04-19 09:19:22
|
it definitely changes pixel values
|
|
2023-04-19 09:19:50
|
IIRC --near_lossless 80 can change +- 1, 60 +- 2, 40 +-4 etc.
|
|
2023-04-19 09:20:06
|
or perhaps by 2* more for each bucket
|
|
|
|
Traneptora
|
2023-04-19 09:20:10
|
I meant more like, mathematically you're just essentially quantizing values enough that it no longer rounds to the same integer
|
|
2023-04-19 09:20:35
|
I suppose that's basically just lossy coding techniques, even if implementation is a pre-filter
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:20:39
|
it is to create less entropy
|
|
|
|
Traneptora
|
2023-04-19 09:20:40
|
and not as part of the codec
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:20:56
|
the quantization decisions are tied to the encoding decisions
|
|
2023-04-19 09:21:04
|
most importantly spatial prediction
|
|
2023-04-19 09:21:15
|
it is tricky to implement and we haven't done the same for jpeg xl yet
|
|
2023-04-19 09:21:38
|
try to compress a photograph with cwebp -near_lossless 60
|
|
|
|
Traneptora
|
2023-04-19 09:22:01
|
but it sounds like you're saying that WebP lossless isn't really "lossless mode" and more accurate to compare it to something like JXL modular, which can do lossless but you can also discard data on encode (e.g. squeeze residuals)
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:23:10
|
near lossless produces a file that is indistinguishable from true lossless
|
|
2023-04-19 09:23:24
|
no hint is left there in any bits that loss was made
|
|
2023-04-19 09:23:42
|
one can guess it from the entropy in residuals (or entropy in general in direct mode too)
|
|
2023-04-19 09:23:55
|
it only changes things if there are more than 256 colors
|
|
|
|
Traneptora
|
2023-04-19 09:24:11
|
I wonder if the hybrid uints could be used for JXL with "near-lossless" modular
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:24:43
|
that could work
|
|
|
|
Traneptora
|
2023-04-19 09:24:53
|
i.e. much of the entropy is in the lower-order-bits residuals
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:25:08
|
indeed
|
|
|
|
Traneptora
|
2023-04-19 09:25:11
|
so they could be a good heuristic to discard
|
|
2023-04-19 09:25:13
|
just a thought
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:25:21
|
that's how near lossless works
|
|
2023-04-19 09:25:44
|
by avoiding residuals of -1,+1,-2,+2,-3,+3, ... up to a limit
|
|
|
|
Traneptora
|
2023-04-19 09:25:48
|
makes sense
|
|
|
|
veluca
|
2023-04-19 09:25:58
|
jxl has better ways to do modular lossless
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:26:01
|
but avoiding them only where there is enough noise otherwise so that the diff cannot be seen
|
|
|
|
veluca
|
2023-04-19 09:26:29
|
you can just straight up multiply/divide residuals by any number you want, among other things
|
|
2023-04-19 09:26:35
|
(but only in some cases)
|
|
2023-04-19 09:26:56
|
nobody knows how to write an optimal encoder for that though 😛
|
|
|
|
Traneptora
|
2023-04-19 09:27:22
|
does libjxl use mul_log or mul_bits at all?
|
|
2023-04-19 09:27:32
|
or does it simply set them all to 0 or 1
|
|
|
Jyrki Alakuijala
but avoiding them only where there is enough noise otherwise so that the diff cannot be seen
|
|
2023-04-19 09:29:40
|
this is sort of the heuristic i implemented for Hydrium, where I look at the highest-frequency DCT coefficients
|
|
2023-04-19 09:29:54
|
and if they're small then I quantize more via HFMult
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:30:43
|
psychovisual optimizations can be complex
|
|
|
|
Traneptora
|
2023-04-19 09:31:10
|
Yea, I don't do anything really psychovisual beyond working in XYB-space
|
|
2023-04-19 09:31:38
|
I could definitely improve quality via some simple heuristics, but I have other higher priority things to handle tbh like stability
|
|
2023-04-19 09:31:58
|
and configurability (options!)
|
|
|
|
Jyrki Alakuijala
|
2023-04-19 09:33:15
|
adaptive quantization, ar control field, ac strategy, patches, dithering in dct coefficients, dead zone quantization, chroma from luma ... all are linked in nasty ways from the optimization viewpoint
|
|
|
|
veluca
|
|
Traneptora
does libjxl use mul_log or mul_bits at all?
|
|
2023-04-19 09:41:52
|
they're used for squeeze
|
|
|
|
Traneptora
|
2023-04-19 09:43:11
|
ah, okay
|
|
|
|
_wb_
|
2023-04-19 10:41:42
|
Avif was not really rejected. Actually the conclusion of the 81st JPEG meeting was that AVIF could be a good starting point for JXL. Pik, fuif and avif were considered the 3 best proposals. The idea was to then start a collaborative phase where the best elements of the proposals would be combined. However, when it became clear that JPEG was not just going to take AVIF and rubberstamp it into JPEG XL without changes, the AVIF proposal was retracted, since they weren't prepared to make any changes to the actual bitstream (which makes sense, av1 hardware was already designed at this point...)
|
|
|
Yeah, that's my point, it was proposed but rejected
|
|
2023-04-19 10:42:25
|
(this was a reply to this)
|
|
2023-04-19 10:45:25
|
Basically AOM came to JPEG looking for a rubberstamping like JPEG had done earlier with JPEG XR (which is just a rubberstamping of Microsoft's WDP/HD Photo format), but JPEG had learned from jxr and didn't want to repeat that mistake, and that's more or less how that ended. At least that's how I interpret how things went, in retrospect.
|
|
|
Traneptora
but it sounds like you're saying that WebP lossless isn't really "lossless mode" and more accurate to compare it to something like JXL modular, which can do lossless but you can also discard data on encode (e.g. squeeze residuals)
|
|
2023-04-19 10:52:44
|
I think this is the case for any lossless format. PNG also gets used in lossy ways (like pngquant or pngblur).
|
|
2023-04-19 10:57:01
|
In general, I think the main important thing is that the encoder should use appropriate techniques (dct, lossless, near-lossless) when given pixel input. Making special transcoding tools will only solve things for applications that use those tools, but that requires special code paths and is unlikely to happen in practice.
|
|
2023-04-19 10:59:49
|
Images can also be composites where some regions are photographic and benefit from dct while others are e.g. text overlays that benefit from lossless techniques. Doing these with layers or patches to mix vardct and modular mode is a good idea (but not trivial, libjxl currently only does it in a quite limited way)
|
|
|
Traneptora
does libjxl use mul_log or mul_bits at all?
|
|
2023-04-19 11:03:46
|
Currently it only uses that to quantize squeeze residuals when doing lossy modular. It could definitely make sense to have different lossy modular modes that use it without squeeze, e.g. with a tree where if abs(WGH) is small it doesn't quantize (so smooth regions remain fine) while if it is large it quantizes residuals (so busy regions are lossy, but you likely cannot tell anyway), or something like that.
|
|
|
|
Traneptora
|
2023-04-19 11:04:18
|
that makes sense
|
|
|
|
veluca
|
2023-04-19 11:06:42
|
could also do that for N-W or something like that for something fast to decode
|
|
|
skalt711#4276
|
2023-04-19 01:47:34
|
Can JPEG XL work as an all-around replacement for PNG, JPEG, TIFF and possibly other formats I haven't heard about for high quality pictures?
|
|
|
|
username
|
2023-04-19 01:48:17
|
for the most part yes!
|
|
2023-04-19 01:48:45
|
although TIFF is a bit of a weird format so I can't comment fully on that
|
|
|
|
skalt711#4276
|
2023-04-19 01:49:50
|
TIFF always sounded a bit mysterious for me
|
|
|
|
username
|
2023-04-19 01:50:23
|
but for both PNG and JPEG (along with some other formats) JPEG XL works as a complete replacement that surpasses them in features, quality and file size.
|
|