OpenPGP key: C8B4098974629448
Fingerprint: 2138 982C 8E27 ED36 CE60 36E3 C8B4 0989 7462 9448
This is the bonus and final article of a series about ADC and the broader pattern around it. The previous articles are here, here, here, and here.
The first four articles were about ADC, an audio codec. This one is about SIC, an image codec by the same author.
After reading the public material on SIC, especially the encode.su thread and the codec's homepage, I kept seeing the exact same pattern I had already seen with ADC:
The SIC homepage opens with the usual kind of language:
If you have read the earlier ADC articles, your brain probably already knows just how true these claims are. It is the same style of presentation:
The homepage also says SIC uses a "highly optimized OGBT Transform", dynamically applies 16x16 blocks, and achieves its "paramount strength" through aggressive range coding of those coefficients. But there is no public source code, no public codec specification, no detailed benchmark methodology on the page, and no reproducible corpus attached to those claims. So right away, the situation is familiar: the marketing is much more detailed than the proof.
One of the biggest problems when trying to evaluate SIC is that "what SIC is" keeps moving.
Here is the rough public timeline from the encode.su thread:
There is nothing wrong with experimentation, of course. Experimental codecs are supposed to change. But once the architecture, transform, block logic, filters, and evaluation method are all moving targets, any big claim about "SIC beats X" becomes much harder to take seriously unless the evidence is extremely clear and version-specific. And that is exactly where the public record gets weak.
As far as public material goes, the encode.su thread is basically the only real discussion with outside testing in it. And what does that thread show? It shows a codec that, for a long time, was very difficult to evaluate properly:
The license alone tells a story. SIC was released under a "closed source evaluation license agreement" for non-commercial evaluation only. Again: nothing inherently wrong with closed source. But if you want the world to believe you have a codec that can seriously challenge JPEG, WebP, AVIF, or JPEG XL, then "trust my binary" is not a very convincing research methodology.
There is also a reproducibility problem. The thread repeatedly refers to private benchmark sets:
Sometimes the comparison target is "same file size". Sometimes it is total bytes across a whole set. Sometimes it is whatever GIMP happened to produce for AVIF at a chosen setting. Sometimes it is a custom weighted score. Sometimes it is PSNR. Sometimes it is SSIMULACRA2. The ground keeps shifting. That makes the headline claims much less solid than they first sound.
There is another pattern in the thread that I do not think should be ignored: the author repeatedly says criticism and feedback are welcome, but then reacts poorly when people actually test the codec and report unfavorable results. It matters because public testing is basically the only thing giving SIC any outside credibility, at all. If your codec is closed-source, unstable, hard to reproduce, and supported mostly by your own screenshots and your own metrics, then the people who take the time to run comparisons are doing you a favor. And yet the thread repeatedly shows a defensive, dismissive, and sometimes openly condescending attitude toward those testers.
When Sebastian said SIC looked worse than JPEG in some examples, the response was not "which regions are you seeing that in?" or "can you share the crops?" It was:
Sebastian I thought you had more objective evaluation skills. Think about developing your own audio compression program.
Audio compression program, huh. The one that... never mind.
And later, after outside scrutiny around the author's other codec work had intensified (e.g., me releasing spectrogram evaluations of their ADC codec in Reddit, and describing the file structure and possible internal audio pipeline), the thread veered into something even worse:
The next version of SIC, which has been ready for release for some time, is being delayed precisely because I've noticed this behavior from a few rare birds who like to copy others' work. I'm sorry, but with the new obfuscation methods, I'll soon release the new version.
LOL I didn't copy anything. Why would I even copy an inferior codec. This is an attempt to turn public criticism into suspicion of theft. And given the surrounding context, it reads much more like resentment toward scrutiny than any evidence-based concern about copying. Reviewing a codec, posting test results, or analyzing public behavior is not "copying others' work." If anything, responding to criticism by promising more obfuscation only makes the whole project look less credible.
And when criticism kept landing in the same place visually, the author drifted into framing disagreement itself as the problem:
The most constructive people in the thread were often the exact people being brushed off:
In other words, the people doing the work that the project's own presentation was not doing.
This matters because it is the same social pattern as ADC. The project invites criticism in theory, but in practice, criticism is welcome only as long as it confirms the author's preferred narrative. Once the tests stop flattering the codec, the tester is suddenly disregarded as biased, unqualified, nostalgic, or not "objective" enough.
SIC's public evaluation story does not just rely on metrics. It relies on changing metrics, homemade metrics, and weighted mashups of metrics.
At various points in the thread, the author presented:
The thread includes all of the following behaviors:
Metrics are useful. I use them too. But if the metric stack itself is moving, partially homemade, and repeatedly reweighted, then you do not get to use the result as a trump card against what people can plainly see in actual image comparisons.
This tension became explicit in the thread. Multiple users kept saying some variation of:
And the response was often some version of:
At one point, the author even wrote:
Your opinion is worth nothing to me, just as mine is worthless. Therefore, we need an impartial judge, which the eyes are not.
Wow. That is a pretty remarkable thing to say about image coding, where the whole point is how the image looks to a human being.
If we strip away the self-authored summaries and look at what the outside testers in the thread kept reporting, a much more grounded picture appears.
| Tester | Repeated public observation |
|---|---|
| Hakan Abbas | SIC frequently introduced roughness, quantization noise, and visible block artifacts, especially in regions that should have stayed smooth. |
| Sebastian | SIC often looked worse than JPEG on posted samples, with more ringing and artifact blocks; later versions looked roughly JPEG-class at best, while AVIF stayed on another level. |
| RoomWithAView | SIC looked like a variable-block DCT codec, basically a "scalable JPEG-1", still young and obviously dominated by DCT-style artifacts and immature block decisions. |
| nika | Early releases were hard or impossible to test, and later visual comparisons did not show any absolute superiority over JPEG; speed and practicality still favored JPEG heavily. |
| awm | Posted one favorable PSNR result on one giant image after the OGBT switch, but even there noted that SIC targets a very low bitrate and the blocks are glaring. |
That summary is, in my opinion, much more honest than the triumphal metric posts.
To make that concrete, here are three matched-size center crops I grabbed from Unsplash, randomly, all encoded using the latest publicly available version of SIC "201mlt". Each one is a 712x534 crop taken from the exact center of the image, exported as lossless WebP for the article. The AVIF images were encoded to the same target file size as the corresponding SIC files.
Notice the recurring visual complaints: block edges, ringing, and textures getting flattened.
To be fair, the thread is not uniformly negative. There are encouraging moments:
That matters, and I want to be fair about it. But one good result on one image, or even a handful of decent-looking images, is not enough to support claims like:
Especially not when the rest of the public thread keeps concluding that "this is still around JPEG territory visually."
Now let's talk about the thing that SIC eventually made into its new identity: OGBT.
The name expands to "Orthogonalized Adaptive Gabor Basis for Energy Compaction in Two-Dimensional Block Transforms". That sounds very grand. And to be fair, the Zenodo paper does at least try to present a mathematical basis. But if you read it closely, the public note is much less mysterious and much less revolutionary than the name suggests.
What the note actually describes is:
That last point is especially funny, because "perfect reconstruction if you don't quantize away information" is not some magical selling point unique to OGBT. It is just what you would expect from an orthonormal transform. The public paper does not prove that OGBT is a breakthrough. It proves that the author can describe what an orthogonal block transform is.
Even more importantly, the transform itself is only one part of a lossy image codec. A codec also lives or dies by quantization, block decision logic, color handling (such as HDR), filtering, entropy coding, among many other things. And on all of those surrounding pieces, the public evidence for SIC remained sparse, unstable, and version-dependent.
So the "secretive" part is not really that OGBT is unknowable. The transform note is there. The secretive part is that the actual codec around it is still opaque enough that nobody can verify how much of the claimed performance comes from the transform, how much comes from tuning, and how much comes from favorable test conditions.
By this point, the resemblance to ADC is hard to miss. The pattern looks like this:
That is almost exactly the structure we saw with ADC. And just like with ADC, the most frustrating part is that there is a respectable version of this story. If only the author said,
I am building an experimental closed-source image codec. It is still unstable. The architecture is evolving quickly. Some early results are promising. The public tests so far suggest it is somewhere around JPEG to maybe WebP territory on many images, with some interesting strengths and some obvious weaknesses. I am experimenting with different transforms, filters, and block decisions to see what works.
That would be totally fine. Actually, that would be interesting. But that is not the version that kept being presented. Instead, the framing kept drifting toward:
And the public record simply does not support that.
This is the bonus and final article of a series focused on ADC and the broader pattern of overclaiming around it.
<- you are hereSIC is not the main subject of this series, but it makes for a very revealing epilogue, because once you look at it, you realize ADC was not a one-off case of awkward marketing from this author. It shows their broader habit: take an experimental codec idea, surround it with inflated language, compare it upward as early as possible, and treat incomplete evidence as if it already proved a revolution.
That is why I wanted this bonus article to exist.
Sure! Build weird codecs. Please do. Building things is fun! But if you want to challenge established formats, the claims have to wait for the evidence, not outrun it. And in the case of SIC, just like in the case of ADC, the evidence still has a lot of catching up to do.