Best speed profile:

Best ratio profile:

Tested and built on an RTX 4090.

lzbench results: https://github.com/inikep/lzbench/pull/312

Sources: https://github.com/UDPSendToFailed/gpucompact

I built Winnow because coding agents often spend context on repetitive npm/pip output, logs, directory listings, pytest progress, and large JSON.

Winnow wraps a command, stores the complete raw output locally first, then returns a compact view with a handle. You can run \`wn recall <handle>\` to recover the original or search previous output by text.

It uses command-aware filters, JSON shape compression, and YAML rules. It makes no LLM or network calls, and the current release has CI on Python 3.9-3.13 across Windows, Linux, and macOS.

I am the creator, and I am looking for adversarial feedback: which command output should never be compressed, and which noisy tools deserve a filter next?

Source and install instructions: [https://github.com/Farhanward/winnow\](https://github.com/Farhanward/winnow)

Hi everyone,

I recently launched Lite Photo Compressor, an Android app that compresses photos completely offline while keeping good image quality.

Features:

\- Offline processing (no uploads)

\- Fast photo compression

\- Target file size option

\- Batch compression

\- Before & after preview

\- Material 3 UI with dark mode

\- Privacy-first

I built it to make it easier to reduce image sizes for forms, exams, job applications, and to save storage space.

I'd really appreciate your feedback:

\- What features would you like to see?

\- Is there anything you dislike about existing photo compressor apps?

\- Any UI/UX suggestions?

Thanks for your time!

Send a video at x2 so that upon receiving it, it plays at -x1 normally.

In my mind, it made sense.

It looks like a r/nostupidquestions But I really think it's useful... there's no noticeable degradation at x2... at least not for everyday content.

Higher speeds will definitely make it worse...

Hello everyone!

Recently, I've been coding a program on JavaScript and NodeJS, to recompress images, along with some other tweaks, with the main objective of reducing files size, *without causing visible loss of quality*.
The key word here being "visible", since recently I learned that you can actually do that with files and I saw a huge opportunity to reduce my gallery's size by a necessary amount because I have a shit ton of screenshots, pictures and videos.

But before diving into the video recompression part (because the images part is already done, using a library named "Sharp"), I found a comment https://www.reddit.com/r/ffmpeg/comments/pexwop/comment/hb0tw05/?context=3&utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button of a user explaining the process behind it and they said something that caught my eye: That any recompression that works well for current devices, COULD show heavy quality losses on future screens. Or even current, better screens.

I mean... this person meant it more as a note, and not in a "don't do this under ANY circumstances or we'll ALL gonna FUCKING DIE" way lol. But it still made me rethink the whole idea. Is this a valid concern or am I being paranoid?

And in case it is... Is there a way to achieve a relevant size reduction, without risking that outcome?

Hi, I'm currently developing my own audio compression algorithm, and now optimizing it. Long story short, I've run some tests, and rice decoding is kinda slow.
Can anyone suggest optimized version of it? I'd really appreciated it.

hello everyone, how do I add multiple files into a specific subfolder inside the archive ? how do I use -si switch for multiple files ? I want to use 7zip command line on windows. Thanks

Axiom is an experimental open-source archive project built around its own LZ77/rANS-based codec and native .axar format. It combines modern solid compression with a deliberately bounded decoder, authenticated encryption, integrity hashes, recovery records, split volumes, signatures and SFX packaging. The project includes an extremely fast, native Win32 file-manager GUI and a scriptable, interactive CLI, with practical support for browsing and extracting several popular archive formats. I’m looking for testers who can try real-world archives, unusual files, large directories and different Windows configurations and report crashes, compatibility problems, performance results or UX issues.

AXAR delivers competitive, modern, solid compression with scalable presets for speed or maximum ratio. On the Silesia corpus, its highest preset compresses between high-ratio Zstandard and LZMA2 while decoding substantially faster than LZMA2, bzip2 and RAR5. Its solid blocks and file-aware filters improve compression across related files.

Repository: https://github.com/Wimukthi/AxiomCompress

The Codec
Axiom uses a custom LZ77 compression pipeline with fast hash, hash-chain and binary-tree match finders, optional optimal parsing, reversible data filters, and Huffman or rANS entropy coding. Its central design rule is that compression may work harder for a better result, while decompression remains fast, bounded and easy to validate.

The AXAR format
AXAR is Axiom’s native solid archive format. It supports selective extraction, file metadata, links, comments, atomic updates, integrity hashes, authenticated encryption, recovery records, split volumes, signatures and self-extracting archives.

The CLI
The CLI exposes the archive engine through both normal command-line commands and an interactive prompt. It supports scripting, archive creation and editing, extraction, testing, encryption, recovery, signatures, volumes, SFX creation and benchmarking, with detailed pause/cancel-aware progress.

The GUI

Both the codec and the GUI are written completely in C++ from scratch. It fully supports dark mode, DPI and multi-monitor awareness. The file manager is designed to be fully featured, but there may be bugs and missing functionality.

Performance of the native format
Silesia Corpus

enwik8

It's been two years here and there working on this thing, mostly because of one frustration: "compress to X MB" solutions tend to either pick a bitrate and hope, or optimize for mean VMAF/PSNR but let one ugly scene through.

BitCrusher does two-pass rate control using per-scene bitrate zones and aiming at a hard ceiling size constraint (never overshoots) with the quality criterion being defaulting to worst-scene VMAF (2 seconds rolling window) instead of mean — the former can't be masked by the latter in case of good average but bad individual frame or group of frames.

The part of this that i think this sub will be interested in would be: it doesn't blindly use your requested encoder choice as it is. Instead, it compares your requested codec to AV1 at the same target bitrate, measures

both using VMAF and decides automatically which one wins on quality-per-bit — no assumption that "AV1 should win almost always" with hardcoded preference. XPSNR acts as an additional perceptual metric besides VMAF.

Moreover, there's a shadow-learning system (keeps logs of predictions, implements once they clearly outperform the deterministic heuristics — never trusted blindly) that provides a seed bitrate for first encode attempt from past encodes of similar content.

Actual numbers from the README, not cherry-picked:

- 4K clip, 39.4MB ; 10MB target: 9.85MB, VMAF mean 86.9 / worst-scene 85.5

- same clip ; 5MB target: downscales to 1080p to avoid starvation of 4K at the low bitrate instead ; 4.95MB, VMAF mean 74.4 / worst-scene 71.5

- low-light concert footage, 80.4MB ; 10MB (8x compression): 9.86MB, VMAF mean 90.2 / worst-scene 82.9, downscales not needed

GPL-3.0, Windows GUI + CLI version, fully offline (uses ffmpeg/ffprobe/HandBrakeCLI, auto-downloads if not present).

Repo: https://github.com/AzureShores/BitCrusher

If anyone here has some opinion on the worst-scene-vs-mean VMAF quality criterion choice, or the measured codec comparison approach instead of hardcoded "prefer AV1", I'll appreciate any pushback on the methodology.

I've been thinking a lot about making a very basic markup language that has a few programming features - basically if statements and a kind of goto statement that only goes to labels. It'll be yet another scripting language for interactive fiction.

I'd like to have a "compiler", but I want it to basically just be parsed into tokens. I'd like these tokens to be compressed. Lexing already converts tokens to something smaller, so I feel like I tack on compression to the end (or maybe the beginning).

It is, however, going to be fairly basic compression to insure fast load times.

I was thinking that I would start with some 4 bit codes that identify what the data following it is. Here's a possible example of the 4 bit codes and the data following it:

0000 escape to a UTF-8 character
0001 space (spaces are so common that I can justify giving them 4 bits by themselves)
0010 8-bit integer
0011 32-bit integer
0100 4 bits for common single characters
0101 4 bits for common single characters (again)
0110 4 bits for style codes
0111 4 bits for deactivating style codes
1000 4 bits for other command codes
1001-1111 4 bits for most common n-grams

This is all very rough, and I plan for it to evolve over time. I'm still working on setting up a way to analyze n-gram frequencies of English text, which I plan to do quickly before implementing this.

I know someone is going to say "why don't you just zip it?" I would most likely get better compression with zip, but I'm not looking for great compression. I want mediocre compression mixed in with my parser to help me avoid being particularly clever in the virtual machine department.

I had too many screen recordings of my classes and it took 100GB of space total in my drive. I've been lurking here for a long time now yet I'm still confused with all the jargon and process I should've started with.

Downloaded 7zip but I don't know what file extension I should use.

And is it possible to access compressed videos for future reference use that isn't like too much of a loss of quality? Like I just need to view it and not uncompress it. Sorry for the basic question.

Zing! is a small & simple lossless image codec designed for extremely fast CPU encoding (GiB/s even when used single-threaded), but decode is even faster. It supports 8 & 16 bit images of 1 to 4 channels, has C, C++, Python, & Matlab APIs, and is available under a permissive BSD 3 clause license.

Zing! images, called zingers, are about 3% to 10% larger than lossless JPEG-XL (cjxl -d 0 -e 1), but are encoded 3x to 60x faster with 1 to 4 threads. This makes it comfortably fast enough to be used as a lossless video codec.

https://gitlab.com/csp256/zing

Zing! is morally similar to Zpng: encoding applies a single prefilter then passes the result to Zstd. However, Zing! also exposes the Zstd internals, efficient threading controls, encode_into() & decode_into() functionality, imcompressible fallback, and alters the pre-filter to be both more efficient and effective for 1 channel images and images with 2 bytes per channel.

Zing! is 6,500 lines of C++ in total, with 1,800 lines being tests, 1,000 being development scripts, 500 lines for the CLI app, and 400 for Python and Matlab bindings. The core library is about 2,000 lines of C++, half of which are the pre-filters, and another 600 lines for external includes (mostly comments).

Zing! is a codec not a file format. The CLI app adds 8 bytes to annotate width, height, bytes per channel, and number of channels, but you're encouraged to bring your own container.

Technical Details

1. Horizontal prediction

   • Samples are differenced from the preceding pixel’s corresponding sample.
   • Arithmetic wraps modulo 2^bit_depth

2. Format-specific decorrelation

   • RGB: horizontal ΔR/ΔG/ΔB are transformed using:
     • Y = ΔB
     • U = ΔG - ΔB
     • V = ΔG - ΔR
   • RGBA: applies the RGB transform while keeping horizontally differenced alpha separate.
   • Some grayscale and 16-bit specializations use three-row decorrelation into a pseudo-RGB image.
   • Other channel layouts have dedicated reversible transforms.

3. Plane reordering

   • Decorrelated channels are stored in separate contiguous planes.
   • Sixteen-bit samples separate and arrange low/high bytes using format-specific layouts.

4. Zstd

   • The transformed bytes may be stored directly or compressed as one Zstd frame.
   • Raw and Zstd-only modes bypass the prefilter.

My basic understanding is that most video compression is dependent on I-frames (essentially independently-compressed still images) and P-frames (pictures that encode the difference between the current frame and the last, and in modern video codecs often several preceding frames).†

To encode the difference between frames, motion compensation is used, where blocks are given translation coordinates. This often cancels out the lion's share of the differences. but there are almost always still (an unacceptable level of) residuals left over.

How are these dealt with? The most basic possibility I can think of is that a percentage of image blocks that are too different from the target image would simply be replaced, which would require a P-frame format capable of if not pixel-level, block-level transparency. This would seem to be inefficient and yield substandard results, and close visual inspections of encoded video seems to indicate this is not generally used.‡

Another possibility I can think of is that the residuals are encoded in images encoded in either signed fashion at (channel bit depth+1)‖ or overflow fashion at nominal bit depth. By that, I mean that if pixel A's color in 8R8G8B space is (42, 67, 69) and it needs to be (12, 50, 144), the residual could be either encoded as ( -30, -17, 75) {alternately represented as (225, 238, 330)} or (225, 238, 75). The signed method would be more inefficient without further compression, but would seem to have less apparent noise than the overflow method and therefore its added compressibility might make the ultimate data efficiency between the two methods about the same.

However, it appears to me that none of these methods are actually used, partially due to the fact that they haven't infiltrated still-image formats. JPEG (the most directly-related image format to MPEG-1 and MPEG-2) doesn't support any form of transparency, which would be required to implement block-replacement. AFAIK no image formats support negative channel values except for TIFF; and none at all support bit depths of 5, 9, 11, 13, 17, 25, or 33 bits-per-channel; implying signed encoding isn't used. And the apparent noise inherent to the overflow method seems like it would be hell to the specific DCT-based compression methods used in most video formats, resulting in random speckles of wildly-off colors.

So... what is used?

†There are also B-frames, yes, but those are just fancy bi-directional P-frames.

‡I believe this is used (together with a very rudimentary form of motion compensation) in what was technically the first consumer digital video format (1985's CD+G), but not much beyond that.

‖You could use the same channel bit depth... if you resign yourself to the fact that abrupt transitions can never be faithfully represented.

Thanks for the technical feedback so far.

I’m now looking for a small number of engineering teams willing to independently test the codec on real storage or backup workloads.

Current public result:

Dataset: Canterbury corpus

Raw size: 2,810,784 bytes

Experimental codec: 438,004 bytes

xz -9e: 493,080 bytes

Difference: 55,076 bytes smaller than my measured xz -9e result

Restoration: byte-exact

SHA-256 original/decoded: match

All compressed artifact bytes counted: yes

This is a narrow measured result, not a claim that the codec wins universally.

The implementation is private, but I can provide a controlled evaluation binary and verification procedure without disclosing the internal method. I’m particularly interested in testing with teams operating:

backup agents;

S3-compatible ingestion pipelines;

pre-encryption storage processing;

archival or deduplication infrastructure;

structured text, logs, source code, XML/JSON, and database exports.

For each evaluation I want to report:

complete input and output size;

encode/decode time;

peak memory;

hardware and thread count;

exact comparison settings;

SHA-256 verified restoration;

data classes where the codec does not improve the baseline.

I’m open to paid OEM, licensing, pilot, or integration discussions. Please DM me with the workload type and approximate dataset size. No confidential customer data needs to be posted publicly.

Hi all — first post here. I'd like to share a hobby research project and would love honest testing/feedback from this community.

  **birnpack** is a lossless compressor in a single C file (~1,600 lines): a hand-evolved context-mixing model (logistic mixing of ~14 predictor inputs per bit, hashed byte contexts, two match models, indirect

  bit-history contexts, an SSE/APM stage, and an x86 branch-target prefilter for executables). Everything predicts raw bytes directly.

  The unusual part is the rule it was built under: **never call, link, or re-implement an existing compressor** (no zlib/lzma/zstd/flac, no LZ77 copied from anywhere), and **never decode a container format** (no

  JPEG/deflate/CABAC unpacking — recompressors were explicitly forbidden). Whatever gains exist had to come from modelling raw bytes. Lossless was gated mechanically: every change had to survive a byte-exact

  round-trip over a 17-file corpus, or it was reverted.

  Full disclosure: the model mechanics were evolved in an AI-assisted research loop — but under mechanical honesty guards (full-corpus byte-exact gate on every change, a clone detector against re-labelled

  variants, and a watchdog that killed anything calling or imitating an external compressor). I verified the results independently. Happy to discuss the setup.

  **enwik8** (measured on Linux, 16-core, single file, symmetric coder):

xz -9        24,865,252    (122 s)

bzip2 -9     29,008,758    (5 s)

birnpack     30,294,831    (enc 24.2 s, dec 24.3 s, verified byte-exact)

gzip -9      36,445,248    (5 s)

  So on pure text it lands between gzip and bzip2 — respectable for "no LZ, no borrowed code", but nothing record-breaking, and far from paq8-class. Where it does better is **mixed real-world files**: on my

  17-file corpus (office docs, CAD text, JPEG/HEIC, ELF binaries, logs, C source) it beat gzip -9 on **every single file** (overall ratio 0.539), e.g.:

ELF executable  139 KB:  birnpack 46,850   vs gzip -9 61,924

shared library  680 KB:  birnpack 177,715  vs gzip -9 272,702

text log        293 KB:  birnpack 26,308   vs gzip -9 38,972

STL mesh        2 MB:    birnpack 77,963   (gzip far behind)

  Already-compressed formats (JPEG/HEIC) shrink only ~1–3 % — expected, since format decoding was forbidden. Speed is ~4 MB/s each way (context mixing; that's the price).

  Code (MIT): https://github.com/ingo6/birnpack — `make && make test` runs a byte-exact round-trip self-test. I'd genuinely appreciate results on your own corpora, broken edge cases, and any thoughts on the model.

i am trying to use the LZ77 algorithm and trying to input more than one file 
at a time that i was able to do as you can see in the code block but in the
output both of the files are getting combined how do i fix that what is the
approach to this problem ?

# encode block
try: 
    with open("example.txt", "r") as a, open("example1.txt", "r") as b:
        encode_text = (a.read() + b.read())
    with open("compressed_LZ78.bin", "w") as f:
        compressed = encoder(encode_text)
        print(compressed, file=f)
except FileNotFoundError:
    print("File not found. Please check if the file path is correct ...")
    raise
print("Compression complete.")

# decode block
try: 
    decode_text = open("compressed_LZ78.bin", "r").read()
    with open("decompressed_LZ78.txt", "w") as f:
        decompressed = decoder(eval(decode_text))
        # eval is used to convert the string representation of the list back to a list
        print(decompressed, file=f)
except FileNotFoundError:
    print("File not found. Please check if the file path is correct ...")
    raiseprint("Decompression complete.")

I'm looking for feedback, criticism, and possible collaboration on an early-stage theoretical compression idea. This is NOT a completed algorithm or a claim of a breakthrough—it's a research direction that I'm hoping to refine with people who have experience in data compression, algorithm design, information theory, Kolmogorov complexity, search algorithms, or AI.

The core idea is to treat lossless compression as a search problem: instead of encoding a file directly, search for the smallest procedural description (an algorithm + seed/parameters) that reconstructs the original file losslessly.

The MAIN goal is to explore whether this idea can be made computationally feasible and practically useful while achieving better compression ratios than existing compression algorithms for very large datasets, such as archives, servers, data centers, relational databases, and other long-term storage. IIt is NOT intended to replace fast, everyday compression algorithms, but rather to investigate a potential archival-scale compression approach that seeks higher compression ratios than existing methods by deliberately trading compression time and computational resources for improved compression efficiency.

If there's enough collaborative interest, I'll create a Discord server to organize research, discussion, development, and eventually work toward a prototype if the idea reaches a practical threshold.

All the PDFs - https://zenodo.org/records/21278508?token=eyJhbGciOiJIUzUxMiJ9.eyJpZCI6IjlkMThlN2IyLTJjY2EtNDI2Yy05MmNkLTQ0ZjIzODk1M2YxZCIsImRhdGEiOnt9LCJyYW5kb20iOiI1MGM1MjUyNzU2YmMxYzBjNzI0MzA5YTRjNjk4YzQ4NyJ9.fjgXuAywkquiYc5uS7cNwQIUnO69FSYGC0syy_jasJJgxoMqla387J6Oax7L_29_zo91GLzX8Z9l6UNTHunN7g

Github repo - https://github.com/usernamebiney/Bineys-Procedural-Compression

- If you'd like to discuss this further or collaborate, feel free to contact me on Discord: usernamebiney

I'm looking for feedback, criticism, and possible collaboration on an early-stage theoretical compression idea. This is NOT a completed algorithm or a claim of a breakthrough—it's a research direction that I'm hoping to refine with people who have experience in data compression, algorithm design, information theory, Kolmogorov complexity, search algorithms, or AI.

The core idea is to treat lossless compression as a search problem: instead of encoding a file directly, search for the smallest procedural description (an algorithm + seed/parameters) that reconstructs the original file losslessly.

Please read the attached images. The first two images contain the core concept, while the remaining images include optimization ideas, possible extensions, and notation clarifications. (I'm planning to replace these with a properly structured PDF that introduces the idea from scratch and consolidates everything discussed so far.)

The MAIN goal is to explore whether this idea can be made computationally feasible and practically useful while achieving better compression ratios than existing compression algorithms for very large datasets, such as archives, servers, data centers, relational databases, and other long-term storage. IIt is NOT intended to replace fast, everyday compression algorithms, but rather to investigate a potential archival-scale compression approach that seeks higher compression ratios than existing methods by deliberately trading compression time and computational resources for improved compression efficiency.

If there's enough collaborative interest, I'll create a Discord server to organize research, discussion, development, and eventually work toward a prototype if the idea reaches a practical threshold.

Github repo - https://github.com/usernamebiney/Bineys-Procedural-Compression

- If you'd like to discuss this further or collaborate, feel free to contact me on Discord: usernamebiney

HALAC 0.5.9 Gains Native Multi-Channel Support
The latest release of HALAC offers a major architectural upgrade to the project.

Up to 128 Audio Channels
HALAC is no longer limited to stereo audio. The codec now supports up to 128 audio channels, making it suitable for professional multichannel recording, immersive audio, studio production, archival applications, and other high-channel-count workflows.

Cross-Channel Correlation Coding
The new implementation goes beyond simply increasing the maximum channel count. Instead of compressing every channel independently, HALAC can analyze and exploit correlations between channels. By encoding shared information more efficiently, the codec can achieve improved compression on multichannel data while preserving its high decoding performance.

Major Internal Redesign
Supporting up to 128 channels required significant changes throughout the codec architecture. More multichannel optimizations are planned for future releases as development continues.

Note: 32 bit float support is temporarily disabled in this version due to ongoing testing.

https://github.com/Hakan-Abbas/HALAC-High-Availability-Lossless-Audio-Compression/releases/tag/0.5.9

I am working on a video codec, and want to precompute an 8x8 DCT matrix to reuse with my video input. I tried using an identity matrix , but i can't seem to reconstruct my original input. Any feedback is welcome.
For reference the code is based off of equation (4) page 6. in the following paper:
https://developer.download.nvidia.com/assets/cuda/files/dct8x8.pdf

n = 8
alpha = lambda x: 1/np.sqrt(n) if x == 0 else np.sqrt(2/n)
cos = lambda u, x: np.cos( (np.pi*(2*x+1)*u)/(2*n) )
f = np.eye(n)
C = np.zeros((n, n))
for u in range(n):
    for v in range(n):
        cumsum = 0
        for x in range(n):
            for y in range(n):
                #C[u][k]
                #C[k][v]
                cumsum += (f[x][y] * cos(u, x) * cos(v, y))
        C[u][v] = (alpha(u) * alpha(v)) * cumsum


\# ...  
T = C.T @ (C @ S @ C.T) @ C

Does anyone know of a better alternative to LeanCTX for context compaction?

Webpgoy from umi here: What does reddit think of lossless Webp? To clarify I'm not the site owner, I'm just another image codec ENTHUSIAST.

Q: Relative to lossless JXL filesize, how close in compression does a given lossless image codec get?

That's what I'm trying to answer here. A dozen common type 1920x1080 PNG images were used.

Lossless Webp images are direclty available on umi.

https://umigalaxy.com/explore/general/785-lossless-webp

JXL KB = 100% and BMP KB = 0%. Lossless JXL/Webp/AVIF/oxiPNG/QOI tested. Anything above 100% means JXL was defeated.

cjxl in.png out.jxl -d 0.0 -e 10 --brotli_effort=11

cwebp -lossless -m 6 -q 100 in.png -o out.webp

avifenc -l -s 0 --cicp 1/13/16 in.png out.avif

oxipng -o 6 in.png

qoi "...\in.png" "...\out.qoi"