Hi,
Just a quick notice to let you know that the new and very welcome “Get Haiku” image looks blurred on retina/HDPI screens. Can someone please replace it by a higher resolution image? 
Not sure what can be done. It’s a PNG as before with the same resolution as before. Why would it now be blurred and not before?
Maybe a different level of compression when exporting the image?
png is lossless…
Even at the native resolution the Haiku logo does not look very good. Did you use the vector version of the logo or did you use a bitmap that you further resized in wonderbrush? also, why not use the “beta 1” stamp as for previous release and as used on the DVD cover?
1 Like
On a HiDPI laptop, only the Haiku logo on the header of the homepage looks sharp. Every other image is displayed at low resolution. I had never noticed, because on my home computer I still use a low resolution screen. Ideally, the website should be serving 1x or 2x resolution images according to the device screen specs reported by the browser.
I am no expert, but I believe that current browsers can do that automatically when the page presents them with a complete picture element.
Hmm, my eyesight isn’t the best, but with my glasses on, it’s alright (I thought). It doesn’t look bad to me… 
I did use the vector version, that I canvas-resized in WonderBrush. Then I “merged visible” layers, because the logo is in half a dozen layers that I think cannot be copy&pasted, to get a bitmap. Which is then used in the banner with no further resizing.
Maybe I don’t use Wonderbrush correctly, but I don’t think you can resize an object - even if it’s vector - without edges becoming more or less blurred. In Icon-O-Matic, you can activate a grid that lets you place vertices only on pixel boundaries. Is there an equivalent for WB?
I could use the “tiny” logo unresized, but that’s a bit smaller. Still good though? See:
compared to what’s up now:
When did the graphic originally, the stamp was a bitmap IIRC saying “alpha” and I didn’t want to recreate it. Also, I wanted the “Beta” to stand out more, extending over the edges of the “badge”. That’s not possible with a stamp.
BTW, I did a vertical version of it as well, if people want to but it on their website:
I (or anyone) can do more colours if needed. Shall I put it on GitHub - haiku/artwork: Artwork for Haiku ?
3 Likes
For “retina” displays, if you simply export the vector graphic at double the final intended css resolution, it should work fine. For instance, if the maximum width is 200px, you export it to a png or jpeg with 400px.
For small size images, it does not make a big difference in bandwidth. If you just use the bigger one and specify half the size in the html, users of hidpi monitors will get the needed resolution. But ideally the html would make both sizes available to the browser. The haiku logo on top of the homepage is displaying correctly, BTW.
That’s because that is the only thing being SVG. 
I tried exporting the graphic as SVG, but opening it in a browser claims:
error on line 15 at column 5: Namespace prefix xlink for href on image is not defined
That’s the export, if anyone wants to investigate: https://0x0.st/s0aa.svg
That’s doubling the bandwidth for 200px viewers. Aka bad way to do it. SVG export (fixed) is always the way to get stuff done if the picture is vectorizable.
Disclaimer: I have done websites under 100kb and I’m obssessed with bandwith and optimization.
There is no xlink:href attribute for image element, just href. However this svg has both dimensions set in attributes and raw image data (in base64) so probably wont scale as you are thinking. Or is going to be blurry once you zoom it in.
Just saying… doubling dimensions of a bitmap quadruples the bandwidth, not doubles. (-: Of course, we’re talking about a PNG here, which has potential for lossless compression savings, so I should probably hush now.
1 Like
@humdinger if you want to see the image you should add xmlns=“http://www.w3.org/2000/svg” to the tag svg and remove xlink: from the error line.
After that you will see the image but there are other problems, for example:
You should add sans-serif to the attribute font-style or when displayed on system without Noto the image will have serif.
And the Beta 1 transparency doesn’t work, maybe this is the problem
https://dev.haiku-os.org/ticket/13202#comment:10
challenge accepted and used an editor to create two pngs with the same content (full red background), but double dimensions.
First used 620bytes, and the double one used 2051bytes.
So… yup, lot more than double, between three and 4 times, no need for you to hush 
@janus2 Cannot scale the image tho, will get a blurry result anyway.
If you use directly the svg file in the browser and use the zoom the image should scale properly with a lot of glitches.
I think we should start fixing the export function in Icon-O-Matic and Wonderbrush…
1 Like
Don’t forget to process the final images in compression/optimization software. But yeah, it takes more bandwidth. Unless it’s something that can be addressed with svg, there comes a moment when you need to choose between blurry images or a bit more bandwidth.
You just provide different versions of the image and check features on js/css. Wasting bandwith for lower image scaling is like booting an electron app to write a txt file.
I have seen nowadays websites with 14MB photos for a product in a shopping catalog tho, … nightmares…
@janus2 Indeed. In this case, i dont know if path-shaped elements would fit in less space than the bitmap image, but worth a try. A manually crafted svg image like this should be in the 1-10kb range. Blindshot guessing based on previous ones i did.
If the problem is bandwidth svg is text and almost all http-servers now compress text transparently… The transmitted image should be smaller than the file size.
Right. That kind of size in some current webpages is crazy. But keeping the Haiku homepage under 1MB with retina-ready graphics shouldn’t be very difficult.
Looking into this image by importing it from the SVG above into GIMP, I would say that a PNG with those big color gradients (including shadows) will always be exported at a bigger file size. If a large portion of the image could be made flat, then probably the resulting image would be much smaller than the current ~30kB. JPEG tends to compress better on images with lots of gradients, but we loose transparency, which seems to be an issue here.
As a quick and dirty proof of concept…
This is a 2x JPG based on the import from GIMP (the blurs got lost in the import process, the text turned into black and there is no shadow and no transparency), weighting 23kB (slightly less than the file size of the current 1x PNG):
This is an export to indexed color PNG (max 256 colors), from the same source, weighting 12kB (less than half the file size of the current 1x PNG):
And this is an export to PNG with all colors, also from the same source, weighting a whopping 51kB (almost double the current 1x file size):
Probably the images will be displayed here at double width, so it natural that they look weird. These are just examples and cannot be used because of all the conversion errors, but should expose what is achievable with these formats in terms of file size for an image like this.
Another option would be to use an SVG file, providing that those shadow and blur effects were compatible with the renderers in current browsers, which I really doubt.
2 Likes
Quick and dirty hack on SVG, starting from original source logo:
Zoomed png representation:
Total SVG size: 8KB.
Better artists can make a better shadow and starlike elements of the background (i have level -53 at art design skill), but will surely still be in the 10kb range. This is non optimized svg code.
2 Likes
@humdinger, just wanted to let you know I’ve used your vertical Haiku download banners in the What makes BeOS and Haiku unique article on my blog and have credited you for it below the images.
Cool (the link doesn’t work though), but the crediting isn’t needed, really.