Please Review My Responsive Image Format(github.com)
github.com
Please Review My Responsive Image Format
https://github.com/DarkLilac/Sxz
8 comments
So what is the advantage and benefit over SVG with embedded PNG?
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.
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.
I think vector (SVG) is superior when it comes to logos and icons. When a vector is rendered it is done in the context of the system used. For example sub-pixel rendering uses the information of the display.
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.
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.
Yours is an interesting image format. How can I get in touch with you?
Do you work with responsive images working group? Are you on the mailing list?
Do you work with responsive images working group? Are you on the mailing list?
So, this is a replacement for PNG. I assume it's intended to be lossless. The additional features seem to be:
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?
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?
Xerox multifunction printers have a feature to scan to PDF, but does so in such a way that the page image is segmented into lossy colour (DCT/JPEG) and coloured monochrome (JBIG2) depending on whether the area is detected as being photo-like or text/diagram-like respectively. These partial images are then overlaid to make the final composite page - the end result has both higher perceptual quality and considerably smaller file size then if it were encoded entirely via DCT or entirely in a lossless format such as deflate.
This is somewhat different to segmentation in video, but it does show that there are useful, fast encoding implementations of segmented image overlays.
This is somewhat different to segmentation in video, but it does show that there are useful, fast encoding implementations of segmented image overlays.
What do you think of embedding a semantic version field in your format, so that you can make backwards-incompatible breaking changes down the line?
Got any demos? I couldn't actually spot any renderings.
You ought to have a gh-pages branch in the repo, so people can see it live.
You ought to have a gh-pages branch in the repo, so people can see it live.
I added some links to the readme.
https://github.com/DarkLilac/Sxz
What are the use cases for this format ? I am guessing the image responsively resizes or something, but it's hard to tell without any examples.
More info: https://github.com/DarkLilac/Sxz/tree/master/Library
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#)
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#)
There is no specification, so there is nothing to review. I'm not going to dive into demo programs to figure out the file format.
How do I pronounce Sxz?
Ess by zee?
Sucks?
The S is silent
Will it support animated images?
The interpretation of frames is left to the rasterer to decide, so yes.
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.