|
fab
|
2021-07-18 11:47:51
|
this is great maybe it will confuse you with what you're doing
|
|
2021-07-18 11:47:59
|
but i gave screenshot
|
|
2021-07-18 11:48:30
|
https://discord.com/channels/794206087879852103/806898911091753051/866257963002101780
|
|
2021-07-18 11:48:55
|
anyway it has less generation loss i think
|
|
2021-07-18 11:49:00
|
is a different format
|
|
|
Jyrki Alakuijala
|
|
Scope
I think modular at low quality requires some sort of smoothing or upscaling to avoid very noticeable pixelization
|
|
2021-07-18 11:49:41
|
I don't think it is feasible to smooth modular correctly since that would require knowing what the resolution is at that stage, and the final resolution can be variable -- squeeze does interpolate, but is not a fine quality upsampler
|
|
|
fab
https://discord.com/channels/794206087879852103/806898911091753051/866257963002101780
|
|
2021-07-18 11:51:48
|
this link just brings me to the off-topic area -- what should I look for
|
|
|
|
fab
|
2021-07-18 11:52:06
|
original webp
1,13 MB (1.195.486 byte)
re encoded webp
980 KB (1.003.554 byte)
|
|
2021-07-18 11:52:30
|
plus the screenshot i posted in <#794206170445119489> with pingo build
|
|
2021-07-18 11:52:40
|
i use it from there
|
|
2021-07-18 11:52:41
|
https://css-ig.net/pingo
|
|
|
Scope
|
|
Jyrki Alakuijala
I don't think it is feasible to smooth modular correctly since that would require knowing what the resolution is at that stage, and the final resolution can be variable -- squeeze does interpolate, but is not a fine quality upsampler
|
|
2021-07-18 11:55:50
|
Or something else (although I don't know what else can be done), because for some images modular may look better, in addition it has better image preservation accuracy or if looking from a distance, but its problem is very noticeable pixelization
|
|
2021-07-18 12:09:04
|
And `--resampling' often looks very blurry, it might be a good idea to find some balance to add more sharpness, at the same time video-based formats like AVIF usually have better visual quality/sharpness in high resolution than its downscaled version
|
|
|
|
fab
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:28:19
|
I experience that AVIF removes middle frequencies before highest and lowest, this is often ok, but sometimes not great -- I consider it different, not just better
|
|
2021-07-18 12:29:23
|
my belief from following people near-by how they do image quality work is that some people (5-10 %) see images like they were median blurred
|
|
2021-07-18 12:30:25
|
for such people, spending bits in texture quality is a waste of bits (WebP look is already just perfect)
|
|
|
Scope
Or something else (although I don't know what else can be done), because for some images modular may look better, in addition it has better image preservation accuracy or if looking from a distance, but its problem is very noticeable pixelization
|
|
2021-07-18 12:31:21
|
I think it is a great idea.
|
|
2021-07-18 12:35:21
|
a problem that remains in that is the lack of geometric interpolation
|
|
2021-07-18 12:36:32
|
what I observe with larger transforms in low bpp is that VarDCT allows choosing between (sharpness, no texture synthesis, and no ringing) and (interpolation of geometry, texture synthesis, and ringing) differently in different areas
|
|
2021-07-18 12:37:06
|
usually 16x16 upwards and particularly 32x32 gives a completely different possibilities to interpolate geometry than smaller transforms
|
|
2021-07-18 12:37:17
|
squeeze is a small transform
|
|
2021-07-18 12:37:56
|
any practical interpolation on it would also have a small support I believe, creating difficulty in interpolation of geometry
|
|
|
_wb_
|
2021-07-18 12:38:11
|
Likely --resampling 2 does a better 2x upscaling than Modular Squeeze with basically the final residuals quantized completely to zeroes. Modular might be better if those final residuals are not completely quantized away.
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:38:25
|
if we could have resampling 1.5 🙂
|
|
2021-07-18 12:38:57
|
AVIF has built in resamplings of 4/3 or something like that
|
|
|
|
_wb_
|
2021-07-18 12:39:24
|
Well we do have the "intrinsic dimensions" header field
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:39:25
|
of course for web use there is a lot of freedom, but there is no culture of the encoder to decide on the density
|
|
2021-07-18 12:40:02
|
in our pik jpeg xl competition entry we tried to get to lower bpp by 2x subsampling to lowest bpp
|
|
2021-07-18 12:40:14
|
it is a double-edged sword
|
|
2021-07-18 12:40:48
|
because of the contrast sensitivity function it is not going to be just forgetting the highest frequencies and getting 4x better otherwise
|
|
2021-07-18 12:41:08
|
perhaps it only gets 1.7x better otherwise
|
|
|
|
_wb_
|
2021-07-18 12:41:12
|
We haven't defined how to go from bitstream dimensions to the signalled intrinsic dimensions (idea being that browsers/viewers just use whatever they would normally do, e.g. in the case of Exif-resolution-based intrinsic dimensions)
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:41:13
|
or 2.5x
|
|
|
|
_wb_
|
2021-07-18 12:41:43
|
But we could pull the logic to libjxl and let it output images at intrinsic dimensions
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:41:53
|
that would make sense
|
|
|
|
_wb_
|
2021-07-18 12:42:03
|
With whatever resampling method we want
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:42:16
|
also, with 2x, every block becomes 2x in size, i.e., ringing artefacts propagate further
|
|
2021-07-18 12:42:32
|
if you compensate that by halfing the integral transform size, then that reduces the gains further
|
|
2021-07-18 12:42:48
|
... and you lose the highest frequencies for sure, no matter how high the amplitude
|
|
|
|
_wb_
|
2021-07-18 12:43:02
|
Can also do things like nonsquare pixels
|
|
|
|
veluca
|
2021-07-18 12:43:53
|
resampling + noise can help already
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
Can also do things like nonsquare pixels
|
|
2021-07-18 12:44:06
|
penrose tiling 🙂
|
|
|
|
_wb_
|
2021-07-18 12:44:11
|
Intrinsic dimensions can be used to do arbitrary resampling both horizontally and vertically
|
|
|
Jyrki Alakuijala
penrose tiling 🙂
|
|
2021-07-18 12:44:28
|
They still need to be rectangular :)
|
|
|
|
veluca
|
2021-07-18 12:44:46
|
but I suspect the best gains from resampling need some really fancy neural-like encoder
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:46:13
|
there would be ways to improve it with more simple approaches, too
|
|
2021-07-18 12:46:28
|
but of course neural is a great option
|
|
2021-07-18 12:47:10
|
like the non-separable we already have -- I know how to improve it further from pik experiments
|
|
|
|
_wb_
|
2021-07-18 12:47:23
|
But can have 3:2 pixel aspect ratio or whatever. We just haven't defined a normative scaling method to go from bitstream pixel dimensions to signalled intrinsic dimensions (mostly to leave freedom to do better things than something generic like some specific bicubic, and to leave room to do it in XYB, linear RGB or nonlinear RGB).
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:47:30
|
by running three iterations of adjustments
|
|
|
|
_wb_
|
2021-07-18 12:48:09
|
I think we currently ignore the intrinsic dimensions header in chrome, that's not good
|
|
|
|
Jyrki Alakuijala
|
2021-07-18 12:48:15
|
that is 15x slower than what we have now, but still 100x less computation than a neural approach
|
|
2021-07-18 12:48:21
|
do we have a bug on that?
|
|
|
|
_wb_
|
2021-07-18 12:49:29
|
I dunno, I don't think so. It's in the todo list for part 3 to add a test case with intrinsic dimensions, so it will not be forgotten, but maybe it should be prioritized a bit
|
|
|
|
veluca
|
2021-07-18 12:49:31
|
I don't mean neural upscalers, I mean neural encoders for the current --upsample option
|
|
|
|
_wb_
|
2021-07-18 12:49:53
|
Neural downscalers?
|
|
|
|
veluca
|
2021-07-18 12:50:57
|
nah, something that splits the image in a "to be downscaled" image and another full res one
|
|
|
|
_wb_
|
2021-07-18 12:52:08
|
Ah
|
|
2021-07-18 12:54:46
|
I think neural is most useful to make choices based on saliency (what's the semantically most important region, where people will look so where we need to get the best fidelity), while if you just want to aim for uniform fidelity (doing the sky as accurately as the face), classical approaches like butteraugli that model the human visual system well are good enough.
|
|
|
|
veluca
|
2021-07-18 12:56:48
|
eh, I'm not quite sure how to figure out where exactly you'd need non-downscaled
|
|
|
|
_wb_
|
2021-07-18 12:56:58
|
I think in the past there has been some mixing of these concepts, where something like "contrast masking" meant both something related to fidelity ("you cannot see distortions in the bushes") and something related to appeal ("you don't care about distortions in the bushes")
|
|
|
|
veluca
|
2021-07-18 12:57:22
|
I guess butteraugli can figure it out somewhat (possibly even simiple XYB K-norm distance)
|
|
|
|
fab
|
2021-07-18 05:48:43
|
is it allowed to post webp screenshot with pingo v0.99.2 auto in <#794206170445119489>
|
|
2021-07-18 05:48:55
|
lossy ones
|
|
|
diskorduser
|
2021-07-18 05:53:51
|
Why not post in benchmark or other codecs?
|
|
|
|
fab
|
2021-07-18 05:55:09
|
because why interrupt flow
|
|
2021-07-18 05:55:25
|
i posted in every channel possible both in jpeg xl and av1
|
|
2021-07-18 05:55:39
|
off topic is bad
|
|
2021-07-18 05:56:01
|
i guess other codecs could be better/good
|
|
|
|
_wb_
|
2021-07-18 06:27:37
|
Pingo is other codecs
|
|
|
|
fab
|
2021-07-18 07:05:36
|
ok wb decided
|
|
|
|
Deleted User
|
|
fab
i posted in every channel possible both in jpeg xl and av1
|
|
2021-07-18 09:48:54
|
Quite surprising that you are still around. ;)
|
|
|
|
Jyrki Alakuijala
|
2021-07-19 11:17:09
|
I like the change from --noise 1 to --photon_noise=ISO250
|
|
2021-07-19 11:17:38
|
Thank you Matt for taking a supporting position on this 🙂
|
|
|
|
Deleted User
|
2021-07-19 12:57:35
|
I would happily switch to --uniform_noise or --triangular_noise though. 😁
|
|
|
|
fab
|
2021-07-20 09:41:57
|
ah the build jamaika released were no SIMD
|
|
2021-07-20 09:54:15
|
also latest 18072021 you need to execute a bat file and there is no information about the commits as always
|
|
|
eclipseo
|
2021-07-20 10:37:06
|
<@!532010383041363969> Your work on ringing is impressive https://eclipseo.github.io/image-comparison-web/#air-force-academy-chapel*3:1&JXL_0.3.7=s&JXL_20210715=s&subset1
|
|
|
|
Jyrki Alakuijala
|
|
eclipseo
<@!532010383041363969> Your work on ringing is impressive https://eclipseo.github.io/image-comparison-web/#air-force-academy-chapel*3:1&JXL_0.3.7=s&JXL_20210715=s&subset1
|
|
2021-07-20 11:25:30
|
Thank you! Your test page is inspiring!
|
|
2021-07-20 11:26:38
|
Any thoughts on adding portraits of people (including people of color) into your test set? Many of the images are selfies or other kind of pictures of people.
|
|
2021-07-20 11:28:32
|
Currently there are some pictures already like the 'end of show' and 'expo', but only end of show has black people and they are far away and blurry in the original, too, not representative of the selfie/portrait quality achievable with modern mobile phones.
|
|
|
|
fab
|
|
eclipseo
<@!532010383041363969> Your work on ringing is impressive https://eclipseo.github.io/image-comparison-web/#air-force-academy-chapel*3:1&JXL_0.3.7=s&JXL_20210715=s&subset1
|
|
2021-07-20 11:33:05
|
can you have add 0.99.2
|
|
2021-07-20 11:33:45
|
webp
|
|
2021-07-20 11:33:55
|
|
|
2021-07-20 11:34:01
|
this not the 0.99.3
|
|
2021-07-20 11:35:33
|
or better add
|
|
2021-07-20 11:35:38
|
https://css-ig.net/pingo
|
|
2021-07-20 11:35:41
|
0.99.3
|
|
2021-07-20 11:35:44
|
webp
|
|
2021-07-20 12:13:21
|
what is the downsampled resolution?
|
|
2021-07-20 12:22:50
|
maybe with next version 0.99.4 you can add
|
|
2021-07-20 12:22:54
|
in lossy
|
|
2021-07-20 12:23:09
|
if all bpp also works
|
|
|
|
Jyrki Alakuijala
|
2021-07-20 01:57:01
|
webp near-lossless?
|
|
2021-07-20 01:57:12
|
❤️ webp near-lossless ❤️
|
|
|
|
fab
|
2021-07-20 03:22:20
|
are news about jxl
|
|
2021-07-20 05:53:24
|
|
|
2021-07-20 05:58:08
|
|
|
|
|
diskorduser
|
2021-07-20 05:59:49
|
??? What are you trying to ....
|
|
|
|
fab
|
2021-07-20 06:00:56
|
Comparing appeal of eclipse github
|
|
2021-07-20 06:01:04
|
https://discord.com/channels/794206087879852103/794206170445119489/866992109936705596
|
|
2021-07-20 06:01:17
|
the right is better to me
|
|
2021-07-20 06:01:22
|
in both the two
|
|
|
improver
|
2021-07-20 06:02:51
|
also needs more anime in that test set :^)
|
|
|
|
fab
|
2021-07-20 06:02:53
|
|
|
2021-07-20 06:09:16
|
|
|
2021-07-20 06:09:55
|
there are the issues i find otherwise appeal is ok
|
|
2021-07-20 06:10:12
|
aom 15072021 is always good at big
|
|
2021-07-20 06:10:33
|
even if lacks a bit of sharpness
|
|
2021-07-20 06:10:51
|
i posted the less sharper image
|
|
|
|
eclipseo
|
|
improver
also needs more anime in that test set :^)
|
|
2021-07-20 06:10:58
|
i would add more stuff but i'm already above the limit of github pages space
|
|
|
|
_wb_
|
|
fab
|
|
2021-07-20 06:12:48
|
You have to stop seeing encoders as image enhancers / denoisers. That's not their job. Preserving the original image is their job.
|
|
|
|
fab
|
2021-07-20 06:13:09
|
so the samples i posted are horrible
|
|
|
_wb_
You have to stop seeing encoders as image enhancers / denoisers. That's not their job. Preserving the original image is their job.
|
|
2021-07-20 06:14:17
|
ok
|
|
|
|
_wb_
|
2021-07-20 06:14:24
|
I dunno, but if you like the 0.66 bpp image more than the 1.75 bpp image, then you probably also like it better than the original
|
|
|
|
fab
|
2021-07-20 06:16:11
|
yes you refer to the second
|
|
2021-07-20 06:35:13
|
|
|
2021-07-20 06:35:59
|
real detail like wb said i struggle to see it
|
|
2021-07-20 06:36:11
|
even if i'm a bit trained
|
|
|
|
Jyrki Alakuijala
|
|
fab
so the samples i posted are horrible
|
|
2021-07-20 06:40:39
|
Consider comparing images using the same bpp like most of us are doing
|
|
|
|
_wb_
|
2021-07-21 07:34:11
|
|
|
2021-07-21 07:37:52
|
That's a fuif/jxl patent Cloudinary is granting irrevocably and royalty free to anyone who is not patent-trolling.
|
|
|
|
improver
|
2021-07-21 08:10:32
|
> anyone who is not patent-trolling
does it actually have that limitation or what do you mean
|
|
|
|
_wb_
|
2021-07-21 08:18:23
|
Yes, it's the Apache 2.0 defensive clause
|
|
2021-07-21 08:18:43
|
https://github.com/libjxl/libjxl/blob/main/PATENTS
|
|
2021-07-21 08:19:38
|
Here it says Google because Google is administrating the CLAs including Cloudinary's
|
|
2021-07-21 08:20:44
|
```
If you or your agent or exclusive licensee institute or
order or agree to the institution of patent litigation against any
entity (including a cross-claim or counterclaim in a lawsuit) alleging
that this implementation of JPEG XL or any code incorporated within this
implementation of JPEG XL constitutes direct or contributory patent
infringement, or inducement of patent infringement, then any patent
rights granted to you under this License for this implementation of JPEG XL
shall terminate as of the date such litigation is filed.
```
|
|
2021-07-21 08:23:21
|
So basically if a patent troll makes some claim and starts litigation claiming people have to pay them to use JPEG XL, then this defensive clause kicks in and takes the patent license away from such trolls, so they cannot use JPEG XL themselves.
|
|
2021-07-21 08:24:29
|
Unfortunately this defensive tactic only works against trolls that want to use jxl themselves; the worst trolls don't actually use anything and are just a company made out of lawyers.
|
|
|
|
improver
|
2021-07-21 08:59:54
|
ah I see. but that's a clause relevant only for reference implementation, not the patent
|
|
2021-07-21 09:00:15
|
that's why I was a bit confused
|
|
2021-07-21 09:02:00
|
clean alternative implementations would still get patent grant, but without patent trolling limitation, if they so desire, correct?
|
|
|
|
_wb_
|
2021-07-21 09:44:00
|
Of course
|
|
2021-07-21 09:44:34
|
Well
|
|
2021-07-21 09:44:47
|
Patents are not on implementations but on ideas
|
|
2021-07-21 09:45:31
|
So any implementation needs the patent grant (and the grant applies to any implementation, not just libjxl)
|
|
2021-07-21 09:46:32
|
And if a patent troll claims you need to pay them for jxl, it will also apply to all implementations that use that idea
|
|
2021-07-21 09:48:58
|
So that's why we have defensive patents which we grant royalty-free to anyone except those who are trying to make jxl non-royalty-free
|
|
2021-07-21 09:53:55
|
So if company X manufactures a fancy device Y that uses jxl, and they then claim they have patents on jxl that would mean libjxl cannot be used without paying them, then we (Google and Cloudinary) don't license our patents related to jxl to them, meaning they cannot legally sell device Y anymore. As long as they play nice and don't make bogus patent claims, everything is fine, but if they try to play the patent troll game, they cannot do it. That's the purpose of these defensive patents.
|
|
|
|
improver
|
2021-07-21 10:02:21
|
> then we (Google and Cloudinary) don't license our patents related to jxl to them
how this licensing works?
|
|
2021-07-21 10:07:02
|
I'm thinking of this from 3rd party independent from reference libjxl implementation. Are patents automatically granted for everyone who simply doesn't claim their own patents on jxl? If so, is there explicit text somewhere in patent for this? If they have new ideas for jxl encoder, what can be patentable, and implement them in their own implementation only, are they allowed to claim patent, and is there limitations of kind of patents what they can claim (eg do they need to make it royalty free?)
|
|
2021-07-21 10:18:26
|
reading PATENTS in libjxl repo, it only mentions "this implementation", and explicitly states that "This grant does not include claims that would be infringed only as a consequence of further modification of this implementation."
|
|
2021-07-21 10:21:02
|
so I guess it gives you no rights to patents from anyone for ideas what aren't committed in main repo, which makes sense. but then, how about independent 3rd party implementations?
|
|
2021-07-21 10:23:12
|
like if I just snatched standard from z-lib and wrote clear state decoder, do I need to get into patent grant mess now? or can I just replicate license/patents from libjxl repo and pretend that it's somehow derived from reference implementation?
|
|
|
|
_wb_
|
2021-07-21 10:41:48
|
I think we may need to ask the lawyers to write some statement that is broader than "this implementation", the idea is that any implementation gets a royalty-free license to whatever patents are needed to do the things libjxl does
|
|
2021-07-21 10:42:38
|
If you want to fork it into a proprietary encoder that does stuff you patented, in principle you can
|
|
2021-07-21 10:43:01
|
If you want to make a proprietary implementation that does stuff you patented, you can too
|
|
2021-07-21 10:44:19
|
It's just if you claim that your patents also cover things in libjxl and you start litigating that those defensive clauses kick in
|
|
2021-07-21 10:47:41
|
I am not sure if the current patent statement accomplishes that, I am not a lawyer
|
|
2021-07-21 10:49:23
|
But it should at least protect libjxl from becoming non-royalty-free
|
|
|
|
improver
|
2021-07-21 10:57:06
|
anyway, is the patent you screencapped earlier royalty-free? is there a link where I can read it in full?
|
|
2021-07-21 11:04:06
|
not a lawyer either, doesn't seem that that patent contains anything about royalties or grants which kinda makes sense
|
|
|
|
veluca
|
2021-07-21 11:07:49
|
IIRC patents don't contain statements about grants
|
|
|
|
improver
|
2021-07-21 11:12:44
|
yeah. but then right now nothing really grants patent license for 3rd party implementations (even if intent is to, text in repository doesn't state that)
|
|
|
|
_wb_
|
2021-07-21 11:19:08
|
The text in the repository can be interpreted as granting a patent license to anything in libjxl regardless of whether you use libjxl or some other implementatio
|
|
2021-07-21 11:19:22
|
But it would be good to make that a bit more clear
|
|
2021-07-21 11:21:13
|
I suppose every time Cloudinary says jxl is royalty-free is also evidence that they are granting a royalty-free license, even if it is only said in something like a blogpost on the Cloudinary website and not in a formal, lawyer-approved statement
|
|
|
|
veluca
|
2021-07-21 11:25:59
|
there's the Type 1 declaration at ISO but IDK how formal that is
|
|
|
|
_wb_
|
2021-07-21 11:38:56
|
I dunno how publicly visible it is, and I think legally it is only a declaration of intent, not an actual license grant
|
|
|
|
veluca
|
2021-07-21 01:02:14
|
it *is* public (perhaps once the standard is actually out though)
|
|
|
|
_wb_
|
2021-07-21 01:15:19
|
looks like IEC has a public patent search thing, but ISO puts it behind a login screen
|
|
2021-07-21 01:15:21
|
https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/16231513/2020-07-05_Cloudinary_Ltd_18181-1.pdf?nodeid=21638255&vernum=-2
|
|
2021-07-21 01:15:30
|
I can see that, but I suppose non-ISO-members cannot
|
|
|
|
fab
|
2021-07-21 04:48:24
|
Please new windows build jxl
|
|
2021-07-22 07:33:52
|
please upload new build
|
|
|
|
improver
|
2021-07-22 07:48:15
|
please don't upload new build. or hide it from Fabian
|
|
|
yurume
|
2021-07-22 09:13:38
|
or upload a fresh build of old commits (which is technically a new build)
|
|
|
|
Scope
|
2021-07-22 09:58:05
|
I think this pull request needs to be prioritized because a lot of people are asking for something like official and more frequent Windows builds
https://github.com/libjxl/libjxl/pull/12
|
|
|
|
fab
|
2021-07-22 10:07:19
|
https://github.com/libjxl/libjxl/pull/339
|
|
2021-07-22 10:07:21
|
isn't this
|
|
|
|
Scope
|
2021-07-22 10:11:10
|
No, it's the Chinese localization
|
|
|
|
fab
|
2021-07-22 11:22:42
|
maybe i didn't understand the title of the pull requests
|
|
|
Sauerstoffdioxid
|
2021-07-22 11:24:29
|
I think that pr is about build testing when building it yourself, and not about actually doing automatic builds
|
|
|
|
improver
|
|
_wb_
https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/16231513/2020-07-05_Cloudinary_Ltd_18181-1.pdf?nodeid=21638255&vernum=-2
|
|
2021-07-22 12:08:29
|
opened just fine here
|
|
|
|
_wb_
|
2021-07-22 12:20:49
|
Ah cool
|
|
2021-07-22 12:21:54
|
To find it, I had to login to the ISO system, but I guess the url for that pdf itself is just public
|
|
|
Troc
|
2021-07-22 09:08:20
|
JXL files really seem to mess up Windows 11 explorer.
|
|
|
|
improver
|
2021-07-22 09:11:32
|
how so
|
|
|
|
Troc
|
2021-07-22 09:14:38
|
When I open a folder with jxl files in it, all icons become white and if I click around too much, explorer crashes.
|
|
|
|
improver
|
2021-07-22 09:57:30
|
interesting. why would that happen. do they have some sort of jxl support but "not quite"?
|
|
|
|
fab
|
2021-07-23 06:21:55
|
no he installed jxl win thumb, edit of the registry
|
|
|
|
diskorduser
|
2021-07-23 07:33:02
|
So jxl thumb DLL is missing or incompatible with w11.
|
|
|
|
fab
|
2021-07-23 07:39:45
|
better jxl should be integrated in windows photos and microsoft paint for windows 11 obviously
|
|
2021-07-23 07:39:54
|
not in unknown softwares nobody uses
|
|
2021-07-23 07:44:01
|
i think at least libjxl should be 0.6.0 for that
|
|
2021-07-23 07:44:08
|
the apng png don't work at all
|
|
2021-07-23 07:44:16
|
the behaviour is unexpected
|
|
2021-07-23 07:44:22
|
and sometimes nothing
|
|
2021-07-23 07:45:15
|
if you decode to .apng you’ll get error
if you decode to .png you will not get the original animated png whom embedded the apng
but a PNG IMAGE SEQUENCE 0001.PNG 0002.PNG
ETC
|
|
2021-07-23 07:45:52
|
at least fix it in imagemagick
|
|
2021-07-23 07:45:59
|
then in cjxl
|
|
|
|
diskorduser
|
2021-07-23 07:46:25
|
Are you trying to say apng to jxl doesn't work?
|
|
|
|
fab
|
2021-07-23 07:46:48
|
also
|
|
2021-07-23 07:46:51
|
yes
|
|
2021-07-23 07:47:09
|
that it didn't worked in any way
|
|
2021-07-23 07:47:15
|
the extension needs to be png
|
|
2021-07-23 07:47:35
|
..........
|
|
2021-07-23 07:48:20
|
you should specify what you are doing in release, what is the specific changelog
|
|
2021-07-23 07:48:27
|
like they did before
|
|
2021-07-23 07:48:45
|
like better apng support
|
|
2021-07-23 07:49:01
|
even if cjxl is not an image processing tool but only an encoder
|
|
|
|
diskorduser
|
2021-07-23 07:52:26
|
Hmm. I get error.
`cjxl Animated_PNG_example_bouncing_beach_ball.png animated.jxl
JPEG XL encoder v0.3.7 [Neon]
Failed to read image Animated_PNG_example_bouncing_beach_ball.png.`
|
|
|
|
fab
|
2021-07-23 08:01:37
|
with animated png and png extension you can also get error with 13072021 build, not sure if with 0.5.0 AT LEAST THIS got fixed
|
|
|
|
diskorduser
|
2021-07-23 08:20:52
|
Ok i will check with newer builds
|
|
|
|
fab
|
2021-07-23 08:26:16
|
check first animated png with .png extension
|
|
|
|
diskorduser
|
2021-07-23 08:27:08
|
I got the animated png from Wikipedia. It plays well.
|
|
2021-07-23 08:27:18
|
`cjxl Animated_PNG_example_bouncing_beach_ball.png animated.jxl
JPEG XL encoder v0.5.0 [Neon]
Failed to read image Animated_PNG_example_bouncing_beach_ball.png.`
|
|
2021-07-23 08:27:47
|
|
|
|
|
fab
|
2021-07-23 08:29:05
|
which commit
|
|
|
|
diskorduser
|
|
|
fab
|
2021-07-23 08:29:24
|
from what date?
|
|
|
|
diskorduser
|
2021-07-23 08:29:28
|
Now
|
|
2021-07-23 08:32:21
|
0a111d10c47776a5bd01219040838ef435929806
|
|
|
|
_wb_
|
2021-07-23 08:43:58
|
Did you compile with libpng?
|
|
|
|
fab
|
2021-07-23 08:45:30
|
i downloaded jamaika build at that time
|
|
2021-07-23 08:45:34
|
so it can be that
|
|
2021-07-23 08:45:40
|
not compiled mself
|
|
|
|
_wb_
|
2021-07-23 08:47:08
|
I suppose windows builds don't typically compile with libpng, and then apng input does not work
|
|
2021-07-23 08:47:33
|
Apng output is not implemented atm, so that doesn't work for anyone
|
|
|
|
fab
|
2021-07-23 08:50:48
|
thanks for reading all
|
|
|
|
diskorduser
|
|
_wb_
Did you compile with libpng?
|
|
2021-07-23 10:03:18
|
For animated it requires libpng but for normal pngs it doesn't need. Right?
|
|
|
|
yurume
|
2021-07-23 10:12:17
|
is cjxl able to combine multiple images into an animated image, as opposed to the APNG input?
|
|
|
|
_wb_
|
2021-07-23 10:13:12
|
No, not atm
|
|
2021-07-23 10:14:03
|
Shouldn't be hard to add such things, it's just annoying plumbing because you then also have to specify durations etc
|
|
|
|
yurume
|
2021-07-23 10:16:08
|
indeed
|
|
2021-07-23 10:17:17
|
as a CLI user I've noticed some corners which I may try to polish at my spare time
|
|
|
|
Deleted User
|
|
_wb_
Shouldn't be hard to add such things, it's just annoying plumbing because you then also have to specify durations etc
|
|
2021-07-23 10:31:38
|
Can't you just copy & paste the parameter handling from FLIF?
|
|
|
|
_wb_
|
2021-07-23 10:33:58
|
FLIF has different internal representations of images, and does argument parsing differently. Easier to do it from scratch...
|
|
|
yurume
as a CLI user I've noticed some corners which I may try to polish at my spare time
|
|
2021-07-23 10:34:58
|
If you have time, feel free to add support for animation in the lodepng code path
|
|
2021-07-23 10:36:56
|
That way you can get apng input without the libpng dependency, will be easier in windows
|
|
2021-07-23 10:37:06
|
And maybe can also do apng write then
|
|
|
|
yurume
|
2021-07-23 10:37:34
|
does libjxl use libpng for APNG and lodepng for "ordinary" PNGs?
|
|
|
|
_wb_
|
|
|
yurume
|
2021-07-23 10:37:57
|
yeah that sounds reasonable
|
|
2021-07-23 10:38:06
|
(to use only lodepng for both)
|
|
|
|
_wb_
|
2021-07-23 10:39:22
|
It's one of those things that doesn't tend to get prioritized, because we have implemented enough to test stuff but not enough to make it convenient to use 😅
|
|
|
|
yurume
|
2021-07-23 10:40:19
|
is there a list for such wishlist of good-to-have-but-not-yet-prioritized tasks? 😄
|
|
|
|
_wb_
|
2021-07-23 10:54:59
|
Not afaik, some of those might be in the github and gitlab issues
|
|
|
|
fab
|
2021-07-23 12:46:02
|
what it talked the program
|
|
2021-07-23 12:46:48
|
basically jxl is a new image format that reduce the image to 1/3, and can reduce without re converting and losing image quality thanks to huffman coding (Not mentioned)
|
|
2021-07-23 12:47:04
|
so 30% smaller file sizes (again not mentioned)
|
|
2021-07-23 12:47:54
|
then the format can give huge panoramics, then it talked about an article found on web, jxl the format that nobody needed or wanted
|
|
2021-07-23 12:48:02
|
the accent was american of both speaker
|
|
2021-07-23 12:48:50
|
so, they said different resolution are needed, images are wide on desktop and contain way less content on mobile.
|
|
2021-07-23 12:49:12
|
then the contro thesis was
|
|
2021-07-23 12:49:41
|
why i need to include as a developer 4 image of a site, with different width, and still just support jxl large there?
|
|
2021-07-23 12:49:48
|
(dead on arrival).
|
|
2021-07-23 12:51:16
|
i have seen video encoders that goes nowhere... in last 25 years
|
|
2021-07-23 12:53:07
|
people who use internet do not know they said image compression that's ..a paint
|
|
2021-07-23 12:53:51
|
the only thing is to developers to serve on our phones we don't care about what format people are using
|
|
2021-07-23 12:54:50
|
the big size is mentioned on that wide website
|
|
2021-07-23 12:55:44
|
developers we don't dictate how a web browser use a file format; we just use a file format
|
|
2021-07-23 12:57:40
|
more consistent file formats with more consistent format support is just what we need
|
|
2021-07-23 12:59:11
|
so jon made an article on christmas
he said GHIF sorry ggif
lazy friendliness
legacy he said
|
|
2021-07-23 01:00:02
|
jxl is OK , it will adjust to the amount of image data and will clamp worse or better based of the nature of the source
|
|
2021-07-23 01:00:16
|
cliff
|
|
2021-07-23 01:03:00
|
.......
|
|
2021-07-23 01:03:07
|
this all he said
|
|
2021-07-23 01:04:17
|
doesn't forget the most important part; do you know AVIF has worse performance than WEBP
|
|
2021-07-23 01:04:19
|
......
|
|
2021-07-23 01:05:36
|
also he doesn't make an emphasis between the b and the other consonant P that is a stop
|
|
2021-07-23 01:06:21
|
and the b it pronounciates strong, on first result on internet the b is light and the p is much aspirated
|
|
2021-07-23 01:06:58
|
.......
|
|
2021-07-23 01:07:42
|
basically is A synthesis of what you already found online searching JPEG XL, skip the jxl parts and listen OTHER parts of the podcast
|
|
|
|
diskorduser
|
2021-07-23 01:27:23
|
`$ cjxl Animated_PNG_example_bouncing_beach_ball.png 1.jxl
JPEG XL encoder v0.5.0 [AVX2]
/mnt/data/yay/libjxl-git/src/libjxl/lib/extras/codec_png.cc:229: JXL_RETURN_IF_ERROR code=1: Decode(bytes, &io->blobs)
/mnt/data/yay/libjxl-git/src/libjxl/lib/extras/codec_png.cc:787: JXL_RETURN_IF_ERROR code=1: reader(bytes, is_gray, io)
/mnt/data/yay/libjxl-git/src/libjxl/lib/extras/codec_exr.cc:146: JXL_FAILURE: OpenEXR failed to parse input
/mnt/data/yay/libjxl-git/src/libjxl/lib/extras/codec.cc:124: JXL_FAILURE: Codecs failed to decode
/mnt/data/yay/libjxl-git/src/libjxl/lib/extras/codec.cc:137: JXL_RETURN_IF_ERROR code=1: SetFromBytes(Span<const uint8_t>(encoded), io, pool, orig_codec)
Failed to read image Animated_PNG_example_bouncing_beach_ball.png.
/mnt/data/yay/libjxl-git/src/libjxl/tools/cjxl_main.cc:58: JXL_RETURN_IF_ERROR code=1: LoadAll(args, &pool, &io, &decode_mps)`
|
|
|
|
fab
|
2021-07-23 01:29:27
|
the blob errors is always
|
|
|
|
_wb_
|
2021-07-23 01:34:19
|
The above just means that the lodepng codepath fails (because it cannot handle animation), and the exr codepath also fails (because it's not an exr file)
|
|
2021-07-23 01:34:33
|
The libpng path is not tried
|
|
|
|
diskorduser
|
2021-07-23 01:35:43
|
how do I fix it? Should I change compile options?
|
|
2021-07-23 01:36:00
|
`> ldd /usr/bin/cjxl | ag png
libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f08b8059000)`
|
|
|
|
_wb_
|
2021-07-23 01:37:48
|
Weird that it links to libpng but doesn't have the libpng/apng path
|
|
|
|
diskorduser
|
2021-07-23 01:39:31
|
I think arch linux's libpng doesn't support apng.
|
|
2021-07-23 01:47:42
|
Doesn't work even after installing patched libpng with apng patch.
|
|
|
|
_wb_
|
2021-07-23 02:37:25
|
That code doesn't need a patched libpng, regular libpng is fine
|
|
2021-07-23 02:38:16
|
But looks like the code is not running for some reason
|
|
|
|
fab
|
2021-07-24 06:33:21
|
in squoosh jxl and webp2 produce same size on most cases
|
|
2021-07-24 06:33:52
|
they seem very the same for an image quality inexpert like me
|
|
2021-07-24 06:35:19
|
foliage looks better with jxl
|
|
2021-07-24 06:35:37
|
wp2 has high compression on that
|
|
2021-07-24 06:36:09
|
but buildings looks sharper on wp2
|
|
2021-07-24 06:39:57
|
shades of hair are better preserved on jxl
|
|
2021-07-24 06:48:04
|
jxl image have look a bit grey
|
|
2021-07-24 06:49:16
|
i prefer jxl because i can encode images taller than 16000
|
|
2021-07-24 07:10:36
|
jxl quality seems better with progressive rendering enabled in squoosh
|
|
2021-07-24 07:12:47
|
|
|
2021-07-24 07:15:32
|
it doesn't inflate size of existent jxls
|
|
2021-07-24 07:15:40
|
it can reduce more
|
|
2021-07-24 07:16:02
|
honestly i won't lose time with experimental builds
|
|
2021-07-24 07:16:15
|
this squoosh version don't even say if the jxl is lossless or lossy
|
|
|
|
_wb_
|
|
|
fab
|
2021-07-24 07:55:11
|
Yes But im talking about the input
|
|
2021-07-24 07:55:41
|
Also no lossless transcode
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 08:29:57
|
The question in image compression is _NOT_ what people need to do to make things look bad, and where the bad is and how bad it is. (wrote the initial version of this statement before coffee and left 'NOT' out)
|
|
2021-07-24 08:31:05
|
Compare techniques when trying to have them behave consistently transparent and authentic.
|
|
2021-07-24 09:30:15
|
There are of course different levels of transparent and authentic -- it means different things if it is for 5x zooming on a 100 dpi screen or 1x on 300 dpi.
|
|
2021-07-24 09:31:00
|
making images look bad or changing how images look are not goals in image compression
|
|
2021-07-24 09:33:22
|
I'm currently trying to tame the color trick from yesterday -- to have some more bits in red and blue areas
|
|
2021-07-24 09:33:42
|
If I do that, low distances look better and get better butteraugli scores, too
|
|
2021-07-24 09:33:59
|
however, that makes middle and high distances worse
|
|
2021-07-24 09:35:08
|
my theory on it is that the additional signal/noise/entropy in the adaptive quantization field reduces the systems ability to use large transforms
|
|
2021-07-24 09:36:10
|
I'm currently experimenting on dedicating it for distances < 4 and fading it between 0 and distance 4, so that it is no longer participating at 4
|
|
2021-07-24 09:36:27
|
It is so much fun that I forgot to drink my morning coffee 😄
|
|
2021-07-24 09:40:59
|
I drink all possible coffee
|
|
2021-07-24 09:41:08
|
I am not a taste-centric person
|
|
2021-07-24 09:41:36
|
I do cold brew, instant, filtered, nescafe, ....
|
|
2021-07-24 09:42:48
|
my $50 espresso machine broke down recently
|
|
2021-07-24 09:43:30
|
I liked aeropress a lot, but the filter part disappeared
|
|
2021-07-24 09:44:16
|
overall, I'd say that aeropress is my favorite way of making coffee
|
|
2021-07-24 09:44:49
|
cold brew is also great, but I don't like washing the container afterwards
|
|
2021-07-24 09:51:44
|
I have made coffee with $20 machine, I owned a $1500 automatic machine, office has $10'000 espresso machines, cold brew can be done with an old free glass container
|
|
2021-07-24 09:52:00
|
I don't taste a big difference, or if I do, it is just not important for me
|
|
2021-07-24 09:52:23
|
good that I'm not compressing taste experiences lossily
|
|
2021-07-24 09:53:17
|
at a younger age, 30 years ago, I tried to approach the world of tasting with seriousness, but then I understood that it is not my world
|
|
|
lithium
|
2021-07-24 09:57:36
|
Sorry for interrupt coffee discuss,
Could you teach me vardct XYB how to work for grayscale content?
maybe I made some mistake for test grayscale content.
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 10:10:57
|
I think you are using it correct, it just doesn't work because of an unknown bug
|
|
2021-07-24 10:11:48
|
Before red+blue boost
|
|
2021-07-24 10:12:07
|
After:
|
|
2021-07-24 10:12:44
|
ba before:
|
|
2021-07-24 10:12:58
|
ba after:
|
|
2021-07-24 10:14:31
|
there seems to be a small improvement in the blue area to me
|
|
|
|
lithium
|
2021-07-24 10:15:58
|
yes, look like that error area(upper right corner) is gone 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 10:16:31
|
same bit rate 🙂
|
|
|
|
fab
|
2021-07-24 02:35:38
|
it looks good on pc
|
|
2021-07-24 02:35:46
|
but not on galaxy s4 screen with normal color range, so saturated
|
|
2021-07-24 02:36:53
|
jpeg xl on full blue looks forced
|
|
2021-07-24 02:36:55
|
weird
|
|
2021-07-24 02:38:13
|
i have standard mode on galaxy s4
|
|
|
|
diskorduser
|
|
fab
but not on galaxy s4 screen with normal color range, so saturated
|
|
2021-07-24 02:54:33
|
Compare original and jxl side by side.
|
|
|
|
fab
|
2021-07-24 02:54:49
|
Is how it looks to my screen
|
|
2021-07-24 02:54:57
|
no i don't compared original
|
|
2021-07-24 02:55:05
|
just jxl looks blue
|
|
|
|
diskorduser
|
2021-07-24 02:55:10
|
You can use this app. https://play.google.com/store/apps/details?id=com.sasiddiqui.ditto
|
|
|
|
fab
|
2021-07-24 03:11:02
|
ON PC IT LOOKS WAY MORE GOOD
|
|
2021-07-24 03:11:30
|
less disturbing
|
|
2021-07-24 03:11:54
|
curious what speed and distance it is on the x ray parts
|
|
2021-07-24 03:17:56
|
all the information found on jpeg xl on internet here
|
|
2021-07-24 03:18:02
|
download
|
|
2021-07-24 03:18:18
|
i think i will program a github html
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 04:14:50
|
I'm not sure if the 30 % holds universially
|
|
2021-07-24 04:15:08
|
It may be the case for the lowest qualities when the slowest AVIF encoding is used
|
|
2021-07-24 04:16:24
|
I suspect that if 'reasonable' speed encoding is used, like above 1 MP/s or close to 10 MP/s, I believe that AVIF loses its edge in the low qualities (and of course that also increases the gap in the middle to high qualities)
|
|
2021-07-24 04:20:55
|
AVIF speed 0 is not quite as bad as 265 HM codec, but it is not a practical encoder
|
|
2021-07-24 04:21:13
|
I think both are measured in kilopixels/second
|
|
2021-07-24 04:21:41
|
what good are coding features that require so much computation, that they remain theoretical
|
|
|
|
_wb_
|
2021-07-24 04:22:05
|
Yes, at faster speed settings, avif gets worse. When doing an apples to apples comparison at similar encode speeds, I think avif is still slightly better than jxl at the very low fidelities (q30 and below), but it's more like 10% than 30%.
|
|
2021-07-24 04:22:50
|
But I am giving avif the benefit of the doubt and not doing apples to apples here, comparing default jxl speed to slowest avif speed.
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 04:22:50
|
I'd like to challenge that -- if both are used at the same speed of say 3-10 MP/s, there is no difference in low quality
|
|
|
|
_wb_
|
2021-07-24 04:23:14
|
Could be true
|
|
2021-07-24 04:23:26
|
Haven't seen enough data on it
|
|
|
BlueSwordM
|
2021-07-24 04:23:49
|
So, one question: does JPEG-XL support higher than 8192x8192 frame sizes for 32-bit devices?
|
|
|
Orum
|
2021-07-24 04:23:56
|
can you even reach 3 MP/s on an AVIF encoder without completely abandoning quality?
|
|
|
|
Jyrki Alakuijala
|
|
BlueSwordM
So, one question: does JPEG-XL support higher than 8192x8192 frame sizes for 32-bit devices?
|
|
2021-07-24 04:24:25
|
JPEG XL, yes, .... libjxl or other practical implementations, ... ?!
|
|
|
|
BlueSwordM
|
2021-07-24 04:24:35
|
I see.
|
|
2021-07-24 04:24:48
|
It's just that this libavif commit just came in:
https://github.com/AOMediaCodec/libavif/commit/1556f21fb54e24d3612a0782fa0e5c8360bccbb9
It does look like it is being done for memory reasons, not for actual coding limitations.
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 04:24:58
|
it either works or doesn't work, and not much thought has been invested in for 32 bit
|
|
2021-07-24 04:26:00
|
32 bit is getting irrelevant in mobile as far as I know
|
|
2021-07-24 04:26:07
|
there may be embedded interests
|
|
|
|
Scope
|
2021-07-24 04:27:55
|
I think it depends on the content, on art images or photos where there is a lot of blur or uses Bokeh, AVIF is also good at very fast speeds and will be better than JXL at low bpp
|
|
|
|
Jyrki Alakuijala
|
2021-07-24 04:40:13
|
yes, it is complex
|
|
2021-07-24 04:40:31
|
my experience is from photographs only, and that set was not heavy on bokeh
|
|
|
|
paperboyo
|
2021-07-24 06:52:52
|
I must be weird [and definitely sound like a broken record, but for a reason, I hope ;-)], because for that site, where occasional spikes are ~200k PVs/m, _where the bad is_ is question number one, because just above is where the sweet spot is (yeah, higher than now, I admit, would have voted such in your twitter poll would I have an account). And would I be doing the compute, in most circumstances, I would be easily able to spend a couple of minutes for these ~10 different renders of a pic that satisfy most views. I’m not doing the compute, external company does, so I feel for them with AVIF, but just a bit. Just a tiny bit… Still, because most popular sizes are below 1MP, speeds that may seem glacial for some, sound practical and useful to me.
|
|
|
|
_wb_
|
2021-07-24 06:57:21
|
What is PVs/m?
|
|
2021-07-24 06:57:34
|
Picture views per minute?
|
|
2021-07-24 06:57:43
|
Page views?
|
|
2021-07-24 07:00:23
|
Things are very different if you have a small number of images and a large number of viewers. You can do manual editing, manual cropping, manual encoding, etc.
|
|
2021-07-24 07:01:09
|
That is not feasible for e.g. social media or other sites dealing with lots of UGC
|
|
|
|
paperboyo
|
|
_wb_
Things are very different if you have a small number of images and a large number of viewers. You can do manual editing, manual cropping, manual encoding, etc.
|
|
2021-07-24 07:03:16
|
I have small number of renders per image (don’t know, less than ten most of the time?). Relatively small number of master images per day (don’t know, less than 1k?) and absolutely zero way of doing any manual encoding. None.
|
|
|
|
Scope
|
2021-07-24 07:03:39
|
Encoding speed depends on the use cases, for example for a site with uploading photos and images from users or publishing blogs, the encoding must be very fast (almost instantaneous), but for platforms where the preparation time before publishing content is long enough and it mostly does not change, the encoding time does not mean that much and it is more important maximum compression, for example movie and music covers that will be viewed billions of times later
Like it wouldn't be very strange if some streaming service would spend dozens of hours to encode one image (if it made sense in efficiency)
|
|
|
|
_wb_
|
2021-07-24 07:04:55
|
Manual encoding is unaffordable in nearly all cases except hobbyist personal sites and very high profile / high traffic pages like hero images on a landing page.
|
|
2021-07-24 07:06:03
|
Yes, latency is critical for some use cases and nearly unimportant for others
|
|
2021-07-24 07:07:47
|
CPU cost is a thing though: even if you don't care about latency, you still usually care about throughput, the electricity bill, and the size of the server farm that you need to buy or rent.
|
|
2021-07-24 07:12:05
|
Also the use cases where latency doesn't matter also tend to be use cases that aren't _fully_ automated, i.e. latency doesn't matter because there are still human steps in the process, for QA and whatnot. But if there are feedback loops involving humans (e.g. deciding if the auto-crop, auto-enhance and compressed image quality are good enough or need to be adjusted/overruled), then high latency does make their job more annoying and less productive.
|
|
|
|
fab
|
2021-07-24 07:53:48
|
https://github.com/libjxl/libjxl/pull/345/files
|
|
2021-07-24 07:53:55
|
|
|
|
raysar
|
|
_wb_
I suppose windows builds don't typically compile with libpng, and then apng input does not work
|
|
2021-07-25 01:31:35
|
The initial 0.3.7 bin for windows works great with APNG.
|
|
|
|
eclipseo
|
2021-07-25 06:25:59
|
is there some volunteer who produces jpeg xl builds for windows (i mean git tip)
|
|
|
|
fab
|
2021-07-25 07:18:27
|
jeremylee
|
|
2021-07-26 06:47:27
|
i want to convert this to d 1 s 9 jxl
|
|
2021-07-26 06:47:28
|
https://mega.nz/file/XMFGjJ5L#_Z_F0cQ3oa621SoaPzt4_vkgc7B6urXs_susYD8OJXg
|
|
2021-07-26 06:47:49
|
how the encoder can improve in this screenshot?
|
|
2021-07-26 06:48:01
|
it has many colours
|
|
2021-07-26 06:54:20
|
obviously don't post screenshots because is youtube chronology
|
|
|
eddie.zato
|
2021-07-26 07:34:24
|
Encoder ≠ improver
|
|
|
|
fab
|
2021-07-26 07:42:32
|
i meant compress
|
|
2021-07-26 07:42:46
|
with a higher quality than the pull request he's making
|
|
2021-07-26 07:42:53
|
i want less color loss as possible
|
|
2021-07-26 07:43:10
|
while decent compression at d 1 s 9 for this type of image
|
|
2021-07-26 07:43:14
|
that has many colours
|
|
2021-07-26 07:43:22
|
jpeg xl is the only codec who can do that
|
|
|
|
Jyrki Alakuijala
|
2021-07-26 07:49:58
|
butteraugli is the only system that tries to model perception of color in high spatial frequency
|
|
2021-07-26 07:50:35
|
Lab color is based on low frequency color measurements (2 degree color discs)
|
|
2021-07-26 07:51:29
|
that is the root cause why we can compress more without color surprises
|
|
2021-07-26 07:59:15
|
https://github.com/libjxl/libjxl/pull/355 for <@!461421345302118401>
|
|
|
|
fab
|
2021-07-26 08:08:25
|
and to resolve my problem with the image i posted on mega.nz
|
|
2021-07-26 08:08:39
|
i'm interested in d1 s9
|
|
|
|
eddie.zato
|
2021-07-26 08:19:36
|
I tried encoding this image (17601x12741, 38.3 MiB) with `-j -e 9` on my old i3570k with 16 GB RAM. I waited 2 hours and gave up, aborting the process. Now I don't use `-e 9` anymore. 😄
legacy.lib.utexas.edu/maps/tpc/txu-pclmaps-oclc-22834566_b-8b.jpg
|
|
|
|
fab
|
2021-07-26 08:33:10
|
does it also exists e 9 i thought only -E 3 existed and only with speed 9
|
|
|
|
eddie.zato
|
2021-07-26 08:36:56
|
```
-e EFFORT, --effort=EFFORT
Encoder effort setting. Range: 1 .. 9.
Default: 7. Higher number is more effort (slower).
-s ANIMAL, --speed=ANIMAL
Deprecated synonym for --effort. Valid values are:
lightning (1), thunder, falcon, cheetah, hare, wombat, squirrel, kitten, tortoise (9)
Default: squirrel. Values are in order from faster to slower.
```
|
|
|
Ringo
|
2021-07-26 08:41:50
|
`-e` and `-E` are different
|
|
|
|
_wb_
|
2021-07-26 08:45:08
|
-e is effort, -E is about extra properties in (modular) MA trees
|
|
|
|
lithium
|
|
Jyrki Alakuijala
https://github.com/libjxl/libjxl/pull/355 for <@!461421345302118401>
|
|
2021-07-26 08:55:56
|
Thank you for your work 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-07-26 09:38:04
|
Luca proposed that I try it with another set of images -- and it looks like it doesn't work for images that were yuv420 before 😕
|
|
2021-07-26 09:38:07
|
grrrrr
|
|
2021-07-26 09:38:27
|
then it just makes them 0.5 % worse instead of 0.4 % better
|
|
2021-07-26 10:12:14
|
hmmm, if I optimize it for the yuv420ish images, then I get a 4 % improvement
|
|
2021-07-26 10:12:31
|
but that will make it perform worse on the super high quality 444 images
|
|
2021-07-26 10:12:58
|
if I can figure this out there seems to be room for big improvements here
|
|
|
|
fab
|
|
Jyrki Alakuijala
but that will make it perform worse on the super high quality 444 images
|
|
2021-07-26 10:50:05
|
Look at the ima
|
|
2021-07-26 10:50:14
|
I posted in mega.nz
|
|
2021-07-26 10:50:30
|
https://mega.nz/file/XMFGjJ5L#_Z_F0cQ3oa621SoaPzt4_vkgc7B6urXs_susYD8OJXg
|
|
2021-07-26 10:50:50
|
I want to Save space on this yt screenshot
|
|
|
|
Jyrki Alakuijala
|
2021-07-26 10:53:56
|
why this image?
|
|
|
|
fab
|
2021-07-26 10:56:03
|
Because it has Lot of colors
|
|
2021-07-26 10:56:15
|
I want to reduce the colors
|
|
2021-07-26 10:56:30
|
Without looking ugly
|
|
2021-07-26 10:56:57
|
And as i said before jpeg xl is only codec for Now that can do it
|
|
2021-07-26 10:57:37
|
So i expect more natural color rendition
|
|
2021-07-26 10:57:49
|
Of original colors
|
|
2021-07-26 11:04:01
|
....
|
|
2021-07-26 11:04:43
|
Im interested how it looks with new Pull request
|
|
2021-07-26 11:04:59
|
Is 10 mpx probably slow to encode
|
|
|
|
Jyrki Alakuijala
|
2021-07-26 11:15:08
|
I'm still working on it 😛
|
|
2021-07-26 11:17:50
|
I suspect youtube transmit images from server as webp lossy, i.e., yuv420
|
|
|
|
fab
|
|
|
Jyrki Alakuijala
|
2021-07-26 11:26:06
|
you cannot make cheese if milk is poured on the ground
|
|
|
|
fab
|
2021-07-26 11:27:25
|
I know
|
|
2021-07-26 11:27:47
|
But at least on d1 should be acceptable with s9
|
|
2021-07-26 11:28:42
|
|
|
2021-07-26 11:29:06
|
Avif is a video codec
|
|
2021-07-26 11:29:26
|
Not for web graphics
|
|
2021-07-26 11:29:47
|
Even if source in the screenshot are lodsy
|
|
2021-07-26 11:30:06
|
Maybe pascal will disagree
|
|
2021-07-26 11:30:34
|
Some things wb uses it as marketing
|
|
2021-07-26 11:30:42
|
Such the q60 stuff
|
|
2021-07-26 11:30:56
|
The Best lossless compression
|
|
2021-07-26 11:31:05
|
They are extremized
|
|
2021-07-26 11:33:40
|
Or such the servers never get overloaded with higher resolution
|
|
2021-07-26 11:33:51
|
Picrures and jpeg xl
|
|
|
|
lithium
|
2021-07-26 03:54:27
|
commits ba8a47c is already merge to main branch. 🥳
https://github.com/libjxl/libjxl/commit/ba8a47cf677aa4ed8f7b2811bf19eef6948db4f9
|
|
|
|
Jyrki Alakuijala
|
2021-07-26 04:01:43
|
yes, it worked out as is -- without changes
|
|
2021-07-26 04:02:06
|
my additional failed testing was first with a HDR corpus without an HDR target intensity -- that confused me
|
|
2021-07-26 04:02:28
|
when I tested with a normal corpus, it worked as expected
|
|
2021-07-26 04:03:51
|
We need 200 more of these 0.5 % wins and we can reduce 100 % 😛
|
|
|
|
lithium
|
2021-07-26 04:19:37
|
Thank you for your work 🙂
For current jxl, I think fix those three question, can improve non-photographic images quality and provide more stable function.
1. color issue(red, blue), this improvement is work in process.
2. high contrast sharp edges(line) ringing issue, current jxl is already have some fix patch about this,
so I not sure this issue is already fixed or still need some improve,
probably need some feedback from <@!111445179587624960> and <@!260412131034267649> (sorry for ping).
3. grayscale content have some unknown bug on vardct(and hope cmyk jpg support commits can merge to main branch).
|
|
|
|
improver
|
2021-07-26 04:24:37
|
are cymk jpg related stuff really in the same category as non-photographic images?
|
|
|
|
_wb_
|
2021-07-26 04:25:27
|
Cmyk jpg we cannot do, VarDCT is limited to 3 channels
|
|
|
|
lithium
|
2021-07-26 04:28:32
|
oh, I mean we can without convert to png,
cmyk jpg => png 16 bit depth => jxl vardct,
cjxl can auto convert to suitable rgb pixel.
|
|
|
|
_wb_
|
2021-07-26 04:28:52
|
We can do lossless cmyk though, with psd input
|
|
2021-07-26 04:30:34
|
I suppose we could also take cmyk jpg as input to internally convert to rgb and encode from there
|
|
2021-07-26 04:31:11
|
Theoretically we could also take cmyk jpg, convert K to pixels and keep CMY as dct coefficients
|
|
|
|
lithium
|
|
improver
are cymk jpg related stuff really in the same category as non-photographic images?
|
|
2021-07-26 04:38:09
|
I noted some people convert comic to cmyk jpg and put than on internet,
so I think if we have auto convert cmyk jpg to rgb, probably can let cjxl more stable.
And about high contrast sharp edges(line) ringing issue improve,
could you share some opinion about this issue for current jxl?
|
|
|
|
paperboyo
|
|
_wb_
I suppose we could also take cmyk jpg as input to internally convert to rgb and encode from there
|
|
2021-07-26 04:44:31
|
> take cmyk jpg as input to internally convert to rgb
Would that mess around my separations? I would rather have no support at all than “support” that could mix channels. IIUC, that is!
|
|
|
|
lithium
|
|
paperboyo
> take cmyk jpg as input to internally convert to rgb
Would that mess around my separations? I would rather have no support at all than “support” that could mix channels. IIUC, that is!
|
|
2021-07-26 04:49:02
|
maybe we need a cjxl option like this?, --displaymode=mode(monitor, print, medical)
|
|
|
|
paperboyo
|
2021-07-26 05:00:51
|
I haven’t got my head around the fact that JXL has this “internal colour management” yet… I suppose it could automagically convert to display colour space when eg. displayed in browser. But if it takes CMYK at all, it **must** be able to spit out CMYKs without having gone through any transformation that mixes the inks. Adobe will have an opinion on that, I imagine.
Again, I may not be understanding the implications of internal storage of channels correctly. They can go through transforms. Just separately ;-).
|
|
|
|
lithium
|
|
paperboyo
I haven’t got my head around the fact that JXL has this “internal colour management” yet… I suppose it could automagically convert to display colour space when eg. displayed in browser. But if it takes CMYK at all, it **must** be able to spit out CMYKs without having gone through any transformation that mixes the inks. Adobe will have an opinion on that, I imagine.
Again, I may not be understanding the implications of internal storage of channels correctly. They can go through transforms. Just separately ;-).
|
|
2021-07-26 05:07:04
|
I respect every use case 🙂 , but for monitor(web) use case,
normal user probably don't understand how to convert cmyk jpg to rgb and input cjxl vardct for web use.
|
|
|
|
paperboyo
|
2021-07-26 05:10:45
|
> normal user probably don't understand how to convert cmyk jpg to rgb
Oh, sure! Nor should they! Browsers/whatever should do it for them.
|
|
|
|
lithium
|
2021-07-26 05:15:14
|
Who can do this job?, Cloudinary can!
For now you just use q_auto, and everything will be alright! 😛
|
|
|
|
improver
|
2021-07-26 05:20:04
|
tbh playing around cymk jpegs sounds kinda ehhh as the way they are is probably quite okay already and jxl will probably not do too good job
|
|
2021-07-26 05:20:36
|
well if you can afford losing info then i guess that'd be fine but idk
|
|
2021-07-26 05:20:48
|
these shouldn't be on the internet in the first place
|
|
|
|
_wb_
|
|
paperboyo
I haven’t got my head around the fact that JXL has this “internal colour management” yet… I suppose it could automagically convert to display colour space when eg. displayed in browser. But if it takes CMYK at all, it **must** be able to spit out CMYKs without having gone through any transformation that mixes the inks. Adobe will have an opinion on that, I imagine.
Again, I may not be understanding the implications of internal storage of channels correctly. They can go through transforms. Just separately ;-).
|
|
2021-07-26 05:21:46
|
Channels are always stored separately, and in the case of lossless, they are in whatever rgb or cmyk color space the input is in. In the case of lossy though, cjxl will first do color conversion from the input space to an absolute color space (XYB), so it knows the perceptual impact of what it is doing. For CMYK, that cannot be done while keeping ink separation though.
|
|
2021-07-26 05:22:48
|
It could do something lossy on CMY (pretending it is RGB), and keep K separate as an extra channel, and then hope for the best.
|
|
2021-07-26 05:24:48
|
I think lossless CMYK, or maybe very slightly lossy (modular q97 or something), makes the most sense in use cases where CMYK is what you want
|
|
2021-07-26 05:27:09
|
If you're fine with printing DCT artifacts to save file size, you better don't bother with ink separation, imo. Better do higher quality RGB then, and let the printer figure out the ink separation.
|
|
|
|
paperboyo
|
|
_wb_
If you're fine with printing DCT artifacts to save file size, you better don't bother with ink separation, imo. Better do higher quality RGB then, and let the printer figure out the ink separation.
|
|
2021-07-26 05:30:25
|
This was discussed before. Sometimes, separation trumps everything (and because it's implied, that "sometimes" means "always"). True that lossiness should be (and in practice is) kept to the minimum in this use case. But the absolute must is that if something is there only on the C (or whichever) channel, it must stay that way.
|
|
|
|
lithium
|
2021-07-26 05:32:14
|
cmyk jpg auto convert features just a suggest for normal user,
actually I care more about vardct quality, so keep current behavior is fine.
|
|
|
|
improver
|
2021-07-26 05:33:46
|
is modular not being adjusted for color spaces format limitation, or something could be done in encoder for that (like giving some channels more bits in some cases)?
|
|
|
|
lithium
|
2021-07-26 05:40:18
|
<@!260412131034267649>
And about high contrast sharp edges(line) ringing issue improve,
in last ringing improve discuss, you mention some good opinion for this issue,
could you share some opinion about this issue for current jxl?
|
|
|
|
improver
|
2021-07-26 05:41:57
|
tbh I'm lazy atm and libjxl-git from aur won't even install because of failing tests
|
|
2021-07-26 05:42:21
|
i could disable testing in yay i guess but ooof
|
|
|
|
lithium
|
2021-07-26 05:44:20
|
ok, thank you for your reply 🙂
maybe Scope have some good opinion for this issue.
|
|
|
|
_wb_
|
|
paperboyo
This was discussed before. Sometimes, separation trumps everything (and because it's implied, that "sometimes" means "always"). True that lossiness should be (and in practice is) kept to the minimum in this use case. But the absolute must is that if something is there only on the C (or whichever) channel, it must stay that way.
|
|
2021-07-26 05:50:13
|
Yes, I get that. Isn't it mostly the K separation that matters most in practice though? Or do you have cases where you print text or lines in pure C or M?
|
|
2021-07-26 05:51:32
|
In any case, jxl can do lossy cmyk (using either vardct for cmy or lossy modular), but cjxl can only do it with lossy modular.
|
|
|
|
paperboyo
|
|
_wb_
Yes, I get that. Isn't it mostly the K separation that matters most in practice though? Or do you have cases where you print text or lines in pure C or M?
|
|
2021-07-26 05:52:37
|
Because of the knowledge they are separate, everything is possible. Would take me time to dig up examples of non-K being distinct, which suggests they are more rare, yeah. But what matters is this assumption: my CMYKs have channels separate.
|
|
|
|
_wb_
|
2021-07-26 05:53:29
|
For the CMY, it can either do YCbCr or XYB on it, or keep it as is. If you want to avoid one channel contaminating another, the last one is what you would want.
|
|
2021-07-26 05:54:28
|
CMYK JPEGs often are YCCK, i.e. ycbcr was applied to the cmy (just pretending it is rgb)
|
|
2021-07-26 05:59:07
|
It's a bit of a pity that we cannot do lossless recompression of CMYK jpegs, but it is what it is. FUIF could do it, but it had way worse jpeg recompression density AND it was slower — the VarDCT-based recompression is much better. But VarDCT was designed hardcoded for 3 channels and it would be a lot of work to change that, not really worth it, I think.
|
|
|
|
paperboyo
|
2021-07-26 06:32:43
|
Oh, if it’s only for lossless recompression, then that’s fine, sorry 🤦. I don’t think there would be a huge appetite for that in print industry. What’s need then are some sensible defaults and, maybe, some options for the cases where the recompression is done in bulk (and usears either don’t know if there are any CMYKs there or don’t even know, or care, what a CMYK is).
|
|
2021-07-26 06:35:10
|
Warn-and-log and leave as is; wrap in JXL anyhow (even if it’s tiniest bit larger); warn-and-log and convert to RGB – would be the options, I guess. But that’s straight out of a hat.
|
|
|
|
fab
|
2021-07-27 09:49:38
|
as always jpeg xl builds aren't available
|
|
2021-07-27 09:49:52
|
neither in eddiezato
|
|
2021-07-27 09:49:57
|
neither in jeremylee
|
|
2021-07-27 09:50:03
|
and in raysar onedrive folder
|
|
2021-07-27 09:50:33
|
jamaika latest update is 24072021
|
|
|
w
|
2021-07-27 10:05:04
|
why don't you build them yourself
|
|
|
|
fab
|
2021-07-27 10:10:55
|
to me build means something i get free
|
|
2021-07-27 10:11:02
|
not building a castle
|
|
2021-07-27 10:12:35
|
eddie zato updated yac reader
|
|
2021-07-27 10:12:40
|
two file still remains
|
|
2021-07-27 10:14:08
|
he updated also qimgv
|
|
2021-07-27 10:14:12
|
https://github.com/eddiezato/eddiezato.github.io/commit/99ee43828f4ab28d8dc31b63f9fc69b7b2094543
|
|
2021-07-27 10:14:34
|
|
|
|
|
eddie.zato
|
2021-07-27 10:27:41
|
If you need daily builds, you better figure out how to create them yourself. At the time I don't make static builds, so I can't share them. Sorry. 🖖
|
|
|
|
Jyrki Alakuijala
|
2021-07-27 02:46:20
|
more ringing improvements
|
|
2021-07-27 02:46:29
|
Before:
|
|
2021-07-27 02:46:46
|
After:
|
|
2021-07-27 02:47:13
|
this is d16:7:epf3
|
|
2021-07-27 02:48:56
|
Before:
|
|
2021-07-27 02:49:10
|
After:
|
|