Please Review My Responsive Image Format
github.com
github.com
An image with a hole allows it's other pixels to not have to carry an extra byte to render transparency allowing for good compression for oddly shaped images. Same reason Sxz supports paletted images with more than 256 colors, hopefully allowing for greater potential compression where PNG and WebP switch over to TrueColor. Most corporate logos use 256 colors and a white background. Why not just remove the background and increase the quality of the image with more colors?
SVG isn't pixel perfect like PNG. Amongst icon content creators, they avoid SVG in order to have precision. Although SVG has good integration with a browser's DOM, while PNG and JPG are merely data blobs. Since Sxz breaks down to chunks, it can potentially be parsed by browsers into DOM nodes allowing CSS interaction.
The target audience would be game developers in highly constrained bandwidth markets such as mobile and browser based games and want PNG's precision with additional features and don't mind the slow encoding.
I will generate more documentation if there is continued interest.
Regarding logos: most corporate logos use even less colors. The reason behind is a follows: a corporate logo works well displayed in its full bright, but also works well as a small icon printed in black and white. Yes in the corporate world, people still print and many still print in black and white to save costs. Here you can see how good logo design works, how a good logo works in is full bright and also very small: http://responsivelogos.co.uk/ You also want to reduce the number of colors, because normally those colors are special colors from standardized color palettes like Pantone. In offset printing for advertisement material, those colors are not mixed on spot, but special colors and they are expansive. For that reason in good logo design you try to stick with 1 color besides black and white, or a maximum of 2.
In my experience a SVG logo rendered in a browser always looks much better than a pixel variant.
The only thing you can say about 'pixel perfect' is that you know for sure that pixel X,Y uses color C. But that doesn't mean you know how it will look on screen. Or how it will be positioned.
Also in this age of very high res screens I think vector is the way to go.
Do you work with responsive images working group? Are you on the mailing list?
1. Embedded image maps. Presumably functionally equivalent to HTML image maps? There don't seem to be accessibility features.
2. Multiple images which are overlaid on each other to produce the final image. These overlays can be true color, bitmapped, or palette based, kind of like DjVu.
The image layers kind of remind me of MPEG-4's Video Object Planes. That's a bad thing. No one ever figured out a reasonably fast method to segment video into overlaid objects without manual intervention. It's cool that your image format has this feature, but if the encoder can't make use of it, what's the point?
3. Multi-resolution encoding PNG and JPEG already have interlaced encoding. I can't tell how yours is different, aside from being less efficient.
4. Images with holes .... how is this an improvement over alpha layers?
5. Manual compression with a C# gui If you're going to do this, why not redraw your image as SVG instead?
In summary, it's an interesting set of features, but I really can't tell the use case you are targeting. In addition, it seems that many of your features already exist in other formats. Maybe you should retarget this as being a simple scene graph builder for Javascript instead of an image format?
This is somewhat different to segmentation in video, but it does show that there are useful, fast encoding implementations of segmented image overlays.
You ought to have a gh-pages branch in the repo, so people can see it live.
But yes, I agree there needs to be more background info here.
I'd also like to see a written format specification document (even though I can read C#)