[08:32] <SiDi> MacSlow: hi
[08:34] <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 ? :/
[09:29] <mpt> SiDi, how large is the original image?
[09:30] <SiDi> mpt: 240x240
[09:30] <macvr> SiDi: anything larger than 48px doesnt display as crisp as the original
[09:31] <SiDi> macvr: its not much better at 48x48 :(
[09:32] <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:33] <macvr> SiDi: https://bugs.launchpad.net/notify-osd/+bug/360228
[09:34] <macvr> see MacSlow's last comment
[09:34] <macvr> MacSlow: btw i didnt notice the second bug! that wasnt me :(
[09:44] <mpt> macvr, a 240*240 image should look much better than a 40*40 one (for example)
[09:45] <macvr> mpt: but when it scales down , the quality is poor , well atleast for me 
[09:46] <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:47] <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:48] <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:49] <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:50] <mpt> SiDi, currently we're using what Gimp calls "Sinc (Lanczos3)" resizing
[09:51] <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:52] <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:53] <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:55] <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:56] <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:57] <mpt> Should Notify OSD resize it up to 128px?
[09:57] <SiDi> macvr: its a bad approach imo
[09:58] <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:59] <mpt> because the bubble was larger than the screen and the close button was off-screen
[10:00] <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:01] <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:02] <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:03] <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:04]  * macvr needs to figure that out
[10:08] <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:40] <SiDi> mpt: macvr: http://img31.imageshack.us/img31/6017/resume.png
[10:41] <SiDi> Tell me for each picture which you think is best
[10:42] <macvr> SiDi: 3rd
[10:42] <macvr> SiDi: i guess you used the same rules for one column?
[10:43] <SiDi> not for the monkey
[10:44] <macvr> do the same as the top3 rows for the monkey also
[10:47] <SiDi> meh
[10:48] <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:49] <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:50] <SiDi> all the pictures were originally 900x900 except monkey, 64x64
[10:50] <macvr> SiDi: its cheating^
[10:51] <macvr> monkey or other face of the same size should be used for good comparison
[10:52] <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:53] <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:54] <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:55] <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:56] <SiDi> http://paste.ubuntu.com/206852/
[10:57] <macvr> i think cubic is best
[10:58] <mpt> So fish sharpen well but monkeys do not? :-)
[10:59] <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
[11:00] <mpt> So how about an image that's only ~10% larger than the target size?
[11:03] <SiDi> 50x50 ?
[11:04] <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:05]  * 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:10] <macvr> SiDi: the description is not clear ! make the table look like your paste>http://paste.ubuntu.com/206852/
[11:15] <SiDi> macvr: happy ?
[11:15] <macvr> :)
[11:19] <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:21] <macvr> mpt: out of curiosity , why Sinc/Lanczos for the small sizes? why not all use cubic?
[11:25] <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:28] <macvr> ah... :)
[11:29] <macvr> mpt: just a couple of hrs ago i deleted all the screenshots i had done for the icons!! :(
[12:51] <artir> I want to help with the 100 papercuts project, but I just know python :(
[12:55] <SiDi> artir find a papercut concerning a python app then :)
[12:56] <artir> maybe there is a list with those bugs, so I was asking for that
[13:31] <mpt> artir, Launchpad doesn't keep track of which languages a package is written in
[13:34]  * MacSlow -> lunch
[13:53] <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:54] <artir> those are already taken
[13:56] <artir> well, the first one is no
[13:56] <artir> t
[14:46] <macvr> MacSlow: how do i exclude notify bubbles from compiz animations? they are using the tootips close animation.
[14:50] <macvr> 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] <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:07] <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:09] <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:10] <macvr> oh... then i need to download that one!
[20:43] <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