SIC (Structured Image Compression) . New lossy codec

[Nania Francesco]

Hello Doom9 community,

I'm an independent researcher with a deep passion for data compression, and I've been working on a novel image codec project in my spare time. My background is in general data compression, and this project is an attempt to explore some less conventional (or perhaps, differently prioritized) approaches compared to what's often seen in standard codecs.

My primary focus has been on achieving high computational efficiency during encoding, even at the potential cost of some compression ratio compared to state-of-the-art solutions, or by leveraging unique architectural choices. I've also put significant effort into ensuring high quality reconstruction at aggressive bitrates.

I've recently completed a series of internal tests comparing my experimental codec (which I'll refer to as 'SIC' for now) against some well-established image formats like WebP and AVIF. These tests were conducted on a diverse set of high-resolution images, measuring PSNR, SSIM, MAE, and SAM, alongside encoding times.

Here's a brief summary of what I'm observing, and where I'd appreciate some discussion and insights from this knowledgeable community:

Computational Speed: My codec, running on a single CPU core, consistently achieves significantly faster encoding times. In some high-resolution image tests, it has shown to be up to 5 times faster than WebP (cwebp x64 CLI, default settings with -q 52 for comparable quality), even though WebP is a highly optimized and mature codec. For a full test set of 41 images (average resolution around 4K-8K), my codec encoded in 38.36 seconds (1 core) compared to AVIF's 73.43 seconds (on 16 cores) for similar PSNR.

Quality vs. Compression Ratio: While AVIF and WebP are renowned for their superior compression ratios, my codec is showing very competitive quality for a given bitrate. In one specific high-resolution test image (5784x8672 pixels), my codec (rawimage1.bmp) achieved a PSNR of 33.987 dB, which is actually slightly higher than WebP (outputw.bmp), which registered 33.543 dB on the same image when measured by both my internal AI-generated tool and independently verified by FFmpeg (using ffmpeg -lavfi psnr). This was achieved even though my codec was operating at what I perceive as a higher 'compression effort' (or aggressive quantization) compared to how WebP might have been configured.

Architectural Approach (High-Level): Currently, my codec relies heavily on a specialized Discrete Cosine Transform (DCT) implementation and a precise, floating-point based quantization scheme. A key aspect of its current design involves separating and independently optimizing the processing of Y, U, and V color components, rather than treating them uniformly. This decision alone yielded a 5.5 dB PSNR improvement at the same bitrate compared to a unified approach in early tests. My current implementation is quite lean, essentially consisting of only these core DCT/quantization/entropy coding stages, without many of the advanced features found in modern codecs (like sophisticated intra-prediction modes beyond basic DC/plane, inter-prediction for video, or complex loop filters).

My questions to the community are:

Are these performance and quality figures (especially the single-core speed combined with competitive PSNR) as unusual or promising as they seem to me, given the limited feature set currently implemented?

What are your thoughts on the trade-offs between computational speed and compression ratio in modern image codecs for various applications (e.g., real-time streaming, archival, web delivery)?

From your experience with codec development, which "next steps" (e.g., advanced intra-prediction, adaptive quantization matrices, refined entropy coding, loop filters) would you prioritize to build upon this foundation, while trying to maintain the encoding speed advantage?

I'm genuinely interested in hearing your perspectives and expertise. I'm excited about the potential of this project and believe that exploring alternative approaches can sometimes lead to interesting discoveries.

Thank you for your time and insights.

Best regards, Nania Francesco Antonio

[Z2697]

current implementation is quite lean, essentially consisting of only these core DCT/quantization/entropy coding stages
That sounds like JPEG 1 (1992)...

measuring PSNR, SSIM, MAE, and SAM
They are not considered ideal nowadays.
I think JPEG-XL developers usually measure Butteraugli and SSIMULACRA2, I don't know how good they are, I don't usually do lossy image compression.
But visual comparison is always a good option.

[Nania Francesco]

Since, as I imagined, you would have kindly asked me for a demo, I will show you the decoder v.0. 000 with an example of an image with raw source of which I will post the link to the download page.

https://www.amazon.com/photos/shared/eYHrtDLWSF-ShhkltEUqdA.3LLLmBjMFcoc92T2IJGNsi/gallery/n1UcpoNnTrmRopbc5jfo7A

[Z2697]

Attachments Pending Approval
Please upload your files to external file hosting service and post the link, or get them approved.

[Nania Francesco]

temporary link to download

https://limewire.com/d/DfMhZ#Vv1ZpbnrkS
https://limewire.com/d/XRl17#b8WeUjoWMa


Could you please post the SIMULACRA 2 and Butteraugli .exe files that I wasn't able to compile? In exchange, I'll post my program (imagecomp2) that uses MSE,MAE,PSNR,SSIM,and SAM to calculate a percentage match with the image.

[Z2697]

temporary link to download

https://limewire.com/?referrer=pq7i8xx7p2

This is not a sharing link...

[Nania Francesco]

try this
https://limewire.com/d/DfMhZ#Vv1ZpbnrkS
https://limewire.com/d/XRl17#b8WeUjoWMa

If I'm not mistaken my imgcomp2.exe , it supports reading for comparison.

JPEG: Supports baseline and progressive (with some limitations, such as lack of support for 12 bpc and arithmetic encoding).

PNG: Supports 1, 2, 4, and 8-bit-per-channel images.

TGA

BMP: Supports non-1bpp and non-RLE formats.

PSD (Photoshop Document): Supports composite view only (without additional channels) and supports 8/16 bits per channel.

GIF: Is read and usually reported as a 4-channel image by stb_image.

HDR (Radiance): Supports the rgbE format.

PIC (Softimage PIC)

PNM: Support for PPM and PGM (binary only)

[Jamaika]

Computational Speed: My codec, running on a single CPU core, consistently achieves significantly faster encoding times. In some high-resolution image tests, it has shown to be up to 5 times faster than WebP (cwebp x64 CLI, default settings with -q 52 for comparable quality), even though WebP is a highly optimized and mature codec. For a full test set of 41 images (average resolution around 4K-8K), my codec encoded in 38.36 seconds (1 core) compared to AVIF's 73.43 seconds (on 16 cores) for similar PSNR.

Quality vs. Compression Ratio: While AVIF and WebP are renowned for their superior compression ratios, my codec is showing very competitive quality for a given bitrate. In one specific high-resolution test image (5784x8672 pixels), my codec (rawimage1.bmp) achieved a PSNR of 33.987 dB, which is actually slightly higher than WebP (outputw.bmp), which registered 33.543 dB on the same image when measured by both my internal AI-generated tool and independently verified by FFmpeg (using ffmpeg -lavfi psnr). This was achieved even though my codec was operating at what I perceive as a higher 'compression effort' (or aggressive quantization) compared to how WebP might have been configured.
I understand that libwebp2 is also lagging behind.

[Nania Francesco]

I understand that libwebp2 is also lagging behind.


I don't understand the point of the comment. I just want to know if it's worth considering as a codec.

[Z2697]

Is it basically a JPEG (1992) with 32x32 blocks, at its current implementation state?
It does perform quite well, what features are you planning to implement next?

(I don't have Butteraugli and SSIMULACRA2 executables, I just compare with my eyes when it comes to still images, most of the time)

[Nania Francesco]

Is it basically a JPEG (1992) with 32x32 blocks, at its current implementation state?
It does perform quite well, what features are you planning to implement next?

(I don't have Butteraugli and SSIMULACRA2 executables, I just compare with my eyes when it comes to still images, most of the time)

That’s a very fair observation regarding the current architecture.

We appreciate your feedback; we’re glad you noticed it performs well despite its current simplicity.

The current implementation represents only about 20-30% of our initial development roadmap. We’ve been focused strictly on building and optimizing the core foundations, such as the specialized DCT and the adaptive quantization scheme.

Many advanced features standard in modern codecs are still missing. Our next steps will include implementing various intra and inter prediction strategies, alternative approaches to coefficient encoding, and adaptive loop filtering. We are optimistic about the future potential once these features are integrated.

Another complesto test from 1 percent to 100 percent webp not SIC
Source raw image https://shotkit.com/wp-admin/admin-ajax.php?action=useyourdrive-download&account_id=101618924177038945298&id=1FIVsy6mtHrajkGxo3hxlMXkl5kYI9Y90&dl=1&listtoken=b2d97f0e8ae191ed1e2222c9b8ae62ca
Sicd.exe is compatible for decode sic images
Full testo to download: https://limewire.com/d/PzNB1#Cbf5DEBYyK

[Z2697]

It's worth noting that WebP, specifically its lossy mode, and perhaps specifically libwebp, is not a good image encoder. (but there's no other encoder for it! :( )
The only good thing it brings, is the Alpha channel for lossy images. The alpha channel in lossy webp is lossless by default, actually. And if you choose to code it lossy, it's not using the VP8 encoding.

JPEG-XL's lossy mode isn't all that amazing as well. The advantage is its versatility, while still better than JPEG (1992) and WebP.

The "king" of todays' compression ratio is, unfortunately, HEIC or AVIF. Among the popular formats.

I can see the future where we celebrate the 40th birthday of JPEG (1992) and are still using it everyday. :(

[Nania Francesco]

It's worth noting that WebP, specifically its lossy mode, and perhaps specifically libwebp, is not a good image encoder. (but there's no other encoder for it! :( )
The only good thing it brings, is the Alpha channel for lossy images. The alpha channel in lossy webp is lossless by default, actually. And if you choose to code it lossy, it's not using the VP8 encoding.

JPEG-XL's lossy mode isn't all that amazing as well. The advantage is its versatility, while still better than JPEG (1992) and WebP.

The "king" of todays' compression ratio is, unfortunately, HEIC or AVIF. Among the popular formats.

I can see the future where we celebrate the 40th birthday of JPEG (1992) and are still using it everyday. :(

But in fact I created this program to see how a jpeg would behave with advanced data compression techniques ( I must admit that I have been an expert in data compression for years and have published many data compression programs ). Then I saw that at some point I started to distance jpeg a lot in psnr results and wondered if I could compete with the holy monsters of image compression that have dozens of developers behind them. I alone created this. :D

[Jamaika]

tune butteraugli is very old on google pages.
butteraugli image1.{png|jpg} image2.{png|jpg}
https://github.com/google/butteraugli

The latest tune butteraugli from the jpegxl codec if anyone is interested.
av1enc_avx.exe -q 100 -420 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.jpeg -d output.av1
av1enc_avx.exe -q 100 -420 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.webp -d output.av1
av1enc_avx.exe -q 100 -420 -size 280x420 -effort 7 -threads 4 -tune butteraugli input_jpeg.wp2 -d output.av1
https://forum.doom9.org/showthread.php?p=2020287#post2020287

[Nania Francesco]

1. SIC Codec (v0.00 Demo Release registered ZENODO Patent: https://zenodo.org/records/15869200)


This initial demo version of the SIC codec is exclusively focused on demonstrating the remarkable compression speed and efficiency we have achieved. It showcases our commitment to fast, optimized encoding.

A crucial note on SIC v0.00: This is an early-stage development build. We cannot guarantee backward compatibility until the stable v1.0 release.

2. ImageComparator 1.0

To facilitate objective evaluation, we are also releasing ImageComparator 1.0, the robust tool developed specifically for comparing image quality.

ImageComparator provides precise metric-based analysis, calculating:

P-SIM (Perfect SSIM): Our new perceptual dissimilarity metric, inspired by SSIMULACRA techniques.

PSNR (Peak Signal-to-Noise Ratio)

MSE (Mean Squared Error)

MAE (Mean Absolute Error)

Optimized with OpenMP, ImageComparator delivers fast and reliable comparative results.

We invite you to test the SIC v0.00 demo using ImageComparator 1.0 and share your feedback!

DOWNLOAD page: http://heartofcomp.altervista.org/SICodec.htm

[Nania Francesco]

SIC license:

CLOSED SOURCE EVALUATION LICENSE AGREEMENT This license agreement governs the use of the software provided, which includes, but is not limited to, the SIC Codec (v0.00 Demo) . This Software is proprietary and closed source. 1. LIMITED LICENSE GRANT The Software is provided "as is" and is licensed solely for the purpose of personal, non-commercial evaluation and testing (the "Evaluation Purpose"). This license grants the user a non-exclusive, non-transferable right to use the Software only for the Evaluation Purpose. 2. RESTRICTIONS ON USE You are explicitly prohibited from: Commercial Use: Using the Software for any commercial purpose, including, but not limited to, use in a for-profit environment, integration into commercial products, or any revenue-generating activity, without prior written authorization from the Author. Distribution: Distributing, sublicensing, selling, leasing, or transferring the Software or any part of it to any third party. Modification and Reverse Engineering: Modifying, adapting, translating, reverse engineering, decompiling, or disassembling the Software, or attempting to derive the source code of the Software. 3. COMMERCIAL AUTHORIZATION Any commercial use of the Software requires a specific written request and authorization from the Author. Requests for commercial licenses must be submitted in writing to the Author. Unauthorized commercial use constitutes a breach of this agreement and is strictly prohibited. 4. NO WARRANTIES AND DISCLAIMER The Software is provided "AS IS," without warranty of any kind, express or implied. The Author shall not be liable for any damages arising from the use of the Software.
Attached Files Attached Files


The current version of the SIC codec is designated as v0.00.

We chose this version number to indicate that this is the very first public release, intended purely as a functional demonstration of the codec’s capabilities. Development hasn’t yet progressed to a stage that warrants a v0.01 designation.

Important Note on Compatibility and Data Safety:

At this stage, the codec may not function correctly with image formats whose dimensions (width or height) are not multiples of 8x8. We are working to ensure full compatibility in future releases.

Due to the pre-release nature of this demo, we strongly advise against using SIC for converting your personal or important images until the stable v1.0 releas

[Z2697]

But in fact I created this program to see how a jpeg would behave with advanced data compression techniques ( I must admit that I have been an expert in data compression for years and have published many data compression programs ). Then I saw that at some point I started to distance jpeg a lot in psnr results and wondered if I could compete with the holy monsters of image compression that have dozens of developers behind them. I alone created this. :D

I mean, comparing to WebP isn't that good of a competition. Lossy JPEG-XL might be a better target. (That is, unless you want to challenge the "Kings")

Here are some thoughts after I tried it a few times:

The priority should be bette partitioning decision, and adaptive quantization.
Using smaller blocks in edges and lines reduces the ugly dct qantization artifact, adaptive quantization improves the flat areas' quality.
(Which are the same problems the "vanilla" JPEG encoder has.)

Also, the current quantization control is hard to use.

Intra prediction is a (mildly) nice thing, but it also means each block will depend on the blocks to its top and left, as in the AVC and HEVC (and so on). This will impact the potential multithreading performance, and the ability to decode a singular block.

[Nania Francesco]

News about the next version

I got to work, improved the compression by a few percent, and that in itself is interesting in my opinion. The strongest point is that I have redefined the core choice of blocks which are now not limited to the archaic quadtree and can be freely dislocated , for now in an initial mirror of 32x32. I have removed for now the 4x4 blocks (not from the code but from the copression) which do not seem to give me great gains (I will evaluate in the future). In an image of an artic landscape, with a lake and a part of green tundra I had great difficulty with compressions. I started with 33 db of psnr, then realized that changing the paramenters went up the db of psnr, the 46.5 db of avif seemed unattainable. With this core I got 47.15 db , surpassing avif despite having far fewer arrows in my bow. The incredible thing is that webp version 1 gets with -m6 option 36.2 db and hear hear webp2 experimental gets 39.26 db , with an incredible gap , the same happens in other images. In general SIC is on average worse than AVIF by 0.5 -1.5 db but sometimes it exceeds it. Let's not forget that modern codecs use some sort of filter that cleans up the image of the annoying squares without losing much in db and in fact perhaps gaining something.

[Nania Francesco]

Hi everyone,

I'm thrilled to share a significant update on my SIC codec! I've been working hard and have successfully implemented major improvements, making it even more powerful and efficient.

Key New Features
The main new additions in this version include:

Alpha Channel (Transparency) Support!
The SIC codec can now handle and compress images containing an alpha channel (transparency). This means you can work with images that have semi-transparent or fully transparent areas without losing any information. Say goodbye to unwanted black or white backgrounds! Transparency is managed efficiently to maintain visual quality.

32-bit Image Support (ARGB/BGRA)
In addition to the alpha channel, the codec now fully supports 32-bit per pixel images. This includes both formats with an active alpha channel (like ARGB/BGRA) and those that use 32 bits for other purposes (e.g., data alignment or as a padding channel). The codec is now more robust in handling these data structures.

What This Means for You!
These enhancements open up new possibilities and offer greater flexibility:

Superior Visual Quality: You can now compress images with complex transparency, such as logos, UI elements, and game graphics, while maintaining their visual integrity.

Extended Compatibility: The 32-bit handling improves compatibility with a wider range of image sources and destinations.

[Nania Francesco]

Get Ready for a Quality Leap! Announcing the next SIC Version

We're thrilled to share incredible progress in our image decoding and comparison technology! Since our initial demo, we've worked tirelessly to bring quality and performance to the next level.

Remember our first demo version? It laid the groundwork, but today we're here to show you just how far we've come. We've conducted rigorous tests on an extended set of 44 images, and the results speak for themselves!

A Comparison That Speaks Volumes: Old Demo vs. next Version
Let's look at the numbers that demonstrate our commitment to excellence:
Test 44 Images:
Metric Old Demo New Version Improvement Note
MSE (Mean Squared Error)______________ 26.83 -- 20.21 Improved (significantly reduced error)
MAE (Mean Absolute Error)______________ 3.3989 -- 3.0422 Improved (lower average absolute error)
PSNR (Peak Signal-to-Noise Ratio)________ 34.5085 dB -- 36.2166 dB Improved (superior image quality, well above 30 dB)
SSIM (Structural Similarity Index Measure)__0.9388 -- 0.9501 Improved (even closer to 1, excellent structure preservation)
SAM (Spectral Angle Mapper)_____________0.0354 rad -- 0.0302 rad Improved (less spectral difference, higher color fidelity)
P-SSIM (Perceptual SSIM - Dissimilarity)____2.31 -- 1.67 Improved (perceived less dissimilarity, more pleasing to the human eye)
Overall Weighted Score (out of 100)_______92.93% -- 94.26% Improved (higher overall score for exceptional quality)


As you can see, version has outperformed the previous one in every single metric! This isn't just a small step, but a true leap forward in image fidelity and accuracy.

What's New Under the Hood? Work Window Revolution and Artifact Reduction!
Beyond the impressive numbers, we've implemented key architectural improvements:

Flexible Work Window (Macroblock): In the previous version, we were locked into a fixed 32x32 pixel macroblock with our quadtree technology. Now, we've unlocked this limitation! Version introduces the freedom to change the work window, with a maximum extension up to 512x512 pixels. This means greater adaptability and control to optimize decoding based on specific image needs.

Improved Compression with Artifacts!: We've refined our compression algorithms and block selection logic. This translates to a drastic reduction in artifacts that might have been present in the previous version. The result? Cleaner images, sharper details, and a significantly superior visual experience.

We're incredibly proud of the progress made with version . Alpha Channel (Transparency) Support! We'll continue to push the boundaries to bring you the best in image processing technology

[Nania Francesco]

SIC Version 0.086 x64 Now Available!

Important Advisories: Development Status
Please Note: SIC is currently in an experimental and active development phase. As such:

Backward compatibility is not guaranteed prior to the official 1.0 release. File formats and API interfaces may change.

We do not recommend using SIC for encoding images of critical personal or professional interest where long-term preservation or universal compatibility is required. This codec is primarily intended for research, testing, and specific applications where its unique strengths are beneficial and the aforementioned limitations are understood.

For the time being, I had to disable the macroblock module, which works in a fixed mode at 64x64 blocks. I completely changed the core which is more stable and faster . At least so far I have not encountered any problems. I have implemented all possible aspects. I have not yet introduced alternative methods such as intra coding and prediction coding. I have tried various deblocking filters but they did not satisfy on some images and therefore it is not included in this version.

DOWNLOAD page: http://heartofcomp.altervista.org/SICodec.htm

[Nania Francesco]

Compared with the previous initial version, I added full support for 32-bit images (ARGB/BGRA) thus including Alpha channel images characterized by transparencies. This new version is visually structured differently from the previous one in that it is aimed at better image stability in every possible context. I used as mentioned above a fixed primary set of 44 variegated images to essay the improvements of the various experimental versions. Both compressine and decompression speed increased. The version under test is compiled with GCC 10.3.0 (the old one used version 5.1.3). I am waiting to assay your impressions.

[Z2697]

SIC Version 0.086 x264

What's x264 doing here?

[Nania Francesco]

Sorry it has nothing to do with x264. in my haste I put an extra number I meant that it is the 64-bit exe version

[Nania Francesco]

In this comparative test, we evaluated the performance of the AVIF 1.3.0 codec (quality 44, YUV444) against multiple versions of our in-house SIC image codec. The benchmark was conducted over 27 diverse test images, including natural scenes, portraits, and artificial patterns, with metrics calculated on a per-image basis and averaged.

Bitrate Comparison
AVIF 1.3.0 (q=44, y444): 12,045,991 bytes

SIC Version I (experimental): 11,873,337 bytes
→ Bitrate reduction: ~1.43% in favor of SIC I

Version A= actual version 0.086
Despite using slightly less space than AVIF, the SIC codec maintains competitive, and in some cases superior, image quality depending on the metric considered.

Conclusions
The SIC codec demonstrates a very strong balance between compression efficiency and visual fidelity, even slightly outperforming AVIF in file size while staying within ~1% of the perceived quality based on the weighted score. The differences in visual quality metrics such as SSIM and PSNR are minimal and not easily noticeable to the naked eye.

The experimental Version I of SIC, using a range-coded entropy backend and optimized DCT block handling, proves especially efficient and visually robust. These results are promising for applications requiring fast decoding, moderate resource usage, and compact file sizes.

Future work will focus on improving decoding speed and further reducing perceptual dissimilarity, with a particular emphasis on UIQ and SAM minimization.

[Nania Francesco]

Thanks to your help and the right and thoughtful, very constructive criticism, I managed to significantly improve compression without intervening on the graphics engine by choosing the right NxN block for each macroblock. This test evaluates 27 images, comparing the AVIF 1.3.0 codec (quality 44, YUV 4:4:4) with several experimental versions of the SIC codec and standard JPEG. All values shown are averages across the image set.
Key Observations:
AVIF shows the best performance in almost every metric, including lowest MSE (12.564) and highest SSIM (0.9419), confirming its modern, high-efficiency design.

SIC Version K (with full macroblock complexity) comes close, with only slightly worse quality than AVIF, while consuming slightly less bitrate.

The latest SIC versions (K and J) consistently improve over the early SIC 0.086 version, showing a steady refinement in both perceptual and numerical metrics.

Compared to JPEG, all SIC versions perform significantly better in PSNR, SSIM, SAM, and P-SSIM, while using similar or lower bitrate.

Notably, P-SSIM, which focuses on perceived dissimilarity, highlights a strong perceptual advantage of AVIF and SIC over JPEG: AVIF (1.346) vs JPEG (3.23)


| Metric | AVIF 1.3.0 (q44, y444) | SIC Version K | SIC Version J | SIC Version I | SIC Version G | SIC Version 0.086 | JPEG |
|----------------------|------------------------|----------------|----------------|----------------|----------------|---------------------|--------------|
| Bitrate (Bytes) | 12,045,991 | 11,937,354 | 11,886,094 | 11,873,337 | 11,693,000 | 11,906,804 | - |
| MSE | 12.564 | 18.232 | 18.270 | 18.730 | 19.066 | 19.336 | 31.066 |
| MAE | 2.308 | 2.826 | 2.844 | 2.855 | 2.879 | 2.910 | 3.901 |
| PSNR (dB) | 37.284 | 36.791 | 36.776 | 36.657 | 36.568 | 36.440 | 33.208 |
| SSIM | 0.9419 | 0.9304 | 0.9298 | 0.9264 | 0.9247 | 0.9238 | 0.8878 |
| SAM (rad) | 0.0296 | 0.0335 | 0.0336 | 0.0339 | 0.0343 | 0.0354 | 0.0528 |
| P-SSIM | 1.346 | 2.001 | 2.016 | 2.053 | 2.086 | 2.149 | 3.238 |
| Weighted Score (%) | 94.63 | 93.7074 | 93.63 | 93.39 | 93.28 | 93.07 | 90.72 |

[Nania Francesco]

I've reached the experimental version 0.0104, which is unified in terms of optimizations and compatibility between AMD and Intel CPUs. Performance has improved significantly. I've changed the data compression core by implementing it again. I've changed the code that managed the blocks, making it stable and compatible in compilation. I've added a deblocking filter that I think is quite qualifying for the final rendering. The data is very comforting with an average on a set of 40 images of various types and resolutions (including comic and manga images that require particular attention). Comparing AVIF 1.3.0 with a setting of -q 44 - y 444 at the same bitrate, AVIF gets an average PSNR of 39,376 against SIC which gets 37,225. The other parameters have improved. SIC on a single CPU is 6 times faster in compression than AVIF and 10 times faster than Webp2 (which I think is in multi-threading).

[Nania Francesco]

Release announcement.

I've released SIC version 0.0104, which I mentioned earlier, and I think it's a significant improvement. Try it out and let me know.

DOWNLOAD page:

http://heartofcomp.altervista.org/SICodec.htm

[VoodooFX]

Welcome to Doom9, Francesco. I remember you from a data compression community.
BTW, your English has improved a lot. ;)

[Nania Francesco]

Welcome to Doom9, Francesco. I remember you from a data compression community.
BTW, your English has improved a lot.
__________________
Thanks for the welcome, I remember you too.

I've continued researching and implementing the code. Currently, I've further modified the compression core, resulting in improved bitrate savings. I've changed the deblocking filter, which has become more efficient, at least for me, significantly improving the overall metrics. I've modified the image comparator (not included in SIC) by inserting part of the SSIMULACRA2 code to get a more precise picture. Currently, I've given a weight of 50% to SSIMULACRA2, 20% to SSIMULACRA, 10% to PSNR, 6% to SSIM, and 4% to SAM (color accuracy). SIC is equivalent to AVIF compression -q 50 -y 444. I'm thinking about putting the code on GitHub and avoiding the mistakes of the past for proper development. I forgot that I also changed the handling of DCT blocks and their selection. At the expense of a worse PSNR and MAE, the filter produces an image more similar to the source.

https://encode.su/attachment.php?attachmentid=12518&d=1755168753 (SIC v.104 )
https://encode.su/attachment.php?attachmentid=12514&d=1755168638 (JPEG)
https://encode.su/attachment.php?attachmentid=12516&d=1755168655 (Webp)
https://encode.su/attachment.php?attachmentid=12517&d=1755168662 (AVIF)
https://encode.su/attachment.php?attachmentid=12515&d=1755168648 (next SIC version)

Any advice?

[Nania Francesco]

Obviously mine was a port of SSIMULACRA2 that I had to adapt. However, more or less the results of the official SSIMULACRA2 follow, with some small differences, the results of my image comparator. Here are the results logs. (The test was done on 40 image files of various types and resolutions)

1) JXL turns out to have a weighted average : 65.8556781 (The king)

2) AVIF turns out to have a weighted average : 62.9328596

3) SIC turns out to have a weighted average : 60.8457124 (next version)

4) SIC turns out to have a weighted average : 58.30881121 (v. 104 Latest official release)

5) Webp turns out to have a weighted average : 53.34261722

5) JPEG turns out to have a weighted average : 37.8871165


Of course, to address any criticisms regarding the test, I clarify that the sum of the bytes of the compressed files is the same, so it could be that an AVIF file consumes twice as much as a SIC file for the same image, or vice versa. It would perhaps be better to consider JXL as a base and compress every file close to it in terms of bytes and compare. But it's too difficult a test.

[Nania Francesco]

Let me clarify. My test uses 40 PNG format images (mostly from raw sources I found online) with varying resolutions. Comic book and manga images are included due to the type of quality and color preservation they require. The parameter is considered AVIF with a quality setting of 50% with yuv set to 444. JPEGXL even reaches a quality setting of 59%. JPEG is set to 25% (I used image magick). WEBP uses the quality setting of 44.5. SIC uses a setting of 97.1 thousandths but has a different quantizer than the others, at least I think. The limit to be respected is approximately 20,000,000 bytes , that is 1% of what they consume in BMP format (Ratio 1:100).

[benwaggoner]

Obviously mine was a port of SSIMULACRA2 that I had to adapt.
Has there been any published research on using SSIMULACRA2 as a video metric? AFAIK it has only been calibrated and tested based on still images, which is a quite different use case.

[Nania Francesco]

Has there been any published research on using SSIMULACRA2 as a video metric? AFAIK it has only been calibrated and tested based on still images, which is a quite different use case.

Regarding your question, which refers to my comment in another post regarding UVG266 (and VVC), obviously SSIMULACRA2 is a metric mainly used to check the quality of static images, I did a test using VVC, UVG266 and ffmpeg to check the compression on a single image (I had to adapt all the images to be at least all multiples in height and width of 8) and I was amazed by the quality of VVC on the key image (first image) which is remarkably high.


Regarding the progress of SIC, I have incredibly managed to improve the compression core beyond all expectations as well as the overall compression with better block management. I have introduced the possibility to choose the subsample in YUV420 and also to choose the activation of the deblocking filters during decompression (one for YUV444 and one for YUV420). As of now, the new version, in my opinion, can compete in terms of quality and efficiency with AVIF.

Despite not having any intra prediction handling in the code! Only DCT compression !

[Nania Francesco]

SIC Codec v0.155 Released!
We're thrilled to announce the release of SIC Codec v0.155, packed with major updates and new features designed to enhance your video compression experience. This version marks a significant step forward in performance and flexibility.

Key Improvements and New Features:
Improved Compression and Block Management: We've fine-tuned our core algorithms to deliver even better compression efficiency, resulting in smaller file sizes without compromising quality. The new block management system is more intelligent and adaptable, handling complex scenes with greater precision.

YUV420 Subsampling Support: This new option allows you to achieve significantly higher compression ratios, making it ideal for web and mobile video applications where file size is critical.

Extended YUV Format Support: With v0.155, you can now choose from five different YUV formats, giving you unprecedented control over color space and data handling.

Advanced Deblocking Filter: A new deblocking filter has been added for a cleaner, smoother viewing experience. The filter is automatically enabled during image decompression, effectively reducing compression artifacts and improving visual fidelity.

Toggle Deblocking: For users who prefer a different level of control, the deblocking filter can be turned on or off during the decompression process, allowing for greater customization.

We are confident that these updates will provide you with a more powerful and versatile tool for your compression needs. Download the latest version today and experience the difference!

We value your feedback and look forward to hearing about your experience with v0.155.


DOWNLOAD page:

http://heartofcomp.altervista.org/SICodec.htm

[Z2697]

I noticed a small color shift produced by:

sic c in.png out.sic
sic d out.sic out.sic.bmp

using "SIC.exe" from sic0155.zip

Is there a color matrix "mismatch" problem?
BTW, what's the difference between "SIC.exe" and "SIC_generic.exe"?

[Z2697]

can compete in terms of quality and efficiency with AVIF.


I think the "DCT ringing" is quite visible in SIC, the deblocking filter can help but it also blurs image too much, I guess because it's not in-loop?
(You should test more "clean" images, the noise hides it.)

Despite not having any intra prediction handling in the code! Only DCT compression !

Intra prediction in x265 can reduce file size by around 50% in "more predictable" images, which are, "clean" images, usually.
So maybe the expectation is like 25% for a mixture of "easy" and "hard" images.
It can also reduce "DCT ringing" by uh... "pushing less data through DCT"... that's how I think it works.

(I tested this by modifying the x265 source code to make it only use "DC prediction", so not completely intra-prediction-less so to speak)

Quite some significant advantages actually!
But in a previous reply I said it's "mildly nice", is because: every block is gonna depend on the pixels to its left and/or top...

[Nania Francesco]

Image Compression Codec Comparison (SSIMULACRA2 Metric)

I recently ran a comparison between four modern image codecs — WebP, JPEG XL, AVIF, and SIC v0.155 (without deblocking) — using the SSIMULACRA2 quality metric (higher is better). The dataset included a diverse set of images, from natural scenes like desert and snow to artificial textures like castle and labyrinth.

Average Results Across All 23 Images

JPEG XL: 55.72

AVIF: 53.06

SIC v0.155: 52.81

WebP: 43.14

JPEG XL clearly comes out on top with the highest overall quality, followed by AVIF and SIC, while WebP lags behind significantly.


Key Takeaways

JPEG XL is the best performer overall, delivering the highest average quality and consistently strong results, although it can fail badly on specific images.

AVIF is a strong runner-up, slightly behind JPEG XL on average but more robust on some difficult cases (e.g., pioggia).

SIC v0.155 (without deblocking) performs surprisingly close to AVIF, showing promise as a competitive codec.

WebP remains the weakest of the group, with noticeably lower quality scores.

In summary: if average quality is the main goal, JPEG XL wins clearly. But for robustness across different types of images, AVIF sometimes shows better stability.

[Z2697]

SSIMULACRA2 is created by Cloudinary, the half one behind JPEG-XL (another half is Google, who created Butteraugli), so no wonder it will prefer JPEG-XL, either unintentionally or intentionally (I don't think the latter is the case).

In reality AV1 or HEVC based HEIF have noticeable better lossy quality. But again JPEG-XL wins on versatility. Lossless, bitdepth, floating point, JPEG-1 reconstruction, resolution... you name it.
(To be clear AV1 and HEVC can do lossless as well, but the compression ratio won't be good, assuming RGB input)

[Nania Francesco]

Surely what you say may have some real foundations regarding SSIMULACRA2, it is still a human creation and is influenced by it. Obviously there are other metrics such as VMAF, PSNR, MSE, MAE, SSIM etc. Whether it was then created around JPEGXL I can't tell you for sure but I actually found it as an attachment of libjxl with SSIMULACRA version 1 and butteraugli.exe which doesn't seem very reliable to me. The point is that a 400x800 p image is not the same thing as a 4000x8000 p image. If I encode a small image with jpeg perhaps it would make sense to use it, but honestly with a medium-high definition image JPEGXL, AVIF and I would also use SIC (latest version) the performance is very different especially at low bitrate. In my tests I have to lower the jpeg bitrate below 20% to compete with 50% of the other codecs.

I'm currently just building the SIC codec, which has the strengths of brutal and efficient coefficient compression, efficient quantization, and a few tricks. I don't know how much benefit there would be if I applied my compression techniques to other codecs.

[CruNcher]

that sounds the way to go bring yourself into another dct based compression sheme and its encoder improvement :)

either go the route of improving AV1 or maybe try how much you can improve out of x264 or maybe even H.263 era like XVID

after you have some reliable improvements if your idea is to survive from your work Patent it immediately.

i mean you should be abble to bring improvements into exisiting code bases

[Nania Francesco]

I've continued to build the compression engine, including quantization and other filtering. Here's a test of the development version (without interframe prediction).
This bar chart compares the average SSIMULACRA2 scores—a perceptual image quality metric—across four codecs, all tested at the same bitrate:

JPEG XL (50% quality) achieves the highest average score (56.6, demonstrating the best overall visual fidelity among the tested formats.

SIC codec (23% quality) follows closely at 53.02, outperforming AVIF (43% quality), which scores 51.75. This is notable because SIC maintains competitive quality at a significantly lower quality setting.

JPEG, the traditional format, lags far behind with an average score of 26.97, showing substantial perceptual quality loss compared to modern codecs.

Key Insight:
Modern codecs like JPEG XL, AVIF, and the SIC codec deliver roughly double the perceptual quality of legacy JPEG at the same bitrate, with JPEG XL taking the lead
https://encode.su/attachment.php?attachmentid=12637&d=1757803503
https://encode.su/attachment.php?attachmentid=12638&d=1757803519

[Z2697]

Please, include more "perceptual" steps and results in the research process.
x265/aomenc/SVT-AV1 used on still images are really strong, with AV1 tend to "prefer" low bitrates just like it with videos.
AVIF is the one has highest compression ratio amongst the tested codecs, although not by far when compared to JPEG-XL (unless a very very bad AV1 encoder is used as its "core"), the metric fails to show that, then it's not a good metric for this purpose.

[Nania Francesco]

I wanted to make an announcement. The next version of SIC will include a new transform for which I hold the intellectual property and which has obviously never been used in image compression. I need to restructure a large part of the code. I don't know if I'll continue using the DCT, which doesn't give me the same results, especially at high quantizations (which doesn't mean it's inefficient). The results are such that there is nothing left to do but change course.
I will not use DCHT but a different proprietary transform of mine that is superior to it which allows me to compete very often with AVIF and JPEGXL without filters, inter frame prediction, or special denoise.

[Nania Francesco]

I've released the new version of SIC 0.200, which breaks away from the DCT dependency and switches to my proprietary OGBT transform , the research for which I published on zenodo. Happy testing!

DOWNLOAD page:

http://heartofcomp.altervista.org/SICodec.htm

[Nania Francesco]

I've released version 0.201, which provides access to multithreading (https://zenodo.org/records/18429911) doubling (or even more for large files) the compression and decompression speed.


DOWNLOAD page:

http://heartofcomp.altervista.org/SICodec.htm