|
Traneptora
|
2021-11-04 08:22:10
|
`global_quality` is the FFmpeg option `-q`
|
|
2021-11-04 08:22:35
|
basically if `-q` is set, then it uses it instead of `-distance`
but `-mquality` always wins in modular mode
|
|
|
_wb_
|
2021-11-04 08:22:47
|
Libjxl encode api is being created still, you can check some recent pull requests to see where it is going
|
|
|
|
Traneptora
|
2021-11-04 08:22:52
|
wait, I should put the "force modular mode" up top
|
|
2021-11-04 08:23:06
|
at least above mquality
|
|
2021-11-04 08:23:08
|
less confusing
|
|
2021-11-04 08:23:39
|
These are my converstion functions, atm
|
|
2021-11-04 08:23:42
|
```c
static float quality_to_distance(float quality){
if (quality >= 100.0) {
return 0.0;
} else if (quality >= 90.0) {
return (100.0 - quality) * 0.10;
} else if (quality >= 30.0) {
return 0.1 + (100.0 - quality) * 0.09;
} else if (quality > 0.0) {
return 6.24 + ff_fast_powf(2.5, (30.0 - quality) * 0.145615258) * 0.16;
} else {
return 15.0;
}
}
static float distance_to_mquality(float distance){
if (distance <= 0.0) {
return 100.0;
} else if (distance <= 1.0) {
return 100.0 - distance * 10.0;
} else if (distance <= 6.4) {
return 100.0 - (distance - 0.1) / 0.09;
} else if (distance <= 15) {
return 30.0 - logf((distance - 6.24) * 6.25) * 7.49479604;
} else {
return 0.0;
}
}```
|
|
2021-11-04 08:24:03
|
`ff_fast_powf` is just `powf`
|
|
2021-11-04 08:24:11
|
but faster with fewer safety checks
|
|
2021-11-04 08:24:22
|
like if the base is zero it will derp, which is fine
|
|
2021-11-04 08:25:11
|
it expands to `expf(b * logf(a))`
|
|
2021-11-04 08:25:47
|
the logf(a) is known so I probably should just do this one myself
|
|
2021-11-04 08:25:55
|
bake it into 0.145615258
|
|
2021-11-04 08:25:57
|
and then do expf
|
|
|
spider-mario
|
2021-11-04 10:01:23
|
does it really need to be fast? presumably, it’s called just once and is extremely negligible compared to the actual encoding
|
|
|
|
Traneptora
|
2021-11-04 10:21:24
|
nope, and I ended up changing it to an expf and a logf version
|
|
2021-11-04 10:21:30
|
it feels better anyway as a mathematician
|
|
|
|
spider-mario
|
2021-11-04 10:22:14
|
why not powf? :p
|
|
|
|
Traneptora
|
2021-11-04 10:22:22
|
there's no reason to use powf
|
|
2021-11-04 10:22:54
|
now it's `6.24 + expf((30.0 - quality) * 0.133425912) * 0.16;` and `30.0 - logf((distance - 6.24) * 6.25) * 7.494796046`
|
|
|
Orum
|
2021-11-06 06:25:21
|
is decode performance still the primary concern for the devs, or is encoding perf going to get some love soon?
|
|
|
|
_wb_
|
2021-11-06 06:52:31
|
I think API/adoption is atm more important, and before we move to encode speed, I think quality/density should be explored some more — but that's just my opinion, and in any case you can focus on something and still make more progress on something else, part of it is like research, serendipity is a factor...
|
|
|
novomesk
|
2021-11-06 09:29:03
|
API for encoding more frames?
|
|
|
|
_wb_
|
2021-11-06 09:35:06
|
Multi-layer encode/decode api is one thing I think we still need to see how we do it, but I think that would be nice for Gimp/Photoshop (but also e.g. adding a text overlay or logo on top of a recompressed jpeg could be useful)
|
|
2021-11-06 09:35:59
|
Multi-frame (animation) is probably not working encode side yet, or is it?
|
|
|
|
novomesk
|
2021-11-06 09:46:02
|
I guess it is not working yet, because there is PR https://github.com/libjxl/libjxl/pull/509
|
|
|
Jyrki Alakuijala
|
|
Traneptora
there's no reason to use powf
|
|
2021-11-06 06:06:52
|
once per pixel optimizations are even better than once per image and I believe we have plenty of room there -- would be great if you take a look
|
|
|
|
Traneptora
|
|
Jyrki Alakuijala
once per pixel optimizations are even better than once per image and I believe we have plenty of room there -- would be great if you take a look
|
|
2021-11-06 06:09:46
|
where?
|
|
2021-11-06 06:10:01
|
could you link me to some points in the codebase where I could take a look
|
|
2021-11-06 06:10:10
|
I haven't looked very much at libjxl itself
|
|
|
|
Jyrki Alakuijala
|
2021-11-06 06:39:29
|
if you have a profiling tool you can find the pain points easily -- and most optimizations should be profile driven, otherwise the effort is likely not spend in right places
|
|
2021-11-06 06:39:34
|
I have used gprof
|
|
2021-11-06 06:40:09
|
but also valgrind / kcachegrind because then I get repeatable results (even if they are 'wrong')
|
|
|
|
Traneptora
|
2021-11-06 06:53:44
|
I see, are you thinking of the encoder or the decoder?
|
|
2021-11-06 06:53:52
|
also, I can take a look at this tomorrow. I got somewhere to be in like an hour
|
|
2021-11-06 06:54:09
|
I might prefer to get the libavcodec wrapper around the encoder working anyway first though
|
|
2021-11-06 06:56:34
|
depending on how I feel that is. i got my covid-19 booster shot today so I might feel oof tomorrow
|
|
2021-11-06 06:59:57
|
(also I'm hoping this lavc decoder wrapper actually gets merged, ugh)
|
|
|
|
_wb_
|
2021-11-06 07:04:31
|
In the decoder there are probably no or few low hanging fruits to speed it up
|
|
2021-11-06 07:06:28
|
In the encoder, there probably are quite a few things that can be sped up or made more parallel. Not at the faster speeds of vardct though (wombat and faster), those are already quite optimized.
|
|
|
|
veluca
|
2021-11-06 09:43:05
|
I'd suggest using `perf` if you run on Linux
|
|
|
|
Jyrki Alakuijala
|
2021-11-07 02:36:02
|
encoder is too early to speed up
|
|
2021-11-07 02:36:08
|
we don't yet know what we want to do there
|
|
2021-11-07 02:36:22
|
we don't know which algorithms will eventually work the best
|
|
2021-11-07 02:36:34
|
I'd advice against investing a lot of time there
|
|
2021-11-07 02:37:22
|
the decoder will also see some changes, most notably more tile based processing with a better integration to exotic and dynamic use cases
|
|
|
Scope
|
2021-11-07 05:53:55
|
https://github.com/saschanaz/jxl-winthumb/releases/tag/v0.1.14
|
|
2021-11-08 12:57:34
|
https://github.com/libjxl/libjxl/pull/821
|
|
2021-11-08 12:57:37
|
With these changes will the encoder also be able to do auto-choice between VarDCT and Modular modes (or just the lossy palette)?
|
|
|
|
_wb_
|
2021-11-08 02:34:02
|
No, we still need to invent those heuristics. But the option is there, with those -1 values.
|
|
|
|
Jyrki Alakuijala
|
2021-11-08 04:33:18
|
We are trying to move to a phase where cjxl and djxl would start using the API we have
|
|
2021-11-08 04:33:37
|
it is more just shoveling code around than being smart about it
|
|
2021-11-08 04:34:07
|
if we don't have a stable and complete API, the API clients are going to pay the price later
|
|
2021-11-08 04:34:26
|
we see API use ramping up now, so it is the right time to focus on this
|
|
|
Fraetor
|
2021-11-08 04:35:16
|
Is there a design for the API that you are trying to impliment, or are you figuring it out as you go?
|
|
|
|
_wb_
|
2021-11-08 04:51:50
|
Afaik we just try to make it so it makes sense and is convenient to use.
|
|
|
|
Fraetor
|
2021-11-08 04:55:06
|
Fair.
|
|
2021-11-08 04:55:47
|
I guess libjxl 1.0 will be when the API is fully stable.
|
|
|
|
_wb_
|
2021-11-08 05:03:27
|
Yes, in 0.x we can basically still change things (though even now we care about not breaking things), at 1.x the api becomes stable (breaking changes mean we have to go to 2.x)
|
|
|
|
Jyrki Alakuijala
|
2021-11-08 05:04:10
|
1.0 api will be stable all the way to 2.0
|
|
|
Duplex
|
2021-11-09 01:56:45
|
How does progressive jxl work?
|
|
|
monad
|
2021-11-09 02:20:51
|
Broad question, but here's some commentary in regard to coding features: https://discord.com/channels/794206087879852103/803574970180829194/838274634846568509
|
|
2021-11-09 02:37:12
|
This page demos what's currently available in the web browser, which I think in Chromium at least is still not progressive and just incremental rendering of decoded groups. https://stan-kondrat.github.io/progressive-image-viewer
|
|
|
|
Jyrki Alakuijala
|
2021-11-09 09:40:42
|
there are several options
1. no progression (like delta palette)
2. 8x8 first, then rest (256x256 tiles in encoding time defined order)
3. variable resolution dc first, then rest
4. all modular progression
5. 'passes' progression, where the tiles in encoding time defined order bring only some of the bits for the dcts, for example 8x8 DC first (10 %), then all coefficients except the last bit for AC (40 %), and finally the AC last bit (50 %)
|
|
2021-11-09 09:42:24
|
the format is pretty flexible for progression, the most practical guarantee is the 8x8 first, which is always the case for DCT based compression even with variable sized transforms
|
|
|
|
_wb_
|
2021-11-09 10:33:35
|
Also there's group reordering which means that most "no progression" cases (e.g. default lossless) can also be done e.g. center-first instead of top to bottom. In a way that's also a form of progression (especially when applied to passes)
|
|
2021-11-09 10:36:12
|
And then there is also the option of having multiple layers and using patches, which in principle allows you to e.g. have all the text parts at full resolution while the photo parts are still blurry
|
|
2021-11-09 10:39:42
|
Finally there's also the PreviewFrame option, which is a redundant image so not really progressive but that's what they are calling 'progressive' in avif, so just to clarify, we can do that too (and we even have a nice bitstream-specified upsampling procedure so you can do a low res preview and get it to full res with the decoder, no need for external procedures like in the case of avif)
|
|
|
|
Traneptora
|
2021-11-09 04:01:51
|
do yall think this is obvious enough?
|
|
2021-11-09 04:01:52
|
|
|
|
fab
|
2021-11-09 04:03:43
|
Yes is same as gimp
|
|
|
|
Traneptora
|
2021-11-09 04:04:02
|
the goal was to use the same names as cjxl
|
|
2021-11-09 04:04:04
|
without inventing new ones
|
|
|
|
fab
|
2021-11-09 04:04:38
|
Why we need to add jxlopts
|
|
2021-11-09 04:05:02
|
Cant we just add the other options to the list
|
|
2021-11-09 04:05:30
|
Do we need to write input.png -jxlopts
|
|
2021-11-09 04:06:46
|
Or Is Just cjxl -h -v -v intention
|
|
|
|
Traneptora
|
|
fab
Cant we just add the other options to the list
|
|
2021-11-09 04:09:35
|
it'll allow it to dynamically update when cjxl adds more options
|
|
|
|
Scope
|
2021-11-09 04:13:09
|
I think a separate `-mquality` is not needed and it can be just `-q` (with an alias like for VarDCT), because two different modes can't work together anyway
|
|
|
|
Traneptora
|
2021-11-09 04:13:35
|
`-q` is a global AVOption
|
|
2021-11-09 04:13:46
|
however `-mquality` is used by cjxl, so I figured I'd do that.
|
|
2021-11-09 04:14:25
|
I find most people very rarely use `-q`
|
|
2021-11-09 04:14:35
|
since you're typically advised to use encoder-specific settings instead
|
|
2021-11-09 04:14:45
|
I think the average FFmpeg user will appreciate it being separate here
|
|
2021-11-09 04:15:39
|
because `-q 100` is lossless here, and `-q 0` is crap, which is the opposite of x264 where `-qp 0` is lossless
|
|
2021-11-09 04:23:06
|
Are `JXL_ENC_OPTION_CHANNEL_COLORS_PRE_TRANSFORM_PERCENT` and `JXL_ENC_OPTION_CHANNEL_COLORS_PERCENT` what `-mquality` actually sets?
|
|
|
|
_wb_
|
|
|
Traneptora
|
2021-11-09 04:23:29
|
the equivalent of mquality on the CLI, how do you set that in libjxl?
|
|
|
|
_wb_
|
2021-11-09 04:23:57
|
we'll probably remove mquality from cjxl, we're not intending to have it as a separate option in libjxl
|
|
|
|
Traneptora
|
2021-11-09 04:24:06
|
okay, how do you set it, then?
|
|
|
|
_wb_
|
2021-11-09 04:24:13
|
basically quality will be auto-mapped to mquality if modular is used
|
|
|
|
Scope
|
2021-11-09 04:24:15
|
Yep, but `-q` anyway should work for VarDCT and for Modular modes and less duplicate options in my opinion is better, `-distance` is understandable, it works differently and has other values
|
|
|
|
Traneptora
|
2021-11-09 04:24:26
|
and if you're planning on removing mquality from cjxl then I won't add it to ffmpeg
|
|
2021-11-09 04:24:45
|
how do you set it in libjxl, map it to distance and then set it?
|
|
|
|
_wb_
|
2021-11-09 04:25:08
|
we're now preparing things to migrate cjxl to libjxl, that's why you're seeing all those new encode options in the library recently 🙂
|
|
2021-11-09 04:25:31
|
yes, all quality setting will happen through SetDistance
|
|
|
|
Traneptora
|
2021-11-09 04:29:20
|
How are you planning on mapping it?
|
|
2021-11-09 04:29:35
|
This is what I have in avcodec rn as a skeleton
|
|
2021-11-09 04:29:47
|
```c
float quality_to_distance(float quality){
if (quality >= 100.0) {
return 0.0;
} else if (quality >= 90.0) {
return (100.0 - quality) * 0.10;
} else if (quality >= 30.0) {
return 0.1 + (100.0 - quality) * 0.09;
} else if (quality > 0.0) {
return 6.24 + expf((30.0 - quality) * 0.133425912) * 0.16;
} else {
return 15.0;
}
}
float distance_to_quality(float distance){
if (distance <= 0.0) {
return 100.0;
} else if (distance <= 1.0) {
return 100.0 - distance * 10.0;
} else if (distance <= 6.4) {
return 100.0 - (distance - 0.1) / 0.09;
} else if (distance < 15) {
return 30.0 - logf((distance - 6.24) * 6.25) * 7.494796046;
} else {
return 0.0;
}
}
```
|
|
2021-11-09 04:30:15
|
they are inverses of each other provided that `0 <= quality <= 100` and `0 <= distance <= 15`
|
|
2021-11-09 04:30:28
|
(as far as I'm aware)
|
|
2021-11-09 04:30:36
|
haven't tested for literally every float value
|
|
|
|
_wb_
|
2021-11-09 04:34:42
|
distance is the thing we use internally, quality is just a convenience thing that at corpus level very roughly corresponds to libjpeg-turbo
|
|
|
|
Traneptora
|
2021-11-09 04:34:57
|
do you use it even for modular?
|
|
2021-11-09 04:35:16
|
|
|
2021-11-09 04:35:31
|
quality => distance using my function
|
|
|
|
_wb_
|
2021-11-09 04:35:46
|
possibly it might be a good idea to add a helper function to the api to convert quality to distance, so all applications that want to use a quality scale will end up doing the same thing instead of each using their own mapping
|
|
|
|
Traneptora
|
2021-11-09 04:35:54
|
makes sense
|
|
2021-11-09 04:36:06
|
I'm not sure what you use internally, tbh
|
|
2021-11-09 04:36:11
|
ideally I'd use the same thing for now
|
|
|
|
Scope
|
2021-11-09 04:39:22
|
As far as I understand these recent changes are also intended to unify the options between VarDCT and Modular
<https://github.com/libjxl/libjxl/pull/808>
|
|
|
|
Traneptora
|
2021-11-09 04:51:28
|
would it make sense to hold off on writing this encoder wrapper until the encoder options in libjxl are stabalized?
|
|
|
|
Scope
|
2021-11-09 04:58:42
|
Maybe, but I don't think these basic options (except maybe -distance) will change, but for some specific options it's better to wait
|
|
|
|
Traneptora
|
2021-11-09 05:14:37
|
one idea is to *only* expose `-distance` and `-effort` (and perhaps `-modular`) for now, and then add those options later
|
|
2021-11-09 05:14:41
|
just to get this off the ground
|
|
2021-11-09 05:15:40
|
since those are the only two I absolutely am certain I want to expose
|
|
2021-11-09 05:15:49
|
(other than `-threads`)
|
|
|
|
_wb_
|
2021-11-09 05:16:02
|
I think that makes sense
|
|
|
|
Scope
|
2021-11-09 05:16:21
|
Yep and `-q` mapping
|
|
|
|
Traneptora
|
2021-11-09 05:17:13
|
oh yea, and `-q`
|
|
2021-11-09 05:17:24
|
only issue with `-q` is do I want to wait for libjxl to implement its own mapping
|
|
2021-11-09 05:17:27
|
or do I just map it myself for now
|
|
|
|
Scope
|
2021-11-09 05:24:15
|
For Modualr it is the same as -mquality, for VarDCT I don't think it will change either (except maybe it would be better to use the same calculation method with -d as in libjxl)
|
|
2021-11-09 05:44:09
|
Also for `-q` I don't think there will be any confusion with values for lossless, since it is better to do it the same way as for image format implementations such as WebP (as I remember 100 is also lossless or lossy maximum quality)
And maybe worth adding `-effort` mapping with `-compression_level` (it also exists for many image formats and may be familiar to people), although if it's not too different from the usual ffmpeg values
|
|
|
|
Traneptora
|
2021-11-09 06:07:41
|
I'm looking at `JxlEncoderAddImageFrame`
|
|
2021-11-09 06:07:47
|
is there a way to set the rowstride, i.e. the linesize
|
|
2021-11-09 06:09:40
|
or does that *have* to be packed neatly
|
|
2021-11-09 06:10:23
|
or can I call that function one line at a time?
|
|
2021-11-09 06:10:32
|
like can I call `JxlEncoderAddImageFrame` for a partial image
|
|
|
|
novomesk
|
2021-11-09 06:11:51
|
you can set align:
/** Align scanlines to a multiple of align bytes, or 0 to require no
* alignment at all (which has the same effect as value 1)
*/
size_t align;
} JxlPixelFormat;
|
|
|
|
Traneptora
|
2021-11-09 06:12:12
|
oh, is that how that works?
|
|
2021-11-09 06:12:16
|
I see
|
|
2021-11-09 06:12:30
|
so that's what that does
|
|
2021-11-09 06:29:58
|
if the encoder returns `JXL_ENC_NEED_MORE_OUTPUT`
|
|
2021-11-09 06:30:04
|
is there any way to ask it how much more it needs?
|
|
2021-11-09 06:30:51
|
also, does `JxlEncoderProcessOutput` automatically use the threadparallelrunner if set?
|
|
|
|
_wb_
|
2021-11-09 06:38:57
|
No and yes, iirc
|
|
|
|
Traneptora
|
2021-11-09 06:40:06
|
It really should so you can just allocate that and then try again
|
|
|
|
_wb_
|
2021-11-09 06:42:39
|
I don't know if it actually knows, probably it does so we could add that
|
|
|
|
Traneptora
|
2021-11-09 06:42:56
|
could it add a function "I need at least this much"
|
|
2021-11-09 06:42:57
|
like
|
|
2021-11-09 06:43:03
|
it has to know that it doesn't fit in the buffer
|
|
|
|
_wb_
|
2021-11-09 06:43:34
|
Memory for the compressed bitstream is going to be quite insignificant compared to the overall memory the encoder will be using, so a big difference it won't make
|
|
|
|
Traneptora
|
2021-11-09 06:43:49
|
I see
|
|
|
|
_wb_
|
2021-11-09 06:46:19
|
I would start with a buffer the size of 1 bpp and double the buffer size whenever more is needed
|
|
2021-11-09 06:48:04
|
Or make it 4 bpp for lossy and 12 bpp for lossless and most likely you won't need to realloc
|
|
|
|
Traneptora
|
2021-11-09 07:07:12
|
my plan at this point is to use `4096` to start and do `size = size + size/16 + 32`
|
|
2021-11-09 07:07:19
|
since that's what FFmpeg does internally elsewhere in the codebase
|
|
2021-11-09 07:07:46
|
then, I reuse the buffer every frame
|
|
|
|
_wb_
|
2021-11-09 07:07:49
|
Do you have to produce a full bitstream in memory, or can you stream output?
|
|
|
|
Traneptora
|
2021-11-09 07:07:58
|
I have to produce one packet per frame
|
|
2021-11-09 07:08:15
|
I can stream but not on a sub-frame level
|
|
2021-11-09 07:08:17
|
so only for animation
|
|
|
|
_wb_
|
2021-11-09 07:09:57
|
I see
|
|
2021-11-09 07:10:54
|
I'd just start with w*h/8 bytes to start with, and double it when you need more
|
|
2021-11-09 07:11:38
|
Reallocating very often means you're doing lots of memcpy to copy the old partial buffer to the new one
|
|
2021-11-09 07:13:22
|
17/16 is more than 1 so strictly speaking that is exponential and asymptotically avoids the quadratic complexity, but I would use a value like 3/2 or 2 that is less pathologically exponential
|
|
|
|
Traneptora
|
2021-11-09 07:16:32
|
I'll do 3/2
|
|
2021-11-09 07:16:35
|
I don't like 2 to start with
|
|
|
|
_wb_
|
2021-11-09 07:23:49
|
The input image buffer will be `w*h*12` bytes (3 floats per pixel) and the encoder will probably use at least double that, so in any case even if you need to double it two times to get to 4bpp (which is a lot for lossy), it's still a relatively neglegible chunk of memory
|
|
2021-11-09 07:25:13
|
(even if you pass the input with uint8, the encoder will convert it to float to work with it)
|
|
|
|
Traneptora
|
2021-11-09 08:11:29
|
why would `JxlEncoderAddImageFrame` fail?
|
|
|
|
_wb_
|
2021-11-09 08:15:58
|
Are you asking because it does, or hypothetically?
|
|
|
|
Traneptora
|
2021-11-09 08:16:05
|
because it is, yes
|
|
|
|
_wb_
|
2021-11-09 08:16:43
|
If you build the debug version it might give you a more informative error
|
|
|
|
Traneptora
|
2021-11-09 08:17:06
|
you mean, it will print it?
|
|
2021-11-09 08:17:10
|
cause it just returns JXL_DEC_ERROR
|
|
|
|
_wb_
|
2021-11-09 08:17:37
|
Yes, it might print something
|
|
2021-11-09 08:17:47
|
Or try with this one: https://github.com/libjxl/libjxl/pull/823
|
|
2021-11-09 08:18:07
|
(I just added some more debug prints to that one)
|
|
2021-11-09 08:21:18
|
There could be a few different reasons, and looks like you'll need that patch to get the reason because it currently just returns JXL_ENC_ERROR
|
|
|
|
Traneptora
|
2021-11-09 08:39:43
|
I will have to investigate after work
|
|
|
|
Duplex
|
2021-11-09 10:36:31
|
Anyone have a good repo of test jxl images
|
|
|
Eugene Vert
|
2021-11-09 10:47:31
|
<@356822848641171456>, https://github.com/libjxl/conformance
|
|
|
|
Traneptora
|
2021-11-10 02:43:47
|
oh, btw, I discovered some bugs while writing this wrapper
|
|
|
|
veluca
|
2021-11-10 02:43:57
|
lovely
|
|
2021-11-10 02:44:01
|
can you file issues?
|
|
|
|
Traneptora
|
2021-11-10 02:44:05
|
minor bugs yea that should be fixable
|
|
2021-11-10 02:44:24
|
like JxlEncoderReset doesn't call the `jxlfree()` function provided by the memory manager, rather it calls C stdlib `free()`
|
|
2021-11-10 02:44:37
|
(I think)
|
|
2021-11-10 02:44:40
|
valgrind is telling me as such
|
|
|
|
veluca
|
2021-11-10 02:45:07
|
ah, yea, would be good to fix that
|
|
|
|
Traneptora
|
2021-11-10 02:47:19
|
I haven't investigated the code exactly
|
|
2021-11-10 02:48:11
|
also, I believe `JxlEncoderOptionsCreate` needs to be called again after you call `JxlEncoderReset`
|
|
2021-11-10 02:49:00
|
it says in `JxlEncoderOptionsCreate` that it's assigned to the encoder but it doesn't say that resetting the encoder unassigns and frees it
|
|
|
_wb_
Yes, it might print something
|
|
2021-11-10 02:55:30
|
it's returning `JXL_ENC_ERR_API_USAGE`
|
|
2021-11-10 02:55:37
|
but I'm not entirely sure what I did wrong
|
|
|
|
_wb_
|
2021-11-10 02:56:24
|
try building a debug version of libjxl, it should also printf some error message then
|
|
|
|
Traneptora
|
2021-11-10 02:56:37
|
debug flag?
|
|
2021-11-10 02:56:50
|
is it a configure or cmake flag?
|
|
2021-11-10 02:58:22
|
ah I see i have to remove `-DNDEBUG` and `cmake_build_type=debug`
|
|
2021-11-10 02:58:25
|
one moment
|
|
|
_wb_
try building a debug version of libjxl, it should also printf some error message then
|
|
2021-11-10 03:10:03
|
it's still not printing an error message, did I fail to do a debug build or am I missing something
|
|
|
|
_wb_
|
2021-11-10 03:11:51
|
I haven't actually tried it manually but I suppose if you build with `./ci.sh debug` it should do the right thing
|
|
|
|
Traneptora
|
2021-11-10 03:12:58
|
maybe it's because I capitalized `Debug` as `DEBUG`
|
|
2021-11-10 03:17:59
|
I see, it's reporting this:
|
|
2021-11-10 03:18:01
|
`./lib/jxl/encode.cc:682: Basic info or color encoding not set yet`
|
|
2021-11-10 03:18:06
|
but I did set the basic info
|
|
2021-11-10 03:20:40
|
why would it be telling me I didn't?
|
|
2021-11-10 03:21:47
|
```c
info.uses_original_profile = JXL_FALSE;
if (JxlEncoderSetBasicInfo(ctx->encoder, &info) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo");
return AVERROR_EXTERNAL;
}
jxl_fmt.endianness = JXL_LITTLE_ENDIAN;
jxl_fmt.align = frame->linesize[0];
if (JxlEncoderAddImageFrame(ctx->options, &jxl_fmt, frame->data[0], jxl_fmt.align * info.ysize) != JXL_ENC_SUCCESS) {
status = JxlEncoderGetError(ctx->encoder);
av_log(avctx, AV_LOG_ERROR, "Failed to add Image Frame: %d\n", status);
return AVERROR_EXTERNAL;
}
```
|
|
2021-11-10 03:25:23
|
ah, it's a bug!
|
|
2021-11-10 03:25:49
|
```c
if (!options->enc->basic_info_set || !options->enc->color_encoding_set)
```
|
|
2021-11-10 03:26:05
|
it should say
|
|
2021-11-10 03:27:15
|
```c
if (!options->enc->basic_info_set || !options->enc->color_encoding_set && !options->enc->metadata.m.xyb_encoded)
```
|
|
2021-11-10 03:49:37
|
once I fixed that, it looks like it's working now
|
|
|
|
veluca
|
2021-11-10 03:50:20
|
ah!
|
|
2021-11-10 03:50:25
|
file an issue please? 😄
|
|
|
|
Traneptora
|
2021-11-10 03:52:12
|
I will, yea
|
|
2021-11-10 03:52:37
|
woot!
|
|
|
veluca
file an issue please? 😄
|
|
2021-11-10 03:54:19
|
should I just send a PR? since with that change it works
|
|
2021-11-10 03:54:24
|
instead of opening an issue, I mean
|
|
|
|
veluca
|
2021-11-10 03:56:47
|
yeah that works too
|
|
|
|
Traneptora
|
|
veluca
yeah that works too
|
|
2021-11-10 04:07:27
|
https://github.com/libjxl/libjxl/pull/839
|
|
|
BlueSwordM
|
2021-11-10 04:14:24
|
With your work bombzen, we'll be getting ffmpeg support before AVIF lul.
|
|
|
|
veluca
|
|
Traneptora
https://github.com/libjxl/libjxl/pull/839
|
|
2021-11-10 04:15:50
|
great thanks!
|
|
|
|
Traneptora
|
|
BlueSwordM
With your work bombzen, we'll be getting ffmpeg support before AVIF lul.
|
|
2021-11-10 04:27:45
|
iirc AVIF is already supported because of dav1d
|
|
|
|
Scope
|
2021-11-10 04:29:01
|
AV1 yes, but not AVIF
|
|
|
|
Traneptora
|
2021-11-10 05:30:45
|
it appears libjxl won't automatically enable modular mode if `distance = 0`
|
|
2021-11-10 05:30:52
|
and it just crashes with SIGILL
|
|
|
|
novomesk
|
|
Traneptora
it appears libjxl won't automatically enable modular mode if `distance = 0`
|
|
2021-11-10 06:34:55
|
yes, minimal value is 0,01 for distance.
|
|
|
|
Traneptora
|
2021-11-10 06:35:19
|
no, cjxl automatically uses modular and lossless for d = 0
|
|
|
|
novomesk
|
2021-11-10 06:36:50
|
only with lossless 0 works.
|
|
2021-11-10 06:37:10
|
I had same problem in GIMP.
|
|
|
|
_wb_
|
2021-11-10 06:43:35
|
Maybe file an issue for that, it shouldn't behave like that
|
|
2021-11-10 06:44:24
|
Imo it should either return an error, or preferably just automatically set lossless for you when distance 0 is given
|
|
2021-11-10 06:45:00
|
Also it should do something sensible when distance 0.005 is given - not just crash
|
|
|
|
Traneptora
|
2021-11-10 06:45:18
|
calling `SetLossless` doesn't actually set lossless it just sets distance to 0 and modular to 1
|
|
2021-11-10 06:45:27
|
you can still set distance to 0, but you have to explicitly enable modular
|
|
|
|
_wb_
|
2021-11-10 09:02:42
|
It also has to disable xyb
|
|
|
|
Traneptora
|
2021-11-10 09:21:34
|
oh, yea, I had to do that manually
|
|
2021-11-10 09:21:54
|
I don't think it does that either
|
|
2021-11-10 09:22:07
|
unless it does
|
|
2021-11-10 09:27:15
|
currently I manually call `JxlColorEncodingSetTo(Linear)?SRGB`
|
|
2021-11-10 09:27:19
|
depending of it's float or int
|
|
2021-11-10 09:27:28
|
and then `JxlEncoderSetColorEncoding`
|
|
2021-11-11 11:59:19
|
me, looking at AUTHORS
|
|
2021-11-11 11:59:21
|
> # Please keep each list sorted. If you wish to change your email address please
> # send a pull request.
|
|
2021-11-11 12:03:25
|
AUTHORS be like
|
|
2021-11-11 12:03:45
|
```
# Individuals:
Alexander Sago <cagelight@gmail.com>
Dirk Lemstra <dirk@lemstra.org>
Jon Sneyers <jon@cloudinary.com>
Lovell Fuller
Kleis Auke Wolthuizen <github@kleisauke.nl>
Marcin Konicki <ahwayakchih@gmail.com>
Petr Diblík
....
```
|
|
2021-11-11 12:03:48
|
hmmm, sorted
|
|
|
|
_wb_
|
|
Kleis Auke
|
2021-11-11 01:01:15
|
Haha, I think I cherrypicked my name wrong with commit https://github.com/libjxl/libjxl/pull/797/commits/f4f3e1dd5896a0dd2a89dbe3d0380d7e9058cb68. 😅
|
|
2021-11-11 01:03:06
|
Anyways, the list is also incorrectly sorted further down.
|
|
|
improver
|
2021-11-11 06:33:19
|
yeh im guilty for just adding my stuff at the end but not alone in that
|
|
2021-11-11 06:34:37
|
not really sure if there's really a point of keeping it sorted
|
|
|
|
_wb_
|
2021-11-11 07:51:23
|
If it's not sorted but always added at the end, you can see who were first to contribute
|
|
2021-11-11 07:51:45
|
If it's sorted there is effectively no information about order given
|
|
2021-11-11 07:52:26
|
Either way it doesn't really matter much I guess
|
|
|
|
fab
|
2021-11-11 08:35:28
|
jpeg xl is good but the bad is that is highlights gives too much importance to the image
|
|
2021-11-11 08:35:59
|
and especially if you don't use s9 is pronounced
|
|
2021-11-11 08:36:20
|
also for the build i downloaded today in doom9 jamaika
|
|
2021-11-11 08:37:22
|
d 1 means just visible to autistic like they can see 24x24 dark boxes less evidenced
|
|
2021-11-11 08:37:39
|
but to all the image it increases the bpp
|
|
2021-11-11 08:38:15
|
avif build i downloaded same from jamaika had minimum banding possible added on top of image
|
|
2021-11-11 08:38:40
|
but it not added external artifacts as patches
|
|
2021-11-11 08:40:46
|
like if you have a painting has the frame with added artifacts with something as
|
|
2021-11-11 08:40:52
|
|
|
2021-11-11 08:41:51
|
jpeg xl is good but need some changes obviously
|
|
2021-11-11 08:42:43
|
d 3.5 with this jamaika doomnine encode means exactly 3.5 as aut peceive shapes
|
|
2021-11-11 08:43:18
|
nomal people will have lowa file sizes and will be happy
|
|
2021-11-11 08:44:03
|
also it adds some of vp9 artifacts
|
|
|
|
_wb_
|
2021-11-11 08:45:21
|
I don't understand any of the above
|
|
|
|
fab
|
2021-11-11 08:45:26
|
ok
|
|
2021-11-11 08:46:00
|
basically i downloaded a build of cjxl in doom9 forum
|
|
2021-11-11 08:46:12
|
today i did
|
|
2021-11-11 08:47:05
|
but as i read many articles from jyrki
|
|
2021-11-11 08:47:13
|
i guess this was the intention of distance
|
|
2021-11-11 08:48:41
|
so basically the image looks same to aut but with strange vp9 and too much importance to the images
|
|
2021-11-11 08:49:35
|
obviously i tried at d1 i also described avif (downloaded from same site
|
|
|
_wb_
I don't understand any of the above
|
|
2021-11-11 08:50:23
|
jyki said fb is inteested in d 3.5 distance
|
|
|
|
_wb_
|
2021-11-11 08:50:49
|
I think they were mostly looking at d2.7, I might be wrong though
|
|
|
Arcane
|
|
|
_wb_
|
2021-11-12 06:12:39
|
500 members!
|
|
2021-11-12 06:37:44
|
Hi <@908204410570686474>, you happen to be the 500th member of this discord 😀
|
|
2021-11-12 06:37:58
|
> Hello! JXL is great! I'm particularly interested in very fast lossless compression (the current "lightning" mode is too slow for me), and compression of 12/14/16 bit Bayer or mono images.
|
|
2021-11-12 06:38:19
|
What's the use case? Replacing camera raw?
|
|
2021-11-12 06:40:27
|
We could make lightning faster, the bitstream can go all the way to basically-uncompressed
|
|
2021-11-12 06:41:44
|
For photo use cases, it might be better to try to make falcon mode faster, so you still get good compression, just faster
|
|
2021-11-12 06:44:18
|
We're still doing some unnecessary stuff in all lossless speed settings: e.g. we always convert every sample from int to float and then for lossless back to int (which is why we can only do up to 24-bit int losslessly).
|
|
2021-11-12 06:47:18
|
Also iirc we always use ANS entropy coding and first compute all tokens to get the histograms, then write thing in reverse order.
|
|
2021-11-12 06:50:15
|
Using fixed prefix codes it could be faster
|
|
|
|
Scope
|
2021-11-12 09:52:25
|
So, now it's possible
https://discord.com/channels/794206087879852103/804008033595162635/808725448325726269
|
|
|
|
_wb_
|
2021-11-12 10:02:26
|
Not yet, it seems:
|
|
2021-11-12 10:02:38
|
|
|
|
|
improver
|
2021-11-12 10:04:49
|
everything about these requirements is disgusting except maybe last one
|
|
|
w
|
2021-11-12 10:05:08
|
ok guys more activity
|
|
2021-11-12 10:05:11
|
more activity!
|
|
|
|
_wb_
|
2021-11-12 10:05:55
|
no idea if this "Partner Program" is even something worth applying for
|
|
2021-11-12 10:06:40
|
https://discord.com/partners
|
|
|
|
improver
|
2021-11-12 10:06:54
|
"""engaged"""
|
|
2021-11-12 10:07:40
|
id rather have stuff at rate i can keep up, not at rate what benefits discord shareholders from engagement metrics
|
|
|
|
_wb_
|
2021-11-12 10:08:13
|
maybe it is nice-ish to have, but certainly not worth artificially inflating whatever indicator they are looking at
|
|
|
|
Scope
|
2021-11-12 10:08:46
|
The most interesting part is the nice and understandable invitation URL
|
|
|
|
improver
|
2021-11-12 10:09:03
|
nothing not nice or not understandable about current one
|
|
|
|
_wb_
|
2021-11-12 10:10:33
|
free nitro and being more discoverable might be nice, but again, no need to start spamming just to get there 🙂
|
|
2021-11-12 10:10:52
|
if organic activity is not good enough, then so be it
|
|
2021-11-12 10:11:09
|
I prefer low but good activity
|
|
|
|
improver
|
2021-11-12 10:11:12
|
current organic activity is good enough. for keeping up, that is
|
|
|
|
Scope
|
2021-11-12 10:11:25
|
I mean <http://discord.gg/jxl> or <http://discord.gg/JpegXL>
|
|
2021-11-12 10:18:38
|
🤔
|
|
2021-11-12 10:20:54
|
So, one Fabian won't be enough
|
|
|
|
_wb_
|
2021-11-12 10:21:37
|
In the past week we had 15 'communicators' and 56 'participators'
|
|
|
|
w
|
2021-11-12 10:26:26
|
i feel like any more than 20 communicators is already too much
|
|
|
|
fab
|
2021-11-12 11:39:04
|
s 0.79 - s 8 fd2 -i 0.12. 14 commits
|
|
2021-11-12 01:07:08
|
that's the setting i'm using
|
|
2021-11-12 01:07:09
|
for %i in (D:\phone\25102021\scan\*.png) do cjxl -s 7 -d 1 %i %i.jxl
for %i in (D:\phone\25102021\scan\*.png) do cjxl -s 6 -q 83.1 --use_new_heuristics -I 0.183 %i %i.jxl
|
|
2021-11-12 01:07:53
|
for some fb images re encoding them i will try the second
|
|
2021-11-12 01:08:13
|
the commit is the one mo271 committed
|
|
2021-11-12 01:14:10
|
-i don't work with second command
|
|
2021-11-12 01:14:36
|
|
|
|
|
embed
|
2021-11-12 01:14:40
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/908706348290695198/FB_IMG_1634994575297.jpg.jxl
|
|
|
|
fab
|
2021-11-12 01:16:37
|
the effect is great
|
|
2021-11-12 01:21:54
|
though jxl is at least five times slowe than it was
|
|
2021-11-12 02:17:26
|
|
|
2021-11-12 02:33:35
|
if you want tue fidelity do 0.929 s 9
|
|
2021-11-12 02:34:44
|
jpeg xl is still in phase on standadization
|
|
2021-11-12 03:50:02
|
i would like to add
|
|
2021-11-12 03:50:04
|
for %i in (D:\pictures\uin\ljt\*.jpg) do cjxl -d 0.529 -s 8 -I 0.879 --patches=0 --epf=2 --faster_decoding=1 %i %i.jxl
|
|
2021-11-12 03:50:10
|
it is much bette
|
|
2021-11-12 03:50:24
|
though file size is bigge
|
|
2021-11-12 03:51:31
|
though my compute could die so i need to do fast encoding
|
|
2021-11-12 03:51:53
|
and s eight would be ten times slowe
|
|
2021-11-12 03:54:35
|
also i don't know if epf two is compatible with fd1
|
|
2021-11-12 03:54:44
|
and patches0
|
|
|
|
NathanO
|
2021-11-12 03:58:10
|
<@!794205442175402004> Yes, the use case is replacing camera raw. Thanks for the suggestions on areas for optimization.
|
|
2021-11-12 03:59:22
|
Can someone tell me how to enable the profiler in libjxl and get a report? Or point me to the right docs? Thanks!
|
|
|
|
Deleted User
|
|
_wb_
In the past week we had 15 'communicators' and 56 'participators'
|
|
2021-11-12 04:03:34
|
Can you change the Arcane bot to derank people by one level if they aren't communicators for two weeks in a row?
|
|
|
|
fab
|
2021-11-12 04:30:47
|
or for selfie use
|
|
2021-11-12 04:30:52
|
for %i in (D:\pictures\uin\ljt\*.jpg) do cjxl -d 0.529 -s 8 -I 0.841 --patches=0 --epf=1 --faster_decoding=1 --intensity_target=263 --photon_noise=ISO100 %i %i.jxl
|
|
|
|
_wb_
|
|
Can you change the Arcane bot to derank people by one level if they aren't communicators for two weeks in a row?
|
|
2021-11-12 04:57:42
|
No idea but I don't think so. But I wouldn't want to force people to be constantly chatty
|
|
|
|
BlueSwordM
|
2021-11-12 05:26:23
|
Indeed. It has to be natural conversations.
|
|
|
|
fab
|
2021-11-12 07:05:15
|
update it could be error in the compiling build of jamaika
|
|
2021-11-12 07:05:21
|
no official version is made
|
|
2021-11-12 07:05:39
|
that mo271 commit is useless
|
|
2021-11-12 07:12:24
|
dont know i will wait final release probably
|
|
2021-11-12 07:12:39
|
o just use this on some selfie with doom nine jamaika build
|
|
2021-11-12 07:12:40
|
https://discord.com/channels/794206087879852103/794206170445119489/908755742679498823
|
|
|
diskorduser
|
2021-11-12 07:24:24
|
Server needs more Fabian!!!! :P
|
|
|
|
Traneptora
|
2021-11-12 08:40:43
|
<@!794205442175402004> what is your end goal when it comes to the setting of the encoder options in libjxl?
|
|
2021-11-12 08:41:08
|
re: your comment on #839
|
|
2021-11-12 08:41:09
|
https://github.com/libjxl/libjxl/pull/839#issuecomment-967042650
|
|
2021-11-12 08:42:29
|
You mentioned this
|
|
2021-11-12 08:43:22
|
> Also you are passing the RGB data in some colorspace, and I would assume it is the same one as the one set with JxlSetColorEncoding.
The docs say that, if you set `uses_orginal_profile = false`, then rather than explicitly call `SetColorEncoding`, it assumes SRGB input
|
|
2021-11-12 08:43:33
|
but it still fails if you don't call `SetColorEncoding`
|
|
2021-11-12 08:43:37
|
directly setting it to SRGB yourself works
|
|
|
|
_wb_
|
2021-11-12 08:57:26
|
Hmyes, but it should also be possible to e.g. encode Display P3 or Rec2100 PQ while using XYB...
|
|
|
|
Traneptora
|
2021-11-12 09:03:02
|
`uses_original_profile` is a bad name
|
|
2021-11-12 09:03:11
|
what it really means is client is setting the color space explicitly
|
|
2021-11-12 09:03:19
|
either by calling `SetColorspace` or `SetICCProfile`
|
|
2021-11-12 09:03:36
|
if you have it set to false, it means there's no color information available
|
|
2021-11-12 09:03:59
|
so the docs tell you it's assuming SRGB input for the RGB you pass it, and enabling the XYB transform internally
|
|
|
|
_wb_
|
2021-11-12 09:04:44
|
It really means use_xyb, I suppose
|
|
|
|
Traneptora
|
2021-11-12 09:04:54
|
`well it's mirror image of that internally
|
|
2021-11-12 09:05:08
|
it literally does `xyb_encoded = !uses_original_profile`
|
|
2021-11-12 09:05:13
|
when you call set_basic_info
|
|
2021-11-12 09:05:17
|
and does nothing else with that variable
|
|
|
|
_wb_
|
2021-11-12 09:05:40
|
I agree it's a bad name
|
|
|
|
Traneptora
|
2021-11-12 09:06:01
|
but in either case, what it then does is it requires you to call setcolorspace, and then promptly ignores whatever you pass to setcolorspace
|
|
2021-11-12 09:06:07
|
which is clearly not intended behavior
|
|
|
|
_wb_
|
2021-11-12 09:06:18
|
I think it shouldn't be ignoring what you pass
|
|
2021-11-12 09:07:17
|
It should allow you to give pixels in different input spaces, not just ignore the colorspace and assume it's linear sRGB
|
|
|
|
Traneptora
|
2021-11-12 09:07:27
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/encode.cc#L678
|
|
2021-11-12 09:07:43
|
this is where it ignores it
|
|
|
|
_wb_
|
2021-11-12 09:08:13
|
Yes, I think that's not very convenient because it means applications have to do the color management
|
|
2021-11-12 09:08:33
|
While libjxl should be able to do Enum colorspaces color management itself
|
|
|
|
Traneptora
|
2021-11-12 09:08:58
|
what if we changed line 678 to say ` if (options->enc->metadata.m.xyb_encoded && !options->enc->color_encoding_set)`
|
|
2021-11-12 09:09:29
|
that way, if the color encoding is set, it will set the color encoding to what you set it to
|
|
2021-11-12 09:09:34
|
and if it's *unset* then it will assume SRGB
|
|
2021-11-12 09:11:04
|
you could even have it say this
|
|
2021-11-12 09:11:13
|
`if (!options->enc->color_encoding_set) {`
|
|
2021-11-12 09:11:47
|
since the entry guard at 658 that I added makes it not possible to hit this line of code with an unset color encoding unless XYB is enabled
|
|
2021-11-12 09:13:29
|
actually, I think I'll add that to my PR
|
|
|
|
_wb_
|
2021-11-12 09:16:14
|
Yes, assuming sRGB if nothing else is specified makes sense. Only allowing sRGB input and just ignoring what was set doesn't make sense to me.
|
|
|
|
Traneptora
|
2021-11-12 09:18:05
|
I pushed that change
|
|
2021-11-12 09:18:28
|
https://github.com/libjxl/libjxl/pull/839/commits/31ba7e091edd9928d650864e19af9c7cddb50f26
|
|
2021-11-12 09:18:45
|
ohey that's my pfp
|
|
2021-11-12 09:18:47
|
and big
|
|
|
Cool Doggo
|
2021-11-12 09:23:54
|
do <url> if you dont want embed
|
|
|
|
Traneptora
|
2021-11-12 09:25:57
|
I'm aware, I can also just click the X if I didn't expect it to be like that
|
|
2021-11-12 09:26:12
|
I was just surprised
|
|
|
|
_wb_
|
2021-11-12 09:35:15
|
Github should make its microbrowser link previews look nicer - just huge profile pics are not the best preview of a pull request...
|
|
|
|
boogerlad.
|
2021-11-13 11:23:53
|
is it possible to store camera raws + a demosaic algorithm in jpeg xl? Would be better than current dngs embedding a cooked jpeg inside in terms of being able to provide a "lossless" preview, and it might be smaller since there are less pixels in a raw than when demosaicked
|
|
|
|
diskorduser
|
2021-11-14 04:39:49
|
algorithm?
|
|
|
|
_wb_
|
2021-11-14 07:04:38
|
jxl itself has no way to specify demosaicing, but that info could be put in a metadata blob
|
|
|
|
boogerlad.
|
2021-11-14 12:26:57
|
nice! then it's up for the application to handle demosaicing. hopefully it catches on 🙂
|
|
|
|
spider-mario
|
2021-11-14 02:40:48
|
in principle, it would have been possible to do that with DNG as well, there must be a reason why they didn’t go that route
|
|
2021-11-14 02:41:56
|
DNG even contains opcodes for lens distortion correction and things like that
|
|
2021-11-14 02:42:30
|
(`OpcodeList3`)
|
|
2021-11-14 02:43:19
|
https://www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf#page=83
|
|
2021-11-14 02:44:50
|
> If bit 1 (the second to least significant bit) is set to 1, the opcode can be skipped when doing “preview quality” processing, and only needs to be applied when doing “full quality” processing.
|
|
2021-11-14 02:44:51
|
interesting
|
|
|
|
_wb_
|
2021-11-14 03:05:07
|
I think it's just convenient for viewing apps to get a simple jpeg instead of having to implement demosaicing and distortion correction and all that
|
|
2021-11-14 03:08:32
|
The new proRAW format Apple has introduced is maybe another approach: if I understand correctly it's basically already demosaiced and all, but it's still high bit depth, and there's info from the camera (like depth maps and other stuff) stored separately. But for a viewer, it's basically just a regular high bit depth image with metadata and aux images it can ignore
|
|
|
|
Traneptora
|
2021-11-15 01:01:10
|
huh, that's interesting
|
|
2021-11-15 01:01:11
|
|
|
2021-11-15 01:01:28
|
it says I committed, when mo271 merged it
|
|
2021-11-15 01:01:45
|
doesn't say "thebombzen authored and mo271 committed"
|
|
2021-11-15 01:02:42
|
given that I don't have write access to the repo
|
|
2021-11-15 01:03:16
|
not that I want it, but github's UI is strange here
|
|
|
|
_wb_
|
2021-11-15 01:03:27
|
It's doing the right thing though
|
|
2021-11-15 01:03:42
|
So I am not complaining
|
|
|
|
Traneptora
|
2021-11-15 01:03:50
|
hm?
|
|
2021-11-15 01:04:16
|
this is what it shows in the mpv, repo, for example, when you merge a PR from someone else
|
|
|
|
_wb_
|
2021-11-15 01:04:38
|
You made the commit, someone else approved it and merged it
|
|
2021-11-15 01:05:19
|
I think there's something else you can do to make a commit while crediting someone else to be the author of that commit
|
|
|
|
Traneptora
|
2021-11-15 01:05:34
|
it might be the difference between "rebase and merge" and "squash and merge"
|
|
2021-11-15 01:05:44
|
which is how we have mpv configured, rebase and merge
|
|
2021-11-15 01:05:49
|
and Im guessing this was was squash and merge
|
|
|
|
haaaaah
|
|
Traneptora
it might be the difference between "rebase and merge" and "squash and merge"
|
|
2021-11-15 06:48:25
|
One preserves history, the other creates a new commit?
|
|
|
|
_wb_
|
2021-11-16 04:42:39
|
https://github.com/libjxl/libjxl/issues/858
So we're now debugging compiler bugs that we hit when compiling the fuzzer, i.e. the tool used just to test the decoder
|
|
2021-11-16 04:43:37
|
gets quite meta when we're no longer working on decoder bugs, but on circumventing bugs in the compiler used to build the thing that helps us find decoder bugs
|
|
|
|
sebseb
|
2021-11-16 08:53:34
|
cd ..
|
|
|
|
_wb_
|
2021-11-17 04:00:01
|
https://github.com/google/oss-fuzz/pull/6837 was merged, yay, clang bug is still there but at least we are avoiding it now instead of letting CI of every pull request fail after 6 hours because clang is stuck in an infinite loop while compiling the fuzz-decoder
|
|
|
|
fab
|
2021-11-18 09:28:11
|
i did
|
|
2021-11-18 09:28:12
|
for %i in (C:\Users\Utente\Documents\hh\*.png) do cjxlnoves -s 8 -d 0.907 -I 0.5 --epf=0 --gaborish=0 --faster_decoding=1 --patches=1 --use_new_heuristics --intensity_target=219 %i %i.jxl
|
|
2021-11-18 09:44:34
|
i'm tying
|
|
2021-11-18 09:44:35
|
for %i in (C:\Users\Utente\Documents\hh\*.png) do cjxlnoves -s 4 -d 0.547 -I 0.356 --epf=0 --gaborish=1 --faster_decoding=1 --patches=0 --use_new_heuristics --intensity_target=253 %i %i.jxl
|
|
2021-11-18 09:53:55
|
is good in evey sense
|
|
2021-11-18 09:54:08
|
but thee is undeexposue
|
|
2021-11-18 09:54:11
|
on selfie
|
|
2021-11-18 09:54:20
|
typical of new heuistics
|
|
2021-11-18 09:54:34
|
jpg ae compessed vey fast
|
|
2021-11-18 09:54:38
|
png ae a bit slow
|
|
2021-11-18 09:55:26
|
it does use 73 x cent of cpu
|
|
2021-11-18 09:55:44
|
jpg
|
|
2021-11-18 09:55:45
|
95,6 MB (100.263.914 byte)
|
|
2021-11-18 09:56:03
|
jxl 36,4 MB (38.203.978 byte)
|
|
|
|
Traneptora
|
2021-11-18 02:55:42
|
oh is that why it failed
|
|
2021-11-18 02:55:46
|
lnao
|
|
|
|
fab
|
2021-11-18 03:11:28
|
i ecommend waiting othe fou commits and doing
|
|
2021-11-18 03:11:30
|
at least
|
|
2021-11-18 03:11:32
|
for %i in (C:\Users\Utente\Documents\et\*.png) do cjxlnoves -j -q 75.581 -s 8 -I 0.351 --epf=1 --gaborish=1 --faster_decoding=2 --patches=0 --use_new_heuristics --intensity_target=253 %i %i.jxl
|
|
2021-11-18 03:11:44
|
even if they ae explicit photos
|
|
2021-11-18 03:11:52
|
fo sue
|
|
2021-11-18 03:13:14
|
i did for %i in (D:\phone\02112021\Screenshotspng\*.png) do cjxlnoves -s 4 -d I0 -I 0.356 --epf=0 --gaborish=1 --faster_decoding=1 --patches=0 --use_new_heuristics --intensity_target=253 %i %i.jxl
|
|
2021-11-18 03:13:50
|
fo re encoding fb images and was pleasantly supised but resolution take an hit
|
|
2021-11-18 03:13:57
|
on photo photogaphic
|
|
2021-11-18 04:22:47
|
.......
|
|
2021-11-18 04:22:59
|
the miacle will happen afte six commits
|
|
2021-11-18 04:23:38
|
at d 1 -s 8 -i 0.724
|
|
|
|
Deleted User
|
2021-11-18 04:26:58
|
Asked your crystal ball?
|
|
|
|
fab
|
2021-11-18 04:38:38
|
i will wait fo nine commits
|
|
2021-11-18 04:39:12
|
i will not compess anymoe
|
|
2021-11-18 05:06:43
|
|
|
2021-11-18 05:06:53
|
This im waiting
|
|
2021-11-18 05:07:28
|
For compressing youtube thumbnails webp
|
|
2021-11-18 05:07:44
|
So YouTube.com screenshots
|
|
2021-11-18 05:08:02
|
Not sure if i can save a lot of space
|
|
2021-11-18 05:08:19
|
Probably i Will do with a new computer
|
|
2021-11-18 05:48:51
|
next release av1enc q 53.03 s 9
|
|
2021-11-18 05:49:12
|
Probably will be Better not sure
|
|
|
|
diskorduser
|
|
fab
i will not compess anymoe
|
|
2021-11-18 07:54:17
|
Pls don't compress any moes
|
|
|
The_Decryptor
|
2021-11-18 11:52:29
|
I have compressed the moes, pray I do not quantize them further
|
|
|
|
fab
|
2021-11-19 01:19:45
|
for %i in (D:\pic\2021a\jpg\insta\*.jpg) do cjxlnoves -j -s 8 -d 3.006 -I 0.622 --epf=0 --gaborish=1 --faster_decoding=4 --patches=0 --intensity_target=253 %i %i.jxl
|
|
2021-11-19 01:19:53
|
compess you instagam photo
|
|
2021-11-19 01:20:10
|
quality isn't impotant
|
|
2021-11-19 01:20:46
|
i do not want moe jpg
|
|
2021-11-19 01:20:57
|
i did many lossless j pg ttansocde
|
|
|
|
diskorduser
|
2021-11-19 02:07:30
|
Look like your keyboard r doesn't work.
|
|
|
|
fab
|
2021-11-19 02:15:54
|
And also many numbers
|
|
2021-11-19 02:16:41
|
On discord av1 audio there is on mobile like 18 columns without the r
|
|
2021-11-19 02:28:14
|
For non Instagram pictures i plan to do at s 5 same settings but two quality improvemrnts commit newer
|
|
2021-11-19 02:28:41
|
I have a folder of JPEG called Xiaomi
|
|
|
|
diskorduser
|
2021-11-19 02:30:17
|
Why are you compressing Instagram pictures at first place?
|
|
|
|
fab
|
2021-11-19 02:36:18
|
Don't know if i replaced folder with bulk rename utility i placed all in a folder
|
|
|
|
Traneptora
|
2021-11-19 11:06:30
|
does anybody have any browser-based JPEG-XL polyfill encoders like the equivalent of flif-poly.js?
|
|
|
190n
|
2021-11-20 12:15:06
|
*en*coder? anyway https://squoosh.app/ has both; idk how easy their wasm version of libjxl is to use standalone.
|
|
|
yurume
|
2021-11-20 02:53:25
|
flif-poly.js seems to be a decoder polyfill
|
|
2021-11-20 02:54:15
|
I personally hope to see a CSS Houdini solution
|
|
|
Blocks
|
2021-11-20 06:14:21
|
i think it would be cool if like, jpg would be replaced with jxl eventually, since JPEG 2000 tried that but only got adopted by movie studios
|
|
|
190n
*en*coder? anyway https://squoosh.app/ has both; idk how easy their wasm version of libjxl is to use standalone.
|
|
2021-11-20 06:14:34
|
squoosh is pretty good for JXL actually
|
|
|
|
190n
|
2021-11-20 06:19:45
|
yeah since it's just libjxl compiled to wasm
|
|
|
|
Hello71
|
2021-11-21 12:19:10
|
is it true that jbrd is always brotli compressed, and exif/xmp/jumbf is optionally compressed but not supported by cjxl yet?
|
|
|
|
_wb_
|
|
|
Blocks
|
2021-11-22 05:50:48
|
okay, i am a fucking noob when it comes to command line tools
but, how would I go about mass encoding a folder of JPEGs into JXL files?
|
|
2021-11-22 05:51:16
|
and should I use wsl for libjxl?
|
|
|
|
diskorduser
|
2021-11-22 08:24:32
|
<@416586441058025472>
|
|
|
|
_wb_
|
2021-11-22 08:36:32
|
What is wsl?
|
|
|
|
Quikee
|
2021-11-22 08:39:58
|
windows subsystem for linux
|
|
2021-11-22 08:41:18
|
that new functionality in Windows where you can run Linux compiled binaries
|
|
|
|
fab
|
|
diskorduser
<@416586441058025472>
|
|
2021-11-22 08:46:46
|
ok
|
|
|
|
diskorduser
|
|
fab
ok
|
|
2021-11-22 09:04:10
|
Help him with your windows commands
|
|
|
|
fab
|
2021-11-22 09:07:36
|
wait fo next build thee haven't been changes othe than patch clamping in one month and half https://github.com/libjxl/libjxl/commit/e4b9d5d770b6b38373ba78b806033539dd204952
|
|
2021-11-22 09:10:57
|
for %i in (C:\Users\Utente\Documents\et*.png) do cjxl -s 7 -d 1 %i %i.jxl
|
|
2021-11-22 09:11:18
|
just put a slash afte the subfolde
|
|
2021-11-22 09:11:24
|
befoe the asteisk
|
|
2021-11-22 09:12:25
|
eencoding fb images do
|
|
2021-11-22 09:12:26
|
https://discord.com/channels/794206087879852103/794206170445119489/910910531148341248
|
|
2021-11-22 09:12:47
|
this fo ecompessing instagam photo
|
|
2021-11-22 09:12:48
|
https://discord.com/channels/794206087879852103/794206170445119489/911244359595360266
|
|
2021-11-22 09:13:12
|
but is not good to me to photo that featues a lot of skin
|
|
2021-11-22 09:14:58
|
this fo phone sceenshots is vey good but it sacifies a lot of quality https://discord.com/channels/794206087879852103/794206170445119489/910827824594690088
|
|
2021-11-22 09:15:41
|
if you want to encode anime i think to wait fo bette implementation
|
|
2021-11-22 09:17:49
|
https://artifacts.lucaversari.it/libjxl/libjxl/
|
|
2021-11-22 09:18:02
|
in this site you can find libjxl softwae
|
|
2021-11-22 09:18:13
|
thee ae compiled builds
|
|
2021-11-22 09:18:37
|
o olde builds:
|
|
2021-11-22 09:18:38
|
https://github.com/libjxl/libjxl/releases/tag/v0.6.1
|
|
2021-11-22 09:18:52
|
this ae taken fom github deploy
|
|