I think haiku icon format is the best for icon… but why only haiku use it…
i want to use it on linux too… but it seem big task…
1 Like
There is a Rust library to render HVIF icons using Cairo: hvif - Rust
So nothing prevents you from using that
2 Likes
Hmm, maybe I should make it portable. The icon format still has room for improvement. Making our library portable means others can read HVIF files with those improvements without waiting for the Rust library to support them.
Why? The format works fine?
Indeed, it works very well. The creator (Stippi, I believe) performed many optimizations to the format. There is a custom three byte float format, and a custom number format. There are flags for if a color is grayscale, allowing the format to specify the color in one byte.
But there is still room for improvement. For example, any transformation to a shape requires 18 bytes, even if it is a simple translation. Also Stippi left some notes in a NOTES file specifying some ways that to improve the format.
3 Likes
Though it should not require changes to the format I think it would be nice to have a HVIF optimizer/cleaner tool.
This could do things like merge similar paths or colors, turn a gradient which is made of the same color into a single color, dump unused styles or paths, etc. This tool could maybe also sort the styles so that the outside stroke is always in the same position to allow for easier machine manipulation (change the outside stroke color for light or dark style for example.)
I mention this because I know in some of my icon editing many years ago I noticed some inefficiencies in some icons which would be painful to fix manually but a tool could make easy. Ideally the tool would show what changes/fixes it is making and it would compare the rendered icon bitmap at all sizes to ensure nothing changes there.
Maybe this just gets added to Icon-O-Matic, though depending on the interface maybe a standalone tool would be better. One would have to experiment I expect.
Though given this is my idea I’ll probably be the one to make it. But if anyone wanted to play with the idea, feel free 
Though don’t worry about it for GSoC Zardshard you probably have enough to do.
6 Likes
Go for it!
I recently filed two related enhancements:
4 Likes
A bird opening a can of worms, live to see 
:
Show the resulting HVIF filesize:
https://dev.haiku-os.org/ticket/18413
Sidebar with previews for more icon sizes:
https://dev.haiku-os.org/ticket/18414
Add shear and projective geometrical transformations:
https://dev.haiku-os.org/ticket/18415
Contour and Stroke transformers to a 1 point shape:
https://dev.haiku-os.org/ticket/18416
Allowing the Icon-O-Matic format to store and show authorship, credits, license, comments, etc.:
https://dev.haiku-os.org/ticket/18417
Leavengood and humdinger already had in mind the discarding of unused paths, shapes and styles, so one less.
@Zardshard your avatar has me fascinated, its hypnotic 
2 Likes
It’s hypnochick. 
2 Likes
@Zardshard, this is also about time to get solved:
https://dev.haiku-os.org/ticket/4837
Using decimals for Stroke or Contour transformers is not so important at big sizes, but at the smaller sizes this is crucial, having to jump from 1px to 2px, or from 2px to 3px is too much.
2 Likes
Nice @Handmaus. A lot of food for thought 
1 Like
Back on topic, the HVIF format has several alternatives these days. Two of them are IconVG and TinyVG. I wonder how these three formats compare.
3 Likes
If anyone is interested, I wrote an HVIF rendering control for WPF (Windows Presentation Foundation) some time ago:
(mostly just for fun and to try out VB.NET instead of C# which I do usually)
4 Likes
One is developed by Google and the other by Microsoft. Great. I’d say importing them would be a stretch goal or an alternative to importing SVG. Both of the others already have SVG importers.
Curiously, neither of them mentioned their application being applied to color font glyphs, even though SVG is still part of the OpenType specification.
Actually they are both just small formats developed by independent developers. While IconVG is under Google on GitHub this is just due to the odd way Google seems to think they own all code of their employees. I’ve seen this for other projects. At the bottom of the README.md for IconVG it says:
This is not an official Google product, it is just code that happens to be owned by Google.
As for TinyVG I know it is just a project from someone in the Zig community, because I am involved in that community and I saw it when it was announced. I don’t know where you got the idea it is from Microsoft.
Either way I don’t think either would be a contender for replacing HVIF. But as Zardshard says it probably would not hurt to give them a look to see if they have interesting ideas or to consider adding some image translators to Haiku for them. TinyVG would likely need a working Zig port, which I know we need to keep working on after some recent changes. I am interested in getting a high quality Zig port on Haiku, as are other people. They have accepted Haiku patches in the past, so our port can be upstreamed.
3 Likes
It’s hard to argue that Google isn’t controlling your project when they make demands and you abide by their demands.
1 Like
Just as a heads up, I’m working on a simple HVIF icon reader library akin to TinySVG. It doesn’t build and is more of a framework then something that is usable. However, I just wanted to let the community know.
It is written in C99 (with some optional C11 code) and is meant to be as portable as possible. The idea is that other languages can be supported through auto-generated language bindings.
5 Likes
Nice! Finally people will be able to use the HVIF format even if they are not using Haiku, Rust, or Visual Basic!
Here is a design problem that you might come across as you code your library.
1 Like
Fortunately the Zig-based TinyVG has a specification external to the SDK so it can be implemented as a file format translator without having to use the original Zig code.
Re:The actual makers of it
TinyVG uses .NET5 framework which is maintained and owned by Microsoft. The library code isn’t Microsoft code but uses the framework that Microsoft maintains so the external dependency is Microsoft based. Sorry I wasn’t clear.
IconVG may be maintained by a Google employee using their Open-Source give-back time on the job. Google has done a lot for the open-source community but the Google hosting requirement makes it suspect. Since this thread is regarding a Google Summer of Code project, I’ll just leave it at that.
Update:
Having read the prerelease 1 specification of TinyVG in its entirety, one feature stands out that I haven’t seen in HVIF so far: coordinate precision settings. The x and y coordinates can be 8-bit, 16-bit or 32-bit. I suspect that could be added to HVIF but the coordinates are unsigned in TinyVG. To add this capability to HVIF, I’d suggest using fixed-point coordinates. That way, adding precision doesn’t require that all coordinates be scaled in the user-interface in Icon-o-Matic. It would also allow a 24-bit format to be possible for example. Thoughts?
1 Like
HVIF is designed for a very specific task: rendering icons. This explains why it lacks some features. It already has way to represent integer x and y coordinates on a 64x64 grid, and 24bit floating point ones.
Having just these two and nothing else means the igon data can be extremely small. The more different formats you add, the more space you wa#te to indicate which format is used.
Doing that is useful in a format designed to store any kind of vector graphics, not just icons, but also larger designs (where more precision and/or is needed). But probably not in HVIF.
It’s more interesting to have Haiku handle these different formats using translators, than to try to fit all features of them into HVIF.
4 Likes