If the max is 318, why did one of my images give 373?
FSE gave 2x faster decoding, vectorization and custom sparse compressors further 3x, totaling 6x. However the emulator of the target I was using was somewhat inaccurate, and the result was still too slow on the real target. 8-bit vars didn't turn out possible. I investigated replacing FSE with various methods, tried nibble-based tANS, etc etc, but couldn't create a generic entropy coder that could beat FSE on the pareto frontier (faster, better or both). Tunstall promised a nice speedup, but nobody...
Well, some other images had even higher values, 373 in one case. So I guess it's by design then, even if it means a 16-bit configured library would be unable to compress 16-bit images losslessly. For now I'm adding "patches" to the file, a list of error locations and the correct values, since the number of such high values per image is small, some tens in the worst case.
More info on my experiment, in case PGF folks are interested. I'm playing around a slow embedded platform that would benefit from optimized image and video formats. Basing both on PGF for the grayscale component seemed the best option, as it's better than JPEG, but still very fast compared to higher compression formats like jpeg2k, webp, flif, bpg, or especially avif. For my sample images, PGF's quality is quite good. Depending on image, level 4 or 5 is still nearly lossless. The main issue is that...
I'm working on customizing PGF for an embedded use case, and with the attached image (grassfield.png, 1280x960 8-bit grayscale), I hit a curious behavior when encoded at quality 0/lossless. One of the macroblock's m_value[]s is 257 after the wavelet transform, but before the bitplane coding. This is rather curious to me, as to my understanding the wavelet transform should only add a sign bit, not increase the bit depth any further. So for 8-bit grayscale data, the transformed data should be at most...
Build fails with ROI disabled
Fix BurningVideo on big-endian
VS does not (did not?) support arrays with a dynamic size, u8 arr[var].
DMA happens instantaneously
24x24 sprites flipped horizontally display wrong
Add recording support
It's now posted in Debian Sid: https://packages.debian.org/source/sid/tightvnc
It needs a Debian developer to upload the change, unfortunately I'm not one. I will...
OpenSuse only ships the TightVNC client, so these patches aren't relevant to them....
Yes, they are already in Ubuntu (15.10, since June 30) and waiting to be in Debi...
The attached two patches fix this issue on top of the 1.3.10 release, tested on Unicamp's...
Add a new option for indenting continued shift ...
Static IQE reading support
Static B3D writing support
If you only had four types, did you check if the sort order made a difference? Ie,...
Add helper functions for converting between wchar and utf-8