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