Default wallpaper images need resizing or remaking?

[johnraff]

At least one of our wallpaper images has been reported to show banding on some displays: https://github.com/BunsenLabs/bunsen-configs/pull/75#issue-172743654

This might be because they are too small for modern display sizes, or because they need to be recreated with full 32 bit colour/monochrome range.

[johnraff]

@tknomanzr and @Head-on-a-Stick what size displays were you seeing banding on? Our wallpapers are currently 2880px × 1800px but at 180~480 kB they're not so big, suggesting they might have been fiercely compressed?

[tknomanzr]

I don't see it at all on 1920x1080 monitors. The gradients are nice and soft at that resolution. At 2560 x 1600, there is some noticeable banding. The resolution is not the problem. It is going to be the pixels per inch (ppi). Open Gimp, create a new image, and notice Under Advanced Options, the settings for x and y resolutions. I would see how the images look with x and y at 144. Check the size of a .png at that pixel density. If it is too large, edge down to 120 or so, bottom end at 100. This is the actual pixel density of the wallpaper:

96.012 × 96.012 ppi

That is straight from BL-beam in wallpapers, loaded into gimp. With the original gimp files, we can re-export the .pngs with a higher pixel density. Try to balance file size with image quality, basically.

I am seeing banding because I am viewing the picture at a pixel density at ~200 ppi. The banding doesn't actually exist. It is my display making stuff up because there is missing information for a display running at 200 ppi. On a lossless .png you can probably safely up the compression considerably as well.

[johnraff]

The resolution is not the problem. It is going to be the pixels per inch (ppi).

Sorry, I don't get this. I thought ppi was just a bit of meta-data that had significance only for printers that were going to put the image on a physical piece of paper. Surely a pixel is a pixel, and the issue is arising because there are more pixels on the screen than there are in the image? If you raised the dpi on an image of a certain pixel size, wouldn't that just instruct the printer (or display?) to display it at a smaller size? Or am I missing something about how images are rendered on a display?

My display is 1440x900 so I can't check any of this - everything looks fine.

Unfortunately I have no idea where the original gimp files are, or who had them. @hhhorb or @capn-damo ?

Can you try increasing the size of a wallpaper image in gimp - using the best algorithm - and seeing if the banding is then gone? (Maybe gimp has more powerful image resizing tools than an LCD display does if forced to expand an image on the fly?)

I have just tried scaling up the images (using the "cubic" algorithm), and while I can't use the result as a wallpaper on my smaller screen, I can inspect it full-size in gimp, using the scrollbars. Yes, the grey images especially show some banding. In fact I can see it even in the original grey versions, but not in the green ones, so part of the problem might have arisen when the green images were decoloured.

I'm off to deviantart to see if I can track down the original image - maybe it's bigger. EDIT: https://rashadisrazzi.deviantart.com/art/Beam-531144169 No, the largest is the same at 2880x1800.

@hhhorb 's remakes here: https://github.com/hhhorb/bunsen-wallpapers But @capn-damo subsequently reprocessed them, moving the logo in a bit.

[ben2s]

I thought ppi was just a bit of meta-data that had significance only for printers that were going to put the image on a physical piece of paper.

This is correct (developer in a company creating prepress software here). When displaying on a computer monitor, the ppi (pixels per inc) or dpi (dots per inch) is not used, unless you're asking for a preview of the printed size (and this is always an approximation).

Surely [...] the issue is arising because there are more pixels on the screen than there are in the image?

Probably. Note however that banding is somewhat complex, and may occur even if there are more pixels in the image than can be shown on the display. This depends on how it is scaled down, what the colour settings of the OS and display are, and even on the colour perception of whoever is looking at the image.

The easiest way to suppress banding is to add noise to a gradient, but this has to be done carefully to avoid making the image look grainy (unless that's a look you want of course).

[tknomanzr]

Using proprietary tools, I am able to reduce the banding by upping the color depth to 16-bit color and adding a bit of noise to it. This comes at significant cost to file size up to about 8.6 megs. A little research shows that Gimp needs to be at least version 2.9.2 to use 16-bit rgb channels. I can confirm the original image was 8-bit rgb. https://image.ibb.co/jfrba7/BL_beam2.png

[johnraff]

Yup, all the banding seems to be gone, as far as I can see it anyway. But, that's a huge increase in file size - the original is 489 kB. There's no way to get it down somewhere under 2MB I suppose?

[johnraff]

I tried exporting your debanded image as a .jpg. It came down to 577 kB. I guess jpgs are inherently fuzzier. Is this usable at all? https://drive.google.com/file/d/1mCxXdggCS4pkYc3_rZjfmqO9qH9WsoOm/view?usp=sharing

[tknomanzr]

I actually thought about exporting it as a jpeg. Jpegs are lossy compression but far more efficient than pngs. We don't really need the transparency information that png's offer. I'd stick with the jpeg and I'll stash the png's back someplace. I think I am a member of the Bunsenlabs Deviant Art group so possibly I could post them there. We'll have to fix up the rest of them, and in the interests of FOSS purism, I guess I should follow the instructions on the forums to get a newer version of Gimp running.

[ben2s]

I tried exporting your debanded image as a .jpg. It came down to 577 kB. I guess jpgs are inherently fuzzier. Is this usable at all? https://drive.google.com/file/d/1mCxXdggCS4pkYc3_rZjfmqO9qH9WsoOm/view?usp=sharing

I'm not usually a fan of jpeg because of the possibility of artifacts (you can see some if you really zoom in on the logo), but that looks very good indeed. If it counts for anything, my vote goes to the jpeg compression (at least for this case).

Note that jpeg artifacts get progressively worse, so any future editing should definitely be done on the png files.

[tknomanzr]

I exported all 4 of the images in question to jpegs at ~.5 mb each. Here they are: I still see a small amount of banding in the lower right corner but it is much better than it was. I don't think I can add much more noise without it becoming very noticeable. Exported images are hosted on scrot.moe, while the originals are stashed in my file server for the time being.

[johnraff]

I am able to reduce the banding by upping the color depth to 16-bit color

Is it possible to use 24-bit (full colour) or perhaps even 32-bit (deep colour) instead?

Did you notice the huge increase in file size that came with going from 8-bit to 16-bit? Is it possible to go to 24 or 32 bits while keeping the wallpaper file size to something sane?

How do you find the jpg files that @tknomanzr posted? Is the banding there still unnacceptable on your display?

[johnraff]

I had no idea the colour depth was so restricted, I would never have supported using that image had I known that.

I don't think these wallpaper images have been kept secret. Discussions with examples go way back to last year on the BL forums.

Anyway, If you'd care to go back to the original Deviantart images, or @hhhorb 's repo, and redo them, I'll be happy to put improved versions in the package. (As long as they're not 10MB each.) I've said on numerous occasions that I'm not a graphics expert and I've no intention of becoming one.

@tknomanzr 's images look fine to me (and @ben2s) ...

[johnraff]

I'd say under 2MB, but @tknomanzr what do you think?

[hhhorb]

Is this a show stopper? If someone has a hi-res monitor, we could either provide a different branded image that matches the default gtk theme in an extras package or just leave it to the user to create their own branded image or use an unbranded one.

I'm wondering how many people out of those with large screens are even bothered by banding.

What's the color depth of the default stretch wallpapers?

[hhhorb]

In that case, I recommend we include Bill's remakes in an extras package and leave this issue open for the time being to catch any complaints.

[johnraff]

Bill's images are an improvement but the cost in respect of file size is prohibitive

What images do you mean? The jpgs he posted here are only 6~700 kB. They still seem to be better than the original pngs, for a ~20% size increase.

[johnraff]

OK for now I'll put Bill's jpg remakes into bunsen-images, and we'll see how it goes from there.

[johnraff]

^Doing this now. Unfortunately the .jpg ending means that the filenames will change. Till the official release, at least, I'll just add the jpg's so that existing users won't see their wallpaper mysteriously disappear. Change the paths in bunsen-configs, and maybe later the extraeneous files can be removed.

EDIT: done.

[johnraff]

My apologies here. I forgot to link to the adjusted wallpapers, with the logo moved further toward the centre. This is necessary for the BL-beam and BL-beam-grey versions, because otherwise on an older "square" display the logo is halfway off the screen and doesn't look good at all.

Here is Damo's adjusted image (ver. 2 of the two he posted here): https://scrot.moe/image/62Vxy and the discussion starts here: https://forums.bunsenlabs.org/viewtopic.php?pid=59587#p59587

Unfortunately he didn't post a greyscale version, so the grey one we formerly had was something I had hacked up on Gimp. That might explain the bad banding @Head-on-a-Stick had originally complained of.

@tknomanzr if you could possibly redo whatever you did before to improve the pngs then make jpgs it would help get this show on the road. This time only two images will be needed, just the ones with logos. Damo's green png > fix colour depth > make jpg, and if you could do a greyscale conversion for the grey version?

Sorry to add to your workload.

[tknomanzr]

Let's see how these two work. Because we have text layered over a gradient, I had to redo the layering before I add the noise. Fortunately, we have the pieces required to rebuild the image, otherwise I would not be able to guarantee you any kind of results.

**NOTE: I am putting a note here to remind myself to start a conversation after Helium releases regarding whether and how we should store originals for Official Bunsenlabs images. If we were able to do so, it would certainly help with re-duplication of effort when the unexpected happens.

[johnraff]

Many thanks! I'll put those in bunsen-images and push it out today.

+1 about organizing our resources so those who follow on can pick up.

[johnraff]

I've committed those two images to GitHub, but just noticed a small issue: the logos are now bigger. Check the previous .png files, eg https://github.com/BunsenLabs/bunsen-images/blob/helium-dev/bl-img/wallpapers/default/BL-beam.png

If it's difficult, leave it, but I think the smaller logos look more elegant, if it's possible to do that.

[tknomanzr]

Ahh yes, one of the benefits of storing our art assets as actual Gimp files is that anyone with the time, knowledge, and inclination could then make small changes such as these. However, since, I have the originals at present, I am glad to make the changes. The question is whether Github is the place to store them. On the one hand, it would give us versioning, branches, etc but these original files tend to be quite large.

[tknomanzr]

See how these two work:

[ghost]

I'm a bit late to the show, but @tknomanzr's latest batch of images shows very noticable JPEG artifacts on my fancy new monitor (24", 1920x1200, not HiDPI), especially the coloured one. where the light beam blends into the upper-left's green-then-turquoise. I wouldn't ship them like this.

[hhhorb]

^ Do any of the wallpapers look good on your monitor?

[tknomanzr]

^ I may need to reduce the noise somewhat and re-export them with much less compression. I think they are sitting at around 75%. The file sizes keep growing on me, so I upped the compression some.

I think I may have killed the backlinks on some of those earlier images because my scrot.moe account was a huge mess and I was trying to organize it somewhat.

It's weird to think that I used to exploit the limitations of raster graphics to create "art" and now I am banging my head up against one such limitation. At any rate, I will mess with it some more in the morning when my eyes aren't so tired and see if I can improve things any.

[ben2s]

I see quite a bit of noise - notably more than in the previous batch, especially in the lower right corner - but no JPEG artifacts. When comparing https://scrot.moe/image/6QXXq to https://scrot.moe/image/6bhfy I feel the top left corner is better in the latest (less banding), but the bottom right was better before (less noise). Anyway, at some point we will have to accept that it will never be perfect for everyone. There are just too many variables.

[johnraff]

OK for now I'll put the latest jpgs in bunsen-images, change filepaths in bunsen-configs to match, and start building a beta iso. We can see if we get any feedback from our user base. The previous pngs will remain too, at least for a while.

EDIT: Extremely sorry, but these are still different from the originals. Please see below.

[johnraff]

@tknomanzr Please forgive me if you think I'm being too picky here, but these latest jpgs are still subtly different from the original pngs in their styling and layout. The logos are further away from the beam, very slightly larger, and the flame is differently placed. The originals by @capn-damo are very nice IMO, and if possible I think we should try to preserve that design.

Compare, the new design: and Damo's original:

(My eyes are quite inadequate to say anything about banding and artifacts.)

[tknomanzr]

Unfortunately, I am not able to find the original Bunsenlabs .svg that @damo used. So here is what I did: I loaded the flame image that I used with the flame over the "e" and moved it slightly to the right, then colorized it with the color from the original image, using Inkscape.

I then brought the image into Gimp 2.9.2, and positioned and scaled it using @damo's original wallpaper as a guide. I then removed the original wallpaper. Then, I add a slight bit of noise to the image (I tried to be a bit more subtle here.). The grey version needed a bit more noise even than the color version in order to reduce the banding.

However, it should be noted that there is the slightest bit of difference between the kerning of the fonts that @damo used than the version of the bl-flame-text.svg that sits in our Github repository, so it is not a pixel-perfect match. It is very close. however.

I am going to issue a pull request with the actual .xcf files as well. Without the originals, making edits becomes more time-consuming and difficult than it really needs to be, imo.

I apologize for my slowness in getting to this. I have been in the middle of finals for school this week.

[johnraff]

@tknomanzr Sorry to badger you like this, when you're busy with more important things. These images look very nice - the layout is now perfect, thank you for taking the time to do this.

They are still .png files, though, and the filesizes are very big. Could you also put them through the same jpg conversion that you did previously? That should get them down to ~1MB I guess?

Also, your recent PR was aginst the 'master' branch, which is now obsolete. There will soon (possibly today) be a renaming of all GitHub repo branches, master > hydrogen and helium-dev > helium. helium will become the default branch in most repos.

[tknomanzr]

Oops. Sorry. I forgot about that. Here is the jpegs

[hhhorb]

^Those look great. Thanks!

[hhhorb]

I don't know, though. This seems rather subjective to me, the percieved image.

I gimped a new master at the same res as Williams, but this has no noise and is in PNG format. The file size is larger, but not bad...

https://raw.githubusercontent.com/hhhorb/bunsen-wallpapers/master/Beam-plain_2880-x-1800.png

This image looks smoother to me in comparison at low res, the other image looks like noisy banding.

[johnraff]

^OK @hhhorb that's a png, so if you felt like redoing the four .png versions, they can co-exist in bunsen-images along with @tknomanzr 's .jpgs until we decide which one to use as default. Because there's no name-clash, users can choose. The default path in bunsen-configs, at the moment though, points to the .jpg. That would have to be changed if we switched.

To me, they all look beautiful, so you guys decide. :)

[tknomanzr]

The top left is significantly better. The bottom right still exhibits a small amount of banding in the lower right but I believe I can live with it. If we could get those 4 re-done @hhh, that would be peachy. If you need the ./svg file for the flame and text, let me know.

[hhhorb]

The bottom right still exhibits a small amount of banding in the lower right...

Yes, banding is most noticeable in the transition to purple. Converting to jpg at 90% quality (default GIMP export setting) makes the banding way worse to my eye. Adding a small amount of noise (25px spread) works great on my small screen but makes the file-size so much larger, 3 MB as opposed to 413 kB. @tknomanzr , what's this look like on your monitor, is it enough noise or do we need more?...

Saving that as a jpg at 90% brings the banding back, worse than in the original png. What should we do? Use the smaller, banded png files for the standard install and offer a "hi-res" wallpaper pack in bl-welcome? Or is 12 MB for the default wallpapers (PNGs with noise added) acceptable for the full-size ISOs?

[tknomanzr]

Like I said, I believe I can live with it like this for the time being. I think when the blue transitions into purple perhaps one more gradient stop was needed. I have been trying to be considerate of folks with lower-end systems in terms of the file size for the wallpaper. Truth be told, if I had designed it, I doubt I would have dropped all the way down to purple on the spectrum anyway, I would have stopped at the dark blue. However, I know from past experience, without the gradient stops as a reference, rebuilding gradients can be a huge pain, and I suspect there is another layer where the green blends down into white as well.

However, since we have a Hi-DPI theme up for consideration, I am not opposed to releasing it as a "Hi-DPI" wallpaper and letting the community know that it is an option that may or may not fix display anomalies. The noise is a visual illusion that helps to distract the eye from the banding, pretty much. I wish I could tell you for sure that this method or that would fix it, but when banding arises in print, a lot of times the only way we could fix it was by attempting to build the gradient with more stops. Banding on newsprint is even worse than on displays, lol.

I would like to reassure you though, that despite the difficulties we have experienced over this development cycle, this iteration is going to be a masterpiece. And it is going to get even better with the next point release, just as Hydrogen did. Art and software design have the characteristic in common that they are highly iterative processes.

[hhhorb]

Playing with the image some more, banding is emphasized in the desaturation process, or maybe my eye just sees it more clearly in greyscale. To compensate, I ran desaturation first, then added a 30px -edit-40px noise spread. When I start adding more noise than that, the distortion started getting more distracting than the banding to me.

Anyways, here it is, the file size is nearly half of the color version...

-edit- 40px spread is the best compromise IMO...

Like I said, I believe I can live with it like this for the time being.

OK, check if this greyscale image is acceptable to you while I add the logos back in.

[hhhorb]

Logos added...

-edit- 40 px noise spread for the B&W images... -edit- oops, wrong file...

Thunar shows those 4 walls as being 10.3 MB, that's not too bad at all IMO.

[hhhorb]

@tknomanzr , something I missed earlier in this thread while I was away, here's where the original svg files are (flame and text-flame)...

https://github.com/BunsenLabs/bunsen-images-extra/tree/helium/bl-img-extra/icon-avatar

I used text-flame.svg for these 2 new logo walls, resized and positioned according to your jpegs.

[tknomanzr]

Ok. Cool. I feel like this will work and lesson learned for us all to be more careful with use of gradients in the future. However, I have really liked the entire Beam theme overall since I first ran it. I think newer versions of Gimp, since they offer higher bit-depths will help with them.

[johnraff]

(After my picky complaints about the flame being moved from the l to the e, there it is in the original! That must have been something Damo changed.)

Anyway, what should we now do for the basic bunsen-images package?

is 12 MB for the default wallpapers (PNGs with noise added) acceptable for the full-size ISOs?

Or 10.3MB in fact. Remembering that these files will go in bunsen-images as well as in the iso, so existing users would get that 10MB next time they upgraded. Is that acceptable for the great majority of our users?

• If so, then @hhhorb 's new png's could go in, and @tknomanzr 's jpg's taken out, and the filepaths readjusted accordingly.

• OTOH if it seems a bit bulky, put the hi-res images in bunsen-images-extra, keep the jpg's in bunsen-images, and possibly remove the equivalent png's from there too?

Either seems reasonably sensible, but we need to decide soonish...

[hhhorb]

If so, then @hhhorb 's new png's could go in, and @tknomanzr 's jpg's taken out, and the filepaths readjusted accordingly.

i vote for this, though I'd suggest simplifying the file names.

I think @tknomanzr 's last comment implies that he's fine with that too, but we should wait for his response.

After my picky complaints about the flame being moved from the l to the e, there it is in the original!

It's how it appears on our website and forum headers as well.

[tknomanzr]

I have no strong opinion either way, at this point. I would have preferred to ship .png's, however because they are lossless. Jepgs will begin to artifact after being copied, moved around, etc.

[hhhorb]

I would have preferred to ship .png's, however because they are lossless.

So, @johnraff, leave this issue open a bit for objections/suggestions but prepare to replace the walls with these 4 PNGs? Or sooner rather than later, if it makes things easier, or I can just put the commits in myself and you can merge them, just give me the word if your plate's too full. :^)

Leave tile.png in, please. I'm unsure about grey.png given the file-size and resolution, but probably better to leave it too.

-edit- Ah, tons of noise in grey.png, that's why the file size is over a meg.

[johnraff]

I have really liked the entire Beam theme overall since I first ran it

Same here. Every time I boot up a newly installed Helium, I think how nice it looks.

grey.png is the former "Velvet Noise". It was the Crunchbang background (maybe?) and certainly the BL Hydrogen, so I think it should stay.

After my picky complaints about the flame being moved from the l to the e, there it is in the original!

It's how it appears on our website and forum headers as well.

But in the Hydrogen wallpapers the flame hovered over the l to look like a bunsen burner: I have to say, I think it looks more elegant that way.

[hhhorb]

^ I remember those walls (early damo, I think), but we'll need to recreate that flame placement. Very easily done.

What's your thought, John, an additional 4 walls with that logo or do you want that logo as the default?

[hhhorb]

Also, that logo uses Open Sans only, not bold in the first half.