JPEG XL

Info

rules 57
github 35276
reddit 647

JPEG XL

tools 4225
website 1655
adoption 20712
image-compression-forum 0

General chat

welcome 3810
introduce-yourself 291
color 1414
photography 3435
other-codecs 23765
on-topic 24923
off-topic 22701

Voice Channels

General 2147

Archived

bot-spam 4380

FPNGE

afed
2023-01-30 07:32:00
ect optimized (with previews) ffmpeg png fpnge
2023-01-30 07:37:20
2023-01-30 07:37:39
2023-01-30 07:38:00
2023-01-30 07:38:12
veluca
2023-01-30 07:44:37
for the anime images I kinda understand, given how fpnge works, but I do wonder what's up with the black images
2023-01-30 07:46:45
can you try doing high effort fpnge?
2023-01-30 07:47:19
it smells like there's a bug lurking
afed
2023-01-30 07:47:38
yeah, it happens even if it's a completely black or single-color frame hmm, I will try
afed
2023-01-30 07:51:45
`-5` is the maximum? looks like nothing changes
veluca
2023-01-30 08:17:16
mhhhh interesting
2023-01-30 08:17:54
ah, I think I know what's happening, I suspect we might end up not RLEing something like 15 values per row
2023-01-30 08:18:34
an easy way to test this is to check whether a, say, 1024xY image and a 2048xY image, all black, have similar or different sizes
afed
2023-01-30 08:30:35
8x2048,8x1024
2023-01-30 08:34:08
2048x8
veluca
2023-01-30 08:56:23
mhhh ok
2023-01-30 08:56:28
ah maybe I get it
2023-01-30 08:57:02
IIRC fpnge forces lz77 symbols to have at least 8 bits
2023-01-30 08:57:33
probably 10 or so
2023-01-30 08:57:59
we might be observing that, probably for single color images this is a very suboptimal choice
2023-01-30 08:59:22
I think I can make length-258 be its own symbol without issues and that should improve all black images a lot
afed
2023-01-30 09:03:57
libvips compression 1
veluca
2023-01-30 09:04:36
*of course* the code seems to say I already do that
2023-01-30 09:04:41
sigh... debugging time
2023-01-30 09:08:49
ops, I am entirely blind, I misread your first set of images as being 1024x8
2023-01-30 09:09:08
the behaviour on the second set makes sense and would be hard(er?) to fix
2023-01-30 09:10:05
as for the first screenshot images... I see they are not entirely black, which certainly changes stuff
2023-01-30 09:10:25
in particular they have super odd patterns
2023-01-30 09:10:34
at least one does
2023-01-30 09:10:47
looks like a DCT basis function that alternates between 0 and 1
2023-01-30 09:11:23
that's pretty much the worst case for fpnge xD probably fixable by doing smarter LZ77, but I am unsure whether I want to try and figure that out
afed
2023-01-30 09:12:30
yes, probably because it's still a lossy video as the source, the colors may not be completely consistent
2023-01-30 09:15:27
well, at least in most cases fpnge has the same or better compression than ffmpeg, and such images are a small percentage
veluca
2023-01-30 09:18:01
I won't go to them asking to replace their png encoder, but if someone does I'm not opposed xD
afed
2023-01-30 10:57:45
for ffmpeg as already discussed there may be difficulties due to different licenses and if ffmpeg already has a stable internal encoder it will be hard to replace it because it must also consider stability, portability and simplicity besides better and faster compression and I have not compared other more typical images but for example for libvips for the fastest modes fpnge may be useful, plus the main developers are here, but this will also require more extensive benchmarks
veluca
2023-01-30 11:14:58
yup, makes sense, as I said I don't particularly feel like trying to convince them
2023-01-30 11:15:13
although I am pretty sure it is OK to use an Apache2 lib in a GPL program
afed
2023-01-30 11:30:35
and maybe it's worth it to add fpnge for djxl? having a fast transcoding to png in the jxl decoder would be cool and actual use would help improve or maybe fix some issues for fpnge