I made my own image format from scratch in 16 years old, and that's why it's better than png

I'm 16, and I spent the last few months doing something most people would call insane: building a new image format from scratch. Why? Because modern web graphics are a mess of trade-offs. You either get performance, or you get advanced features, or you get security. You almost never get all three.

My project, PIX, is my attempt to fix this. It's not just another codec. It's a declarative web container designed with a few non-negotiable principles in mind.

This isn't just a story about a kid coding. It's a technical deep-dive into why the future of web content needs to be built on better foundations.

The Problem: Why Another Format?

PNG is great, but it's static. SVG is declarative, but can be slow. AVIF compresses well, but offers no interactivity or advanced features. And most importantly, none of them were fundamentally designed to be secure containers for potentially executable content.

PIX is designed to solve this by being:

Procedural: It stores a recipe to generate an image, not just pixels.

Secure: It's built on a "zero trust" model with mandatory cryptographic verification.

Performant: It has a C++ core compiled to WebAssembly for near-native speed.

The Architecture: C++, Not Prayers

I chose C++ for a reason. When you're dealing with binary formats and performance-critical parsing, you need control. The core of PIX is a C++20 implementation that's obsessed with security and efficiency.

Here's the high-level loading process, which is designed to be attack-resistant:

The most critical step is Verify Signature.

Security Model: Cryptography, Not CRC32

This is where most hobby projects fail. They use CRC32 for "integrity." But CRC32 only protects against accidental corruption. It offers zero protection against a malicious attacker who can simply recalculate the checksum after modifying the file.

PIX enforces real security. Every file contains a mandatory SIGN chunk with a cryptographic signature (the provider is pluggable, e.g., ECDSA).

The signature of the entire compressed data block is verified before a single byte is decompressed or parsed.

Generated cpp
//

This is conceptual, but captures the essence of the SceneReader
void SceneReader::initialize(stream) {
    // 1. Read footer to find offsets
    auto footer = read_footer(stream);

    // 2. Read the compressed data block and the signature
    auto compressed_data = read_block(stream, footer.data_offset);
    auto signature_data = read_block(stream, footer.signature_offset);

    // 3. VERIFY. The most important step.
    // If this fails, we stop immediately.
    if (!crypto_provider->verify(compressed_data, signature_data)) {
        throw SecurityViolationError("FILE TAMPERED! Signature verification failed.");
    }

    // 4. Only now do we decompress and parse
    auto decompressed_stream = decompress(compressed_data);
    this->index = parse_index(decompressed_stream);
}

This makes it safe to include features like embedded scripts (SCPT chunk), because their integrity is guaranteed by the same mechanism.

The "Chicken-and-Egg" Problem: The Hybrid Model

A new format is useless if no one can use it. How do you get PIX into tools like Photoshop? You don't force users to change. You adapt.

My proposed solution is a Hybrid Interaction Model plugin:

On Open: The plugin transparently translates a .pix file into a native Photoshop document structure in-memory.

During Edit: The artist uses 100% native Photoshop tools. No custom panels, no weird UI. The plugin monitors changes in the background.

On Save: The plugin acts as an intelligent diff & merge tool. It translates parametric changes (like transforms) back to the PIX graph and handles destructive changes (like painting on a procedural layer) with "graceful degradation" by converting that node to a raster layer.

This provides a zero-friction workflow for artists, solving the adoption problem by making the format invisible.

Where The Project Is Now.

The entire reference implementation is open-source. so I had to make the architecture clean and simple enough to reason about.

I'm not looking for a job. I'm looking for feedback, criticism, and collaborators.

Break my code. Tell me why my architecture is not well. Tell me what I haven't thought of.

Check out the repository and dive in.

👉 GitHub Repo: PIX v26 - The Declarative Web Container 👈

This is just the beginning. Let's build the future of web content. Together.