|
|
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
|
|