[matplotlib-devel] matplotlib book -- free copy for developers
Packt is offering a free copy of Sandro Tosi's new book "Matplotlib for Python Developers" to matplotlib developers, and has generously offered to donate 2% of book sales to the mpl project. If you are an svn committer and would like a copy of the book, send me your name and shipping address offlist and I will pass it on to the publisher. http://www.amazon.com/Matplotlib-Python-Developers-Sandro-Tosi/dp/1847197906/ref=sr_1_1?ie=UTF8&s=books&qid=1260986058&sr=8-1 JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
Jae-Joon Lee writes: > While extending this to other backend such as pdf and svg should be > straight forward, I want to hear how others think about the overall > approach, e.g., api change and such. The current approach is to > minimize change in backends. While the backend API is being changed, would it be similarly easy to support arbitrary affine transformations? It would make the API more symmetric, since many other draw_* methods take an affine transformation, and I guess at least the PS and PDF backends could easily support this. > * If there are multiple images (and the ps backend is used), the > images are resampled as they are compositted into a single image. The Figure.draw method already has some logic for not compositing multiple images: if len(self.images)<=1 or not_composite or \ not allequal([im.origin for im in self.images]): I suppose this could also include a check for whether all images have the same transformation. Anyway, I'm not quite sure what the win from compositing is for a vector backend. > * The current solution forces not to resample whenever > interpolation=="nearest", I think this is generally good behavior. > However, on the highly extreme case of very high resolution of image > (e.g., image dpi > 1000 ?), it might be better if the image is > resampled (i.e., downsampled). This sounds like it would make sense for naive users but could get very annoying for somebody who really does want high resolution (e.g. for zooming in in a viewer application). -- Jouni K. Seppänen http://www.iki.fi/jks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen wrote: > Jae-Joon Lee writes: > >> While extending this to other backend such as pdf and svg should be >> straight forward, I want to hear how others think about the overall >> approach, e.g., api change and such. The current approach is to >> minimize change in backends. > > While the backend API is being changed, would it be similarly easy to > support arbitrary affine transformations? It would make the API more > symmetric, since many other draw_* methods take an affine > transformation, and I guess at least the PS and PDF backends could > easily support this. > Yes, supporting arbitrary affine transform would not be difficult. On the other hand, I'm not sure if that feature is practically useful, assuming that other rasterizing backend won't implement it. I'll think about it. >> * If there are multiple images (and the ps backend is used), the >> images are resampled as they are compositted into a single image. > > The Figure.draw method already has some logic for not compositing > multiple images: > > if len(self.images)<=1 or not_composite or \ > not allequal([im.origin for im in self.images]): > > I suppose this could also include a check for whether all images have > the same transformation. Anyway, I'm not quite sure what the win from > compositing is for a vector backend. One benefit of compositing would be an indirect support of alpha compositing in the ps backend, although it is not clear this is practically useful. Checking whether compositing is required seems not very straight forward to me. We may try to sort out images that needs to be composited and those does not. Anyhow, I am personally happy with the current behavior so I may leave it as is, and let others take it if they want. > >> * The current solution forces not to resample whenever >> interpolation=="nearest", I think this is generally good behavior. >> However, on the highly extreme case of very high resolution of image >> (e.g., image dpi > 1000 ?), it might be better if the image is >> resampled (i.e., downsampled). > > This sounds like it would make sense for naive users but could get very > annoying for somebody who really does want high resolution (e.g. for > zooming in in a viewer application). What I meant was the case when the dpi of the image painted on the canvas is much higher than the dpi of the canvas itself (I mean the dpi of the typical postscript output device). Anyhow, I guess the current behavior is good enough, and it seems more reasonable to let users do the down-sampling explicitly if they want. Regards, -JJ > > -- > Jouni K. Seppänen > http://www.iki.fi/jks > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
Jae-Joon Lee wrote: > On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen wrote: > >> While the backend API is being changed, would it be similarly easy to >> support arbitrary affine transformations? It would make the API more >> symmetric, since many other draw_* methods take an affine >> transformation, and I guess at least the PS and PDF backends could >> easily support this. >> >> > > Yes, supporting arbitrary affine transform would not be difficult. On > the other hand, I'm not sure if that feature is practically useful, > assuming that other rasterizing backend won't implement it. I'll think > about it. I second the notion that affine transformations on images would be useful. There are a lot of things one can do with this, such as make pseudo-perspective projections of texture-mapped rectangles. This is exactly one of the things that I routinely do in Inkscape. I'm reasonably sure Cairo supports arbitrary affine transformations when drawing image data -- I don't know about Agg. -Andrew -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
