| === rickspencer3-afk is now known as rickspencer3 | ||
| === GreySim_ is now known as GreySim | ||
| SiDi | MacSlow: hi | 08:32 |
|---|---|---|
| SiDi | I'm having blur notifications with jpg/png files with python notifications, while i just pass the path to the image and dont resize anything, any idea ? :/ | 08:34 |
| mpt | SiDi, how large is the original image? | 09:29 |
| SiDi | mpt: 240x240 | 09:30 |
| macvr | SiDi: anything larger than 48px doesnt display as crisp as the original | 09:30 |
| SiDi | macvr: its not much better at 48x48 :( | 09:31 |
| macvr | SiDi: i was getting blurs with 128px, i can't just imagine how a 240px would look ;p | 09:32 |
| SiDi | And album art is usually between 200x200 and 600x600. And i'm 100% sure i dont use resized pixbufs | 09:32 |
| macvr | if the original image is 48px , you *will* get good quality | 09:32 |
| macvr | SiDi: https://bugs.launchpad.net/notify-osd/+bug/360228 | 09:33 |
| macvr | see MacSlow's last comment | 09:34 |
| macvr | MacSlow: btw i didnt notice the second bug! that wasnt me :( | 09:34 |
| mpt | macvr, a 240*240 image should look much better than a 40*40 one (for example) | 09:44 |
| macvr | mpt: but when it scales down , the quality is poor , well atleast for me | 09:45 |
| SiDi | http://filebin.ca/ttttug/PythonBlurTest.tar.gz | 09:46 |
| SiDi | macvr: as you can see with these examples, the result is exactly the same with a 900 / 300 / 48 px image | 09:46 |
| SiDi | the only way to get it not blur is to make a sharp 48x48 pic on my own | 09:46 |
| macvr | SiDi: yes ^ , that is the only way | 09:47 |
| mpt | macvr, probably the thing that would most help would be a bug report containing (1) a sample image, (2) a screenshot of how Notify OSD displays it, and (3) a less-blurry resized version | 09:47 |
| mpt | hang on there | 09:47 |
| macvr | mpt: this is a known issue > https://bugs.launchpad.net/notify-osd/+bug/360228 | 09:47 |
| mpt | SiDi, if you can do a better job of resizing it than Notify OSD can, that's a bug in Notify OSD | 09:48 |
| macvr | see MacSlow last comment | 09:48 |
| SiDi | mpt: i think the resizing algo isnt strong enough | 09:48 |
| SiDi | gimp's one isnt terrible either, i explicitely resharpened the picture in gimp | 09:48 |
| mpt | SiDi, ok, so it would help most to report a bug with the three things I listed above | 09:48 |
| macvr | mpt: the problem is because notify-osd sets a fixed limit of 48px , while AFAIK , the previous daemon used a max 128px for images | 09:49 |
| mpt | SiDi, currently we're using what Gimp calls "Sinc (Lanczos3)" resizing | 09:50 |
| mpt | It would be cool if someone could make a table of example images (some photographic album art, some line drawings, some smaller than 48*48, etc) showing how different algorithms resize them to 48*48 | 09:51 |
| mpt | That would help us decide if we need to switch algorithms, or use one for small images and another for large ones, or something else. | 09:52 |
| SiDi | mpt: do you know about any other algorithms ? cause i dont :p | 09:52 |
| mpt | SiDi, sure, Gimp lists "Linear" and "Cubic" alongside Sinc | 09:53 |
| mpt | (Image > Scale Image) | 09:53 |
| SiDi | okey | 09:53 |
| SiDi | let me make some pictures then | 09:53 |
| mpt | cool, thanks | 09:53 |
| macvr | mpt: SiDi the problem is mostly only for album art from music players, so setting a limit of 128px exception for those app alone should fix this | 09:55 |
| mpt | macvr, you mean music players should be able to send notifications with bigger images than any other app? | 09:55 |
| macvr | yup | 09:55 |
| mpt | I don't think that would solve the problem, it would just shift it around | 09:56 |
| mpt | e.g. what would happen if a player sent this image <http://www.ilovethe80s.com/murrayhead_chess_1986.jpg>? | 09:56 |
| mpt | (album art from the Chess soundtrack) | 09:56 |
| mpt | Should Notify OSD resize it up to 128px? | 09:57 |
| SiDi | macvr: its a bad approach imo | 09:57 |
| macvr | mpt: SiDi: the previous daemon , from usage experience , Used to be able to display small images less than 128px as is , but if it was larger than 128 px it would scale down , Maybe MacSlow has more knoledge about this | 09:58 |
| macvr | knowledge^ | 09:58 |
| mpt | macvr, the version of notification-daemon in Ubuntu 8.10 had no limit on the size of images at all. | 09:58 |
| mpt | I DoSed myself by typing "notify-send -i Screenshot.png". :-) | 09:58 |
| mpt | because the bubble was larger than the screen and the close button was off-screen | 09:59 |
| macvr | mpt: ah i didnt know that , but a rule as i had mentioned would be a nice addition to notify-osd | 10:00 |
| macvr | maybe i didnt have very large album art ;p | 10:00 |
| mpt | macvr, I think if we get the scaling right, the attractiveness of consistent image size for all notification bubbles will be greater than the ugliness from any remaining blurriness. | 10:01 |
| mpt | But we need to fix applications to not send tiny images to Notify OSD, just like we fixed them to not ask for actions without checking. | 10:01 |
| macvr | mpt: that is the problem , scaled down image can *never* be clear at 48px , it needs to be larger | 10:02 |
| mpt | macvr, I can point you to Mac OS X as a counterexample | 10:02 |
| macvr | ;p | 10:02 |
| mpt | Nearly all the icons you see in recent Mac OS X screenshots are 512*512 originals scaled down to about 48*48. | 10:03 |
| mpt | And it's the OS doing the scaling. | 10:03 |
| macvr | mpt: i tested notify-osd with various sizes to create icons for breathe, it never looked good | 10:03 |
| mpt | So, there must be some way to do it. | 10:03 |
| * macvr needs to figure that out | 10:04 | |
| SiDi | macvr: svg with an original size bigger than 48px are very very likely scaled with another algorithm, specific to svg files, btw | 10:08 |
| SiDi | from my testing the best is to resize + resharpen if the image was bigger | 10:08 |
| SiDi | possibly sharpen's intensity depending on the original / 48px ratio | 10:08 |
| SiDi | mpt: macvr: http://img31.imageshack.us/img31/6017/resume.png | 10:40 |
| SiDi | Tell me for each picture which you think is best | 10:41 |
| macvr | SiDi: 3rd | 10:42 |
| macvr | SiDi: i guess you used the same rules for one column? | 10:42 |
| SiDi | not for the monkey | 10:43 |
| macvr | do the same as the top3 rows for the monkey also | 10:44 |
| SiDi | meh | 10:47 |
| mpt | SiDi, for the first three rows I'd choose 3, 1, 3 | 10:48 |
| mpt | For the last row I can barely tell any difference | 10:48 |
| SiDi | ok so, 3 is cubic | 10:49 |
| SiDi | 1 is no interpolation | 10:49 |
| SiDi | renders great with geometric forms but horribly with photos | 10:49 |
| SiDi | i'll add a cubic monkey | 10:49 |
| SiDi | all the pictures were originally 900x900 except monkey, 64x64 | 10:50 |
| macvr | SiDi: its cheating^ | 10:50 |
| macvr | monkey or other face of the same size should be used for good comparison | 10:51 |
| SiDi | mpt macvr http://img141.imageshack.us/img141/6017/resume.png now featuring a cubic monkey \o/ | 10:52 |
| SiDi | macvr: the goal is to test the algos if the picture is little, not only if it is big :P | 10:52 |
| SiDi | so apparently the cubic algorithm would give sharpen results | 10:53 |
| macvr | +1 | 10:53 |
| mpt | Except for the first column, they all look pretty good | 10:53 |
| mpt | What we're wanting is to avoid it looking *bad* | 10:53 |
| macvr | mpt look at the monkey in the 5th column! its horrible | 10:54 |
| mpt | in pathological cases e.g. if Notify OSD is trying to scale a 42*42 icon to 48*48 | 10:54 |
| macvr | too much contrast | 10:54 |
| mpt | Is that the Sinc/Lanczos3? | 10:54 |
| SiDi | the last column is lanczos + sharpen | 10:55 |
| SiDi | the 4th colomn for monkey is lanczos + smooth sharpen | 10:55 |
| SiDi | the 4th column for other pictures is lanczos | 10:55 |
| macvr | 2nd? | 10:55 |
| SiDi | http://paste.ubuntu.com/206852/ | 10:56 |
| macvr | i think cubic is best | 10:57 |
| mpt | So fish sharpen well but monkeys do not? :-) | 10:58 |
| SiDi | mpt: actually the fish was 900x900 and monkey 64x64 :) | 10:59 |
| SiDi | what i wanted to show here is that the sharpen's intensity should depend on how big the image was | 10:59 |
| SiDi | for a good result | 10:59 |
| SiDi | how big the image was -> how blur the resized one will be -> how much it should be sharpened | 10:59 |
| mpt | So how about an image that's only ~10% larger than the target size? | 11:00 |
| SiDi | 50x50 ? | 11:03 |
| mpt | e.g. 55*55 down to 48*48 | 11:04 |
| mpt | That's about the worst case, so it would be useful to tell which algorithms are best at avoiding horrible results | 11:04 |
| * SiDi just made a 64x64 one :( | 11:05 | |
| SiDi | bug 393797 | 11:05 |
| SiDi | https://bugs.launchpad.net/notify-osd/+bug/393797 (no ubottu x.x) | 11:05 |
| macvr | SiDi: the description is not clear ! make the table look like your paste>http://paste.ubuntu.com/206852/ | 11:10 |
| SiDi | macvr: happy ? | 11:15 |
| macvr | :) | 11:15 |
| mpt | SiDi, macvr: Ok, here's a hypothesis: The best approach is to use Sinc/Lanczos if the original image is smaller than the target size, and to use bicubic if the original image is larger than the target size. | 11:19 |
| macvr | mpt: out of curiosity , why Sinc/Lanczos for the small sizes? why not all use cubic? | 11:21 |
| mpt | macvr, compare the cubic vs. sinc on <http://www.all-in-one.ee/~dersch/interpolator/interpolator.html> for example | 11:25 |
| mpt | but feel free to make some more Notify-OSD-specific examples :-) | 11:25 |
| macvr | ah... :) | 11:28 |
| macvr | mpt: just a couple of hrs ago i deleted all the screenshots i had done for the icons!! :( | 11:29 |
| artir | I want to help with the 100 papercuts project, but I just know python :( | 12:51 |
| SiDi | artir find a papercut concerning a python app then :) | 12:55 |
| artir | maybe there is a list with those bugs, so I was asking for that | 12:56 |
| mpt | artir, Launchpad doesn't keep track of which languages a package is written in | 13:31 |
| * MacSlow -> lunch | 13:34 | |
| === MacSlow is now known as MacSlow|lunch | ||
| mpt | artir, but two bugs in packages I'm fairly sure are written in Python are bug 349336 and bug 377697 | 13:53 |
| artir | i'll take a look | 13:53 |
| artir | those are already taken | 13:54 |
| artir | well, the first one is no | 13:56 |
| artir | t | 13:56 |
| === MacSlow|lunch is now known as MacSlow | ||
| macvr | MacSlow: how do i exclude notify bubbles from compiz animations? they are using the tootips close animation. | 14:46 |
| macvr | ah ! just realized i had set notifications to use compiz same as tooltips! | 14:50 |
| * macvr bangs head on the wall! | 14:50 | |
| * SiDi helps macvr to bang his head on the wall. | 14:57 | |
| * macvr grateful | 14:58 | |
| MacSlow | siDi the full resolution fish image example is 2000x2000 not 900x900 as you state in the test-script's desription text | 15:05 |
| MacSlow | SiDi I'm redoing that comparision table with the current upstream version of notify-osd | 15:05 |
| SiDi | MacSlow: okies | 15:07 |
| SiDi | MacSlow: yes sorry, my mistake | 15:07 |
| SiDi | MacSlow: mind having a look at this https://bugs.launchpad.net/notify-osd/+bug/382094 ? Just let me know if its feasible, and i'll do the appropriate changes if needed | 15:07 |
| macvr | SiDi: your test python uses your home folder! | 15:09 |
| SiDi | macvr: yes its why the one in the bug report uses shell scripts instead \o/ | 15:09 |
| macvr | oh... then i need to download that one! | 15:10 |
| === rgreening_ is now known as rgreening | ||
| === GreySim_ is now known as GreySim | ||
| jdeslip | I am trying to get a new blueprint accepted into the gnome-do project. Can anyone here have a look and give me some feedback (or leave feedback on the whiteboard) https://blueprints.launchpad.net/do/+spec/current-workspace | 20:43 |
| === GreySim is now known as AwaySim | ||
| === jono_ is now known as jono | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
