From: Ed W <li...@wi...> - 2006-06-27 11:01:40
|
Anyone have any suggestions on how to structure an application that will center around a zoomable map of the whole world. The basic idea is to show weather patterns at various regions, but the user is to be able to zoom in quite tightly onto a specific area and then scroll around at that zoom level (think google maps, but for offline use and not so detailed and with a weather overlay) I'm going to ignore memory usage for the moment, but this is something of an issue when you are handling 40MB image files. Clearly the most desirable structure is to be able to tile the image in some way and then load in only the parts of the image which are relevant at that time (plus some overlap to help with scrolling. Also the overlay images for weather arrows could be quite large (but are also vector shapes basically). I could draw these on the current viewport, or pre-prepare them. They will also animate with time though so again this needs to be handled in memory efficient manner. Any suggestions on how to approach this using wxperl? Cheers Ed W |
From: Jouke V. <jo...@pv...> - 2006-06-27 11:15:41
|
<snip> > Any suggestions on how to approach this using wxperl? I can't tell you in detail how to do this, but my guess would be that wxWidget's image handling is too limited for real imaging applications. That's one of the reasons why I created Wx::Perl::Imagick (http://search.cpan.org/dist/Wx-Perl-Imagick/). You can use the same methods and parameters as you would for the normal Wx::Image class, but you can also call any method that Image::Magick supports (which gives you a huge toolset) HTH, Jouke |
From: Ed W <li...@wi...> - 2006-06-27 13:10:16
|
Jouke Visser wrote: > <snip> > >> Any suggestions on how to approach this using wxperl? >> > I can't tell you in detail how to do this, but my guess would be that > wxWidget's image handling is too limited for real imaging applications. > That's one of the reasons why I created Wx::Perl::Imagick > (http://search.cpan.org/dist/Wx-Perl-Imagick/). You can use the same > methods and parameters as you would for the normal Wx::Image class, but > you can also call any method that Image::Magick supports (which gives > you a huge toolset) > Oooh. I say! Now that looks really nice for all kinds of reasons! Thanks for creating this What's likely the best technique to handle an oversized image with a small viewport in Image:Magick? I'm guessing that I will have to use a static image and some slider bars to emulate the effect of a viewport on a much larger sub image? Are there any other useful features in Image::Magick which can help support the viewport kind of model? Cheers Ed W |
From: Jouke V. <jo...@pv...> - 2006-06-27 13:37:09
|
Hi Ed, > Oooh. I say! Now that looks really nice for all kinds of reasons! > Thanks for creating this My pleasure. If you encounter any bugs, let me know via CPAN's RT. > What's likely the best technique to handle an oversized image with a > small viewport in Image:Magick? I'm guessing that I will have to use a > static image and some slider bars to emulate the effect of a viewport on > a much larger sub image? Are there any other useful features in > Image::Magick which can help support the viewport kind of model? Well, you could take the original image, and crop (see the crop method in Image::Magick's documentation) pieces of it and put that in your window. When the user wants to scroll a whole page in any direction (north, east, south or west), you could crop again from the original, and if someone would just want to move in any direction for only a few pixels, maybe it's faster to crop that extra bit and add it to the copy you're already displaying. You can easily "montage" (see IM docs again) several pieces together... Since Wx::Perl::Imagick gives you more image manipulation possibilities, you could also choose to put a kind of compass on top of your image and let the user use that for navigation, or whatever you'd want. I usually get the best ideas for solving my Image manipulation issues by browsing through Image::Magick's documentation (a link to that can be found in the Wx::Perl::Imagick POD), and read what the various methods do. HTH, Jouke |
From: Andreas R. <ar...@rc...> - 2006-06-27 11:46:37
|
On Tuesday, 27. June 2006 13:01 Ed W wrote: > Anyone have any suggestions on how to structure an application that > will center around a zoomable map of the whole world. The basic idea > is to show weather patterns at various regions, but the user is to be > able to zoom in quite tightly onto a specific area and then scroll > around at that zoom level (think google maps, but for offline use and > not so detailed and with a weather overlay) > > I'm going to ignore memory usage for the moment, but this is > something of an issue when you are handling 40MB image files. > Clearly the most desirable structure is to be able to tile the image > in some way and then load in only the parts of the image which are > relevant at that time (plus some overlap to help with scrolling. > > Also the overlay images for weather arrows could be quite large (but > are also vector shapes basically). I could draw these on the current > viewport, or pre-prepare them. They will also animate with time > though so again this needs to be handled in memory efficient manner. > > Any suggestions on how to approach this using wxperl? > Have you looked at PDL, the "Perl Data Language"? PDL could be used for the behind-the-scenes data manipulation, and wxperl for the interface to the user. PDL is an excellent package for handling large amounts of vector- or array-based data - convenient and as fast as any numerics application. Check out the web page at http://pdl.perl.org/, or the success stories at http://pdl.perl.org/nifty/index_en.html Because PDL is perl as well as wxperl, it may be possible to connect both packages in a sensible way, without losing platform-independency. HTH, Andreas |
From: Ed W <li...@wi...> - 2006-06-27 13:06:44
|
> Have you looked at PDL, the "Perl Data Language"? PDL could be used for > the behind-the-scenes data manipulation, and wxperl for the interface > to the user. > I like the idea of PDL, but my primary platform will be windows (gotta follow the customers...). As far as I can see PDL appears not to be well supported on Win32? Any comments on how well it works in practice? I actually have another project that I would like to use PDL + PGPLOT/PLPLOT on - I had kind of assumed that this was not going to work well under win32? Ed W |