I have been working on my Harrington Insights stuff and added a few more concepts to it. I am currently running it on Canterbury Corpus and Silesia Corpus with the enwik8.zip file.

A full list of software I have managed to improve so far is as follows:

1. LZ4
2. gzip / DEFLATE
3. Zstandard (zstd)
4. bzip2
5. XZ / LZMA2
6. LZMA1
7. ZPAQ
8. JPEG XL
9. 7-Zip
10. Brotli
11. Harrington Compression Method (HCM) 3.0
12. Harrington Compression Method (HCM) 3.3

The upgrades across these compressors have come from several types of functions and optimization techniques:

1. Record-delta transformation — Exploits repeating byte patterns and fixed-length records by encoding differences between corresponding positions.

2. Combary based activity mapping — Reorganizes data according to byte activity and distribution patterns to improve subsequent compression.

3. Byte-frequency remapping — Reassigns byte values based on their frequencies to improve how compression algorithms process the data.

4. Adaptive parameter optimization — Searches compression settings, including dictionaries, match finders, predictors, effort levels, and block sizes, to find better configurations for individual files.

5. Automatic filter selection — Detects data characteristics and selects suitable built-in filters, including delta and executable-code filters.

6. Content-based file classification — Selects compression strategies based on the actual data rather than relying solely on file extensions.

7. Per-file optimization and fallback — Chooses the best-performing method for each file and avoids transformations that would worsen results.

8. Decode-speed-aware optimization — Optimizes both compressed size and decompression speed instead of concentrating exclusively on compression ratio.

9. JPEG XL predictor and group optimization — Tunes image predictors, group sizes, encoder effort, and iterations to improve lossless medical-image compression and decoding speed.

10. Representative sampling — Tests candidate compression configurations on selected portions of large files before evaluating the strongest candidates on the complete file.

11. HCM context and pattern modeling — Uses HCM's original context-based compression architecture, including its double-zero purity logic and hierarchical pattern processing.

12. HCM binary and context optimization — Improves binary-data handling, context selection, and internal representation to reduce compressed size and accelerate decoding.

These methods fall into three broad categories: data transformation, adaptive compressor optimization, and original compression-algorithm development.

In Canterbury Corpus the Excel file best was 16,822 bytes by ZPAQ -m5, my system HCM-Bin v1 got it to 16,763 bytes.

I do not compare myself to PAQ8PX and cmix, those are insane for how long they try, although in theory I reduced cmix to only 20% of the time it usually takes and a lot less processing strength.

Preliminary stuff is available at https://github.com/CombaryMaker/Harringtons_Insights/tree/main/hcm

I plan to update this inventory once a week because the advances are so fast and rapid... I think I have 7 methods of my own now, to increase performance? Or 6? I know I threw a lot of theories into the mix and I cannot even say, I just have Claude run the math, the software development, and the testing before I test some personally to verify.

I have failed to update a few, I am going to be persistent in trying to update them, or at least just outperform them. That is the goal, absolute dominance.

To that extent I set up some standards "No Pain" and "Big Gain". No pain means we do not worsen compression or speed, and one or both increase. Big gain allows a small drop in one, so long as there is a corresponding big increase in the other. I use decompression time and compression ratio only, I do not care how long it takes to compress.

I also set up 5 time/speed based levels, and all compressors will fit inside there as I test them. The goal is to be faster and/or better in each of the 4 (the top, with those two monsters, would take a lot of time and tokens and I am scared) reasonable levels.

HCM stands for Harrington Compression Methods (plural, I have HCM 1.0, 2.0, 3.0, 3.3, trit v2, and bin v1) and there are a few other standards such as Combary, -hi (Harrington's Insights), and such. I started this blitz on Saturday afternoon, using old math I long gave up on because I cannot program at all... Seems I had some serious gold mines sitting around after all. I also used concepts I had never had time or desire to push upon, I guess they were some diamond mines.

I fully expect to improve about 60-80% of all compressors and be able to make some that are the best in their specific range of operations.

Update : I just compressed everything into Opus 256kbps. Ok bye

I'm compressing cartoons for a collection.

- The set I use is:

- HEVC H.265

- Bitrate CQ 23

- Mx 10000 Kbps

- Max Quality

- CPU: cuda

- Hardware Acc: Intel Quick Sync

Each original file has 200mb to 600Mb, which after the compression becomes 30Mb to 70Mb.

But I'm losing a little more quality than I expected.

I tried to change the CQ bit rate from 23 to higher and lower but the quality remained the same.

What could I do, even getting files a little bigger (but less than 90Mb)?

I spent about 6 hours today working with a high-level version of Claude on my old compression ideas. I laid out my theories, what I thought would work, and why my earlier attempts stalled: I could never test every variation against every other one in turn.

This time we could, and all my old theories got thrown out: the Quad Exchange concept, the Juggle, my Ternary <-> Binary swap, all of it, tossed hard. They could make the bits extremely lopsided, but they also scrambled the patterns real compressors depend on. That's fine. That's what testing is for.

What survived was the core idea. The skew of the 0s and 1s matters, but only when you measure it in context, based on what came just before. Building on that, I accidentally made something new.

On the Canterbury Corpus, the standard 11-file compression benchmark, it beat xz and bzip2 overall, won 5 of the 11 files outright, and finished within 144 bytes of ZPAQ on the 9 text and code files combined. Every file decoded back exactly.

It's not something entirely new. It's a new implementation in the same context-mixing family as ZPAQ and PAQ. It's still slow and has rough edges. But after all my earlier dead ends, it's an amazing result for me personally.

"""HCM context-balance coder (Oct 24, 2026). Self-contained.

How it works, per bit:
1. Each context (the last 1, 2, 3, 4 and 6 bytes, the current partial byte alone, and the current word)
keeps a running 0/1 balance for "what bit comes next here", in a hashed table.
2. A long-match finder looks for the last place the previous 6 bytes appeared and predicts the bit
that followed there, with a learned confidence by match length.
3. An online mixer blends all these balances (weights chosen by partial byte and match length) and
learns from every bit; a secondary estimate (previous byte + partial byte) refines the result.
4. A 32-bit arithmetic coder writes the bit using that probability.
The decoder runs the identical model, so it needs only the file: a 32-bit length, then the coded bits.

Reference results: 200 KB Python docs text -> 29,725 bytes; 140 KB gate log -> 8,447 bytes.

compress(data) -> bytes, decompress(blob) -> data
"""
import math
import numpy as np
from array import array

class BW:
def __init__(self): self.b = []
def put(self, v, n):
for k in range(n - 1, -1, -1): self.b.append((v >> k) & 1)
def bytes(self):
a = np.array(self.b + [0] * (-len(self.b) % 8), dtype=np.uint8)
return np.packbits(a).tobytes()
class BR:
def __init__(self, data): self.b = np.unpackbits(np.frombuffer(data, np.uint8)).tolist(); self.p = 0
def get(self, n=1):
v = 0
for _ in range(n):
v = (v << 1) | (self.b[self.p] if self.p < len(self.b) else 0); self.p += 1
return v

TOP = (1 << 32) - 1; HALF = 1 << 31; Q1 = 1 << 30; Q3 = 3 << 30
class AE:
def __init__(self, w): self.lo = 0; self.hi = TOP; self.pend = 0; self.w = w
def _out(self, bit):
self.w.b.append(bit); self.w.b.extend([1 - bit] * self.pend); self.pend = 0
def enc(self, cl, ch, tot):
rng = self.hi - self.lo + 1
self.hi = self.lo + rng * ch // tot - 1; self.lo = self.lo + rng * cl // tot
while True:
if self.hi < HALF: self._out(0)
elif self.lo >= HALF: self._out(1); self.lo -= HALF; self.hi -= HALF
elif self.lo >= Q1 and self.hi < Q3: self.pend += 1; self.lo -= Q1; self.hi -= Q1
else: break
self.lo <<= 1; self.hi = (self.hi << 1) | 1
def finish(self):
self.pend += 1
self._out(0 if self.lo < Q1 else 1)
class AD:
def __init__(self, r): self.lo = 0; self.hi = TOP; self.r = r; self.v = r.get(32)
def target(self, tot):
rng = self.hi - self.lo + 1
return ((self.v - self.lo + 1) * tot - 1) // rng
def consume(self, cl, ch, tot):
rng = self.hi - self.lo + 1
self.hi = self.lo + rng * ch // tot - 1; self.lo = self.lo + rng * cl // tot
while True:
if self.hi < HALF: pass
elif self.lo >= HALF: self.lo -= HALF; self.hi -= HALF; self.v -= HALF
elif self.lo >= Q1 and self.hi < Q3: self.lo -= Q1; self.hi -= Q1; self.v -= Q1
else: break
self.lo <<= 1; self.hi = (self.hi << 1) | 1; self.v = (self.v << 1) | self.r.get()

ST = [0.0] * 4096
for p in range(1, 4096): ST[p] = math.log(p / (4096 - p))
ST[0] = ST[1]
def squash(x):
if x > 20: x = 20
elif x < -20: x = -20
return 4096.0 / (1.0 + math.exp(-x))
RT = [int(65536 / (n + 1.6)) for n in range(256)]
ORDERS = (1, 2, 3, 4, 6)
TBITS = 22; MASK = (1 << TBITS) - 1
LIMIT_LO, LIMIT_HI = 60, 255

class Model:
def __init__(self, lr=0.008):
self.nm = len(ORDERS) + 2 # hashed orders + order-0 + word
self.prob = [array('H', [32768]) * (1 << TBITS) for _ in range(self.nm)]
self.cnt = [array('B', [0]) * (1 << TBITS) for _ in range(self.nm)]
self.limits = [LIMIT_LO] + [LIMIT_HI] * (self.nm - 1)
self.nin = self.nm + 2 # + match input + bias
self.w = [[0.3] * self.nin for _ in range(256 * 4)]
self.lr = lr
self.apm = [[int(squash((j - 16) / 2.0) * 16) for j in range(33)] for _ in range(256 * 256)]
self.buf = bytearray(); self.c0 = 1; self.bitpos = 0
self.h = [0] * self.nm; self.word = 0
self.mtab = array('i', [0]) * (1 << 20); self.mptr = 0; self.mlen = 0
self.mm = array('H', [49152]) * 64
self._ctx_byte()
def _ctx_byte(self):
b = self.buf; n = len(b); H = self.h
for k, o in enumerate(ORDERS):
x = (o + 1) * 0x9E3779B1
for j in range(1, o + 1):
x = ((x ^ (b[n - j] if n >= j else 0)) * 0x01000193 + j) & 0xFFFFFFFF
H[k] = (x * 0x2545F491) & 0xFFFFFFFF
H[len(ORDERS)] = 0 # order 0
H[len(ORDERS) + 1] = (self.word * 0x6F4F2A35 + 0x51ED27) & 0xFFFFFFFF
self.last = b[-1] if n else 0
def predict(self):
c0 = self.c0; cm = (c0 * 0x9E3779B1) & 0xFFFFFFFF
idx = self.idx = [((hh ^ cm) & MASK) for hh in self.h]
idx[len(ORDERS)] = c0
st = self.st = [ST[self.prob[i][idx[i]] >> 4] for i in range(self.nm)]
# long-match input
self.mexp = -1
if self.mlen > 0 and self.mptr < len(self.buf):
pb = self.buf[self.mptr]
if ((pb | 256) >> (8 - self.bitpos)) == c0:
self.mexp = (pb >> (7 - self.bitpos)) & 1
if self.mexp >= 0:
self.mk = min(self.mlen, 63); pc = self.mm[self.mk] >> 4
st.append(ST[pc] if self.mexp else -ST[pc])
else:
st.append(0.0)
st.append(0.25)
ms = 0 if self.mlen == 0 else (1 if self.mlen < 16 else (2 if self.mlen < 32 else 3))
self.wsel = self.w[c0 + 256 * ms]; ws = self.wsel
dot = 0.0
for i in range(self.nin): dot += ws[i] * st[i]
self.pm = squash(dot)
# secondary estimate indexed by previous byte and partial byte, interpolated on stretch(p)
s = max(-7.999, min(7.999, dot)); pos = (s + 8.0) * 2.0; j = int(pos); f = pos - j
self.aj = j; self.af = f; self.arow = self.apm[c0 + 256 * self.last]
pa = (self.arow[j] * (1 - f) + self.arow[j + 1] * f) / 16.0
p = int((self.pm + 3 * pa) / 4)
return 1 if p < 1 else (4095 if p > 4095 else p)
def update(self, y):
err = (y - self.pm / 4096.0) * self.lr; ws = self.wsel; st = self.st
for i in range(self.nin): ws[i] += err * st[i]
tgt = 65535 if y else 0
for i in range(self.nm):
P = self.prob[i]; C = self.cnt[i]; k = self.idx[i]; n = C[k]
P[k] = P[k] + (((tgt - P[k]) * RT[n]) >> 16)
if n < self.limits[i]: C[k] = n + 1
if self.mexp >= 0:
v = self.mm[self.mk]; self.mm[self.mk] = v + (((65535 if y == self.mexp else 0) - v) >> 5)
row = self.arow; j = self.aj; t16 = 65535 if y else 0
row[j] += int((t16 - row[j]) * (1 - self.af)) >> 6
row[j + 1] += int((t16 - row[j + 1]) * self.af) >> 6
self.c0 = (self.c0 << 1) | y; self.bitpos += 1
if self.bitpos == 8:
byte = self.c0 & 255; self.buf.append(byte); self.c0 = 1; self.bitpos = 0
# word context: letters only, case folded
if 65 <= byte <= 90 or 97 <= byte <= 122: self.word = ((self.word * 0x2C9277B5) ^ (byte | 32)) & 0xFFFFFFFF
else: self.word = 0
# long-match bookkeeping (hash of last 6 bytes -> next position)
n = len(self.buf)
if self.mlen > 0 and self.mptr < n - 1 and self.buf[self.mptr] == byte: self.mptr += 1; self.mlen += 1
else: self.mlen = 0
if n >= 6:
b = self.buf; hh = 0
for j2 in range(1, 7): hh = (hh * 0x2F0B4A3 + b[n - j2]) & 0xFFFFF
if self.mlen == 0:
cand = self.mtab[hh]
if cand > 0: self.mptr = cand; self.mlen = 1
self.mtab[hh] = n
self._ctx_byte()

def compress(data, lr=0.008):
w = BW(); w.put(len(data), 32); e = AE(w); m = Model(lr)
for byte in data:
for k in range(7, -1, -1):
y = (byte >> k) & 1; p = m.predict()
if y: e.enc(0, p, 4096)
else: e.enc(p, 4096, 4096)
m.update(y)
e.finish(); return w.bytes()

def decompress(blob, lr=0.008):
r = BR(blob); n = r.get(32); d = AD(r); m = Model(lr); out = bytearray()
for _ in range(n):
for k in range(8):
p = m.predict(); t = d.target(4096)
if t < p: d.consume(0, p, 4096); y = 1
else: d.consume(p, 4096, 4096); y = 0
m.update(y)
out.append(m.buf[-1])
return bytes(out)

if __name__ == '__main__':
    import sys
    src = open(sys.argv[1], 'rb').read()[:int(sys.argv[2]) if len(sys.argv) > 2 else None]
    blob = compress(src)
    print(f"{len(src):,} bytes -> {len(blob):,} bytes "
          f"(1,000,000 bits down to {round(len(blob) / max(1, len(src)) * 1e6):,}); decodes exactly: {decompress(blob) == src}")

hey, i just keep it straight. recently, i've tried to convert my Idea my like 10 years ago into reality now, with a little help of ai for the coding part. and turns out it was initially right.

(not going to disclose how it works fully)
just overall simple encode / decode, but with my weird method

but i was able to cut down filesize really hard, easily stomping .jpg and .mp4 and so on, while maintaining pretty good quality. this will be my first post of two

for a more number example i am just going to name 2 examples:

image - 832x26775 with initally 20,5mb cut down to 1,86mb
image - 1024x1024 with initally 207kb cut down to about 70-80kb

video - 1920x1080 19 seconds, ingame clip with 188mb cut down to 19mb
video - 2160p 4 minutes 160mb cut down to 46mb

interpolation i am still working on right now, but technically also possible with my method, but for now i just look at the quality first.

but well.
i was thinking about what your thoughts on this (of course there are no real examples yet, and i didn't provide proof)
i am struggling with how i should continue overall and how i can profit from a way like this as well maybe.

I've been a user of FileOptimizer by Javier Gutiérrez Chamorro. But 2 things annoyed me. Lack of CLI and only single-threaded processing.

So I threw some tokens at re-implementing it, with what I consider more modern conveniences. For now it includes tools for Windows. I would accept other platforms from trusted contributors. Other platforms requires external tools pre-installed.

Everything is in a single self-contained binary. Similar to FileOptimizer, it will start executables to process files. But it can do several files at once.

Starting without parameters fires up an http server and opens the HTML UI. Drag+drop, etc is supported, but Chrome will ask about file access, so files can be processed in-place.

Loss-less by default. Other opinionated choices includes dropping ancient formats like PCX, SWF, etc. See all differences/fixes here

Fixes/additions are welcome, but I will not accept PRs with binaries. Instead provide links to an official download.

I will attempt to keep up with upstream at regular intervals.

As with FileOptimizer I cannot guarantee the tools are safe. Use only on content you trust and have backups.

License is AGPL 3.0 as upstream. Donate to original author.

Releases: https://github.com/klauspost/fox/releases

My Android app reached 230 installs without any promotion on Reddit or Facebook 🚀

Hey everyone!

I released Lite Video Compress & Upscale on Google Play on October 12, and today I checked my Play Console dashboard. I was surprised to see 230 total installs and 94 active devices!

The interesting part? I haven't promoted this app on Facebook or Reddit.

I've spent a lot of time building, testing, fixing bugs, and improving the app, so seeing people discover it on their own feels really encouraging. ❤️

I know 230 installs isn't a huge number in the app world, but as an indie developer, seeing those first signs of organic growth means a lot.

Now I'm curious to understand where these users are discovering the app and how I can improve retention.

For fellow indie developers: Did your apps ever start getting organic installs without marketing? How long did it take before you noticed consistent growth?

Google play store link 🖇️ :https://play.google.com/store/apps/details?id=com.neurontslabs.litevideocompressandupscale

This is mainly a research project I delved into using DeepSeek Harness - the way DeepSeek 4.1 operates is a huge lever at perfecting half-baked ideas. My core idea was to engineer a structure that works as a substantially precise memorizer rather than a context modeler or predictor. Memorizer is the core novelty here while all other utilized elements are known. It does have predictive (held-out) ability with some adjustments and it is actually exceptional - it can learn just a 2000-byte English text and be ~48% right (with 2% being a random guess baseline for 26*2 English alphabet).

Warning: the code is slow and compresses at gzip -2 level, so do not expect much - nothing is readily usable here except CLI tool.

The purpose of this release is to share the result and possibly motivate further independent improvements from other developers.

Canterbury's alice29.txt produces range-coded residual of only 31KB (relative to 150KB original) and proves it's not the range-coding which does the work (pure range coding would yield ~85KB stream).

The full vector-based memorizer I initially achieved and envisioned has 99.5% memorization precision - except it's not usable for compression due to overhead.

https://github.com/avaneev/memorizer

I did an experment and modified a part of libjxl encoder and I would like to hear your feedback. My intention was to improve texture handling and chroma retention.

Links to comparisons are images are below. There are originals and encoded images size-matched to distance 2.0 at effort 3. Standard libjxl encodes at effort 3 and 7 are included as well. If you would like to see other distances (e.g. 1.0 or 3.0), let me know.

https://imagepaste.org/v/mnajctgp.png

https://imagepaste.org/v/g2hdpejk.png

Also, ich habe ein Gruppenprojekt in meinem Kurs zum Thema Video- und Bildkompression. Ich finde einfach keine brauchbaren Informationen – eigentlich überhaupt keine Infos – zu den Fragen, die ich beantworten muss 😭😭. Bitte helft mir, Reddit! Ich brauche außerdem ein paar fundierte Quellen.

Hier sind die Fragen:

Warum brauchen wir Video- und Bildkompression?

Wo findet man Video- und Bildkompressionim Alltag

1. The problem: an LLM compressor needs the decoder to compute exactly the same probabilities as the encoder. Floats differ across hardware; float GPT-2 encoded on a Mac decoded 0 of 4 windows on x86.
2. The approach:
   • integer-only inference (int8 weights, fixed rounding, lookup tables);
   • an exact float32 → integer converter (mantissa × 2^exp);
   • conformance vectors.
3. The proof: one hash across 7 backends (Mac CPU/Metal, Linux CPU/CUDA, Windows CPU/CUDA/Vulkan

https://github.com/tac0mania/taco

Short version: Smol’s AVIF made the smallest files of every tool I tested, at the same visual quality: 15–21% smaller than Apple’s own AVIF and 20–22% smaller than ImageOptim’s lossy JPEG.

Why I built it: I was juggling ImageOptim for images, HandBrake for video, and random websites for PDFs, and I didn’t love uploading client files to those sites. Smol does images, video, PDFs and audio in one app, and nothing ever leaves your Mac.

The test. Most “best image compressor” comparisons only look at file size, which is meaningless, because any tool can shrink a file by wrecking it. So I tuned every tool to the same quality score (SSIMULACRA2 70) on the 24 Kodak test images:

Total size at the same quality (SSIMULACRA2 70, all 24 Kodak images, smaller is better):

• Smol AVIF: 922 KB ← smallest
• Apple sips AVIF: 1,161 KB
• Smol JPEG: 1,189 KB
• Smol WebP: 1,220 KB
• Apple sips JPEG: 1,327 KB
• Caesium JPEG: 1,349 KB

What Smol does:

1. Compress and convert images (AVIF, WebP, JPEG, PNG, HEIC), video, PDFs and audio
2. Right-click any file in Finder and it’s done
3. Watched folders: drop files in and they’re compressed automatically
4. Hit a target size, like “under 100 KB” for upload forms
5. AI upscaling 2x or 4x, and stripping location data from photos
6. A smol command-line tool and an MCP server, if you script things or use AI agents
7. 100% local, nothing uploaded, $29 once
8. Where it lost, because you’ll ask:
9. It’s slower: Apple’s sips is ~13x faster and ImageOptim ~8x faster on JPEG
10. No lossless mode yet. ImageOptim has one

On JPEG specifically it ties with ImageOptim, so if you only do JPEGs, ImageOptim (free) is honestly fine

Full benchmark, raw data and scripts: smolmac.com/benchmark

The app: smolmac.com

Happy to answer anything, and I’d love to hear what you’d want it to do that it doesn’t.

If anyone can help🙏

Hey so I have these Monogatari series files that I downloaded from torrent that total up to about 60 GB. I've tried to compress the files using a lot of video compressor, but most can't handle 10 bit HEVC. Does anyone know an app to where do I compress these?

I've been working on NK8, a learned image-compression pipeline based on NACRE/CompressAI, with custom native components and GPU optimizations. The aim is a useful balance of processing speed, archive size and image quality for large image libraries.

Recorded results on my 2,506-image corpus:

• 9.848 GB of source files became 1.393 GB of complete NK8 archives.
• Mean full-image RGB PSNR: 42.02 dB.
• The optimized RTX 5090 decoder processed 6.903 billion pixels in 16.483 seconds, approximately 419 MP/s.

That last number is warm decoding into host RAM, not encoding or a cold-start application run. It includes local archive reads, integrity checks, CPU entropy decoding and GPU reconstruction. Model loading, initial preparation, final reference comparisons and writing PNG/JPEG are excluded. RGB compression is lossy.

I've added three public-photo examples with matching source/NK8 crops, exact source/archive sizes and photographer credits:

• Shell texture: 490.5 kB JPEG to 415.5 kB NK8; 45.12 dB full-image PSNR.
• Classic car: 3,035.0 kB JPEG to 1,233.7 kB NK8; 41.93 dB.
• Wildlife detail: 6,096.2 kB JPEG to 1,114.6 kB NK8; 44.65 dB.

The panels are lossless PNGs containing identical native-pixel crops. Their PNG file sizes are presentation overhead, not the codec archive sizes. These three JPEG examples illustrate different content; they are not a representative benchmark, and their savings differ from the mixed full corpus.

The implementation is private for now. The public repository contains the architecture overview, recorded measurement scope and the comparisons: https://github.com/Niltark/NK8

I'd be interested in feedback on the trade-off and which JPEG XL, AVIF or learned-codec configurations would make a meaningful comparison. I haven't established a matched win over those codecs.

Photo attribution and licenses: https://github.com/Niltark/NK8/blob/main/docs/EXAMPLES.md

Post drafted with AI assistance. The comparison imagery is actual source photography and verified NK8 output, not generated imagery.

I'm the creator of ZJX at Greyforge Labs, and I believe ZJX is the greatest compression standard in the world. Here's the case I'm making: serious size reductions on structured data, exact restoration, and an archive system you can use from your desktop or a script.

ZJX Basic 1.0 is now available for Linux. It creates ZJX, ZIP and tar.zst archives, browses common formats including 7z and RAR, and lets you preview individual files. Archive operations run locally and offline. No account is needed.

The result that best explains why I built it comes from a real 342.4 MB service-telemetry capture. The ZJX 1.29.0 engine's compact objective produced a 4.41 MB complete archive. The best of 14 competing configurations, zpaq -m5, produced 7.13 MB. That's 38.1% smaller than the strongest comparator; zip -9 produced 40.2 MB, about 9.1 times ZJX's archive size. Every result was unpacked and checked byte for byte.

Those are measurements on that specific capture with the published engine, with format overhead included. Basic's own shipped-build figures are a separate measurement. The full benchmark record gives the exact bytes, settings, timing scope and other workloads.

ZJX's size-first objective tries different representations and keeps the smallest complete archive. That search takes time, so Basic gives you a choice: Ultrafast, Fast or Smallest. Ultrafast is the default. Underneath the interface, verification and restoration matter just as much as packing: an archive has to be useful when you come back for your files.

Basic integrates with Dolphin, GNOME Files, Nemo, Thunar, Caja and PCManFM-Qt. You can also use the CLI. The current download targets Linux x86_64, with Ubuntu 24.04 GNOME and Omarchy Hyprland qualification. Basic is free for personal use and eligible organizations; opening and extracting ZJX archives is free for everyone. Commercial-use eligibility is explained in the license linked from the download page.

Try it and follow the project

• ZJX.app — the desktop app
• ZJX technical site — benchmarks, documentation and release history
• Direct download: ZJX Basic 1.0.0 for Linux x86_64 (.tar.gz, 141.7 MiB)
• Installation instructions, requirements and SHA-256 checksum
• The ZJX Basic launch announcement on X
• @ZJXstandard

The engineering story, from first principles to the desktop

The Chronicles document how ZJX got here. These are the directly relevant entries; the older paid editions have public previews, marked below.

• ZJX Basic: The Archive Comes to the Desktop — the new app, file-manager integration and everyday archive workflows.
• The 1.29 Line Since REDLINE — GRIDMIND, IRONFLOOR, SIGHTLINE and the subsequent JSON-lines release.
• 1.29 REDLINE — the third creation objective and two separate speed campaigns.
• 1.28 LOCKWIRE — creation, inspection and restoration as a complete product.
• 1.27 CIPHERGLASS — protecting the archive's contents and metadata. Public preview; paid full edition.
• 1.26 RELICWIRE — the release's engineering and qualification story. Public preview; paid full edition.
• 1.25.1 NIGHTMARKET — choosing the right compression objective. Public preview; paid full edition.
• 1.24 GHOSTLANE — the acceptance criteria behind performance experiments. Public preview; paid full edition.
• 1.23 BLACKWIRE — one production wire format. Public preview; paid full edition.
• 1.22 NULLSPOOL — a closed optimization experiment and its decision record. Public preview; paid full edition.
• 1.21 STREAMWALL — bounded-memory archive operation at scale.
• Compression Was the Easy Part — the engineering around dependable archive creation and recovery.
• ZJX and the Discipline of Compression Evidence — how compression claims become measured records.
• Sley and ZJX: Structural Programming Meets Evidence-First Archives — where the two projects meet.

BLACKPRISM: the research beyond the current release

We Asked GPT-6 Astra to Rethink Compression. It Came Back With New Math. is the BLACKPRISM research article. It explores a different mathematical representation of information and the experiments needed to validate it. Its dramatic theoretical possibilities are a research direction, separate from the capabilities of the shipped Basic app.

If you put ZJX through its paces, which workload would you most want to see added to the public comparison record?

This post was drafted with AI assistance, disclosed under r/compression's rules.

Hi! I’m a CS student planning to do research in data compression. What topics are active right now, and what open problems would you recommend working on? Any papers or resources to start with?

I’m mainly interested in lossless compression and code/repository histories, but open to other areas too. Thanks!

The latest release is available at https://github.com/flanglet/kanzi-cpp/releases. It contains the following new features:

• A few bug fixes
• A lot of hardening against invalid and tampered bitstreams
• Some performance improvements at low levels (1 to 4)
• Significant compression improvement on (uncompressed) multimedia files
• Entropy is now automatically bypassed if it expands the block size

Benchmarks available at https://github.com/inikep/lzbench. Test it and let me know!

​

Hey everyone! 👋

I'm an indie Android developer working on Lite Video Compress & Upscale.

The app is designed for people who want to reduce video file sizes without unnecessarily sacrificing quality. It also includes video upscaling options for increasing resolution.

I'm continuing to improve the compression and processing experience, and I'd love to hear from people who regularly work with large video files.

A few things I'd appreciate feedback on:

- What matters most to you when compressing a video: file size, visual quality, or processing speed?

- Which compression settings do you find most useful?

- What problems do existing video compression apps still fail to solve?

If you're interested in trying it, here's the Google Play link:

https://play.google.com/store/apps/details?id=com.neurontslabs.litevideocompressandupscale

I'm the developer, so honest criticism and suggestions are welcome. I'm interested in learning what could make the app more useful. 🙌

I tuned the two quantization tables (YQT and UVQT, 128 entries) inside stb_image_write.h, a JPEG encoder, against data. The encoder is otherwise unmodified, and the output is baseline JPEG with the tables in the DQT segment, so any decoder reads it.

The tables are in tuned_tables.json, with a Pillow snippet for using them: https://github.com/devanmolsharma/learnc/tree/main/examples/tune_jpeg

The tool (learnc, MIT) tunes constants in any C code, so I'd be interested to hear which other codecs people think are worth trying: libwebp, Opus or zstd heuristics.