|
TheBigBadBoy - πΈπ
|
|
CrushedAsian255
|
2024-11-05 12:35:20
|
GIF is only 256 colours though |
|
|
|
TheBigBadBoy - πΈπ
|
2024-11-05 12:56:24
|
> True-color GIFs are a hack that uses the animated GIF format, puts a 256 color square in each frame, offset from all previous frames, makes each frame not disappear when the next frame appears, and loops only once. Few programs other than web browsers display such images correctly. The files are very large as a result and not suitable for web use. |
|
|
lonjil
|
2024-11-05 01:06:52
|
paging <@281958058190700546> |
|
|
A homosapien
|
2024-11-05 01:12:08
|
God, I remember I used this hacky technique to get progressive GIF's with region of interest decoding. |
|
2024-11-05 01:12:20
|
It's was such a pain to make by hand |
|
|
VcSaJen
|
2024-11-05 06:23:39
|
convert from uncompressed avi with ffmpeg |
|
|
jonnyawsom3
|
2024-11-05 07:16:15
|
FFMPEG doesn't have animated JXL encoding, if I recall |
|
|
|
VcSaJen
|
2024-11-05 07:27:47
|
I'll check when I'm home. I see patches with "libjxl_animated" encoder, but I'm not sure if they're merged. |
|
|
Mine18
|
2024-11-05 08:09:12
|
it seems that Imagemagick (and subsequently, Magicknet, the library used by Imageglass) doesn't support animated jxl since 2021, i'm not sure if this has changed since then but that would explain my issue earlier |
|
|
RaveSteel
|
2024-11-05 11:24:27
|
They are not |
|
|
_wb_
|
2024-11-05 04:43:08
|
i'm trying to visualize the implicit delta palette by showing what it does to a predicted gray color |
|
2024-11-05 04:43:14
|
```
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(projection='3d')
deltas = [
[0, 0, 0], [4, 4, 4], [11, 0, 0], [0, 0, -13], [0, -12, 0], [-10, -10, -10],
[-18, -18, -18], [-27, -27, -27], [-18, -18, 0], [0, 0, -32], [-32, 0, 0], [-37, -37, -37],
[0, -32, -32], [24, 24, 45], [50, 50, 50], [-45, -24, -24], [-24, -45, -45], [0, -24, -24],
[-34, -34, 0], [-24, 0, -24], [-45, -45, -24], [64, 64, 64], [-32, 0, -32], [0, -32, 0],
[-32, 0, 32], [-24, -45, -24], [45, 24, 45], [24, -24, -45], [-45, -24, 24], [80, 80, 80],
[64, 0, 0], [0, 0, -64], [0, -64, -64], [-24, -24, 45], [96, 96, 96], [64, 64, 0],
[45, -24, -24], [34, -34, 0], [112, 112, 112], [24, -45, -45], [45, 45, -24], [0, -32, 32],
[24, -24, 45], [0, 96, 96], [45, -24, 24], [24, -45, -24], [-24, -45, 24], [0, -64, 0],
[96, 0, 0], [128, 128, 128], [64, 0, 64], [144, 144, 144], [96, 96, 0], [-36, -36, 36],
[45, -24, -45], [45, -45, -24], [0, 0, -96], [0, 128, 128], [0, 96, 0], [45, 24, -45],
[-128, 0, 0], [24, -45, 24], [-45, 24, -45], [64, 0, -64], [64, -64, -64], [96, 0, 96],
[45, -45, 24], [24, 45, -45], [64, 64, -64], [128, 128, 0], [0, 0, -128], [-24, 45, -45] ]
xss,yss,zss,c = [],[],[],[]
deltas += [ [-x,-y,-z] for [x,y,z] in deltas ]
for d in deltas:
xss.append(d[0])
yss.append(d[1])
zss.append(d[2])
c.append(((128+d[0])/255,(128+d[1])/255,(128+d[2])/255))
c = [(min(max(x,0),1),min(max(y,0),1),min(max(z,0),1)) for (x,y,z) in c]
#ax.scatter(xss, yss, zss, c=c, marker='o', depthshade=False, s=20)
ax.quiver(xss, yss, zss, xss, yss, zss, length=1, arrow_length_ratio=0.2, normalize=False, colors=c, pivot='tip')
ax.set_xlabel('R-delta')
ax.set_ylabel('G-delta')
ax.set_zlabel('B-delta')
ax.set_proj_type('persp', focal_length=0.3)
#ax.view_init(elev=24, azim=-61)
#plt.savefig("implicit_delta_palette.pdf",bbox_inches='tight')
plt.show()
``` |
|
2024-11-05 04:43:37
|
|
|
|
DZgas Π
|
2024-11-05 10:22:37
|
*per frame |
|
|
|
_wb_
|
2024-11-06 07:41:10
|
The convention is that minimum frame duration in GIF is 20 ms iirc (50 fps), and a frame duration of zero gets interpreted as 100 ms (10 fps). This was needed because there are too many GIFs out there in the wild that would otherwise not play back correctly. So the "true-color GIF" thing does not really work if what you want is a still image. |
|
|
|
TheBigBadBoy - πΈπ
|
2024-11-06 07:44:17
|
yeah I also read on gifski doc that >50fps are played as 10fps by some browsers |
|
|
|
VcSaJen
|
2024-11-06 09:56:42
|
Really fast GIFs are played all differently on different viewers. |
|
|
|
DZgas Π
|
2024-11-06 10:22:21
|
yes. that's why I always have to do no more than 30 fps. otherwise there will be incompatibility.
it also works on gifs (H264 video) in telegram. but in TG something more complicated based on the h264 level |
|
|
|
jonnyawsom3
|
2024-11-07 01:22:17
|
Wondered about the feasibility of radio transmission when this gets implemented, but I think the issue is you'd be having data loss rather than corruption probably
https://github.com/libjxl/libjxl/issues/3712 |
|
|
|
CrushedAsian255
|
2024-11-07 04:19:16
|
Maybe a JXL with extra redundancy could be introduced? Like it transmit each group as a box, then an ECC box or somethig |
|
2024-11-07 04:19:29
|
Would add extra overhead but could help with that kind of usecase |
|
2024-11-07 04:19:39
|
Also the box header could be used as a pseudo sync word |
|
|
Quackdoc
|
2024-11-07 06:31:47
|
is it worth having a forum thread thing for jxl-rs? |
|
|
|
CrushedAsian255
|
2024-11-07 06:33:13
|
why not π€·ββοΈ |
|
2024-11-07 06:41:13
|
<@794205442175402004> can the `jxlp` boxes be split arbitrarially or do they need to be only split on group boundaries or something |
|
|
|
_wb_
|
2024-11-07 06:56:16
|
Arbitrarily |
|
|
|
CrushedAsian255
|
2024-11-07 06:56:51
|
can i put each byte in its own jxlp? (obviously stupid idea) |
|
|
|
_wb_
|
2024-11-07 06:57:04
|
Yes |
|
2024-11-07 06:57:29
|
Even empty jxlp is allowed |
|
2024-11-07 06:57:40
|
IIRC |
|
|
|
jonnyawsom3
|
2024-11-07 09:00:15
|
Probably want a real dedicated channel underneath <#804324493420920833> since it'll practically be the new default |
|
|
|
CrushedAsian255
|
2024-11-07 09:29:55
|
Maybe it can just join <#804324493420920833> |
|
|
|
Quackdoc
|
2024-11-07 09:30:10
|
default for what? |
|
|
|
CrushedAsian255
|
2024-11-07 09:30:49
|
Everything, because rust is π blazingly fast π |
|
|
|
jonnyawsom3
|
2024-11-07 09:31:38
|
Also new, hopefully cleaner, codebase |
|
|
|
CrushedAsian255
|
2024-11-07 09:31:54
|
That too |
|
2024-11-07 09:32:07
|
Was libjxl being written while the format was still being developed? |
|
|
|
VcSaJen
|
2024-11-07 09:33:57
|
It's a decoder-only, tho |
|
|
|
CrushedAsian255
|
2024-11-07 09:34:26
|
Will there ever be a JXL encoder in rust? |
|
|
|
Quackdoc
|
2024-11-07 09:35:09
|
maybe |
|
2024-11-07 09:35:13
|
I mean zune exists |
|
|
|
veluca
|
2024-11-07 09:38:54
|
oh yes |
|
2024-11-07 09:39:12
|
might end up porting fjxl sometime π |
|
|
|
CrushedAsian255
|
2024-11-07 09:39:48
|
Is fjxl that encoder that is now e1? |
|
|
|
Quackdoc
|
2024-11-07 09:41:50
|
I think that's what zune-image did, not sure source for it is here, never bothered to look at it https://github.com/etemesi254/zune-image/tree/dev/crates/zune-jpegxl |
|
|
|
afed
|
2024-11-07 09:49:51
|
fjxl for lossless, jxl-tiny for lossy
then fpnge and jpegli <:KekDog:805390049033191445> |
|
|
|
veluca
|
2024-11-07 10:02:42
|
yup |
|
2024-11-07 10:04:00
|
`ChunkSampleCollector`... yeah looks like it xD |
|
2024-11-07 10:04:44
|
no SIMD though! |
|
|
|
CrushedAsian255
|
2024-11-07 10:54:58
|
with JXL frames, can you set a frame as being only internal vs being a layer? like if a photo editor loads each frame, can jxl differentiate a frame being used as a coding tool for patches vs an actual seperate layer? |
|
2024-11-07 10:55:04
|
as they would both be duration 0 frames |
|
|
|
jonnyawsom3
|
2024-11-07 11:59:41
|
Reference frames if I recall |
|
|
Naksu
|
2024-11-07 01:38:00
|
Hi, I am using the parameters `-d 0 -e 10 -E 4 -I 100 -g 3 --patches=0 --brotli_effort=11`, and after comparison, the output image does not seem lossless. It's quite subtle, but look at the top: https://slow.pics/c/2Zx93jEt |
|
|
|
jonnyawsom3
|
2024-11-07 02:37:00
|
Was the source a jpeg by any chance? |
|
|
|
Naksu
|
2024-11-07 02:53:30
|
Nah, PNG. |
|
2024-11-07 02:54:32
|
Oh wait, yes, it's actually JPEG. I picked the wrong image. |
|
2024-11-07 02:54:59
|
So, what's the issue with this format? |
|
2024-11-07 02:57:42
|
I cropped a part of a JPEG image and encoded it as PNG. |
|
|
|
jonnyawsom3
|
2024-11-07 03:01:13
|
The issue is actually with the JPEG format. Because the decoder wasn't completely standardised, different decoders have different outputs.
Because libjxl uses floats internally and only goes 8bit at the end, it gives different (although arguably more precise) output than mozjpeg, libjpeg, libjpeg-turbo, ect
If you add `-j 0` it should disable the jpeg specific transcoding and use standard lossless, although the filesize will be larger and make decoding back to the original JPEG file impossible |
|
2024-11-07 03:01:44
|
That's assuming it was `cjxl test.jpg output.jxl` |
|
2024-11-07 03:02:30
|
If you cropped it beforehand, encoded the PNG and the output is still different, then something is definitely wrong... |
|
|
Demiurge
|
2024-11-07 04:02:44
|
Funny enough, jpeg xt does standardize decoder output |
|
2024-11-07 04:03:48
|
But no one cares about xt |
|
|
|
DZgas Π
|
2024-11-07 05:07:17
|
I think it's time to make a meme out of it |
|
2024-11-07 05:08:52
|
it also on VarDCT because of the 8x8 only. And on Modular - https://discord.com/channels/794206087879852103/847067365891244042/1301180357881757737 |
|
|
|
RaveSteel
|
2024-11-07 05:23:25
|
JXLs transcoded from JPEGs will, in my experience at least, always look slightly different. But since the transcoding is lossless by default, you can do a bitexact reconstruction of the JXL back to JPEG using `djxl` and it will be the exact same image as the original. |
|
|
|
Naksu
|
2024-11-07 05:42:59
|
Thank you for the explanation. It works, despite a 331% increase in size (from 220 KB to 948 KB). |
|
2024-11-07 05:43:09
|
I can't be sure, I might have gotten mixed up. |
|
2024-11-07 05:45:42
|
Okay, I see. But I don't plan on switching back to JPEG, so it would be better if the JXL display was accurate. |
|
|
|
jonnyawsom3
|
2024-11-07 05:47:23
|
Well, accurate to what? When every JPEG decoder is different you can't really define the original. You can probably download any 2 decoders and it won't give the same output |
|
2024-11-07 05:47:51
|
Related thread https://github.com/libjxl/libjxl/issues/1470 |
|
2024-11-07 05:48:38
|
From testing the JXL output is actually closer to the original source |
|
2024-11-07 05:50:08
|
It might not do anything, but you could try `--jpeg_reconstruction_cfl=0`, might get it slightly closer |
|
2024-11-07 05:51:00
|
Transcoding reuses the DCT data inside the original JPEG encoding, `-j 0` disables that and just hands it the pixels instead |
|
|
|
Naksu
|
2024-11-07 06:06:27
|
Yeah, I see the problem, but then I have no way of knowing the actual visual? |
|
|
|
jonnyawsom3
|
2024-11-07 06:06:47
|
Actually, what's your use case? |
|
|
|
Naksu
|
2024-11-07 06:07:48
|
`βjpeg_reconstruction_cfl=0` instead of `-j 0`, or both? |
|
2024-11-07 06:08:02
|
Archiving. So I would like the most authentic image possible. |
|
|
|
jonnyawsom3
|
2024-11-07 06:08:14
|
Instead of, it might get closer to the other decoder at least |
|
2024-11-07 06:14:45
|
I know you already said you don't plan on going back from JXL, but the transcoding does mean you're keeping the exact same file that went in, so it'd be best to use it
Give me a moment to run a few tests... |
|
|
|
Naksu
|
2024-11-07 06:17:29
|
`βjpeg_reconstruction_cfl=0` gives the same result as https://discord.com/channels/794206087879852103/794206170445119489/1304077400812027968, while `-j 0` seems identical to the libjpeg decoder. |
|
|
Traneptora
|
2024-11-07 06:22:50
|
yea, it doesn't use jpegli to decode jpegs, it uses whatever libjpeg is linked |
|
2024-11-07 06:23:02
|
you have to use `djpegli foo.jpg foo.png` followed by `cjxl foo.png foo.jxl` |
|
|
|
jonnyawsom3
|
2024-11-07 06:24:52
|
Their issue is that the jpegli/jpegxl output doesn't match whatever decoder is being used for the original JPEG file, so they want to know the output is nearest the original image |
|
2024-11-07 06:24:56
|
Ssimulacra2 scores of an ffmpeg encoded JPEG against it's PNG original, in order of lowest to highest quality
`ffmpeg -i Jpeg.jpg ffmpeg.png`
87.34217046
`ssimulacra2 Original.png Jpeg.jpg`
87.36211094
`djxl JpegXL.jxl JpegXL.png`
87.46153571
`djpegli Jpeg.jpg jpegli.png`
87.51766600
`cjxl Jpeg.jpg JpegXL.jxl`
87.68811764 |
|
2024-11-07 06:25:34
|
So it does seem like the JXL is actually closest to the original, although I'd be happy to help you confirm it yourself |
|
|
|
RaveSteel
|
2024-11-07 06:27:25
|
Shouldn't a losslessly transcoded JXL have the same score as the original JPEG if ssimulacra2 is used? |
|
|
|
jonnyawsom3
|
2024-11-07 06:27:44
|
https://discord.com/channels/794206087879852103/794206170445119489/1304098342707396728 and https://discord.com/channels/794206087879852103/794206170445119489/1304149077608370208 |
|
|
|
RaveSteel
|
2024-11-07 06:28:44
|
This wasn't a question in the technical sense, but rather a question toward the functionality of ssmulacra2 |
|
|
|
jonnyawsom3
|
2024-11-07 06:29:40
|
I was a little slow with my edit but as Traneptora said, Ssimulacra just uses whatever decoder is linked rather than jpegli, then JXL can also use the chroma from luma and probably some other tricks too |
|
2024-11-07 06:31:13
|
It is a bit weird that jpegli was made in the libjxl repository, yet never used for it... |
|
2024-11-07 06:33:45
|
If you mean trying to decode the JXL back to jpg and then comparing that, then people might think we're cheating on our results when they look at the image like this :P |
|
|
|
RaveSteel
|
2024-11-07 06:36:31
|
I get where you are coming from and understand the technical aspect of the JXL looking slightly different than the original JPEG and having different checksum, but we see often, not just on this discord, people who are confused due to those differences. They do not know that the JXL has to be decoded back to JPEG.
Maybe this should be added to the FAQ? I honestly have no idea how to best solve this |
|
|
|
jonnyawsom3
|
2024-11-07 06:39:53
|
I mean, we have a case right now, could ask <@1219592742011932732> how they might've been able to find out the info beforehand. Maybe a reddit post so google can find it, on the website FAQ, or just continue helping when people ask here and on Github. I just hope we're not too overwhelming haha
TL;DR, the JXL will be more accurate to the original but will look different as a result, the original file can always be transcoded back on demand if the exact same image is required |
|
|
monad
|
2024-11-08 03:32:19
|
Then it's important _not_ to use `-j 0`, which discards data. You can just use defaults and be safe. The data encoded in the JXL is then exactly the same as the data encoded in the original JPEG. In that sense, the JXL is authentic. It is most prudent to then transcode the JXL back to JPEG as a verification step ensuring the files match.
The JPEG data does not encode exact pixel values. In this sense, there is no "actual visual". Current libjxl uses more accurate math than other JPEG decoders, so you may get a higher-fidelity visual. `-j 0` allows decoding the JPEG data to pixels and encoding those resulting values in JXL exactly. In this way, you can eternalize some specific representation of the data, but it is authentic to only one JPEG decoder. |
|
|
|
CrushedAsian255
|
2024-11-08 04:04:30
|
Does JXL have any of those βno actual visualβ issues? Is the decoding for JXL always the same barring floating point weridness? |
|
|
|
Demiurge
|
2024-11-08 06:46:43
|
I really wish jpegli was more integrated into libjxl, not less... |
|
|
|
monad
|
2024-11-08 07:26:43
|
JXL VarDCT does have some decode flexibility, but less than JPEG. Current decoders can produce different results. <https://libjxl.github.io/bench/> |
|
|
|
_wb_
|
2024-11-08 08:23:34
|
It is mathematically defined exactly, but implementations can deviate slightly to allow efficient implementations (since arbitrary precision arithmetic is prohibitively slow). The tolerances are way smaller than for JPEG conformance though. |
|
|
|
CrushedAsian255
|
2024-11-08 08:25:43
|
so there is one technically "canonical" decoding, and decoders can just add tradeoff some accuracy with speed? |
|
|
Tirr
|
2024-11-08 08:30:10
|
the spec uses infinite precision, but most implementations would use 32-bit float |
|
|
|
_wb_
|
2024-11-08 08:30:41
|
Yes. This is also the case in JPEG, but there they allow pretty huge loss of accuracy: they allow doing dequant+IDCT in any way that causes only off-by-ones in the quantized coeffs when doing DCT+quant to the decoded result. But that allows very big deviations for low quality images where the quantization factors are big. |
|
|
|
Tirr
|
2024-11-08 08:32:45
|
this is for jxl, jpeg decoders would use, uh, 16-bit integers internally? |
|
|
|
_wb_
|
2024-11-08 08:36:14
|
In jpeg, both the quantized and dequantized coeffs are integers that fit in 12-bit for normal jpegs and in 16-bit for 12-bit jpegs. The DCT itself is defined mathematically though, just like in jxl. Not like in video codecs where they define the DCT in integer arithmetic so any errors due to that are part of the spec there. |
|
2024-11-08 08:37:30
|
You can make a variant of libjxl that uses double precision floats internally instead of single precision, and it would be closer to the spec than the regular libjxl. |
|
2024-11-08 08:38:44
|
You can also make a variant that uses fixed point arithmetic internally (that's what the hw implementations will do) and still conforms to Level 5. |
|
|
|
CrushedAsian255
|
2024-11-08 11:16:53
|
Has anyone here used jpegxl-rs? |
|
2024-11-08 11:16:56
|
If so is it good? |
|
2024-11-08 11:17:46
|
https://docs.rs/jpegxl-rs/latest/jpegxl_rs/ |
|
2024-11-08 11:21:53
|
So I can patch libjxl to use custom 4096 bit floats and make the most accurate jxl encoder / decoder in the world? |
|
|
|
Quackdoc
|
2024-11-08 11:29:26
|
its just GPL'd bindings over libjxl |
|
|
|
CrushedAsian255
|
2024-11-08 11:41:49
|
if it's GPL do i legally have to release the code for the project? |
|
|
|
Naksu
|
2024-11-08 11:52:48
|
OK, that makes things clearer for me. I donβt want to go through the hassle of transcoding an image just to get the supposed original, but if JXL is actually closer to how the image *should* look, then Iβm fine with that. Iβm just surprised by this claim because, in the example I provided, the JXL output appears more blurred and pixelated. |
|
|
|
_wb_
|
2024-11-08 11:53:46
|
yes, won't be trivial to do that though, and it will be very slow, but yes |
|
|
|
Quackdoc
|
|
|
CrushedAsian255
|
2024-11-08 12:08:12
|
even for personal projects? or is it just for things im releasing the binary for |
|
|
|
Quackdoc
|
2024-11-08 12:08:25
|
if you give the binary to someone, yes |
|
|
|
CrushedAsian255
|
2024-11-08 12:08:38
|
if i don't give the binary? |
|
2024-11-08 12:09:02
|
or is the licence "if you get the binary, you must also be able to get the source"? |
|
|
spider-mario
|
2024-11-08 12:15:43
|
https://www.gnu.org/licenses/gpl-faq.en.html#NoDistributionRequirements |
|
2024-11-08 12:16:50
|
also https://www.gnu.org/licenses/gpl-faq.en.html#CanIDemandACopy |
|
2024-11-08 12:20:00
|
tl;dr: the requirements only apply _if_ you decide to redistribute your program; no one can force you to do so |
|
|
|
Quackdoc
|
2024-11-08 12:25:22
|
also you can distribute "internally" so like, businesses can use a modified program business wide |
|
|
|
spider-mario
|
2024-11-08 01:18:42
|
that becomes a bit tricky because you canβt prevent the recipients of your modified version from redistributing it themselves https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowModNDA |
|
|
|
Quackdoc
|
2024-11-08 03:23:59
|
yeah, its a bit murkey, but the way we generally thought of it was that we werent redistributing it to individuals, but employees being part of the overall entity |
|
|
yoochan
|
2024-11-08 06:00:56
|
I don't think this raise any issue. The problem mentioned by spider-mario is also about what happens if an employee or a subcontractor , release outside, code modified inside the company... π€ |
|
|
lenscap
|
2024-11-10 04:40:43
|
I've just made a repo public for a project I'm working on for fun. It's a JXL library for Go (just for reading). Although I started out with good intentions (reading through specs, libjxl, JXLatte and JXL-Oxide...) after several rewrites it's basically become a 90% Go port of JXLatte (although nowhere near complete). Am slowly going through filling out more parts of the implementation as I hit various test cases, but it's working for the tasks I need (but will keep developing). Both modular and vardct images are working fine (for my cases) but still have plenty of cases to deal with (eg. EncodedICC not nil, misc blend modes etc). Just thought I'd mention it here if anyone is interested. https://github.com/kpfaulkner/jxl-go |
|
|
|
CrushedAsian255
|
2024-11-11 07:17:51
|
Just wondering why was the message deleted? |
|
|
|
jonnyawsom3
|
2024-11-11 11:29:10
|
It wasn't their message so I doubt they know |
|
|
|
Demiurge
|
2024-11-11 12:21:26
|
I'm actually really surprised more people arenβt making jxl encoders. Encoders are much simpler to make than a decoder. |
|
2024-11-11 12:21:47
|
Decoders have to support every possible valid input. |
|
2024-11-11 12:22:02
|
Encoders can support whatever the hell you feel like doing |
|
2024-11-11 12:22:35
|
But everyone's making decoders |
|
2024-11-11 12:24:55
|
There are some really clever encoders for gif and png and even webp, a lot more clever and sophisticated tricks than the existing encoders included with libjxl use |
|
2024-11-11 12:25:26
|
Lots of room for clever innovation still with image encoding |
|
2024-11-11 12:25:52
|
I wish more people would try writing encoders |
|
|
|
CrushedAsian255
|
2024-11-11 12:30:06
|
There isnβt an encoder specification |
|
|
|
Demiurge
|
2024-11-11 12:31:59
|
Neither is there for JPEG... |
|
2024-11-11 12:32:12
|
Most formats only specify a decoder |
|
2024-11-11 12:32:18
|
That's normal and expected |
|
2024-11-11 12:32:55
|
The encoder can do whatever the hell it wants as long as the output can be read by the decoder |
|
2024-11-11 12:34:13
|
It can even be a complete black box neural net |
|
|
|
CrushedAsian255
|
2024-11-11 12:34:50
|
I will probably try to write encoder after trying to write decoder |
|
2024-11-11 12:35:03
|
So I can get my head around the bitstream |
|
|
|
Demiurge
|
2024-11-11 12:38:56
|
Makes sense |
|
2024-11-11 12:39:40
|
There are some really clever tricks possible with jxl |
|
2024-11-11 12:40:35
|
Lots of untapped potential and the best way to get closer to tapping it is to make unconventional encoders |
|
2024-11-11 12:41:10
|
Silly encoders |
|
2024-11-11 12:41:17
|
Encoders just for fun |
|
2024-11-11 12:41:34
|
That's the best way to explore untapped potential |
|
2024-11-11 12:42:13
|
Starting silly at first until it gets seriously cool |
|
|
|
CrushedAsian255
|
2024-11-11 01:33:41
|
Encoder that uses 1x1 pixels and patches? |
|
|
|
jonnyawsom3
|
2024-11-11 01:57:15
|
Technically a worse Hydrium |
|
|
|
_wb_
|
2024-11-11 02:12:37
|
It would be a fun exercise to try to make a lossless jxl encoder in a very small number of lines of code. For example something like fjxl but without all of the specializations that make it very fast. |
|
|
|
veluca
|
2024-11-11 02:36:38
|
heh, small LoC count or small binary size? π |
|
|
|
jonnyawsom3
|
2024-11-11 03:02:40
|
Reminded me to finally try Hydrium...
I know people mentioned the decode speed is bad without using a single frame, but yikes... Then tried one frame, and tile size 3 |
|
2024-11-11 03:03:54
|
4 minutes, 4 seconds and (under) 400 miliseconds xP |
|
|
Dejay
|
2024-11-11 04:49:57
|
Well I'd love to make an jxl encoder with a few specialized tricks for comics / manhwa / scanned ebooks (image font and patches and multiple translation layers). (EDIT: But you'd also need a viewer / browser support)
But I need to upgrade my PC memory, switch to linux and a development setup. I've started to hate c++ development on windows with a burning passion |
|
2024-11-11 04:51:30
|
Sorry, no idea. I guess that message was about why you would need "reversible png transcode" |
|
|
pshufb
|
2024-11-11 04:57:22
|
Does libjxlβs adaptive quantization do anything equivalent to SVT-AV1βs βvariance boostβ? (<https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Variance-Boost.md>)
tl;dr of that link: it reduces quantization in low-contrast areas |
|
|
|
jonnyawsom3
|
2024-11-11 05:17:08
|
Ah, they link to the [Theora update](<https://people.xiph.org/~xiphmont/demo/theora/demo9.html>) that <@1028567873007927297> mentioned a few weeks ago.
I was thinking about asking the same, but I think VarDCT and the intensity target might have that covered, at least partially |
|
|
|
Quackdoc
|
2024-11-11 05:44:16
|
should the wpt tests include cmyk? |
|
|
LMP88959
|
2024-11-11 05:58:56
|
|
|
2024-11-11 05:59:00
|
|
|
2024-11-11 05:59:16
|
|
|
2024-11-11 05:59:42
|
```
jxl e10 d14.0
``` |
|
2024-11-11 06:00:01
|
|
|
2024-11-11 06:00:04
|
^ this is AVIF |
|
2024-11-11 06:00:56
|
|
|
2024-11-11 06:01:13
|
this is a zip file containing a few other codecs at the same file size |
|
2024-11-11 06:03:38
|
why does JXL look so bad on this image? |
|
|
|
jonnyawsom3
|
2024-11-11 06:03:46
|
Huh... jpegli seems to be doing something wrong too |
|
2024-11-11 06:14:45
|
Changing to `--resampling=2 -d 4.2` gets some detail back. I'll keep testing but the encoder has only been tuned for high quality so far (Distance 3 or lower) |
|
2024-11-11 06:45:02
|
Seems like `-e 4` might actually look better, since at 6 and above it adds a lot more DCT noise. |
|
|
|
LMP88959
|
2024-11-11 06:47:06
|
Do the edges look cleaner? |
|
|
|
jonnyawsom3
|
2024-11-11 07:03:34
|
I think so, flicking between the same few images for 45 minutes made my eyes kinda give up
Might be a case of <#1278292301038227489> too |
|
|
Oleksii Matiash
|
2024-11-11 09:00:02
|
1024x640 image needs 330 ms to decode π€¦ββοΈ |
|
2024-11-11 09:02:45
|
Agree. I personally prefer e4 look over e5+ |
|
|
|
LMP88959
|
2024-11-11 09:03:07
|
totally |
|
2024-11-11 09:03:16
|
looks more like jpeg with good chroma now |
|
|
|
Oleksii Matiash
|
2024-11-11 09:03:50
|
That regular low frequency bubbles from e5+ are really bad |
|
|
|
jonnyawsom3
|
2024-11-11 09:04:25
|
Well, at e4 it essentially is a jpeg with some extra spice. 8x8 DCT blocks only. e5 does remove the block borders, but smooths it too, e6 overcompensates and has more noise than it started with |
|
2024-11-11 09:06:00
|
I mean... Something is wrong when downsampling the image by 2 gives better results than just lowering the quality, even though it does that automatically at distance 20+ iirc |
|
|
|
Oleksii Matiash
|
2024-11-11 09:06:14
|
Tried e5 - no, blurry and that regular artifacts are much worse than on e4 for me |
|
2024-11-11 09:06:40
|
e4 - e5 |
|
|
|
jonnyawsom3
|
2024-11-11 09:07:09
|
I know part of the regression since 0.8 seems to be using larger VarDCT blocks than it used to. e4 being fixed 8x8 is probably reversing that somewhat |
|
|
|
LMP88959
|
2024-11-11 09:07:11
|
wow that's wild, it really does just look blurred |
|
|
|
Oleksii Matiash
|
2024-11-11 09:08:02
|
Yes. And for me it is much more annoying than that steppy gradients |
|
|
|
LMP88959
|
|
|
jonnyawsom3
|
2024-11-11 09:08:54
|
It gives the table woodgrain again, at the cost of the actual image content :P |
|
|
|
Oleksii Matiash
|
2024-11-11 09:12:00
|
It is sad that jxl can't compete with avif on such low bitrates. Not for me, I don't use such 'qualities', but it gives a valid argument to internet avif advocates π¦ |
|
|
|
jonnyawsom3
|
2024-11-11 09:15:18
|
Generally you can 'win' the conversation by asking "What's your use case?" since no one really wants a watercolor painting of their image |
|
2024-11-11 09:15:58
|
Makes me think that's a *no* |
|
|
HCrikki
|
2024-11-11 09:17:08
|
jxl can just fine, its just the official binaries and default parameters from libjxl that are tuned to preserve *more quality* - in tune with preexisting criticisms about how images are badly compressed everywhere and we should stop focusing on lowering kilobyte numbers without a concern about visual quality |
|
|
|
jonnyawsom3
|
2024-11-11 09:20:14
|
Years of only having 20 digits of usable quality in a scale is no more |
|
|
|
Demiurge
|
2024-11-11 11:21:30
|
C++ development in general is a soul crushing thing |
|
2024-11-11 11:22:06
|
C++ is a sadomasochistic dev environment |
|
2024-11-11 11:26:40
|
Take an existing, successful language like C, which became successful because it was inherently simple and easy to use, and then throw all those virtues out of the window by attaching an ever-growing tumor on top of it that's designed to make code as unreadable as possible. |
|
2024-11-11 11:27:50
|
And then add Cmake on top of that |
|
2024-11-11 11:28:09
|
It's like it's designed by and for sadomasochists |
|
2024-11-11 11:29:46
|
Who have no idea how to limit and manage layers of complexity, and end up with this Enterprise(tm) grade fragile and interdependent spaghetti. |
|
|
|
CrushedAsian255
|
2024-11-11 11:59:13
|
I need to learn Cmake |
|
|
|
Demiurge
|
2024-11-12 12:21:41
|
Do you? |
|
2024-11-12 12:21:56
|
Make is a lot easier... |
|
|
|
CrushedAsian255
|
2024-11-12 12:23:04
|
or i can learn π¦π<:rust:854096515727753266>***__rust__***<:rust:854096515727753266>ππ¦ |
|
|
|
Demiurge
|
2024-11-12 02:01:56
|
Might as well, you'll be forced to at some point no doubt |
|
2024-11-12 02:02:58
|
In the Rust Reeducation Center |
|
|
|
CrushedAsian255
|
2024-11-12 06:03:07
|
Is the planned JPEG XL gain map going to be [ISO 21496-1](https://www.iso.org/standard/86775.html)? |
|
|
|
Oleksii Matiash
|
2024-11-12 06:35:24
|
I agree, but lowest quality re-re-recompressed images and videos taught people completely blurred media, where borders is the only thing that is preserved. It would be hard to override this bad habit |
|
|
|
A homosapien
|
2024-11-12 08:52:44
|
Here the best result I could get. `libjxl 0.8 --gaborish 0 -d 16` |
|
2024-11-12 08:56:43
|
Larger VarDCT blocks are present in 0.11 |
|
|
|
Oleksii Matiash
|
2024-11-12 08:56:54
|
I still prefer -e 4 look |
|
|
|
A homosapien
|
2024-11-12 09:02:39
|
I mean, in these extreme cases you are better off just using `resampling=2` for a slightly blurry but more detailed look. |
|
2024-11-12 09:03:41
|
|
|
2024-11-12 09:03:52
|
`-d 3.9 --resampling 2 -e 9` Still libjxl 0.8 btw |
|
|
|
CrushedAsian255
|
2024-11-12 10:32:50
|
Does resampling 2 just downscale 2x ? |
|
|
|
A homosapien
|
2024-11-12 10:34:31
|
Yup, for an extremely low bit-rate situation, lowering the resolution is your best bet at preserving quality. |
|
|
|
CrushedAsian255
|
2024-11-12 10:39:10
|
Idea for ultra low quality, put the image through one of those PNG to SVG converters with max smoothing so the image is just a few blobs of colour |
|
|
|
jonnyawsom3
|
2024-11-12 11:39:01
|
Can just do resampling 8 for that |
|
|
|
CrushedAsian255
|
2024-11-12 12:30:22
|
cjxl -d 25 βresampling=8 |
|
|
|
jonnyawsom3
|
2024-11-12 12:39:34
|
Nah, `--resampling=8 --intensity_target=1` |
|
|
|
CrushedAsian255
|
2024-11-12 01:17:03
|
What does intensity target do again? |
|
|
|
jonnyawsom3
|
2024-11-12 01:18:04
|
Basically changes the brightness of the image to the encoder, so if you're using a HDR display you can set it to 3000 and it won't crush the blacks, ect |
|
2024-11-12 01:18:13
|
Or set it to 1 and it just sees a black square |
|
|
|
CrushedAsian255
|
2024-11-12 01:20:20
|
So itβs like saying what a value of β100% brightnessβ should equal? |
|
2024-11-12 01:20:51
|
So like pixel_brightness (nits) = intensity_target * pixel_value? |
|
|
|
jonnyawsom3
|
2024-11-12 02:37:09
|
Probably |
|
|
|
Quackdoc
|
2024-11-12 02:55:16
|
if this was linear and you were working in float |
|
|
|
DZgas Π
|
2024-11-13 08:05:11
|
<:BlobYay:806132268186861619> |
|
|
|
CrushedAsian255
|
2024-11-13 08:35:13
|
What is the largest JXL block |
|
2024-11-13 08:54:45
|
apparently intensity target can be a float, here is 0.1 |
|
2024-11-13 08:54:49
|
|
|
|
|
embed
|
2024-11-13 08:54:58
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/1306180462137442304/out.jxl?ex=6735bad9&is=67346959&hm=3ea904ee7af2d36a9f8f2735bf43c04a7cdd8dcf12e3456eb28ce47468cfa008& |
|
|
|
CrushedAsian255
|
|
|
embed
|
2024-11-13 09:21:41
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/1306187180506484777/out.jxl?ex=6735c11b&is=67346f9b&hm=d132e4878c96793f5df36c068fb58d6075ad09e291dedb7172fce90c7d4023a0& |
|
|
|
_wb_
|
2024-11-13 09:24:04
|
The bitstream allows up to 256x256, but libjxl doesn't use anything larger than 64x64 dcts |
|
|
|
CrushedAsian255
|
2024-11-14 02:36:41
|
<@794205442175402004> (continuing from <#848189884614705192> )
Is YCbCr VarDCT particularly good? Or does not allowing it to use XYB make it significantly worse |
|
|
|
Tirr
|
2024-11-14 02:39:03
|
iiuc ycbcr vardct exists mainly for lossless jpeg recompression though |
|
|
|
_wb_
|
2024-11-14 02:58:33
|
There's two things: 1) libjxl has not been tuned for encoding in not-XYB, and 2) XYB should be better than a less perceptual space like YCbCr, we don't really know by how much but I'd estimate it may make something like a 5% difference. |
|
|
|
jonnyawsom3
|
2024-11-14 03:27:18
|
Didn't we have numbers from jpegli for YCbCr vs XYB? |
|
|
|
_wb_
|
2024-11-14 07:35:49
|
Yeah but jpeg(li) is restricted to 8x8 and doesn't have Chroma from Luma etc, so you cannot really extrapolate... |
|
|
|
jonnyawsom3
|
2024-11-14 07:57:36
|
jpegli got around 10% better from what I'm finding, so probably quite a dent in JXL's side having to use YCbCr with the extra tooling |
|
|
|
CrushedAsian255
|
2024-11-15 07:41:52
|
VarDCT is unable to do RGB, right? |
|
|
|
_wb_
|
2024-11-15 09:02:45
|
No, it can do RGB. But that's probably a bad idea. |
|
|
|
A homosapien
|
2024-11-15 05:33:39
|
It would be like RGB jpeg, generally a bad idea |
|
|
|
Dejay
|
2024-11-16 03:17:01
|
I wonder if you could define a "aesthetically lossless" distance for images. Like you have the original and train a model to reduce complexity without impacting the "visual enjoyment" for the average viewer |
|
2024-11-16 03:18:07
|
The visually lossless distance metric is really cool but if you need to compress further it would be nice if there was some other meaningful distance for image compression |
|
2024-11-16 03:19:35
|
I imagine you could measure it through experiments or with a CRT or sticking some electrodes on the head |
|
|
|
CrushedAsian255
|
2024-11-16 05:08:02
|
How can I add the embed bot to another server? |
|
|
|
_wb_
|
2024-11-16 07:23:14
|
Some literature talks about the JOD unit besides the JND unit, difference being JND is just noticeable difference and JOD is just objectionable difference. |
|
2024-11-16 07:25:56
|
I think it's more tricky to make all observers have the same criterion for "objectionable difference" though. Whether something is noticeable or not is more clear-cut. |
|
2024-11-16 07:27:31
|
Most likely, for practical purposes, just using 2 JND or so will be "close enough" to 1 JOD in most codecs. |
|
2024-11-16 07:32:50
|
If it's not noticeable, it cannot be objectionable. 1 JND means 50% of observers cannot notice it, but 50% can (just barely) notice it. If you want 95% of observers to not object to a distortion, then maybe 1 JND is a reasonable choice.
That is, 1 JOD might not be what you actually want to use, since having only 50% of people "not object" can be not good enough. |
|
|
|
CrushedAsian255
|
2024-11-16 07:47:59
|
What JND level is it so that nobody can tell the difference? |
|
2024-11-16 07:48:11
|
(Not lossless but 100% visually lossless) |
|
|
|
_wb_
|
2024-11-16 07:55:36
|
Theoretically 0 |
|
2024-11-16 07:57:00
|
In practice, below 0.3 JND or so you can be pretty sure that even someone with the best visual acuity will not be able to see the difference (assuming fixed viewing conditions, of course) |
|
|
|
CrushedAsian255
|
2024-11-16 08:11:40
|
Would lossy modular be better for near-lossless? |
|
|
|
_wb_
|
2024-11-16 08:26:49
|
probably VarDCT makes sense above d0.1, below d0.1 probably lossy modular gives better compression results (though it will be slower) |
|
|
|
DZgas Π
|
2024-11-16 08:32:00
|
VarDCT on such parameters has all sorts of artifacts of the coding principle itself. the effect is similar to jpeg q100 or webp q100 |
|
2024-11-16 08:33:32
|
but as I observed six months ago, the artifacts themselves have a different character. it seems that the artifact may be 1+ block away from the place with the data |
|
|
|
CrushedAsian255
|
2024-11-16 08:37:57
|
I guess itβs like WebP near_lossless |
|
|
|
DZgas Π
|
2024-11-16 09:49:52
|
<@179701849576833024> where... |
|
2024-11-16 09:54:31
|
Still exists |
|
2024-11-16 09:55:02
|
|
|
2024-11-16 09:57:35
|
this is the q90. But in the upper left corner, on a completely solid color, there are artifacts of the wrong gradients. Although there is need to make a solid color of the same color... Everything is the same as six months ago tests. But there is also good news, there are no more red artifacts in the green area |
|
2024-11-16 09:58:35
|
but there is still an incomprehensible artifact of blue color on the red lines. Although there is no blue color at all. |
|
2024-11-16 10:01:01
|
I added just one blue pixel, and it directly affected the artifact in the upper left corner |
|
2024-11-16 10:03:26
|
I still have a hard time understanding how different blocks can different each other. But this makes using varDCT on d 0.1 useless |
|
2024-11-16 10:12:05
|
Recently, I completely rewrote the STRESS algorithm from the gimp sources, also using the documentation. So now I can show artifacts very clearly on super-flat surfaces. |
|
2024-11-16 10:14:37
|
|
|
2024-11-16 10:18:56
|
mozJpeg q50 |
|
|
|
Dejay
|
2024-11-16 06:24:12
|
Thanks, those terms make sense!
I do think "some light grumbling" for 50% at 1 JOD would be useful. Like if 50% say "slightly objectionable" but only very few say "very objectionable" |
|
|
|
JendaLinda
|
2024-11-17 05:05:42
|
What is the smallest VarDCT block size?
Also I wonder if would be possible to crop VarDCT image without decoding to pixels. |
|
|
|
jonnyawsom3
|
2024-11-17 05:31:50
|
8x8, although IIRC there are multiple variations of it |
|
|
|
CrushedAsian255
|
2024-11-17 05:58:18
|
There are 2x2 and 4x4 but they arenβt able to be placed arbitrarily, so they are effectively just modified 8x8 |
|
2024-11-17 05:59:01
|
1. You can drop by 256x256 easily as that is the size of a group
2. JXL frames support setting a crop so you can just do that and not mess with pixel data in the first place |
|
|
username
|
2024-11-18 06:33:43
|
<@794205442175402004> https://discord.com/channels/794206087879852103/848189884614705192/1307955586331181147 (continuing in here because of the cooldown in the other chat preventing me from typing)
I do know of a application author who dislikes JPEGΒ XL because they claim it's not lossless by claiming it "drops imaginary colors" or something. I assume libjxl during color management is dropping said colors during decode or something however I don't know because said author wouldn't make it clear what was happening even after I asked |
|
2024-11-18 06:34:26
|
was wondering if you would have any idea as to what might have been happening |
|
|
|
Tirr
|
2024-11-18 06:36:50
|
uh I think in lossless mode libjxl encodes samples as integers and doesn't try to interpret those as color |
|
|
|
_wb_
|
2024-11-18 06:37:57
|
If you do lossless, it will encode the image as is. If you do lossy, it will convert to XYB which will indeed only preserve the image you can see β that's the point of lossy compression. |
|
|
|
Tirr
|
2024-11-18 06:38:14
|
(that's how lossless 32-bit pfm encoding works) |
|
|
|
_wb_
|
2024-11-18 06:40:05
|
You can make a lossy encoder that does not convert to XYB if there's a need for that, but I would assume that if you want to have imaginary colors (like negative light), you don't want to do lossy compression in the first place. |
|
|
|
username
|
2024-11-18 06:42:45
|
|
|
2024-11-18 06:42:55
|
|
|
2024-11-18 06:43:10
|
^ for context this is what they where saying |
|
|
|
_wb_
|
2024-11-18 07:59:47
|
He must be doing something wrong if lossless isn't lossless for him |
|
2024-11-18 08:00:14
|
Or her, or whatever the relevant pronoun is |
|
|
|
JendaLinda
|
2024-11-18 09:28:17
|
Verifying lossless compression is easy. |
|
|
|
Oleksii Matiash
|
2024-11-18 11:14:24
|
Not for all, as we can see |
|
|
|
JendaLinda
|
2024-11-18 11:20:47
|
I do it all the time, just comparing bytes. |
|
|
|
Oleksii Matiash
|
2024-11-18 11:40:54
|
It was sarcasm. Person from the quote above definitely has some troubles with it |
|
|
|
JendaLinda
|
2024-11-18 11:41:36
|
I see |
|
|
Amiralgaby π
|
2024-11-18 12:56:32
|
I've done a PR (#3918) on the libjxl github, but she didn't pass two test.
It's a rebase commit who fail.
How Can I remove it to submit only my commit |
|
|
|
spider-mario
|
2024-11-18 01:04:14
|
do you have a link to it? there doesnβt seem to be a PR #9482 |
|
|
|
Amiralgaby π
|
2024-11-18 06:34:06
|
Sorry it was #3918 |
|
|
|
Traneptora
|
2024-11-19 05:10:43
|
theoretically the smallest guaranteed is an LF Group |
|
2024-11-19 05:10:51
|
which is 2048x2048 on VarDCT |
|
2024-11-19 05:11:32
|
the LF Group contains the 8x8 downsampled image, but it's (usually) encoded in modular which goes in scanline order so it's typically quite hard to crop that without re-encoding the image |
|
2024-11-19 05:12:26
|
but you can theoretically crop a 2048x2048 VarDCT image without generation loss. currently there's no tools to do it, though. |
|
|
|
JendaLinda
|
2024-11-20 01:13:22
|
I thought there's something more complex going on. I tried just change the image dimensions and it didn't go as expected. |
|
2024-11-20 01:20:17
|
I was making sure the boundaries stay inside the same DCT blocks but pixels around the edges were corrupted. |
|
|
|
jonnyawsom3
|
2024-11-20 01:22:08
|
Likely EPF or one of the cross-group tools messing with it |
|
|
|
JendaLinda
|
2024-11-20 01:43:57
|
So the crop property could work better. Making the "canvas" smaller than the actual image.
No sure how does it actually work and how to set it up. Editing jxl headers without a proper header editor is very difficult. I was just tinkering in a hex editor so far. |
|
|
|
jonnyawsom3
|
2024-11-20 12:38:36
|
Really wishing I had JPEG XL right now.... |
|
|
Fox Wizard
|
2024-11-20 12:46:10
|
Looks more like an avif situation <:KekDog:884736660376535040> |
|
|
|
jonnyawsom3
|
2024-11-20 12:47:54
|
With ping like that I suppose it might actually decode in time for the next image |
|
2024-11-20 12:48:07
|
Assuming it doesn't loose a single packet and fail |
|
|
|
spider-mario
|
2024-11-20 02:34:03
|
is that a 12-second ping? |
|
|
|
jonnyawsom3
|
2024-11-20 02:54:52
|
5 seconds idle, 15 seconds during 50KB/s download and 9 seconds with 36KB/s upload
I'm having to switch to data to avoid timeouts during uploads |
|
2024-11-20 03:23:57
|
And now it's giving an Access Denied error... |
|
|
|
Quackdoc
|
2024-11-20 04:41:54
|
cellular? |
|
|
|
jonnyawsom3
|
2024-11-20 04:42:46
|
WIFI |
|
2024-11-20 04:43:06
|
Though I can connect again now |
|
|
|
Quackdoc
|
2024-11-20 04:44:17
|
I hope you are pretty far away lol, |
|
|
|
jonnyawsom3
|
2024-11-20 04:46:13
|
Look at the screenshot. 3/4 bars :P |
|
|
|
Quackdoc
|
2024-11-20 04:46:36
|
[av1_monkastop](https://cdn.discordapp.com/emojis/720662879367332001.webp?size=48&name=av1_monkastop) |
|
|
|
jonnyawsom3
|
2024-11-20 04:47:13
|
Hence using mobile data, though it seems stable again for now |
|
|
|
CrushedAsian255
|
2024-11-20 11:49:07
|
Australian internet be like |
|
|
|
DZgas Π
|
2024-11-21 12:20:17
|
130 gb π per month |
|
|
|
CrushedAsian255
|
2024-11-21 01:16:24
|
i remember when i had a 10 GB/month data cap π |
|
|
|
A homosapien
|
2024-11-21 01:47:42
|
That's 18 GB less than my mobile data cap! |
|
|
|
CrushedAsian255
|
2024-11-21 01:49:14
|
i now get 80+132=212 GB mobile cap |
|
|
|
Quackdoc
|
2024-11-21 01:54:05
|
i dont use mobile data lol |
|
|
|
jonnyawsom3
|
2024-11-21 02:45:11
|
Wifi is unlimited but data is a 5GB cap per month, although it's actually faster than my ethernet too... |
|
|
|
CrushedAsian255
|
2024-11-21 03:16:57
|
look into getting 4G / 5G home broadband |
|
2024-11-21 03:17:03
|
don't know if it exists in your region |
|
|
|
jonnyawsom3
|
2024-11-21 08:11:01
|
Not really, can just use a sim hotspot with an unlimited data contract, but that's 5x+ what I'm paying currently which is already a scam at Β£35 for 60Mbps (friends in Europe or in the North are getting gigabit bidirectional for less) |
|
|
|
CrushedAsian255
|
|
|
VcSaJen
|
2024-11-23 04:16:01
|
For my ISP, new clients can permanently have 300Mbps (up/down) for the same price as I have for 100Mbps (up/down). A bit ridiculous. |
|
|
|
Traneptora
|
2024-11-23 06:43:33
|
what prevents you from canceling and signing back up? |
|
|
|
jonnyawsom3
|
2024-11-23 07:02:31
|
Been sending my sister JXL compressed DNGs since they're smaller than the JPEGs xD |
|
|
|
A homosapien
|
2024-11-24 02:13:33
|
https://github.com/wroad/manjaxl |
|
|
|
TheBigBadBoy - πΈπ
|
2024-11-24 10:37:49
|
except for visual novels, I don't see the point of using deltas [β ](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&name=av1_Hmmm) |
|
|
|
jonnyawsom3
|
2024-11-24 10:42:35
|
I'm surprised they didn't use the float deltas Jon talked about before |
|
2024-11-24 10:42:51
|
Then pixels just have to be similar for an improvement |
|
|
|
Demiurge
|
2024-11-24 04:31:12
|
This is a cool idea, but it would probably be better done with multi page jxl instead maybe...? |
|
|
|
jonnyawsom3
|
2024-11-24 04:32:46
|
Multipage with addition blending instead of Alpha layering |
|
2024-11-24 04:33:10
|
Though maybe that's only layered... |
|
|
|
Demiurge
|
2024-11-24 04:33:53
|
Or whichever blend technique is less entropy |
|
2024-11-24 04:35:08
|
I wonder if it's a good idea to name multi image jxl files .jxls for sequence |
|
2024-11-24 04:35:23
|
Or maybe jxlls for lossless sequence |
|
2024-11-24 04:36:36
|
Or maybe jjxls for jpeg92-reconstructed sequence |
|
2024-11-24 04:37:04
|
That last one seems pretty unlikely though |
|
2024-11-24 04:38:18
|
I think .avifs is the accepted convention for animated avif |
|
2024-11-24 04:38:25
|
Like .apng |
|
|
|
CrushedAsian255
|
2024-11-24 08:49:55
|
I think this is good idea, but things like lossless and jpeg92 reconstruction donβt need to be extension tagged |
|
2024-11-24 08:50:19
|
Animation and multipage impacts how you view the file, lossless or jpeg reconstruction donβt |
|
|
|
DZgas Π
|
2024-11-24 09:26:06
|
Where can I watch animated Jpeg XL at all? mpv and palemoon browser. From what I found. vlc can't. mpc-hc too. avidemux cannot. Although Xnview supports jxl, the frame rate definition is broken there, it works for gif and apng, but it is broken for jpeg xl. |
|
2024-11-24 09:28:39
|
and ffplay works |
|
2024-11-24 10:17:09
|
finally |
|
2024-11-24 10:17:41
|
full Shrek in 10 Mb jpeg xl |
|
|
|
A homosapien
|
2024-11-24 10:17:51
|
|
|
2024-11-24 10:19:21
|
You could also just open it in a JXL compatible browser |
|
2024-11-24 10:19:29
|
Although I wouldn't really consider that a proper image viewer |
|
|
|
Demiurge
|
2024-11-25 12:10:50
|
Idk, I think lossless is arguably nicer to know at a glance than whether something is animated or not |
|
2024-11-25 12:11:00
|
Since you can know that by opening up the file |
|
2024-11-25 12:11:18
|
Lossless is not something that's always known unless you know the process used to make the file |
|
2024-11-25 12:12:03
|
So that's why a filename convention for losslessly transcoded files would be even more useful than for multi frame/multi page files |
|
2024-11-25 12:12:32
|
There's no .gifs or .agif |
|
2024-11-25 12:12:52
|
And I always thought .apng was dumb even though people like it for some reason |
|
2024-11-25 12:13:35
|
But that info is always a lot more redundant than saying whether the compression is lossless or not |
|
|
|
CrushedAsian255
|
2024-11-25 12:17:17
|
Why do you need to know if it is lossless? |
|
|
|
Demiurge
|
2024-11-25 12:19:52
|
It's pretty useful to know if it was originally a jpeg or if it contains compression artifacts that make it less practical to transcode to a different format |
|
2024-11-25 12:20:19
|
Practically speaking lossy files are less practical to transcode |
|
2024-11-25 12:20:25
|
Simple as that |
|
2024-11-25 12:28:23
|
jjxl and jxll say the file can be conveniently transcoded to other formats |
|
|
|
joel
|
2024-11-25 12:42:57
|
not sure if this is the right channel, i'm trying to encode a jpg losslessly but djxl fails to decode it. any ideas?
```
~/tmp $ cjxl -q 100 original.jpg a.jxl
JPEG XL encoder v0.11.0 [AVX2,SSE4,SSE2]
Encoding [Modular, lossless, effort: 7]
Compressed to 1068.8 kB (6.926 bpp).
960 x 1286, 0.592 MP/s [0.59, 0.59], , 1 reps, 8 threads.
~/tmp $ djxl a.jxl a.jpg
JPEG XL decoder v0.11.0 [AVX2,SSE4,SSE2]
Warning: could not decode losslessly to JPEG. Retrying with --pixels_to_jpeg...
Decoded to pixels.
960 x 1286, 11.392 MP/s [11.39, 11.39], , 1 reps, 8 threads.
``` |
|
|
Laserhosen
|
2024-11-25 02:03:22
|
I suspect original.jpg is not actually a jpg. Could it be a PNG that's been renamed to .jpg or something? cjxl would normally output:
```
Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0).
Encoding [JPEG, lossless transcode, effort: 7]
``` |
|
|
|
joel
|
2024-11-25 02:58:42
|
Good catch! You're correct, it's a PNG renamed to JPG. Thanks! |
|
|
|
Dejay
|
2024-11-26 08:31:40
|
What the heck, both webp and avif have pretty low resolution limits?
16383 height for webp? And 8,704 for avif officially? It seems more than 65k height for avif isn't possible with gimp |
|
2024-11-26 08:33:06
|
I mean how can you even call them modern image formats π |
|
|
|
A homosapien
|
2024-11-26 08:53:40
|
That's baggage from the video codec word. Not future proof at all. |
|
|
|
HCrikki
|
2024-11-26 09:08:56
|
doesnt cover even *today's* needs for photography, image sensors capture at 100+ megapixels but cameras pixelbin the final output to around 12megapixels or smaller |
|
|
|
Dejay
|
2024-11-26 09:24:47
|
Yeah that makes it more important that jxl becomes more supported (like in browsers) |
|
|
|
CrushedAsian255
|
2024-11-26 11:05:30
|
Why are we shipping 108 MPx images over a browser? |
|
2024-11-26 11:05:41
|
Latino question |
|
|
|
Dejay
|
2024-11-26 12:05:38
|
Well photos, screenshots of complete webpages and of course manhwas / webtoons |
|
|
|
lonjil
|
2024-11-26 01:37:52
|
phones pixelbin, but proper cameras with 100+ megapixel sensors don't. |
|
|
|
CrushedAsian255
|
2024-11-26 01:55:35
|
i threw my pixels in the bin |
|
|
|
_wb_
|
2024-11-26 03:08:24
|
For the web, the limits of webp are OK-ish. Even for the web, it does become a practical limitation though, in some cases. E.g. for a long infographic or comic, it's rare but not unthinkable to have something like a 40 Mpx image that is 2000x20000. |
|
|
Foxtrot
|
2024-11-26 03:09:18
|
How is it going with jxl-rs? Is there any idea how long it should take? I have no idea how long does rewrite from C++ to Rust usually take so I just wonder if its like a year or more? Thanks. |
|
|
|
_wb_
|
2024-11-26 03:10:16
|
Or some kind of decorative element or timeline-like thing that runs along the whole page and is like 100x100000 which is only 10 MPx but you cannot do it in webp nor in jpeg |
|
2024-11-26 03:13:02
|
you can follow the progress here: https://github.com/libjxl/jxl-rs/commits/main/ |
|
|
|
Foxtrot
|
2024-11-26 03:14:47
|
Thanks I know, but I have no idea from commits how much is done and how much is "to be done" π |
|
|
|
RaveSteel
|
2024-11-26 03:35:44
|
Does jxl-rs have to goal of being faster than libjxl as well? libjxl is, mostly for very large images, pretty slow. At least above e1 and similar |
|
|
|
afed
|
2024-11-26 03:46:07
|
probably not, unless there are some new optimization ideas that have not been used in libjxl yet |
|
|
|
_wb_
|
2024-11-26 04:53:06
|
jxl-rs is only a decoder, not an encoder |
|
2024-11-26 04:53:24
|
if you say libjxl is pretty slow, I assume you mostly mean the encoder? |
|
2024-11-26 04:53:57
|
since decoding is quite fast:
```
JPEG XL decoder v0.11.0 0.11.0 [NEON]
Decoded to pixels.
4064 x 2704, geomean: 192.461 MP/s [145.59, 199.90], , 30 reps, 4 threads.
``` |
|
2024-11-26 04:55:46
|
at least that's fast enough to do realtime Full HD @ 100 fps so I have a hard time imagining use cases where for decoding a still image that's "pretty slow"... |
|
|
|
Tirr
|
2024-11-26 04:57:52
|
I guess it's slow for high effort lossless |
|
|
|
RaveSteel
|
2024-11-26 05:28:46
|
I was refering to the decoder, encoding speed is pretty good indeed.
Decoding speed is also fine, but mostly for smaller to larger images.
At default effort it takes neglibibly longer to load an image compared to other formats, but this changes when we look at very high resolution images.
This also seems to only apply to JXL images not losslessly transcoded from JPEGs, as those often load much faster, but a JXL converted from PNG etc. will often, not always, be slower.
Just one example, which I posted before:
https://discord.com/channels/794206087879852103/794206087879852106/1305412731347800106
THis is of course not representative, but is not only the case with this particular image.
One other example:
https://www.visibleearth.nasa.gov/images/57747/blue-marble-clouds
The original PNG, 21600x21600, weighing in at 202 MiB loads in around 1.5 seconds, while the JXL (which offers a very respectable halving of filesize, to ca. 100 MiB) takes 3-4 seconds to load. |
|
|
|
Quackdoc
|
2024-11-26 05:49:45
|
modular decode speed is still a bit of a pain on lower end devices like midrange or below, or slightly older android devices |
|
|
|
A homosapien
|
2024-11-26 05:50:42
|
isn't decoding speed for larger images also dependent on the amount & speed of ram available? |
|
2024-11-26 05:51:05
|
or am I thinking of encoding? |
|
|
|
_wb_
|
2024-11-26 05:51:09
|
Oh, right, modular decode is quite a bit slower than vardct |
|
|
|
RaveSteel
|
2024-11-26 06:26:40
|
For reference, 7950X and 64GiB RAM |
|
|
|
veluca
|
2024-11-26 09:03:10
|
I do expect the code I'm cooking up for modular decode in jxl-rs to eventually do a better job, fwiw |
|
|
|
Quackdoc
|
2024-11-26 09:44:38
|
neat, better modular is always appreciated, currently jxl-coder, using libjxl, causes my phone to noticeably heat up when browsing a gallery on my phone |
|
|
Salty
|
2024-11-27 08:30:51
|
I made a Photoshop plugin for JPEG XL support.
https://gitlab.com/SuperSaltyGamer/jpegxlformat |
|
|
|
CrushedAsian255
|
2024-11-27 09:08:31
|
Is JXL a supported payload in PDF? |
|
2024-11-27 09:08:47
|
It would be nice for optimising my large archive |
|
|
|
_wb_
|
2024-11-27 09:32:18
|
Not yet. Maybe in a future version of PDF. |
|
|
|
CrushedAsian255
|
2024-11-27 09:36:09
|
can't wait to save ~15 GB |
|
2024-11-27 09:36:16
|
i'm already using JXL to optimise SVGs |
|
2024-11-27 09:36:32
|
i wrote a program that finds all assets in an SVG and converts the JPEGs and PNGs to JXL, and then converts them back |
|
|
|
jonnyawsom3
|
2024-11-27 08:33:02
|
Huh, it fails to decode in both Fossify Gallery and Irfanview |
|
2024-11-27 08:33:16
|
`Unknown JPEG XL file` |
|
|
|
CrushedAsian255
|
2024-11-27 11:16:45
|
will be even better once proper crossframe prediction is implemented in libjxl |
|
|
|
DZgas Π
|
2024-11-27 11:26:17
|
<:pancakexl:1283670260209156128> |
|
|
|
CrushedAsian255
|
|
|
Demiurge
|
2024-11-28 07:51:40
|
high effort lossless decodes at the same speed at effort=3 and above |
|
2024-11-28 07:51:53
|
only really low effort has special fast paths |
|
2024-11-28 07:52:27
|
But that's also something that can probably be accelerated even further... if there was any reason to, when it's already so much faster than the alternatives |
|
2024-11-28 07:53:43
|
The main problem with the decoder is that it has unbounded, unpredictable memory use |
|
2024-11-28 07:54:29
|
There's no way to limit it or predict how much memory it needs |
|
2024-11-28 07:55:00
|
Also the multi core speedup is extremely sub-linear. |
|
2024-11-28 07:55:44
|
but I don't remember if that last part is during encoding or decoding or both. |
|
2024-11-28 07:56:20
|
I wish I had some jpegxl pancakes... |
|
|
novomesk
|
2024-11-28 04:54:02
|
I get "JXL_FAILURE: Blending in unsupported color space" after playing approx. 40 frames in gwenview |
|
|
|
DZgas Π
|
2024-11-28 05:17:11
|
Hmm decoder problems |
|
|
|
novomesk
|
2024-11-28 05:52:52
|
How did you create that JXL Shrek animation? |
|
|
|
jonnyawsom3
|
2024-11-28 05:53:16
|
I'd assume video to APNG then cjxl |
|
|
|
DZgas Π
|
2024-11-28 06:13:51
|
```ffmpeg.exe -i Shrek.mkv -vf "fps=2,scale=128:-1:flags=spline+full_chroma_inp,mpdecimate=hi=64*50:lo=64*8:frac=1,crop=128:64" -compression_level 0 APNG.apng
```
```cjxl -e 9 -d ? APNG.apng OUT.jxl
``` |
|
2024-11-28 06:15:31
|
I used the complex mpdecimate function to avoid updating frames that are too similar. so I saved about 15% of data |
|
|
|
jonnyawsom3
|
2024-11-28 06:16:17
|
Running an APNG optimizer on it first might've helped further, since I don't think ffmpeg considers inter-frame transparency prediction |
|
2024-11-28 06:17:04
|
Though, at 2fps there's probably not much anyway |
|
|
|
DZgas Π
|
2024-11-28 06:17:11
|
I didn't understand what you were talking about |
|
|
|
jonnyawsom3
|
2024-11-28 06:17:32
|
Using transparency for identical pixels to the previous frame |
|
2024-11-28 06:18:11
|
I've never found a short way of saying it... |
|
|
|
DZgas Π
|
2024-11-28 06:19:28
|
Are we talking about jpeg xl right now? apng is just an intermediate container |
|
|
|
jonnyawsom3
|
2024-11-28 06:20:10
|
Yes, but libjxl doesn't do any optimization on it's own, you need to optimize the APNG first to use cropped frames and transparency |
|
|
|
DZgas Π
|
2024-11-28 06:22:02
|
I understood what you mean. hmm. I didn't know that jpeg xl can overlay animation frames on top of each other. using transparency |
|
|
|
novomesk
|
2024-11-28 06:24:11
|
So cjxl created JXL animation which is not fully decodable by libjxl decoder. Looks like a bug to report. |
|
|
|
jonnyawsom3
|
2024-11-28 06:24:56
|
Same method as GIF and APNG, kBlend (I think). Though if you make your own tools, you can use kAdd with negative floats |
|
|
|
DZgas Π
|
2024-11-28 06:25:20
|
This is actually great news. Perhaps I will write my own program that will do this by analyzing each frame. But I'll deal with it later. First I need to figure out how to convert an image into analog information, I write about this in <#806898911091753051> |
|
|
|
jonnyawsom3
|
2024-11-28 06:25:25
|
Seems like an application color management error. djxl decodes it fine and so does my version of ffmpeg |
|
|
|
novomesk
|
2024-11-28 06:26:25
|
The error is returned by libjxl. |
|
|
|
DZgas Π
|
2024-11-28 06:26:54
|
ffplay, mpv, Palemoon(2023) -- work without errors. the animation is playing. the mpv even speeds up. Unfortunately, rewinding is not possible |
|
|
|
jonnyawsom3
|
2024-11-28 06:26:59
|
Huh... So why is djxl working? |
|
2024-11-28 06:27:12
|
Weiiird |
|
|
|
DZgas Π
|
2024-11-28 06:27:47
|
<:galaxybrain:821831336372338729> do not use djxl (like me) |
|
|
|
jonnyawsom3
|
2024-11-28 06:28:41
|
https://discord.com/channels/794206087879852103/804324493420920833/1294414119541411924 |
|
2024-11-28 06:29:35
|
No transparency needed, and lower residuals across all frames (Probably) |
|
|
|
DZgas Π
|
2024-11-28 06:30:55
|
This is not currently implemented at the encoder level |
|
|
|
jonnyawsom3
|
2024-11-28 06:31:16
|
Correct, you need to directly use libjxl |
|
|
|
DZgas Π
|
2024-11-28 06:32:19
|
"you can", I don't like that. therefore, I will somehow work on a block update of the frame using transparency |
|
|
|
jonnyawsom3
|
2024-11-28 06:32:51
|
I wish you luck on your Shrek compressing |
|
|
|
DZgas Π
|
2024-11-28 06:33:04
|
<:Stonks:806137886726553651> |
|
|
|
novomesk
|
2024-11-28 06:38:44
|
I don't know now. Maybe different API used or maybe some settings are needed to encounter the problem. |
|
|
|
DZgas Π
|
2024-11-29 12:23:53
|
what programs do this? |
|
2024-11-29 12:24:50
|
I have written my own algorithm for this. I can't find a way to record footage with an overlay. png --> apng
APNG_BLEND_OP_OVER <:FeelsReadingMan:808827102278451241> |
|
|
|
jonnyawsom3
|
2024-11-29 01:01:04
|
https://sourceforge.net/projects/apng/files/APNG_Optimizer/ |
|
|
|
DZgas Π
|
2024-11-29 01:01:37
|
not work |
|
|
|
jonnyawsom3
|
2024-11-29 01:01:51
|
Interesting |
|
|
|
DZgas Π
|
2024-11-29 01:02:45
|
It optimizes only the apng and does not overlay the alpha channel
if the apng is already with the alpha channel |
|
2024-11-29 01:04:38
|
https://github.com/mr-Librian/APNG I found it but I have no idea how to use this code..... I've been looking hour and I don't even know what to do. I'm not java enjoyer |
|
2024-11-29 01:18:13
|
i FOUND it in pillow -- PngImagePlugin.Blend.OP_OVER |
|
2024-11-29 01:28:11
|
there is also bad news, it's good that I noticed it. for some reason, information is abnormally lost on e8 e9, everything is fine on e1-7. As I understand it, the block separation system is broken.
In any case,
**the world's first Jpeg xl with block-by-block animated updates** <:Poggers:805392625934663710> |
|
2024-11-29 01:29:42
|
<@238552565619359744>it 2 times less than if do not do such an optimization |
|
|
|
jonnyawsom3
|
2024-11-29 01:51:44
|
Huh, that actually looks pretty good for under 200KB |
|
|
|
DZgas Π
|
2024-11-29 02:00:10
|
There is still something to work on here, but as for me this is already a complex algorithm |
|
2024-11-29 02:23:43
|
|
|
|
|
jonnyawsom3
|
2024-11-29 03:27:32
|
You can see a small list of todo's here https://github.com/libjxl/jxl-rs/blob/main/jxl/src/frame.rs |
|
|
|
DZgas Π
|
2024-11-29 11:30:51
|
I think need to create a website for this <:JPEG_XL:805860709039865937> video to jxl animation with my optimize |
|
2024-11-29 08:18:17
|
Well, he invented JVC <:logo:829708783336816671> |
|
2024-11-29 08:19:05
|
now i have to drown in endless testing of good encoder parameters |
|
2024-11-29 08:22:06
|
|
|
|
AccessViolation_
|
2024-11-30 03:57:14
|
I wonder if JPEG XL has a place in browser caching of regular JPEGs |
|
2024-11-30 03:59:28
|
Possibly also for lossless image formats, but then you can't rely on it being a bit-exact representation so wouldn't be a true cached version of the original file, but it would match the pixel data which is probably what's most important |
|
|
|
jonnyawsom3
|
2024-11-30 04:22:04
|
If a browser supports JXL, CDNs should already be serving them. JPEG cache transcoding *could* work, and IIRC Chrome was thinking of having a JXL content type to compress JPEGs during transfer like GZIP, Brotli and ZSTD |
|
|
|
HCrikki
|
2024-11-30 05:44:58
|
as long as theyre transcoded by web services at effort 7 or lower, itd happen almost in realtime (avg web image should transcode and start being served is less than 15ms) |
|
|
|
Dejay
|
2024-11-30 08:14:46
|
Would be cool for a minimalist browser similar to geminiprotocol over low throughput long range wifi like. So any news article / web page would be turned into a highly compressed static blob that can be mirrored p2p |
|
2024-11-30 08:15:03
|
Unfortunately avif would be better for that atm π (I know, heresy haha) |
|
|
|
Traneptora
|
2024-11-30 10:11:11
|
I got a libjxl_anim ffmpeg wrapper coming soon (tm) |
|
2024-11-30 10:11:31
|
may help with that |
|
|
|
DZgas Π
|
2024-12-01 12:21:29
|
at the moment, during testing, I get a 2 times saving in file size with imperceptible changes (moments when 8x8 blocks in the frame are not updated)up to 3 times when it is noticeable when zoomed in, but still imperceptible from a normal distance. I also want to note that the algorithm is super complicated, so discuss in advance the size of the image that you want to process and the number of frames. For 1080p 100 frames, my new ryzen 5 7600 will run for maybe half a day. This is also due to the fact that I don't like PSNR and SSIM and I prefer the more classical method of pixel difference sums of the brightness channel
But yes, I have been actively developing an algorithm for the last 2 full days. And I can help compress a specific jpeg xl animation for you |
|
2024-12-01 12:25:50
|
So far, the idea of a website has been postponed. since then, I have greatly complicated the logic of the algorithm, making it much better, and much slower. I can make animation for any if it's something interesting. I will not upload the source code yet. But I'll do it Sometime. At the moment it is python code with pure math and with shit |
|
2024-12-01 12:30:21
|
I thought it would be something like: if we know the ratio of each block to each block in all frame, then "we can just take the most information-relevant blocks to expose inside the frame".
But it turned out not to be so. |
|
2024-12-01 12:33:35
|
I fell into all the traps that arose on the early xvid and avc ultrafast, as well as gif optimizers. But I've almost solved it all |
|
2024-12-01 02:37:14
|
So I finally have a ready-made solution!
And there is something to show you
Everything is compressed in v0.11.0 4df1e9e -e 7 -d 2 --epf=0 |
|
|
|
CrushedAsian255
|
2024-12-01 05:54:46
|
Is this like block based motion compression or something? |
|
|
|
jonnyawsom3
|
2024-12-01 05:57:17
|
Kinda yeah, it encodes in 8x8 blocks and only changes a block when the difference between frames is high enough |
|
2024-12-01 05:57:26
|
As far as I can tell |
|
|
|
DZgas Π
|
2024-12-01 10:05:57
|
it sounds simple, but in fact, so much had to be done to do it |
|
|
|
VcSaJen
|
2024-12-02 01:36:11
|
Didn't people found that at least 10% of arbitrary internet JPEGs fail on lossless transcode? Not very practical. |
|
|
|
CrushedAsian255
|
2024-12-02 01:47:42
|
i have not had a single jpeg that fails on lossless transcode, excluding the occasional `.jpg` that was actually a WebP or PNG |
|
|
|
Quackdoc
|
2024-12-02 02:00:02
|
I encountered one and thats because I downloaded half and corrupted it lol |
|
2024-12-02 02:00:59
|
I think this is actually browser fail, im 99% sure what is happening here is the reverse proxy is doing it's job, but browsers are too dumb, if you "save image" vs "save image as" I think that will cause one to save as a proper png, and the other to save as a jpeg |
|
2024-12-02 02:01:00
|
I think |
|
|
|
Salty
|
2024-12-02 07:40:49
|
Updated my JPEG XL Photoshop plugin (https://gitlab.com/SuperSaltyGamer/jpegxlformat)
* Now using libjxl v0.11.1.
* Now supports 16-bit color depth.
* Now supports embedded ICC color profiles.
* Now uses native PS memory management and error dialogs.
* Added info about the Camera Raw plugin. |
|
|
|
Demiurge
|
2024-12-02 12:23:52
|
Yeah in reality it's very rare like cmyk 4-channel jpeg |
|
2024-12-02 12:24:12
|
Like less than 1% |
|
2024-12-02 12:25:47
|
Some malformed/corrupted jpeg canβt be transcoded either but it can if reconstructed without errors like with jpegtran |
|
|
|
novomesk
|
2024-12-02 07:46:37
|
qimgv. It is possible to seek animated files there. |
|
|
|
DZgas Π
|
2024-12-02 10:21:36
|
<:Poggers:805392625934663710> |
|
2024-12-03 03:07:35
|
3 fps shrek 10 mb will be ready tomorrow |
|
|
Meow
|
2024-12-03 03:33:32
|
I can't wait any longer for watching it on my 4K display |
|