Created attachment 91960 [details] Screenshot See attached screenshot which is 100% scale using the correct resolution. They should be regenerated either with AA on or generated bigger and downscaled afterwards. I believe we can do better with our default wallpaper.
Martin, you implied on IRC that you'd be up for doing this? The .svg is here: https://share.kde.org/public.php?service=files&t=e943244361c19c2b6e2c04ab8b3dccb7&path=%2FDeep
I did...when I was sitting at my workstation. Now I'm all packed for my journey home and on mobile only, so can do Monday soonest. But you also said something about cropping and stuff? What do I need to do?
We've spun the beta, so we have till final release anyway. I'll just make sure we use a massive rendering for the screenshots. I don't really feel I'm qualified to give advice on this, given I did the last set :) Some of the images we need to make are of different ratios, see the current filenames. When that happened I (after discussion with Ken) went with the bottom right section.
So I've spent couple hours on this and no matter what I use to export it (as well as no matter what format or size), the lines are still coming up very pixelated. Inkscape is crashing on me right after opening this file so I can't even attempt to change some settings or something. I'm afraid someone more knowledgeable of inkscape would have to help out here. Ken, Andrew - do you know what's up with those pixelated lines?
(In reply to Martin Klapetek from comment #4) > So I've spent couple hours on this and no matter what I use to export it (as > well as no matter what format or size), the lines are still coming up very > pixelated. > > Inkscape is crashing on me right after opening this file so I can't even > attempt to change some settings or something. > > I'm afraid someone more knowledgeable of inkscape would have to help out > here. > > Ken, Andrew - do you know what's up with those pixelated lines? Hrm... "It's not a bug, it's a feature!" But in all seriousness, it seems like you're pointing to an effect I tried to create where I let white 'bleed' through the triangles; I was trying to take advantage of the natural gap created by the rendering process, but it's clear it's not enough if it's looking like a lack of AA. (If you examine the source, you'll see I purposefully added white slabs to help this along) Because I can't really coax Inkscape to play along with the effect better (without significant effort, at least), I've emphasized the intended effect via a highlight layer and GIMP; you can see better 'what I was going for' but unfortunately it also means there's no SVG for this specific iteration, unless I manually add hundreds of lines... https://share.kde.org/public.php?service=files&t=01fff646eccf2b4a81fc54f72d2c362d Assuming this is satisfactory, David, if you want, reply with the cropping measurements and I can send you the updated artwork.
Created attachment 92019 [details] Screenshot 2 I do like the white-line-bleeding-through effect, but I think the updated one has the same problem, see the attached screenshot. You can see that the line is not smooth and it looks jagged/not-AA'd; but it does look at least one level better.
> I do like the white-line-bleeding-through effect, but I think the updated > one has the same problem, see the attached screenshot. You can see that the > line is not smooth and it looks jagged/not-AA'd; but it does look at least > one level better. I produced one more update, but there's almost no difference; https://share.kde.org/public.php?service=files&t=63af6e617dc6fde0cc8228f5c7009514 On second look, it appears you are downscaling the graphic - I'm assuming you're using a live screenshot - the 'jaggies' you see might me a result of the intermediary scale operation on fine lines. If you view the raw desktop images at 100% you'll see the lines are quite smooth. Do you think this is something where we need to look at the downscaling algorithm for the wallpaper and make sure it's not something hideously cheap?
>Do you think this is something where we need to look at the downscaling algorithm for the wallpaper and make sure it's not something hideously cheap? It is something rubbish There's an open bug on that annoyingly it's not an easy fix to do it properly. see https://bugs.kde.org/show_bug.cgi?id=338506
Created attachment 92025 [details] Screenshot at 100% > If you view the raw desktop images at 100% you'll see the lines are quite smooth. I'm afraid not. This attachment is crop from 100% zoom (from the last version) and you can see the little stairs (in every single line). This is also actually opened in Gwenview, but I'm actually not sure if-and-what we could do to get rid of that...
I'm thinking - do you have some of those hi-dpi screens? Maybe that's why it looks super smooth for you?
I'm running on a normal monitor; Plus I've been zooming in 800x so I'm getting a clear look. What you're describing at this point is not that they *aren't* anti-aliasied, it's just that the lines are so thin that the pixel transition is relatively short; in the images I've been sending, the line with is ~.2px. Once the line enters a pixel it remains there longer, until the next line where the transition is more sudden. So this is one of those 'it's technically correct' things. It's also why, even when using superscaling, it still appeared 'wrong'. The impact was most obvious on lines with shallow gradients. So, below is my final image; I've applied a mask that puts the white lines at ~.5px, which is enough to keep the lines looking sharp without them having the short-stepping you're referring to. https://share.kde.org/public.php?service=files&t=92415b8d0e04160bf038e081dcc31501
http://oserv.org/files/kde/wallpaper-deep/ — renders with 4x supersampling. If this is ok, I will minify them and upload as a single archive.
Those are based on desktopWallpaper-deep-1.0-kvermette.svg (20bf0e5af56181f79b3a55b846c43970) The render script is also uploaded to that folder, if you need it. The command for running it is embedded as a comment on the top of the script. I might update and re-upload the script as the same filename without notice.
advdef gives ~9.6% file size reduction (33600420 → 30388816) pngcrush+advdef gives ~18.5% file size reduction (33600420 → 27378972) I uploaded pngcrush+advdef compressed images.
(In reply to Nikita Skovoroda from comment #14) > advdef gives ~9.6% file size reduction (33600420 → 30388816) > pngcrush+advdef gives ~18.5% file size reduction (33600420 → 27378972) > > I uploaded pngcrush+advdef compressed images. Hmm... On close inspection the images appear muddy; There's a noise map used on the wallpaper to alleviate banding, it looks like the resampling/compression used has blurred the noise map making it look like it has JPG compression artefacts. It also looks like the colour has been adjusted (automatically?); colour adjustments would actually 'break' the palette when compared to icons and widget colouring schemes, as the wallpaper strictly adheres to the Breeze palette. Plus it's not really in the purview of the filed issue, I'm still learning to change one thing at a time. ;) Other than those two things, it did get rid of the aliasing by removing the lines entirely; I would recommend adjusting your processing script to avoid the muddy effect (supersample at exact X:1 ratios) and not having it adjust the pallet. Alternatively you could remove the noise map before your process, and apply it in post. At this point I'm satisfied the wallpaper is already 'fixed' (comment 11), at least down the road my method goes. If we go Nikitas route, I'd like to see his script/ouput corrected with the above issues taken care of.
Ken, can you please share parts of the image where those two effects (color difference and the muddy effect) is visible on the antialiased wallpapers but are not visible on the stock ones (from v1.0)?
I can not see any visible difference in the texture with 400% zoom of the highest-resolution 3200x1800 image. I can the texture difference though with 400% zoom on the lowest-resoliton 1280x800 image. The problem with the noise is that it an embedded raster png image and is actually scaled with the wallpaper. If the rendered image resolution is lower than the noise resolution then the noise is blurred (even worse with supersampling, but that's not the initial source of the problem), and if the image resolution is larger than the noise resolution then the noise is pixelated (you can observa that on a 3200x1800 image even without supersampling). As there is no other way to remove banding now (inkscape doesn't support dithering or 16bpc, browsers support dithering only linear gradients and not the radial ones), I can try to separate the noise from the wallpaper and tile it without scaling on top of every resulting wallpaper. Will that be fine?
Created attachment 92035 [details] Side-by-side of noise map 2x scale; Left: Original Right: Processed
Thanks. What image (resolution) is that? I can't find the corresponding picture in the 5.2.95 package (that looks like the left side).
(In reply to Nikita Skovoroda from comment #17) > I can not see any visible difference in the texture with 400% zoom of the > highest-resolution 3200x1800 image. > I can the texture difference though with 400% zoom on the lowest-resoliton > 1280x800 image. > > The problem with the noise is that it an embedded raster png image and is > actually scaled with the wallpaper. If the rendered image resolution is > lower than the noise resolution then the noise is blurred (even worse with > supersampling, but that's not the initial source of the problem), and if the > image resolution is larger than the noise resolution then the noise is > pixelated (you can observa that on a 3200x1800 image even without > supersampling). > > As there is no other way to remove banding now (inkscape doesn't support > dithering or 16bpc, browsers support dithering only linear gradients and not > the radial ones), I can try to separate the noise from the wallpaper and > tile it without scaling on top of every resulting wallpaper. > > Will that be fine? I attached a sample; it's both wallpapers at (native) 2560x1600, and upscaled them so the difference can be seen. When I supersampled this image, I supersample to 5120x3200; doing this keeps the pixmap on the grid for when it's put before going back to 2560x1600, where it remains 'crisp'. Granted, when a users monitor rescales it to their own resolution you'll still get a bit of that, but at least it's not a double-hit. Anyway, if you look super-closely at your result image @ 2560x2600 you'll see in some areas its crisp, while others it's blurry; you could probably draw the lines where you see the Moire pattern. Anywho, removing the noise map from the image before processing and then adding one manually after is probably the best option; once you scale it in anything other than precise ratios you start getting funky rendering; I never imagined other people seriously working with the raw SVGs. It should be easy to remove the noise map in Inkscape; the file is in labelled layers, so you should have no problem finding the noise layer. :) The banding issue isn't even Inkscape; any gradient that has too few steps between its constituent colours will always have banding, unless the export is dithered. Also, if for any reason someone is using a low-quality screen the noise also helps a bit. Plus, it just looks less sterile. I wouldn't worry about anything bigger than 2560x1600; from what I understand that's what we're topping out at for now. Looking at your image again, and the side-by-side, I think the colour shift was in my head, or because of the (dying) monitor I've been using. So that's not a worry.
(In reply to Nikita Skovoroda from comment #19) > Thanks. What image (resolution) is that? > I can't find the corresponding picture in the 5.2.95 package (that > looks like the left side). It's the 2560x1600 versions, simple scaled 2x for convenience. :)
Created attachment 92036 [details] 5.2.95 2560x1600 screenshot
>It's the 2560x1600 versions, simple scaled 2x for convenience. :) No, it's not. 5.2.95 has less opaque noise. What I am referring to is that the 2560x1600 image in 5.2.95 does not match to the image that you were using. Which one is correct?
See https://projects.kde.org/projects/kde/workspace/breeze/repository/revisions/master/entry/wallpapers/Next/contents/images/2560x1600.png and https://projects.kde.org/projects/kde/workspace/breeze/repository/revisions/master/show/wallpapers/Next/contents/images
Please check the http://oserv.org/files/kde/wallpaper-deep/noise-outside/ folder, it contains post-processed noise so the noise is always tiled and never scaled. Not all images are ready, and the images are not minified yet.
*** Bug 346252 has been marked as a duplicate of this bug. ***
So what should happen with this? Should we use Nikita's images? The release is on Tuesday, that doesn't give much time to sort this out, so some decision should be made.
Nikitas' images turned out quite well; they get my vote. If he wants to minify them a bit that'd be great, but in terms of visual fidelity they get my seal of approval. If he doesn't minify them by tomorrow I'll take care of compression. @Nikita: Nicely done!
@Martin, tagging and release to distros was done earlier today.
Yes, but everytime there are new tarballs re/made. So that should be fine, especially given that this is something that the first time users will be greeted with.
If it would help I can do some quick compression in a few hours once my shift is over, but if it will gum up the works I can hold off. Let me know and I'll do whichever when I get home.
The sooner the better. So if you get home and there's no response here, just do it. Thanks
I've run the images through GIMP and compressed them. Went from ~140MB for the lot down to ~30MB. They're still uploading, so if some are missing check back in 5. Here's the link: https://share.kde.org/public.php?service=files&t=6567dc0c559f4d3b09c26f612f6bb2eb
Btw: 1) I was using desktopWallpaper-deep-1.0-kvermette.svg (version 1.0) because that was the only one available. 2) I am not sure that the unscaled noise pattern works well at hiding the gradients steps for high resolutions (i.e. 3200x200). 3) You used some kind of lossy image compression? I can apply additional lossless compression and save extra ~5%.
At 3): The problem was that the images I uploaded were somewhy at 16bpc, but they should be in 8bpc — both layers (the wallpaper and the noise) are 8bpc. That's why the resulting size was too big. I'll reupload.
Ok, let me know when that's done, I'll push them.
I re-uploaded compressed 8bpc images to http://oserv.org/files/kde/wallpaper-deep/noise-outside/
These two issues are still present: > 1) I was using desktopWallpaper-deep-1.0-kvermette.svg (version 1.0) because that was the only one available. > 2) I am not sure that the unscaled noise pattern works well at hiding the gradients steps for high resolutions (i.e. 3200x200). If you are ok with that, fine =). Btw, Qt 5.6 might receive 16bpc support afaik, and that could be used to generate wallpapers with dithering, making noise not needed. That won't support filters natively, though (Qt supports SVG Tiny), but it might be possible to post-apply them.
Git commit ba113c5e5a6c7ef3f7732a279197b914a299d2f5 by Martin Klapetek. Committed on 24/04/2015 at 07:06. Pushed by mklapetek into branch 'Plasma/5.3'. Next Wallpaper iteration This smooths out what looked like jagged lines in the original images Thanks to Nikita Skovoroda for the modifications and generating these Committing with Ken's approval A +- -- wallpapers/Next/contents/images/1024x768.png M +- -- wallpapers/Next/contents/images/1280x1024.png M +- -- wallpapers/Next/contents/images/1280x800.png M +- -- wallpapers/Next/contents/images/1440x900.png M +- -- wallpapers/Next/contents/images/1600x1200.png M +- -- wallpapers/Next/contents/images/1638x1024.png M +- -- wallpapers/Next/contents/images/1680x1050.png M +- -- wallpapers/Next/contents/images/1920x1080.png M +- -- wallpapers/Next/contents/images/1920x1200.png M +- -- wallpapers/Next/contents/images/2560x1440.png M +- -- wallpapers/Next/contents/images/2560x1600.png M +- -- wallpapers/Next/contents/images/3200x1800.png A +- -- wallpapers/Next/contents/images/3200x2000.png M +- -- wallpapers/Next/contents/screenshot.png http://commits.kde.org/breeze/ba113c5e5a6c7ef3f7732a279197b914a299d2f5
Git commit a19b3c45986fc0a4c635df58d98dd7912ccc90a1 by Martin Klapetek. Committed on 10/07/2015 at 08:29. Pushed by mklapetek into branch 'master'. Next Wallpaper iteration This smooths out what looked like jagged lines in the original images Thanks to Nikita Skovoroda for the modifications and generating these Committing with Ken's approval A +- -- wallpapers/Next/contents/images/1024x768.png M +- -- wallpapers/Next/contents/images/1280x1024.png M +- -- wallpapers/Next/contents/images/1280x800.png M +- -- wallpapers/Next/contents/images/1440x900.png M +- -- wallpapers/Next/contents/images/1600x1200.png M +- -- wallpapers/Next/contents/images/1638x1024.png M +- -- wallpapers/Next/contents/images/1680x1050.png M +- -- wallpapers/Next/contents/images/1920x1080.png M +- -- wallpapers/Next/contents/images/1920x1200.png M +- -- wallpapers/Next/contents/images/2560x1440.png M +- -- wallpapers/Next/contents/images/2560x1600.png M +- -- wallpapers/Next/contents/images/3200x1800.png A +- -- wallpapers/Next/contents/images/3200x2000.png M +- -- wallpapers/Next/contents/screenshot.png http://commits.kde.org/breeze/a19b3c45986fc0a4c635df58d98dd7912ccc90a1
Hi all. 5.4 wallpapers have the same issues. Why didn't you use my render script? I uploaded the renders and the patch against the 'breeze' repo to http://oserv.org/files/kde/wallpaper-horizon/. I could push that to the breeze repo if anyone in charge approves me to do so. Also there is an updated version of the script (render.sh), but the only difference from the previous version is that I added some more comments at the top.
Reviewboard link (for 5.4): https://git.reviewboard.kde.org/r/124668/