[HN Gopher] 500 Byte Images: The Haiku Vector Icon Format (2016)
___________________________________________________________________
500 Byte Images: The Haiku Vector Icon Format (2016)
Author : smartmic
Score : 121 points
Date : 2024-04-29 09:37 UTC (2 days ago)
(HTM) web link (blog.leahhanson.us)
(TXT) w3m dump (blog.leahhanson.us)
| pimlottc wrote:
| This is great and all but how do they look? The only good example
| is the tape recorder which imho looks less and less like a real
| tape deck at larger sizes; the shape of the tape is noticeably
| distorted and the curves in the shape of the body are
| unrealistic.
|
| Saving space is well and good but for icons it's secondary to how
| clear and usable the images themselves are.
| tdeck wrote:
| I found a repo of the Haiku icons in various formats:
| https://github.com/darealshinji/haiku-icons
|
| Typically how they look is up to the designer, they can decide
| how many small details they want to put in to make the icon
| look better at a larger scale. Haiku seems to have gone with a
| kind 3d clipart style that isn't highly detailed.
| zamalek wrote:
| Haiku has an extensive UX and design guidelines document -
| including meticulous rules for icon design. The tape recorder
| looks that way because it adheres to those guidelines, not
| because of a file format.
| Someone wrote:
| Can you provide a link? The only thing I found is
| https://www.haiku-os.org/development/icon-guidelines. I
| wouldn't call that extensive.
|
| I think Android's
| (https://m2.material.io/design/iconography/product-
| icons.html...), Apple's
| (https://developer.apple.com/design/human-interface-
| guideline...), and Microsoft's
| (https://learn.microsoft.com/en-
| us/windows/apps/design/style/...) are more detailed than
| that.
|
| (And yes, that's comparing to the work of huge companies, but
| I don't think that matters for deciding whether to call this
| 'extensive')
|
| I also do not rule out that the tech choices they made
| (partly) drove the guidelines. It doesn't make sense to
| proscribe things the OS cannot display.
| Jasper_ wrote:
| One of my favorite articles on this topic, "About those vector
| icons", goes into this issue and many more flaws in much more
| detail. There's nothing fundamentally wrong with vector icons,
| but it's not all that's needed for a one-size-fits-all
| solution.
|
| https://www.pushing-pixels.org/2011/11/04/about-those-vector...
| gfody wrote:
| showing some image using fewer and fewer pixels is like
| trying to summarize some text using fewer and fewer words, at
| some point it requires intelligence, at another point it's an
| artform
| wk_end wrote:
| Appropriate for an operating system called Haiku ;)
| trollerator23 wrote:
| How so? It's obvious it was drawn to look like that. It's not a
| deformation.
| themerone wrote:
| When the format was developed nobody was rendering icon's at
| 128x128. PC Icons were 16x16 or 32x32. Mac's might have
| supported bigger icons, but it was still a long time long time
| before screen resolutions necessitated 64x64 icons.
| Findecanor wrote:
| I believe NeXTStep used 64x64 icons from the beginning
| (1989), although they always included some margin.
| tedunangst wrote:
| Previously: https://news.ycombinator.com/item?id=22373422 And:
| https://news.ycombinator.com/item?id=12420763
| tdeck wrote:
| > If you use the standard bitmap icon formats, you'll probably
| store them in their own files, separate from the files that use
| them. In order to display each file in a folder, the operating
| system will need to read the metadata for the file (including its
| name and file type) and then read the icon file for that file
| type. If the icon file were so small that you could store it in
| the same place as the file metadata, then you could save a read
| from the hard drive - you could get the metadata and the icon all
| in one read.
|
| > ... it could be a significant performance gain to halve the
| number of disk reads even if rendering a vector image takes
| longer than rendering a bitmap.
|
| Surely another option would be to cache all the filetype icons in
| memory and thereby only read them once? You could still use this
| cool vector format and get the best of both worlds, so each icon
| would be small and would be read only once, and you wouldn't have
| duplicate icon data all over the disk. And then if you wanted to
| change the icon associated with a particular filetype, you
| wouldn't need to update every single inode for files of that
| type.
| zamalek wrote:
| 24x24 and below still require special treatment because pixel
| grid alignment becomes really important. The tape recorder image
| demonstrates this well: the raster 16x16 looks way better than
| the vector. I wonder if it would generally be better to store
| these tiny sizes as bitmaps in the container.
| marcellus23 wrote:
| Yeah, I'm suprised the original article didn't mention that.
| One of the main reasons that smaller icons are stored as
| separate files is that they need to actually be designed
| differently, not just scaled down.
| geon wrote:
| Haiku icons have support for Level of Detail.
| sunaookami wrote:
| Link: https://www.haiku-
| os.org/docs/userguide/en/applications/icon... under "Level
| of Detail"
| idle_zealot wrote:
| Perhaps I'm misunderstanding something but... does this mean that
| when you say, create a text file or PDF on Haiku the application
| creating that file is responsible for copying its icon into the
| new file's metadata? i.e. if I make a directory full of 1000 text
| files then I've also created 1000 duplicate images?
| Someone wrote:
| I think you're misunderstanding things. FTA:
|
| _"If you use the standard bitmap icon formats, you'll probably
| store them in their own files, separate from the files that use
| them."_
|
| = i think they're talking of having to read the same data again
| and again, and then try to minimize the number of blocks read
| from disk.
|
| Of course, reading the icons again and again is the MVP
| implementation, but not necessary. They could create a cache of
| icons. Even if they don't, the file system cache would
| significantly decrease the number of actual disk reads.
| alkonaut wrote:
| A resonable icon format would be a vector file plus (at least
| optionally) 16 and 32px bitmap images. A 16x16 px icon is still
| common (eg toolbar buttons at desktop resolutions lower than 4K)
| and as evident by the article there is no way of rasterizing a
| vector image to 16x16 and preserving anything but a blurry mess.
| At least not without using a very clever (AI could possibly do
| it) rasterizer.
|
| The 16x16 representation is often completely different from the
| vector or 64x64 version. If you draw a clock, the large version
| is 3D has numbers and 3 hands. The smaller versions is 2D, has 2
| hands and no digits.
| Findecanor wrote:
| HVIF supports having different shapes at different levels-of-
| detail in one file.
| nox101 wrote:
| > there is no way of rasterizing a vector image to 16x16 and
| preserving anything but a blurry mess.
|
| Deep learning suggests differently?
| LukeShu wrote:
| Many of us look at
| https://github.githubassets.com/favicons/favicon.svg at 16x16
| every day, and wouldn't call it a blurry mess.
| AlienRobot wrote:
| I've always thought SVG was a terrible format and I hate that it
| has become synonymous with "vector". The only thing it has is
| interoperability because of XML. Any binary format would be more
| performant. Then we have Inkscape that is basically a SVG editor
| so it has to stay compatible with the SVG standard. Proprietary
| vector image editors like Affinity, Illustrator, and Corel Paint
| all use their own formats, so they can add and change any
| functionality they want. It's just Inkscape that's confined to
| SVG.
|
| That said, I don't think a single vector file is a good solution
| for icons. If you take a look at Windows 98 icons[1], you'll see
| that many icons are manually re-drawn for lower resolutions,
| which is something that ICO format can do which nobody else can
| do for some reason. A simple example is the calendar icon.
| Because a calendar has a "grid" for all 7 days of the week, it
| would need to have 6 vertical lines, which would look too busy in
| 16x16. So the 16x16 icon just uses fewer grid lines instead of
| turning everything into a blurry mess.
|
| Anecdotally, I've tried using 16x16 pixel icons on the web
| before, but fractional scaling made them look bad on my phone.
|
| 1. https://win98icons.alexmeub.com/
| makapuf wrote:
| Inkscape is not really "confined" to svg, because saving to
| pure svg is lossy. Only svg with extra specific inkscape
| metadata is lossless- clearly legit svg, but with specific bits
| under the "sodipodi" namespace IIRC.
|
| Edit: also note that svg can have resolution-dependent details
| : see last discussion on hn
| https://news.ycombinator.com/item?id=22374744
| idle_zealot wrote:
| As mentioned elsewhere in this thread, Haiku solves the detail
| issue by allowing shapes/paths etc to be marked to only render
| in certain resolution ranges.
| Dwedit wrote:
| So why not use the SWF file format? It's a well-documented
| standard, and is binary and compact.
___________________________________________________________________
(page generated 2024-05-01 23:00 UTC)