> -----Alkuperäinen viesti----- > Lähettäjä: UMN MapServer Users List > [mailto:[EMAIL PROTECTED] Puolesta Norman Barker > Lähetetty: 14. joulukuuta 2005 11:16 > Vastaanottaja: [email protected] > Aihe: Re: [UMN_MAPSERVER-USERS] PHP Mapscript - Jpeg2000 > > -----Original Message----- > From: UMN MapServer Users List > [mailto:[EMAIL PROTECTED] > Behalf Of Yewondwossen Assefa > Sent: Wednesday, December 14, 2005 12:27 AM > To: [email protected] > Subject: Re: [UMN_MAPSERVER-USERS] PHP Mapscript - Jpeg2000 > > > Frank Warmerdam wrote: > > >On 12/13/05, Norman Barker <[EMAIL PROTECTED]> wrote: > > > > > >>Hi, > >> > >>Is there a binary version of PHP mapscript for windows that > anyone has available that includes support for Jpeg2000? It > seems that the version I have with MS4W doesn't include JP2 > suppport. Any help would be great. I can't build mapscript > on windows myself, since I don't have the microsoft compiler. > >> > >> > > > >Norman, > > > >I think that Assefa is building the MS4W binaries with ECW > >support, is that not right? If so, I think it should also include > >JPEG2000 support (with driver name JP2ECW). > > > >Best regards, > > > > > Yes the ECW support is built in the binaries distributed with ms4w. > > -- > > Thank you for your help, I will try to get this working. > Jpeg2000 offers lots of benefits, and seems to work really > well with MapServer (I was using FWTools on Windows before I > needed php support), the resolution pyramids in Jpeg2000 > avoid the need to use gdaladdo (correct me if I am wrong!), > and offer excellent compression as well! > > Many thanks, > > Norman
Hi Norman, I have just started playing with a test area covered by over hundred jpeg2000 images (lossless compression, 10000 by 10000 pixels each). My first impression is that they can be served quite well by MapServer through virtual raster layer (.vrt), or by using tileindex. When zoomed to full extent, meaning that MapServer has to go through all the 113 original jpeg2000 files one by one, I am getting a view of size a 600 by 600 pixels to web browser in 10-13 seconds. So yes, the internal structure of jpeg2000 works, and no additional overviews seem to be needed for individual jpeg2000 files if they have been created with reasonable options. However, in cases when a bunch of jpeg2000 files are to be used together, like in my case, I guess it would be a benefit to have overviews. As far as I know, you cannot create them for tileindexes, but for virtual raster layers it is possible. I made a try and built 32, 64, 128, and 256 overviews for my test vrs-set. I was thinking that small downsampling values are unnecessary with jpeg2000, because when zoomed close enough you need to read only couple of files and jpeg2000 driver should do the downsampling automaticly and well. I think my trial was giving support for this idea, successful. Having a look on the whole test area takes about two times longer without overviews than with them, and my area is not especially large. But there is one thing I am not happy with: creating overviews with gdaladdo is painfully slow. It took 20 hours with 3 GHz Pentium to build those 32 64 128 256 overviews for my virtual raster layer. I think that is awfully long time. But fortunately I am almost sure that this speed could be dramatically improved. I made another test with Kakadu executables, and taking out a 1:32 downsampled version of one image file took no more than 2 seconds. For those who know Kakadu, my command was "kdu_expand -reduce 5 -i test.jp2 -o reduce.ppm". Based on that I estimated that creating an usable overview file for my set should not take very much longer than [113 (images) x 2 (seconds per image) x 4 (downsampling levels)] = 900 seconds = 15 minutes. It would be quite an improvement, compared to 20 hours! Who will be the one to implement it? I cannot, I am no programmer. By the way, I am using MS4W 1.3.0, and I suppose it is using jpeg2000 files through JP2ECW (rw+): ERMapper JPEG2000 driver. Regards, Jukka Rahkonen
