|
_wb_
|
2022-10-30 01:14:59
|
Currently TIFF and PSD are basically used as an interchange format for layered images, but those are proprietary formats
|
|
2022-10-30 01:20:51
|
This is roughly how I see the positioning of jxl
|
|
|
Jim
|
2022-10-30 01:31:59
|
Not just for that.
Lossy is not always the best for text/vector & lossless is not always the best for photographic information without having a large file size.
Having an image with a lossly background layer with a photo in it and one or more lossless layers with text/shapes above that can provide a high-quality output where the text/shapes are crisp, clear, and easy-to-read while the photograph in the back is still lossy which reduces the total size.
|
|
|
|
_wb_
|
2022-10-30 01:34:02
|
Yes, that's also true. Or for captions/logos that can still be removed/translated
|
|
|
|
JendaLinda
|
2022-10-30 01:55:46
|
Do patches have fixed colors or could the colors be changed? For example, is it possible to use patches as a bitmap font to render text in different colors?
|
|
|
|
_wb_
|
2022-10-30 02:04:02
|
They do have fixed colors, but you can still do different colors in a roundabout way: put the rendered font in alpha with a black color (all zeroes in the color channels), encode a frame that is just filled with the color you want and transparent alpha, and then use patches with kAdd blending to set the alpha channel
|
|
2022-10-30 02:10:41
|
The same technique could be used to get a gradient color or using the font as a mask in general
|
|
2022-10-30 02:12:07
|
But these kind of tricks will require a tight integration with authoring tools so they know what the actual font is and where it is used, letting the encoder figure that out from a flattened raster image alone is kind of tricky
|
|
|
|
JendaLinda
|
2022-10-30 02:13:23
|
I see. I thought that might be handy for text mode or tile based graphics like in old computers and game consoles. It seems it would be necessary to create patches of different colors as both foreground and background colors may vary. I get this wasn't the original intention for patches.
|
|
2022-10-30 02:17:00
|
Indeed this would have to be done "by hand". Ordinary graphics editors have usually basic image export. Users often don't know how image formats work.
|
|
|
|
_wb_
|
2022-10-30 02:18:25
|
If both bg and fg color vary, that's not an issue, you just need one extra layer for the bg color
|
|
|
|
JendaLinda
|
2022-10-30 02:21:33
|
Right, but there's only one alpha, so background color can be changed by the underlying layer, but I would need to create patches for different foreground colors.
|
|
|
|
_wb_
|
2022-10-30 02:28:34
|
Well you'd need two layers and three frames total.
First frame: rasterized font, with RGB=0 and A containing the letters (so black on transparent background), kReferenceOnly.
Second frame: background colors in RGB, A=1, zero duration kRegularFrame
Third frame: foreground colors in the RGB, A=0, uses patches from the first frame to draw the text so it becomes a mostly transparent layer with only the text being opaque, kRegularFrame which gets blended with regular kBlend over the background.
|
|
|
|
JendaLinda
|
2022-10-30 02:33:18
|
That's clever. So it could be done, after all, and the file would be very tiny.
|
|
|
|
_wb_
|
2022-10-30 02:41:41
|
Yes, in principle. For something like an emulator of a text-based or sprite-based computer/console, it might be doable to produce screenshots or even video recordings using patches, which would be quite effective and lossless.
|
|
2022-10-30 02:42:48
|
After all they have to emulate the sprite blitting so they know what the sprites are
|
|
|
|
JendaLinda
|
2022-10-30 02:46:41
|
That's right. And the set of tiles is usually fixed per game, so it need to be referenced only once.
|
|
2022-10-30 02:53:07
|
I hope there will be some direct JXL editor for composing/decomposing frames, layers, custom patches and other stuff that ordinary graphics editors just can't do.
|
|
2022-10-30 02:59:08
|
Those can't make use of all features of current picture formats either.
|
|
|
Traneptora
|
2022-10-31 08:54:10
|
man I'm getting really stumped by what I think is a bug in the weighted predictor
|
|
|
|
_wb_
|
2022-10-31 08:56:31
|
the weighted predictor is quite horrible
|
|
2022-10-31 08:56:42
|
are you going by spec, libjxl, or J40?
|
|
|
|
Traneptora
|
2022-10-31 08:57:00
|
well spec at first and when it doesn't work I'm comparing it to libjxl code
|
|
2022-10-31 08:57:19
|
and possibly j40 code
|
|
2022-10-31 08:57:53
|
the issue I'm having here is one specific channel is getting an erroneous maxError value that is causing the MA tree to pick the wrong node
|
|
2022-10-31 08:58:25
|
which requires me to dig way back in the WP tree to figure out what the heck happened
|
|
2022-10-31 08:58:31
|
where does it diverge from the reference code
|
|
2022-10-31 09:47:10
|
ah, okay, finally found it
|
|
2022-10-31 09:47:19
|
the problem was with my ceil(log(1 + p)) function
|
|
|
yurume
|
2022-10-31 09:48:09
|
oh, that's hard to discover
|
|
2022-10-31 09:48:20
|
(I also hit by a similar problem in the past)
|
|
|
|
Traneptora
|
2022-10-31 09:48:44
|
I had `floor(log(1 + p))` set to equal `ceil(log(1 + p)) - 1` provided that `1 + p` was not a power of two
|
|
2022-10-31 09:49:25
|
but I was off-by-one on my check to see if a number is a power of two
|
|
|
Pigophone
|
2022-10-31 09:52:40
|
what's a good way to find the file offsets where the squeeze transform gives me a full image? trying to build a responsive image previewer.
though at the moment I can't seem to get chrome to display more than 1 blurry image before progressively loading 256x256 blocks... so maybe no point...
|
|
|
|
yurume
|
2022-10-31 09:55:26
|
do you want to preview an image by taking an initial part of it? libjxl is not designed to do that, so I think you need to reconsider your approach.
|
|
|
|
Pigophone
|
2022-10-31 09:56:03
|
so, a libjxl limitation at the moment?
|
|
|
|
yurume
|
2022-10-31 09:56:32
|
libjxl essentially assumes that the entire image is eventually going to be available through the stream, and you are breaking that assumption
|
|
|
|
Pigophone
|
2022-10-31 09:57:18
|
I'd like to achieve this
|
|
|
|
yurume
|
2022-10-31 09:57:33
|
I agree that there is a merit in knowing the exact offset for each part of images, but this requires some decoding anyway
|
|
|
|
Pigophone
|
2022-10-31 09:58:00
|
using Service Workers you could actually implement this in browsers without any browser support
|
|
|
|
yurume
|
2022-10-31 09:58:19
|
I think libjxl does have a callback for noting you that a part of relevant image is indeed available
|
|
2022-10-31 09:58:27
|
but web browsers do not expose the full libjxl API anyway
|
|
2022-10-31 09:58:46
|
it only knows if the image is not loaded, being loaded or fully loaded
|
|
|
|
_wb_
|
2022-10-31 09:59:01
|
The best approach is probably to have a wasm bitstream parser that decodes the TOC
|
|
|
|
yurume
|
2022-10-31 09:59:25
|
yeah, and thinking about that I really should port that part of J40 into JS or whatever
|
|
|
|
_wb_
|
2022-10-31 10:00:08
|
making some assumptions like 1) no arbitrary icc profiles are used, 2) it's just a single-frame image, such a TOC parser could be relatively simple
|
|
|
|
yurume
|
2022-10-31 10:00:16
|
because that was *exactly* what I initially wanted to do when I started J40
|
|
|
|
Pigophone
|
2022-10-31 10:03:37
|
hm I don't think this needs any clientside wasm, say you have a full size jxl, but you want to show thumbnails etc, you'd precompute these offsets and put those offsets in your html etc. currently in html there is a `srcset` thing on images to allow the browser to choose how big an image it should display depending on dpi etc, so you'd put those offsets in there.
but anyway just to confirm, there's no way currently to access those very small full images right now in libjxl? I would've hoped the progressive decoder would spit out an image once it hits EOF (or in my case, "virtual EOF" as I'm just cutting the files shorter)
|
|
|
|
Traneptora
|
2022-10-31 10:04:32
|
alright, I'm confused about compositing the passgroups onto the main channel. I have a 512x512 image that's been squeezed so there shouldn't be any out of bounds pixel additions at all
|
|
|
|
yurume
|
2022-10-31 10:04:35
|
libjxl is capable of doing that, but I'm not sure web browsers correctly wired it into their pipeline
|
|
|
|
Traneptora
|
2022-10-31 10:04:40
|
but I've managed to do that somehow
|
|
|
|
Pigophone
|
2022-10-31 10:07:25
|
hmm djxl doesn't want to do it 😦 whereas chrome displays
```
adam@Adam-PC:~/sites/jxl-responsive$ ./djxl --allow_partial_files split_32000.jxl split_32000.png
JPEG XL decoder v0.8.0 506714ed [AVX2,SSE4,SSSE3,Unknown]
couldn't load split_32000.jxl
```
|
|
|
|
_wb_
|
2022-10-31 10:13:39
|
could be loading partial files is currently broken in djxl, maybe open an issue about it
|
|
2022-10-31 10:14:40
|
libjxl/newest chrome should support showing partial jxl files, at least starting at the DC being available
|
|
|
|
Pigophone
|
2022-10-31 10:14:59
|
https://jxl.o-o.au/split.html here's what I have so far
|
|
2022-10-31 10:15:07
|
(scroll)
|
|
|
|
_wb_
|
2022-10-31 10:16:17
|
you'll see that gives different results in current stable chrome (which only has incremental jxl decode) compared to chrome canary (which has progressive jxl decode)
|
|
|
|
Pigophone
|
2022-10-31 10:17:33
|
canary 109, stable chrome 107 same results for me
I'll open an issue about djxl after some more tests
|
|
|
|
_wb_
|
2022-10-31 10:17:56
|
stable on the left, canary on the right
|
|
|
|
Pigophone
|
2022-10-31 10:18:32
|
what version of stable is yours? because on my stable I get what you have on the right. i.e. image at 32000
|
|
|
|
Jim
|
|
Pigophone
using Service Workers you could actually implement this in browsers without any browser support
|
|
2022-10-31 10:18:46
|
It already exists: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl
|
|
|
|
_wb_
|
2022-10-31 10:18:47
|
ah I am still on 106 it seems
|
|
|
|
Pigophone
|
|
Jim
It already exists: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl
|
|
2022-10-31 10:19:08
|
no, that is not what I am implementing.
|
|
|
|
_wb_
|
2022-10-31 10:19:16
|
ah cool so progressive jxl landed in stable already
|
|
|
|
Pigophone
|
2022-10-31 10:20:03
|
with service workers you can do things like:
if the user downloads "file.jxl?stop_at=32000", you can intercept that request, and make a request instead to file.jxl with Range=0-32000.
|
|
2022-10-31 10:20:22
|
then, if the user then wants to download file.jxl, you can intercept that too, provide the bytes you already have immediately from cache, and make another request with Range=32001-
|
|
2022-10-31 10:20:52
|
this means CDNs don't need to do anything, all responsive stuff is done client side (as long as the client knows the offset)
|
|
|
|
_wb_
|
2022-10-31 10:21:08
|
so theoretically we could also show previews before the dc is fully available, it hasn't been exposed in libjxl yet though and it's a bit questionable how useful that really is
|
|
|
|
Jim
|
2022-10-31 10:21:38
|
That has to do with http ranges. Most servers already support that, but not all. Though I don't think there is any check for cache? Not sure if caching works for ranges.
|
|
|
|
Pigophone
|
2022-10-31 10:22:02
|
browsers have only had to do range fuckery with videos before now
|
|
2022-10-31 10:22:21
|
(like downloading the MOOV atom at the end of an mp4 before loading the start)
|
|
|
|
Jim
|
2022-10-31 10:24:54
|
I thought they moved indexes to the front of the video so browsers could use ranges when skipping through the video.
|
|
|
|
Pigophone
|
2022-10-31 10:25:20
|
yeah whenever I make mp4's in ffmpeg I always do `-movflags faststart`.. really should be on by default but oh well
|
|
|
|
Jim
|
2022-10-31 10:26:05
|
Most GUIs I've seen seem to do that automatically unless you tell it not to.
|
|
|
|
Pigophone
|
2022-10-31 10:26:25
|
about caching with ranges, I could be wrong but technically it may not be allowed, they are separate requests, the content could've changed, etc
|
|
2022-10-31 10:26:34
|
(browsers may cheat with videos and just ignore that)
|
|
2022-10-31 10:26:58
|
regardless it doesn't really matter...
|
|
|
The_Decryptor
|
2022-10-31 10:27:29
|
iiuc the range is taken into account when doing validation
|
|
2022-10-31 10:27:44
|
If browsers handle the situation where the resource has changed properly I don't know
|
|
|
|
Pigophone
|
2022-10-31 10:27:49
|
the only way to support real responsive jxl images is either service workers or full browser support. seeing as chrome is being a donkey, I wanted to try service workers
|
|
|
|
Jim
|
2022-10-31 10:27:53
|
Technically it's still just one file, regardless of using a range. A piece of file A that was modified 5 minutes ago should still be cachable.
|
|
2022-10-31 10:35:43
|
When streaming videos first came out, ranges were not widely supported. They created the idea of breaking up videos into roughly 10-second segments in order to get around that issue (and I think it worked better for some reason with mobile devices) - that is where things like DASH and HLS evolved. However, technically those are not really needed as long as it's encoded properly for the web.
|
|
|
|
Pigophone
|
|
_wb_
could be loading partial files is currently broken in djxl, maybe open an issue about it
|
|
2022-10-31 10:37:29
|
I am stupid, djxl works fine with partial files... i was giving wrong filename... it has the same output as chrome, i.e. starts working at 32000 for my sample image
no issue necessary...
|
|
2022-10-31 10:37:58
|
for everything before that I get `Input file is truncated and there is no preview available yet.`
|
|
|
|
Traneptora
|
2022-10-31 10:46:14
|
I'm just very confused about how to composite the final modular image
|
|
2022-10-31 10:46:33
|
I can't tell if I messed up the inverse squeeze or if I messed up the compositing
|
|
|
|
_wb_
|
2022-10-31 11:07:44
|
well maybe one thing you could try is filling the final pre-global-inverse-transforms image (so a bunch of channels that start small with high shift and get twice as large with lower shifts in one dimension) with some silly value like -123456789, and check if at the end none of these values remain (before doing the inverse squeeze)
|
|
|
andrew
|
2022-10-31 03:15:45
|
Is anyone working on a Rust port of libjxl? I’m tempted to start one, maybe even a clean implementation from the spec
|
|
|
BlueSwordM
|
|
andrew
Is anyone working on a Rust port of libjxl? I’m tempted to start one, maybe even a clean implementation from the spec
|
|
2022-10-31 03:25:54
|
<@268284145820631040>
|
|
|
|
yurume
|
2022-10-31 03:26:27
|
I have a long term plan to make a Rust version of J40, but so far I only have a small portion of sample code
|
|
2022-10-31 03:26:57
|
(currently indefinitely delayed due to the fact that I'm looking for jobs)
|
|
|
|
andrew
|
2022-10-31 03:32:03
|
Also, where can I find a copy of the spec or something reasonably close to the spec?
|
|
2022-10-31 03:37:57
|
Oh cool they’re in this Discord
|
|
|
improver
|
2022-10-31 04:07:04
|
please start one
|
|
2022-10-31 04:08:35
|
i kinda played around some of parsing stuff months ago but ended up finding job now
|
|
2022-10-31 04:09:45
|
kinda felt like too big of a scope for me back then as a hobby project, especially with spec being not quite clear in some places and ref impl being kinda hard to read
|
|
|
|
andrew
|
2022-10-31 04:14:24
|
Full disclosure: I have a full time job, have little experience with image encoding, and am easily distracted
|
|
2022-10-31 04:14:39
|
So chances are you’re not going to see something useful for… a while
|
|
|
|
improver
|
2022-10-31 04:27:08
|
you can use j40 as reference now i think, it should be in better shape than it was back then
|
|
|
|
JendaLinda
|
2022-10-31 05:22:58
|
I have a fun hypothetical idea. 7zip can extract pretty much anything. Imagine if 7zip could extract JPEGs stored in JXL.
|
|
|
|
yurume
|
2022-10-31 05:23:39
|
probably already possible with plugins
|
|
|
Kagamiin~ Saphri
|
2022-10-31 06:49:50
|
I'm having a weird issue with this one specific APNG file when trying to encode it in cjxl. For whatever reason it just quits with the message `JxlEncoderAddImageFrame() failed.`, no matter what encode options I choose.
Tried other APNG files and had no issues, but this specific one seems to trigger this problem. And I've just generated it in FFmpeg, in the same way I did for other files that didn't present this issue. Anybody have a clue of what could be going on?
|
|
|
|
_wb_
|
2022-10-31 07:03:57
|
Could be we still didn't implement one of those apng dispose modes in the apng reader?
|
|
|
|
Kagamiin~ Saphri
|
|
_wb_
Could be we still didn't implement one of those apng dispose modes in the apng reader?
|
|
2022-10-31 07:04:19
|
the weird thing is I'm encoding using the same settings
|
|
2022-10-31 07:04:34
|
also is there another way to import animations into cjxl besides APNG and GIF?
|
|
|
|
_wb_
|
2022-10-31 07:12:42
|
No. We should probably add some syntax that just lets you have multiple input images and some timings
|
|
|
Jyrki Alakuijala
|
|
JendaLinda
I have a fun hypothetical idea. 7zip can extract pretty much anything. Imagine if 7zip could extract JPEGs stored in JXL.
|
|
2022-10-31 11:20:55
|
7zip media layer includes jpeg xl's predecessor 'brunsli' for this purpose
|
|
2022-10-31 11:21:39
|
brunsli and guetzli were combined to get the initial version of pik -- then some features were added, like gaborish, xyb, forced progression and adaptive quantization (within pik development)
|
|
2022-11-01 12:35:09
|
I believe the media filter is some sort of plugin
|
|
2022-11-01 12:35:14
|
I don't use 7zip myself
|
|
2022-11-01 12:37:56
|
oh, I didn't know that
|
|
|
|
Traneptora
|
2022-11-01 01:56:36
|
does `mpv` count
|
|
2022-11-01 02:00:27
|
you should report that bug then
|
|
2022-11-01 02:00:31
|
otherwise it will never get fixed
|
|
2022-11-01 02:07:35
|
you could try decoding it with FFmpeg directly, for example
|
|
2022-11-01 02:07:39
|
I'm not sure of the syntax
|
|
2022-11-01 02:08:00
|
do you have a sample file or is this "any JPEG"
|
|
2022-11-01 02:08:32
|
and what is "bugged output"? is it simply incorrect colors or does it look like garbage / i.e. full of artifacts
|
|
2022-11-01 02:23:30
|
try master again, I think this bug was fixed 17 days ago:
|
|
2022-11-01 02:23:30
|
https://github.com/mpv-player/mpv/commit/66e30e7f2f17cd1bbc66161ab6bf60f033af588a
|
|
2022-11-01 02:23:39
|
> In practice, with an Intel vaapi driver, this will result in us
> supporting a handful of extra formats for hwuploads - particularly
> yuv420p (so no need to convert to nv12 first) and various orderings
> of rgb(a).
|
|
2022-11-01 02:24:01
|
given that the log says this: `[vo/gpu-next/vaapi-egl] unsupported VA image format yuv420p`
|
|
|
|
Jyrki Alakuijala
|
2022-11-01 02:34:49
|
it would be ok if there was a GPU XYB, it would nice if the was a GPU XYB with gaborish, it would be great if there was a GPU XYB with EPF and gaborish
|
|
|
|
Traneptora
|
2022-11-01 07:37:25
|
so I just compared the pre-inverse-global-transform output from jxlatte to libjxl and it's identical
|
|
2022-11-01 07:37:34
|
so that means I'm not laying the pass groups improperly
|
|
2022-11-01 07:37:40
|
I'm probably doing something wrong with squeeze
|
|
2022-11-01 07:52:16
|
nope, apparently not!
|
|
2022-11-01 08:10:12
|
apparently I'm outputting the same pixel values out of my squeeze transform
|
|
2022-11-01 08:10:17
|
but there's some sort of postproc that isn't happening
|
|
2022-11-01 08:11:03
|
but somehow the render pipeline in libjxl is making it work properly
|
|
2022-11-01 08:11:05
|
but my code is not
|
|
2022-11-01 08:12:26
|
I'm trying to figure out what I didn't do that it did
|
|
2022-11-01 08:13:47
|
It's not gaborish and it's not EPF, both are disabled
|
|
|
|
_wb_
|
2022-11-01 09:52:39
|
What does your result look like?
|
|
|
|
Traneptora
|
2022-11-01 09:54:25
|
turns out I didn't xyb -> rgb
|
|
2022-11-01 10:00:54
|
!!!!!!
|
|
|
|
_wb_
|
2022-11-01 10:01:42
|
ah, yes lossy modular works in xyb by default
|
|
|
|
Traneptora
|
2022-11-01 10:02:15
|
|
|
2022-11-01 10:02:26
|
Decoded png, output by JXLatte!
|
|
2022-11-01 10:02:40
|
I think that's modular in the bag now
|
|
|
Fraetor
|
2022-11-01 10:02:46
|
Ooh, very good.
|
|
|
|
Traneptora
|
2022-11-01 10:02:55
|
now that XYB is implemented
|
|
2022-11-01 10:03:12
|
currently it only outputs sRGB PNGs.
|
|
2022-11-01 10:03:22
|
out of gamut values are clamped to [0, max]
|
|
2022-11-01 10:03:35
|
where max is 255 or 65535
|
|
2022-11-01 10:07:58
|
Currently implemented in JXLatte:
|
|
2022-11-01 10:09:53
|
1. Full image header and frame header parser implemented.
2. Entropy Streams, LFGlobal, LF Groups, and Pass Groups all implemented.
3. RCT, Palette, and Squeeze all implemented.
4. XYB -> sRGB, with PNG output.
|
|
2022-11-01 10:10:40
|
Not Yet Implemented:
1. VarDCT.
2. Multiple frames. Currently it outputs the last frame only.
3. Splines, Patches, and Noise Parameters.
4. Gab and Epf Restoration Filters.
|
|
2022-11-01 10:11:24
|
I believe this should work for any lossless image encoded by libjxl at this moment though
|
|
2022-11-01 10:11:35
|
Except patches maybe
|
|
2022-11-01 10:12:39
|
I'm very very glad I figured that out
|
|
|
|
_wb_
|
2022-11-01 10:18:27
|
Should also work for fjxl files, or lossless in general
|
|
2022-11-01 10:18:42
|
Except patches
|
|
|
|
Traneptora
|
2022-11-01 10:33:24
|
LF Groups are poorly tested though
|
|
2022-11-01 10:33:27
|
will need more testing
|
|
2022-11-01 10:36:28
|
that means Patches is next on the todo list
|
|
2022-11-02 01:50:24
|
post log?
|
|
2022-11-02 02:42:38
|
try `vaapi-copy`
|
|
2022-11-02 02:42:44
|
I believe it can decode 4:2:0 but can't render it
|
|
2022-11-02 02:43:04
|
it can render 4:4:4 but can't decode it
|
|
2022-11-02 02:43:05
|
go figure
|
|
2022-11-02 04:45:10
|
What kind of parallelization can be done in general? I just implemented decoding Pass Groups in parallel
|
|
2022-11-02 04:45:47
|
but I'm wondering if there's an easier way to parallelize
|
|
|
|
BlueSwordM
|
|
Traneptora
What kind of parallelization can be done in general? I just implemented decoding Pass Groups in parallel
|
|
2022-11-02 04:55:20
|
Well, you could likely decode in slices, yes?
|
|
2022-11-02 04:55:36
|
It couldn't be done all the time, but it could be done.
|
|
|
|
Traneptora
|
|
BlueSwordM
Well, you could likely decode in slices, yes?
|
|
2022-11-02 05:28:32
|
not really for modular, as you go in scanline order
|
|
2022-11-02 05:28:45
|
plus each channel depends on the ANS stream of the previous channel being decoded
|
|
2022-11-02 05:28:53
|
I suppose you could always lazily compute WP
|
|
2022-11-02 05:29:00
|
in case it's needed
|
|
|
|
BlueSwordM
|
2022-11-02 05:29:21
|
Yeah, row-mt could be done.
|
|
|
|
Traneptora
|
2022-11-02 05:29:51
|
not sure how that works with prediction
|
|
2022-11-02 05:31:16
|
I'm interested in parallelizing the globalmodular block because it particularly matters for squeeze
|
|
2022-11-02 05:31:28
|
since squeeze creates a bunch of small channels that all end up in globalmodular
|
|
2022-11-02 06:01:38
|
ugh, apparently still got more bugs to squish
|
|
2022-11-02 06:02:22
|
I bet it's the weighted predictor again <:holyfuck:941472932654362676>
|
|
2022-11-02 06:36:10
|
nope, apparently you have to truncate the final group to the image width/height
|
|
2022-11-02 07:26:43
|
and ants-lossless is decoded now!
|
|
2022-11-02 07:39:22
|
hm, looks like LFGroups are still buggy tho
|
|
|
fab
|
2022-11-02 07:53:47
|
wonder why this was reverted, maybe it looked like cloudinary spam
|
|
2022-11-02 07:53:48
|
https://en.wikipedia.org/w/index.php?title=JPEG_XL&diff=prev&oldid=1116988834
|
|
|
|
Traneptora
|
2022-11-02 07:54:28
|
I reverted that edit because it doesn't meet wikipedia's quality standards
|
|
2022-11-02 07:54:59
|
it also cites no sources
|
|
|
|
fab
|
2022-11-02 07:56:17
|
what was the video of that channel
|
|
2022-11-02 07:56:30
|
ah headless ceato
|
|
2022-11-02 07:56:50
|
https://www.youtube.com/watch?v=8jQoVmD3FDc
|
|
2022-11-02 07:57:13
|
you can find that useful also
|
|
2022-11-02 07:57:14
|
https://fontesk.com/abd-elrady-pro-typeface/
|
|
2022-11-02 07:57:20
|
it was uploaded today
|
|
2022-11-02 07:57:30
|
not sure if it has coding glyphs
|
|
2022-11-02 07:58:24
|
ah is this
|
|
2022-11-02 07:58:26
|
https://www.youtube.com/watch?v=ZpSQYs3YaGI&t=2338s
|
|
2022-11-02 08:02:50
|
but this i think even in file format page of wikipedia is still off topic
|
|
2022-11-02 08:03:02
|
at 35:28
|
|
|
Traneptora
it also cites no sources
|
|
2022-11-02 08:05:06
|
yes wikipedia isn't also the cloudinary site
|
|
2022-11-02 08:05:22
|
it will get immediately removed in less than a second
|
|
2022-11-02 08:05:49
|
even if a dev writes it
|
|
2022-11-02 08:06:49
|
i just wanted to add something more than jpeg.org page
|
|
2022-11-02 08:07:01
|
that was my biggest commit
|
|
2022-11-02 08:08:10
|
it was only a jon copied discourse without any attribution and and or sources
|
|
2022-11-02 08:08:26
|
attached
|
|
2022-11-02 08:09:06
|
i hoped somebody will added the sources but they gave up
|
|
|
|
Traneptora
|
|
fab
it was only a jon copied discourse without any attribution and and or sources
|
|
2022-11-02 08:28:09
|
and that's against wikipedia rules
|
|
|
|
fab
|
2022-11-02 08:54:16
|
I haven't lost anything
|
|
2022-11-02 08:54:33
|
It was unuseful and unhelping
|
|
|
Traneptora
and that's against wikipedia rules
|
|
2022-11-02 09:49:49
|
https://en.m.wikipedia.org/wiki/Special:MobileDiff/1119582044
|
|
2022-11-02 09:50:19
|
New commit I fixed the formattation with proper mothertongue formattation
|
|
2022-11-02 09:50:28
|
And not belgium one
|
|
2022-11-02 09:51:07
|
This probably will get removed
|
|
2022-11-02 09:51:25
|
Wikipedia users hate when there are added characters
|
|
2022-11-02 09:51:45
|
With no content
|
|
2022-11-02 09:52:08
|
+19 characters
|
|
2022-11-02 09:52:47
|
Why not using ,
|
|
2022-11-02 09:53:01
|
And do. Every 28 characters
|
|
2022-11-02 09:53:08
|
English do that
|
|
2022-11-02 09:53:23
|
But that in Italian grammar is proihibited
|
|
|
w
|
2022-11-02 10:49:09
|
can you at least use <#1019989652079394826> for wikipedia talk
|
|
|
|
Traneptora
|
|
fab
New commit I fixed the formattation with proper mothertongue formattation
|
|
2022-11-02 05:50:12
|
don't edit English articles using Italian grammar
|
|
2022-11-02 05:50:22
|
I had to revert it because it wasn't an improvement
|
|
|
|
fab
|
|
Traneptora
I had to revert it because it wasn't an improvement
|
|
2022-11-02 06:00:59
|
How to improve the grammar of the articles
|
|
2022-11-02 06:01:13
|
I feel like there are no,
|
|
2022-11-02 06:01:42
|
To me as italian it's just unreadable
|
|
2022-11-02 06:02:11
|
I like Italian
|
|
2022-11-02 06:02:58
|
You do a huge block of text with only commas and is super readable
|
|
2022-11-02 06:03:05
|
Like it doesn't need.
|
|
2022-11-02 06:03:09
|
Points
|
|
2022-11-02 06:03:29
|
With English it Simply doesn't happen
|
|
2022-11-02 06:03:33
|
On no article
|
|
|
|
yurume
|
|
fab
You do a huge block of text with only commas and is super readable
|
|
2022-11-02 06:03:44
|
no. https://en.wikipedia.org/wiki/WP:PROSE
|
|
|
Fedora
|
2022-11-02 06:03:45
|
did you consider that the english article isn't italian?
|
|
|
|
fab
|
2022-11-02 06:03:52
|
Yes
|
|
2022-11-02 06:03:58
|
Is it ENGLISH.
|
|
|
|
yurume
|
2022-11-02 06:04:39
|
have you ever read wikipedia MoS (a portion linked above)?
|
|
|
|
fab
|
2022-11-02 06:04:58
|
But if you know English why not improve the grammar?
|
|
|
|
yurume
|
2022-11-02 06:05:04
|
if not, please take a time to read all of them
|
|
|
|
fab
|
2022-11-02 06:06:26
|
https://en.m.wikipedia.org/w/index.php?title=JPEG_XL&oldid=1109961846
|
|
|
|
yurume
|
2022-11-02 06:06:26
|
it is not exactly a rule and more of a guideline, but I believe you'd better treat it as a rule
|
|
|
|
fab
|
|
fab
https://en.m.wikipedia.org/w/index.php?title=JPEG_XL&oldid=1109961846
|
|
2022-11-02 06:06:37
|
Look at this
|
|
2022-11-02 06:06:48
|
This was version before all my edits
|
|
2022-11-02 06:07:28
|
No it isn't it
|
|
2022-11-02 06:07:33
|
It is way older
|
|
|
Traneptora
don't edit English articles using Italian grammar
|
|
2022-11-02 06:08:14
|
https://en.m.wikipedia.org/w/index.php?title=JPEG_XL&oldid=1105444803
|
|
2022-11-02 06:08:30
|
20th August 2022
|
|
2022-11-02 06:08:48
|
I removed prose edits without any permission
|
|
2022-11-02 06:09:04
|
And edited all using English and bad italian grammar
|
|
2022-11-02 06:09:31
|
Then two month to correct my mistakes, errors of style etc.
|
|
|
|
yurume
|
2022-11-02 06:10:48
|
I don't know about an Italian grammar, but let me see:
|
|
2022-11-02 06:11:01
|
> [...] but blocks, instead of being restricted to 8×8, come in various sizes (2×2 up to 256×256), non-square shapes (e.g. 16×8, 8×32, 32×64), or can use another transforms (AFV, Hornuss).
|
|
2022-11-02 06:11:20
|
you changed the third comma between "various sizes" and "non-square shapes" to a semicolon
|
|
2022-11-02 06:11:39
|
this is, to my best knowledge, just incorrect
|
|
2022-11-02 06:12:37
|
it parses as: but blocks, ((instead of ...), come in (various sizes, non-square shapes)), or can use another transforms.
|
|
|
|
fab
|
|
|
yurume
|
2022-11-02 06:13:01
|
so if you've changed the *fourth* comma to a semicolon it might be correct, but the third comma can't be changed to a semicolon
|
|
|
|
fab
|
2022-11-02 06:13:04
|
This is the danger I done
|
|
|
|
Traneptora
|
|
fab
To me as italian it's just unreadable
|
|
2022-11-02 06:13:13
|
that's because you don't speak English
it reads completely fine to an English speaker
|
|
|
|
fab
|
|
|
yurume
|
2022-11-02 06:14:36
|
this is becoming overly specific though, please bring this to a forum post
|
|
|
|
fab
|
2022-11-02 06:14:40
|
during the development
|
|
2022-11-02 06:14:46
|
Big error
|
|
2022-11-02 06:14:56
|
Is during developmemt
|
|
2022-11-02 06:15:16
|
Please use ctrl+f to correct this
|
|
|
|
Traneptora
|
2022-11-02 06:19:11
|
I'm wondering how you're supposed to determine the size of pass group channels with odd dimensions
|
|
2022-11-02 06:19:40
|
I have a lossy modular image that has been squeezed a few times, so there's a few channels with vshift and hshift in the order of 1-2
|
|
|
|
_wb_
|
2022-11-02 06:21:52
|
The channel dimensions are given in the squeeze definition, you need that to get the exact dimensions since shift alone does not tell you the parity
|
|
|
|
Traneptora
|
2022-11-02 06:21:52
|
the groupsize is 256x256, but the width of the 2nd and third modular channels in each passgroup are 128, because they have higher hshift
|
|
2022-11-02 06:22:07
|
the actual image is 606 wide
|
|
2022-11-02 06:22:27
|
so the third group in scanline order is 94 pixels overflowing
|
|
2022-11-02 06:23:52
|
after squeezing twice this gives odd numbers
|
|
|
_wb_
The channel dimensions are given in the squeeze definition, you need that to get the exact dimensions since shift alone does not tell you the parity
|
|
2022-11-02 06:28:33
|
but what if they overflow the right side of the image?
|
|
2022-11-02 06:28:43
|
do I need to crop the groups before computing forward squeeze?
|
|
|
|
_wb_
|
2022-11-02 06:43:19
|
First compute full channel dimensions based on squeeze params, then split those channels in groups
|
|
|
|
Traneptora
|
2022-11-02 06:43:36
|
full channel dimensions being before cropping?
|
|
|
|
_wb_
|
2022-11-02 06:48:03
|
Yes, pretend you're working with the full sized modular image you're going to reconstruct
|
|
2022-11-02 06:48:41
|
Apply all the fwd transforms to change the channel list
|
|
|
|
Traneptora
|
2022-11-02 06:49:03
|
when I say before cropping I'm referring to groups overflowing the edge, not the have_crop factor
|
|
|
|
_wb_
|
2022-11-02 06:49:51
|
I mean there are no groups when applying the fwd transforms to obtain the list of channels and their dimensions
|
|
|
|
Traneptora
|
2022-11-02 06:50:01
|
that's true, so I just do that
|
|
2022-11-02 06:50:14
|
and then each of those channels gets split into groups
|
|
2022-11-02 06:52:19
|
are the group dimensions of the channel I'm splitting into groups
|
|
2022-11-02 06:52:28
|
are those dimensions shifted by hshift and vshift, accordingly?
|
|
|
|
_wb_
|
|
|
Traneptora
|
2022-11-02 06:56:28
|
and if the resulting channels are split into groups, how do I calculate when those groups overflow the size of the image?
|
|
2022-11-02 06:59:33
|
or does it only matter if it overflows the size of the channel?
|
|
|
|
_wb_
|
2022-11-02 07:01:00
|
You basically take the group size and position for the shift-0 case, and you shift the positions and the sizes, and then you clamp it to not go outside the channel dimensions
|
|
|
|
Traneptora
|
2022-11-02 07:01:07
|
ah, that did it
|
|
2022-11-02 07:02:00
|
this is what I came up with
|
|
2022-11-02 07:05:45
|
```c
group_width = group_dim >> channel.hshift;
group_height = group_dim >> channel.vshift;
num_cols = ceil(channel.width / group_width);
group_x0 = (group_index Umod num_cols) * group_width;
group_y0 = (group_index Idiv num_cols) * group_height;
if (group_width + group_x0 > channel.width) group_width = channel.width - group_x0;
if (group_height + group_y0 > channel.height) group_height = channel.height - group_y0;
```
|
|
2022-11-02 07:07:13
|
per-channel
|
|
2022-11-02 07:08:28
|
and there we go!
|
|
2022-11-02 07:08:31
|
unusual dimensions
|
|
2022-11-02 07:08:39
|
(I don't currently respect the Orientation field, that's a TODO)
|
|
2022-11-02 07:11:14
|
I'd recommend elaborating on what to do in these scenarios since "width, height, x0, and y0 are shifted by hshift and vshift" is about how much text is in the spec
|
|
2022-11-02 07:11:46
|
it doesn't say what to do if you have odd dimension for example when shifting
|
|
|
|
_wb_
|
2022-11-02 07:28:02
|
Yeah I agree the spec is a bit too vague on this
|
|
|
spider-mario
|
2022-11-02 08:12:35
|
even after rotating the bench upright, I thought it was supposed to face the left side of the image
|
|
2022-11-02 08:12:38
|
am I misremembering?
|
|
2022-11-02 08:12:48
|
or is the orientation tag able to transpose as well?
|
|
|
|
_wb_
|
2022-11-02 08:26:40
|
It can do that, yes.
|
|
2022-11-02 08:27:46
|
There are 8 orientations, so there are flips/transposes too, not just rotations
|
|
|
|
Traneptora
|
2022-11-02 09:27:23
|
I believe this is the correct orientation of the bench, however I decoded the vardct bench to pixels and reencoded in lossy modular as a test
|
|
|
|
_wb_
|
2022-11-02 09:31:50
|
The one in the conformance repo is intentionally oriented wrong iirc
|
|
|
|
Traneptora
|
2022-11-02 10:57:41
|
it is, to test the orientation header
|
|
2022-11-02 10:58:06
|
this image was produced by djxling that to PNG, and then re-encoding that with cjxl
|
|
2022-11-02 10:58:16
|
this is not the conformance sample, but just the same pixel data
|
|
|
Dr. Taco
|
2022-11-02 11:24:05
|
Looking over this: https://cloudinary.com/blog/the-case-for-jpeg-xl there are a few charts not loading, had to open in a new tab and edit the URL to get them to load
|
|
|
|
yurume
|
2022-11-03 03:05:05
|
same for me, most images do not load.
|
|
|
|
andrew
|
2022-11-03 03:17:45
|
seems like a Cloudinary problem
|
|
|
|
Traneptora
|
2022-11-03 06:29:57
|
wondering if I should work on patches next to finish modular-mode decoding, or start on VarDCT?
|
|
2022-11-03 06:30:24
|
or even work on cascading frames, although I'm not sure I have samples for that
|
|
2022-11-03 07:28:43
|
how do you efficiently compute whether or not WP is needed if there's a palette transform with nbDeltas > 0?
|
|
2022-11-03 07:28:54
|
and d_pred == 6
|
|
2022-11-03 07:29:08
|
do you just treat it as though it's necessary if `d_pred == 6`?
|
|
|
|
yurume
|
2022-11-03 07:49:05
|
both libjxl and J40 checks for the presence of particular node to check if wp should be run or not
|
|
2022-11-03 07:49:42
|
for palettes I would have to check the source code but I have an upcoming interview in next 10 minutes so I'll take a look later 😉
|
|
|
|
_wb_
|
|
Dr. Taco
Looking over this: https://cloudinary.com/blog/the-case-for-jpeg-xl there are a few charts not loading, had to open in a new tab and edit the URL to get them to load
|
|
2022-11-03 08:35:35
|
Strange, what browser are you using?
|
|
2022-11-03 08:42:58
|
I am currently in holidays so only have my phone. On Android chrome the charts load fine.
|
|
|
|
The_Decryptor
|
2022-11-03 08:55:37
|
They load fine for me in Edge on Win11
|
|
|
pshufb
|
|
yurume
for palettes I would have to check the source code but I have an upcoming interview in next 10 minutes so I'll take a look later 😉
|
|
2022-11-03 08:56:23
|
good luck!
|
|
|
|
yurume
|
|
_wb_
Strange, what browser are you using?
|
|
2022-11-03 09:55:10
|
Firefox 107.0b5, Windows 10
|
|
|
pshufb
good luck!
|
|
2022-11-03 10:01:57
|
thank you, though I've already finished it 🙂
|
|
|
|
_wb_
|
|
yurume
Firefox 107.0b5, Windows 10
|
|
2022-11-03 10:35:22
|
Is that stable or nightly?
|
|
|
|
yurume
|
|
|
_wb_
|
2022-11-03 10:35:51
|
Could it be that you get issues because the jxl flag is enabled but jxl decode doesn't actually work?
|
|
|
|
yurume
|
2022-11-03 10:36:36
|
that's actually a good question, I turned image.jxl.enabled on many years ago, let me check if this makes any difference
|
|
2022-11-03 10:36:50
|
oh indeed
|
|
|
|
_wb_
|
2022-11-03 10:37:11
|
Yeah if firefox claims it accepts jxl, then we send it a jxl
|
|
2022-11-03 10:37:21
|
That's a firefox bug though
|
|
|
|
yurume
|
2022-11-03 10:37:44
|
so Firefox stable or beta emits `Accept: image/jxl` even when it doesn't support it at all but the preference is turned on somehow
|
|
2022-11-03 10:37:47
|
huh.
|
|
|
|
_wb_
|
2022-11-03 10:39:55
|
Yeah since the accept header stuff is probably not disabled, just the libjxl integration (which is what adds binary size)
|
|
2022-11-03 10:40:47
|
They should just not show the flag if the feature is not actually compiled in
|
|
2022-11-03 11:22:10
|
I don't think Mozilla execs want to play the hero that saves the day — they won't want to antagonize Chrome and the AOM.
|
|
|
|
Jim
|
2022-11-03 11:25:44
|
I know there was a bug previously where it was emiting the jxl accept in stable (ended up being discovered when people went to Shopify which I think is using jxl for images and nothing was showing) but I think they fixed it. If you enable the flag in stable it won't work because they don't actually have the codec compiled in. It only works in nightly I believe.
|
|
|
_wb_
I don't think Mozilla execs want to play the hero that saves the day — they won't want to antagonize Chrome and the AOM.
|
|
2022-11-03 11:28:10
|
They antagonize Google all the time and shame them for various things (Manifest V3 and various other security-related API issues). Not that it matters, Google still goes ahead with most of it. Likely more to do with not having the resources available to work on it unless they must (and the internal strife leaning against adding new formats).
|
|
|
|
_wb_
|
2022-11-03 12:09:25
|
Yeah but AOM is something Mozilla also played a big role in - the Daala team was at Mozilla and influenced AV1. Now they don't really have a codec team anymore though, so it could indeed be a resources issue too.
|
|
|
|
Traneptora
|
2022-11-03 12:56:11
|
maybe if chrome goes ahead with removing adblock extensions from the chrome store, people might actually leave en masse
|
|
2022-11-03 12:56:24
|
that could very well be the killing feature
|
|
|
|
Jyrki Alakuijala
|
2022-11-04 02:51:58
|
ex Daala people were proud of getting CDEF into AV1 -- people advising to use AVIF propose to turn CDEF off as the first improvement -- something went wrong there, if someone knows more about it I'd like to learn
|
|
2022-11-04 03:00:48
|
we made three separate attempts (two with the same engineer, one with another more experienced engineer) to have CDEF like (but more directed to high quality) efforts and none of them was making a difference worth the added complexity
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
ex Daala people were proud of getting CDEF into AV1 -- people advising to use AVIF propose to turn CDEF off as the first improvement -- something went wrong there, if someone knows more about it I'd like to learn
|
|
2022-11-04 03:25:35
|
Oh, that is actually for an interesting reason.
Aside from rav1e, all the CDEF RDO in AV1 encoders implementations are based on optimizing for MSE...
You can see how that can go horribly wrong if you optimize for PSNR.
|
|
|
|
Traneptora
|
2022-11-05 04:52:11
|
and jxlatte supports patches now!
|
|
2022-11-05 04:52:18
|
I believe that concludes lossless support
|
|
2022-11-05 04:52:28
|
assuming Gaborish and Epf aren't used for lossless
|
|
2022-11-05 04:52:33
|
and neither are splines, or noise
|
|
|
|
yurume
|
2022-11-05 04:52:52
|
wow, great!
|
|
|
|
fab
|
2022-11-05 04:55:34
|
great
|
|
|
daniilmaks
|
2022-11-05 06:10:22
|
oh no, fab is also here
|
|
|
|
fab
|
2022-11-05 06:34:24
|
Watch <#805176455658733570> <#806898911091753051> <#822105409312653333>
|
|
|
diskorduser
|
|
oh no, fab is also here
|
|
2022-11-05 06:38:02
|
Fab is everywhere
|
|
|
|
spider-mario
|
|
Traneptora
and neither are splines, or noise
|
|
2022-11-05 06:46:22
|
these two theoretically can, but their design largely assumes XYB so it is unlikely
|
|
|
|
_wb_
|
2022-11-05 06:56:20
|
Splines for lossless probably only makes sense if authoring software emerges that allows artists to draw with splines directly.
|
|
|
|
fab
|
|
|
_wb_
|
2022-11-05 06:58:26
|
Though in theory an encoder could extract splines and gain some compression advantage with them — something I think is more plausible for lossy than for lossless, but it is hard to estimate. It's in any case not an easy thing to pull off.
|
|
|
|
Traneptora
|
2022-11-05 07:31:41
|
you could possibly have a spline frame with an alpha channel and blend but it seems impractical
|
|
|
|
daniilmaks
|
|
fab
Watch <#805176455658733570> <#806898911091753051> <#822105409312653333>
|
|
2022-11-05 08:15:21
|
I meant you're also in this *server*
|
|
2022-11-05 08:15:32
|
I just joined here
|
|
|
|
Traneptora
|
|
_wb_
here's the grayscale image with funky whitepoint
|
|
2022-11-05 09:31:04
|
I'm trying to work on color management now before I start on VarDCT, and I'm getting confused about enums being declarative vs instructional
|
|
2022-11-05 09:32:17
|
i.e. I'm taking the XYB image linked here, but the PNG writer I have maps the XYB data to sRGB/D65 and then writes a PNG with no tags.
|
|
2022-11-05 09:32:47
|
If I want this to look "correct" is the proper way to do it to just write a PNG with the weird white point tagged?
|
|
2022-11-05 09:34:22
|
Since this funky image is XYB, it's supposed to be D65 linear SRGB, because `default_m == true` (i.e. no custom XYB)
|
|
2022-11-05 09:35:08
|
I'm trying to figure out how to write it to a PNG properly so it views properly. should I ignore the tagged white point value?
|
|
2022-11-05 09:36:59
|
but if the enums are supposed to describe the input space *before* being pumped into XYB, then shouldn't X=B=0 be incorrect?
|
|
|
|
_wb_
|
2022-11-06 12:39:35
|
You can ignore the colorspace info if the image uses xyb, it only suggests what you might want to convert it to, not what it is
|
|
2022-11-06 12:39:59
|
Only if the image does not use xyb, then it describes what space the pixel data uses
|
|
|
|
andrew
|
2022-11-06 03:52:50
|
_this is fine_
|
|
|
|
Traneptora
|
2022-11-06 04:20:51
|
full support is the todo list
|
|
2022-11-06 04:20:56
|
so at this moment the big one is VarDCT
|
|
2022-11-06 04:35:11
|
I still need to implement MA tree properties > 15 tho
|
|
|
|
dds
|
2022-11-06 06:24:16
|
Splines for lossy: does anyone have an image that properly showcases the splines feature? E.g. one that uses splines to reduce the compressed size of an image containing individual hairs (as per the JXL presentation) rather than a synthetic image defined from splines.
|
|
|
|
_wb_
|
2022-11-06 02:43:39
|
There was at some point a manually made image like that
|
|
|
|
fab
|
2022-11-06 02:47:32
|
https://en.m.wikipedia.org/wiki/Special:MobileDiff/1120348578
|
|
2022-11-06 02:47:41
|
<@853026420792360980>
|
|
2022-11-06 02:47:48
|
Could you correct this?
|
|
2022-11-06 02:48:01
|
I added jxlatte and libjxl tiny
|
|
2022-11-06 02:48:24
|
I don't know if yours has attribution and if libjxl was precedently apache
|
|
2022-11-06 02:48:31
|
So i deleted all
|
|
2022-11-06 02:48:59
|
And libjxl tiny in the part copied from jon without references I don't Remember the tweet
|
|
2022-11-06 02:49:05
|
Was written
|
|
2022-11-06 02:49:50
|
Ah
|
|
2022-11-06 02:49:53
|
Splines for coding e.g. hairs (not yet used by the reference encoder).
|
|
2022-11-06 02:49:57
|
Italian
|
|
2022-11-06 02:50:08
|
spline per la codifica, ad es. capelli (non ancora usate nel codificatore di riferimento); spline e rumori sono rimossi in Libjxl-tiny.
|
|
2022-11-06 02:50:31
|
Spanish
|
|
2022-11-06 02:50:33
|
splines para codificar, p. pelos (todavía no utilizados en el codificador de referencia), splines y ruidos se eliminan en Libjxl-tiny.
|
|
2022-11-06 02:50:41
|
Plus some more errors
|
|
2022-11-06 02:50:53
|
I'm confusing Wikipedia
|
|
2022-11-06 02:51:52
|
I wanted only to contact bombzen
|
|
2022-11-06 02:57:56
|
ok
|
|
|
|
dds
|
|
_wb_
There was at some point a manually made image like that
|
|
2022-11-06 03:35:27
|
Ah great - do you know where it is? I suppose the real question here is 'how much has it been demonstrated that splines are useful for real-world images, rather than just straight lines etc' given the relatively large code / spec footprint of the feature
|
|
|
|
_wb_
|
2022-11-06 03:44:17
|
not that much, imo — I somewhat opposed it, initially, for this reason: not enough justification since not used in current encoder.
The spec/code footprint is not that bad though, and I do think it's one of those future-proofing features that can become useful later.
It's clearly not easy to make an encoder for it (which is why it hasn't been done yet), but the decode side is not too bad, and what is clear is that for relatively long thin lines (straight or curved), it is very complementary to DCT: DCT is very inefficient on those, requiring basically all coeffs to be nonzero, and has a high risk of producing interrupted / partially blurred away lines and/or ringing. Splines are a way more compact representation of such image features, and the way they are defined (with varying colors and sigma/'thickness'), they can in principle be useful for photographic images too.
|
|
2022-11-06 03:47:52
|
It's one of those things where making an encoder for it is hard, but it doesn't seem outrageously impossible either: after all, vectorization of raster images is a thing, and it seems feasible to apply similar techniques and some heuristics to detect some of the stronger thin lines in an image, represent a good approximation of them as splines, subtract them from the image and get left with a residual image that will compress much better.
|
|
2022-11-06 03:52:09
|
Originally we had a specific coding tool for dots as well (representing small elliptic shapes, like e.g. stars in a picture of a night sky) and for that we did have an encoder to extract dots, but I opposed that because it added quite some code and spec footprint for what I considered to be an overly specific coding tool, and after some experimentation we decided to drop it as a decoder-side special coding tool and to use patches for this instead.
|
|
2022-11-06 03:54:32
|
But splines were kept because representing a long curly line with antialiasing using modular patches would still be quite expensive compared to doing it with splines (unlike dots that were just a few pixels big so doing it with a special representation doesn't save much compared to doing it with small patches).
|
|
2022-11-06 04:00:11
|
<@604964375924834314> designed splines so he can probably tell you more about its history and how its usefulness was assessed. I think we made a good decision by keeping splines and removing dots — both are aimed at the same thing (special coding tool for stuff that is hard for DCT), but one seemed a bigger potential compression win (or rather, compression vs spec complexity trade-off) than the other. It's always hard though to make decisions on coding tools that you're putting in the decoder just for future-proofing and not for immediate use.
|
|
|
|
dds
|
2022-11-06 04:07:05
|
I can see the intended advantages but it's not obvious to me that they'll work for high-fidelity compression. e.g. suppose we want quality d=1. Once you remove the spline, is it definitely cheaper to encode the residual noise than the hair you started with? A single example of this done well (however expensive the encode process) would convince me.
|
|
2022-11-06 04:07:44
|
One of the general concerns I have about JXL is the highly variable decoding speed - if you're malicious, it's easy to construct an image that takes a long time to decode (recall I posted a splinebomb image a while ago). Splines are an easy way to make decodes go slowly - even with the current Profiles and levels - so I'm more in the 'opposed to splines' camp at present.
|
|
|
|
improver
|
2022-11-06 04:08:35
|
splines and more advanced use of patches feel like pretty good research area for AI-based coding
|
|
|
|
dds
|
2022-11-06 04:23:57
|
Agreed - and ML techniques never cease to impress. My point is that IMO there's a minimum 'proof of utility' hurdle that should be demonstrated before a feature is committed, so I was hoping that someone had created a proof-of-concept. <@604964375924834314> can you tell me anything about the history / rationale behind this feature?
|
|
|
|
spider-mario
|
2022-11-06 04:25:30
|
it was indeed for features such as hair that are harder to encode with DCT; I’ll see if I can dig up the hand-crafted examples later but they seemed relatively promising
|
|
|
|
dds
|
2022-11-06 04:27:40
|
thanks!
|
|
|
|
andrew
|
2022-11-06 04:33:44
|
I don’t think you need AI/ML for splines
|
|
2022-11-06 04:34:39
|
Classical computer vision techniques (OpenCV?) can probably get you quite far
|
|
|
|
BlueSwordM
|
|
andrew
Classical computer vision techniques (OpenCV?) can probably get you quite far
|
|
2022-11-06 04:37:26
|
Just edge masking would help a lot, as we aren't dealing with temporally complex video sequences.
|
|
|
|
_wb_
|
2022-11-06 04:50:13
|
yes, detect edges and filter for those that are strong and thin enough, then apply a path tracing vectorization algorithm, then fit the sigma and color to match as closely as possible
|
|
2022-11-06 04:51:02
|
it would make most sense in cases where the residual noise can just get quantized away and the end result still looks better than what dct would do
|
|
|
|
Traneptora
|
2022-11-06 05:11:00
|
what would be the simplest way to encode splines? as they're rendered atop the frame it might make sense to calculate splines, subtract the computed splines from the image, put them on a separate frame, and use kBlendAdd
|
|
|
|
spider-mario
|
2022-11-06 05:45:13
|
I might be missing something – what would be the purpose of putting them on a separate frame?
|
|
|
|
Traneptora
|
2022-11-06 06:21:06
|
so you can use blendAdd
|
|
|
|
spider-mario
|
2022-11-06 06:23:26
|
but splines are already additive
|
|
|
|
Traneptora
|
2022-11-06 06:26:56
|
ah, nvm then
|
|
2022-11-06 06:30:53
|
I think `benchmark_xl` fails with `--save_decompressed`
|
|
2022-11-06 06:30:57
|
try any rgb24 png
|
|
2022-11-06 06:31:05
|
I used white.png here but it can be any
|
|
2022-11-06 06:31:08
|
`benchmark_xl --input="white.png" --save_decompressed --save_compressed --debug_image_dir="/tmp" --output_dir="/tmp" --codec=jxl:d1`
|
|
2022-11-06 06:31:24
|
```
benchmark_xl v0.8.0 26a3570d [AVX2]
4 total threads, 1 tasks, 0 threads, 4 inner threads
./lib/extras/dec/color_hints.cc:54: No color_space/icc_pathname given, assuming sRGB
./lib/extras/codec.cc:172: PNG only supports up to 16 bits per sample
./lib/jxl/dec_external_image.cc:259: JXL_CHECK: float_out ? bits_per_sample == 16 || bits_per_sample == 32 : bits_per_sample > 0 && bits_per_sample <= 16
Illegal instruction (core dumped)
```
|
|
2022-11-06 06:36:28
|
error goes away without `--save_decompressed`
|
|
|
|
_wb_
|
2022-11-06 06:51:09
|
Looks like it's decoding to a float32 buffer and the png encoder no longer knows what to do with that
|
|
|
|
afed
|
2022-11-06 06:54:06
|
```Error in jxl:d1 codec
tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary)```
```lib\jxl\dec_external_image.cc:260: JXL_CHECK: float_out ? bits_per_sample == 16 || bits_per_sample == 32 : bits_per_sample > 0 && bits_per_sample <= 16```
|
|
|
|
_wb_
|
2022-11-06 06:55:06
|
Could someone open an issue for this? Should be an easy fix
|
|
|
|
Traneptora
|
|
afed
```Error in jxl:d1 codec
tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary)```
```lib\jxl\dec_external_image.cc:260: JXL_CHECK: float_out ? bits_per_sample == 16 || bits_per_sample == 32 : bits_per_sample > 0 && bits_per_sample <= 16```
|
|
2022-11-06 08:53:14
|
you need a debug build to get past this part
|
|
2022-11-06 08:53:18
|
and I'll open an issue in a moment, sure
|
|
|
_wb_
Could someone open an issue for this? Should be an easy fix
|
|
2022-11-06 09:11:23
|
https://github.com/libjxl/libjxl/issues/1872
|
|
|
|
_wb_
|
2022-11-06 09:12:28
|
Thanks!
|
|
|
|
Traneptora
|
2022-11-06 09:21:49
|
Just want to double check to make sure I've read the upsampling correctly
|
|
2022-11-06 09:23:04
|
for every `kx, ky, ix, iy` where `kx, ky` range from `[0, k)`, and `ix, iy` range from `[0, 5)`
|
|
2022-11-06 09:23:59
|
you use the pseudocode to calculate the index, and then get a weight by feeding that weight into `upk_weights` in the image header
|
|
2022-11-06 09:25:05
|
so for each pixel (kx, ky) in that `k * k` block, you get a 5x5 matrix of weights corresponding to `ix` and `iy` coordinates
|
|
2022-11-06 09:26:30
|
and you just sum over `ix, iy` from 0 to 5 of `weight(ix, iy) * sample(ix, iy)` where the corresponding sample in the original assuming the matrix is centered at the original pixel
|
|
2022-11-06 09:30:31
|
is this correct?
|
|
|
|
_wb_
|
2022-11-06 09:47:08
|
yes
|
|
2022-11-06 09:49:55
|
the concept is relatively simple, to upsample 1 original pixel to k x k new pixels, you take a 5x5 window around the original pixel, and then every one of the k x k pixels gets its own 5 x 5 weights
|
|
2022-11-06 09:51:29
|
we allow this thing to be nonseparable, but we do constrain it to respect some symmetries, so we don't need to signal all 25k^2 weights explicitly
|
|
|
|
Traneptora
|
2022-11-06 09:55:45
|
I just wanted to make sure I was reading the spec correctly
|
|
2022-11-06 09:55:53
|
but it looks like it's clear in this case
|
|
2022-11-07 02:47:48
|
I noticed that `blending_info.source` is u(2)
|
|
2022-11-07 02:48:08
|
does that mean that only the first four frames can be referenced?
|
|
2022-11-07 02:49:06
|
and are those reference frames supposed to be only regularframe or skipprogressive only?
|
|
|
|
_wb_
|
2022-11-07 03:20:34
|
The indices are in `Reference[]`, which gets overwritten whenever a frame gets saved
|
|
|
|
Traneptora
|
2022-11-07 03:27:30
|
I see, so `Reference` is an array of size 4
|
|
2022-11-07 03:27:50
|
`save_as_reference` tells you where to save that frame
|
|
2022-11-07 03:28:00
|
most of the time `save_as_reference == 0` which effectively means "dont' save"
|
|
|
|
_wb_
|
2022-11-07 03:39:23
|
uhm, iirc that means don't save if it's a regular frame, but if it's a reference-only frame, it saves in slot 0
|
|
2022-11-07 03:41:31
|
ah or no, if it's a zero-duration frame (like reference-only frames or layers), then it does save in slot 0, only if it's a non-zero-duration (animation) frame then save_as_reference == 0 means "don't save"
|
|
|
|
Traneptora
|
2022-11-07 03:43:22
|
so if `save_as_reference == 0` then it' saved in `Reference[0]` if and only if `duration == 0`
|
|
|
|
_wb_
|
2022-11-07 03:46:08
|
spec says:
If either save_as_reference != 0 or duration == 0, and !is_last and frame_type != kLFFrame, then the samples of the decoded frame are recorded as Reference[save_as_reference] and may be referenced by subsequent frames.
|
|
|
|
Traneptora
|
2022-11-07 03:46:26
|
ah I missed that
|
|
|
|
_wb_
|
2022-11-07 03:51:20
|
it's a pretty powerful mechanism that kind of generalizes the dispose modes you have in gif/apng: there after each frame, the canvas state you have as a basis for the next frame is either how things are after blending the current frame (APNG_DISPOSE_OP_NONE), how they were before blending the current frame (APNG_DISPOSE_OP_PREVIOUS), or the canvas is cleared to all zeroes (transparent black, APNG_DISPOSE_OP_BACKGROUND).
|
|
2022-11-07 03:52:31
|
instead of having dispose modes, jxl allows an encoder to choose when to save in one of the four slots, and then each frame can select which of those to use as a basis (that's the blending_info.source)
|
|
2022-11-07 03:59:41
|
of course the current libjxl encoder is not at all using this bitstream feature to encode animations more effectively, but it's one of those things that don't complicate the spec/decoder code much while it could potentially be quite powerful for specific types of animations, say something where (patch-blitted) sprites are moving on top of two different backgrounds (say an animation of a phone call between two people, where it cuts between two scenes in an alternating way)
|
|
|
|
Traneptora
|
2022-11-07 04:31:21
|
I'm confused about `save_before_ct`: Patches are computed before color transforms, but patches requires references
|
|
2022-11-07 04:31:31
|
how does `save_before_ct == false` work with patches?
|
|
|
|
_wb_
|
2022-11-07 04:42:10
|
it does not make sense to take a Reference frame as a source for patches if save_before_ct was false when storing that frame, since then you would end up blending RGB values on top of XYB values
|
|
2022-11-07 04:43:39
|
so the typical pattern would be to have a kReferenceOnly frame with save_before_ct == true, which can then be used as a source for patches on a regular frame that could be a save_before_ct == false frame that then gets used as a source for frame blending
|
|
|
|
Traneptora
|
2022-11-07 04:43:50
|
is that an illegal bitstream?
|
|
2022-11-07 04:44:00
|
or does it just produce nonsensical output
|
|
|
|
_wb_
|
2022-11-07 04:44:21
|
I think with the current spec it's not illegal but it would be nonsensical and I'm not sure if libjxl will allow it
|
|
2022-11-07 04:44:37
|
<@179701849576833024> do you know?
|
|
|
|
Traneptora
|
2022-11-07 04:45:12
|
can I treat it like Undefined Behavior? basically not forbidden but the output is unspecified
|
|
|
|
veluca
|
2022-11-07 04:45:18
|
Ask me again in a few hours, I got some eye drops and I am unable to read properly 😂
|
|
2022-11-07 04:45:53
|
But I would prefer we avoid to make *anything* UB
|
|
|
|
_wb_
|
2022-11-07 04:46:33
|
the intention is that frame blending always happens in RGB (so with both bottom and top layer after ct), while patch blending always happens in the 'native' space (so with both source and current frame before ct)
|
|
|
|
veluca
|
2022-11-07 04:47:48
|
If you're asking about blending using a save before CT transform, that should probably be forbidden
|
|
2022-11-07 04:47:56
|
If it isn't already
|
|
2022-11-07 04:48:03
|
Libjxl should not allow it I think
|
|
|
|
_wb_
|
2022-11-07 04:48:13
|
I _think_ libjxl checks that blending (for both patches and frames) is only done when both are in the same colorspace
|
|
2022-11-07 04:48:47
|
so we should probably add to the spec that it's an invalid bitstream if this is not the case
|
|
|
|
Traneptora
|
2022-11-07 07:29:03
|
I'm confused about how blending is supposed to be done, anyway
|
|
2022-11-07 07:30:05
|
in the <#824000991891554375> contest submission, each frame has `save_as_reference == 1`
|
|
2022-11-07 07:31:53
|
but each frame except the first one is smaller than the image size
|
|
2022-11-07 07:32:12
|
so how is kAdd supposed to work
|
|
2022-11-07 07:32:34
|
none of them have upsampling either
|
|
|
|
_wb_
|
2022-11-07 07:36:20
|
First (bottom) layer is upsampled, then blending is done on the upsampled pixels
|
|
|
|
Traneptora
|
2022-11-07 07:37:22
|
but frame = 3 (sirpinski) has `save_as_reference = 1`
|
|
2022-11-07 07:38:24
|
and frame = 4 (signature) has `blend_mode = kAdd` with `source = 1`
|
|
2022-11-07 07:39:20
|
so currently I have each frame drawing on a canvas, but doing this overwrites the lower right corner with alpha=0 for most of it (the part that isn't inside the spline)
|
|
|
_wb_
First (bottom) layer is upsampled, then blending is done on the upsampled pixels
|
|
2022-11-07 07:40:25
|
I guess what I'm confused about is, when you have more than two frames, where do you store the intermediary blending results, and how do you composite the entire thing together?
|
|
2022-11-07 07:40:37
|
do you blend and *then* save as reference?
|
|
|
|
_wb_
|
|
|
Traneptora
|
2022-11-07 08:22:39
|
ah, okay, I got frame blending working
|
|
2022-11-07 08:22:44
|
that was apparently the key
|
|
|
|
Jyrki Alakuijala
|
2022-11-07 11:24:39
|
I'd like a volunteer to evaluate the new JPEG encoder
|
|
2022-11-07 11:25:06
|
$ ./ci.sh opt
$ ./build/tools/benchmark_xl --input input.png --output_dir . --codec=jpeg:libjxl:d1.0 --save_compressed
|
|
2022-11-07 11:25:44
|
it is amazing, isn't it?
|
|
2022-11-07 11:26:30
|
it should be about 28.777 % more dense than libjpeg-turbo or mozjpeg
|
|
|
lonjil
|
2022-11-07 11:38:13
|
latest main?
|
|
|
|
Jyrki Alakuijala
|
|
|
Traneptora
|
2022-11-07 11:54:33
|
How do I render splines on a non-xyb image?
|
|
|
|
Jyrki Alakuijala
|
2022-11-07 11:55:01
|
SpiderMario knows splines best
|
|
|
|
Traneptora
|
2022-11-07 11:55:44
|
the spec just says "X Y and B" channels
|
|
2022-11-07 11:55:56
|
is this a standin for channels[0], channels[1], channels[2]?
|
|
|
|
Jyrki Alakuijala
|
2022-11-07 11:56:08
|
I'd go with that
|
|
|
|
Traneptora
|
2022-11-07 11:56:20
|
I'm getting the wrong color with that
|
|
|
|
lonjil
|
2022-11-07 11:56:26
|
I had to edit ci.sh to not build docs because doxygen wants to error on warnings and there is a warning
|
|
|
|
Traneptora
|
2022-11-07 11:56:27
|
so idk if it's a misinterpretation of the spec, or a bug
|
|
|
|
lonjil
|
2022-11-07 11:56:33
|
But it is now building
|
|
|
|
Jyrki Alakuijala
|
2022-11-07 11:56:59
|
I think we can rethink that -- no production encoder is yet creating splines
|
|
2022-11-07 11:57:22
|
perhaps best to talk with SpiderMario and Jon
|
|
|
|
Traneptora
|
2022-11-07 11:58:27
|
jon's jxl art is an example I'm using to test the features
|
|
2022-11-07 11:59:12
|
unfortunately it appears to be rendering in the wrong place and also the wrong color
|
|
2022-11-07 11:59:16
|
which are two separate bugs probably
|
|
|
|
Jyrki Alakuijala
|
2022-11-08 12:11:50
|
we should be more careful with bugs -- we need to make them such that they cancel each other
|
|