Menu
▾
▴
jump-pilot-devel
|
From: Stefan S. <ss...@ge...> - 2009-02-23 03:45:42
|
Hei, I just added the possibility to loaded images with the classes from Pirols/Jan Ruzicka's using the new dialog (look for option Add Sextante Raster Image). This was done to be able to use the raster analysis functions from Sextante in future. While testing with an image that was derived from vector data (using OJ) and loading the images with this new one and the old build-in loader (done by Jon) I realized that the Pirol Image loader introduces an offset. Not sure why this is, since it only "reads" the reference info from worldfile - but there is clearly an offset of about 1-2 pixels between both loaders. I assume that the build-in version is correct, since the edges are better overlapping with the vector data. Any comments/suggestions or further tests with other data? (I'm a bit tired now - to figure out what happens. So this email is rather a warning for people that digitize based on images.) cheers, stefan |
|
From: Sunburned S. <sun...@gm...> - 2009-02-24 15:23:31
|
Stefan, I'm not sure why you would be getting a 1 or 2 pixel offset. I'm wondering when it would be worthwhile to tackle comprehensive support for rasters in OpenJUMP. It seems like we are always trying to get some raster plug-in form a third party to work well in OJ. :] Just thinking out loud... SS On Sun, Feb 22, 2009 at 7:45 PM, Stefan Steiniger <ss...@ge...> wrote: > Hei, > > I just added the possibility to loaded images with the classes from > Pirols/Jan Ruzicka's using the new dialog (look for option Add Sextante > Raster Image). This was done to be able to use the raster analysis > functions from Sextante in future. > > While testing with an image that was derived from vector data (using OJ) > and loading the images with this new one and the old build-in loader > (done by Jon) I realized that the Pirol Image loader introduces an offset. > Not sure why this is, since it only "reads" the reference info from > worldfile - but there is clearly an offset of about 1-2 pixels between > both loaders. I assume that the build-in version is correct, since the > edges are better overlapping with the vector data. > > Any comments/suggestions or further tests with other data? > (I'm a bit tired now - to figure out what happens. So this email is > rather a warning for people that digitize based on images.) > > cheers, > stefan > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > |
|
From: Rahkonen J. <Juk...@mm...> - 2009-02-24 18:46:21
|
Hi, I made a quick test with one topographic map in png format. I am not sure if I saw offset, but sure images look a bit different. In this case the native system seems to make some antialiasing while Add-Sextante-Raster-Image doesn't. I will do some further tests later. -Jukka- -----Alkuperäinen viesti----- Lähettäjä: Sunburned Surveyor [mailto:sun...@gm...] Lähetetty: ti 24.2.2009 17:23 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] image data and vector data (pirol image loader bug?) Stefan, I'm not sure why you would be getting a 1 or 2 pixel offset. I'm wondering when it would be worthwhile to tackle comprehensive support for rasters in OpenJUMP. It seems like we are always trying to get some raster plug-in form a third party to work well in OJ. :] Just thinking out loud... SS On Sun, Feb 22, 2009 at 7:45 PM, Stefan Steiniger <ss...@ge...> wrote: > Hei, > > I just added the possibility to loaded images with the classes from > Pirols/Jan Ruzicka's using the new dialog (look for option Add Sextante > Raster Image). This was done to be able to use the raster analysis > functions from Sextante in future. > > While testing with an image that was derived from vector data (using OJ) > and loading the images with this new one and the old build-in loader > (done by Jon) I realized that the Pirol Image loader introduces an offset. > Not sure why this is, since it only "reads" the reference info from > worldfile - but there is clearly an offset of about 1-2 pixels between > both loaders. I assume that the build-in version is correct, since the > edges are better overlapping with the vector data. > > Any comments/suggestions or further tests with other data? > (I'm a bit tired now - to figure out what happens. So this email is > rather a warning for people that digitize based on images.) > > cheers, > stefan > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Jump-pilot-devel mailing list Jum...@li... https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel |
|
From: Stefan S. <ss...@ge...> - 2009-02-24 19:37:45
|
@Jukka, thank you for testing. I also noticed the antialiasing effect. I discoverd the pixel shift by saving a vector graphics (with OpenJUMP) as image, and then did load this images with both options. Would be good to hear if you don't see a shift with "real" image data (if that would be true, then it may be something that relates to image scaling and rounding errors?). @Sunburned: Well, you are right and wrong. The first image support came with JUMP 1.2 and I included it for compatibility. It uses JAI. The second image support, added the last days, comes from Pirol since this implementation (based on JAI too) is accessible to do raster algebra operations. I implemented it to allow a direct connection with Sextante, which provides a lot of raster analysis functions. Hence, I am not going to include any raster analysis functionality by now, since it is provided by Sextante, but only added the necessary visualisation and navigation options (i.e. the pirol image layer context menu). However, I did this also since I deem some basic raster analysis functions provided by Sextante necessary for every Desktop GIS - when looking on what people get taught at the university in geography, (landscape) ecology, environmental sciences and so on... I know, for a surveyor vector data is the major data type - but these disciplines are keen on raster data (probably because they do not have the archives yet, and lots of the information is pulled from some sort of aerial images - also involving infrared and other thermal information = fuzzy boundaryobjects) Hope you understand these both points... stefan Rahkonen Jukka schrieb: > Hi, > > I made a quick test with one topographic map in png format. I am not sure if I saw offset, but sure images look a bit different. In this case the native system seems to make some antialiasing while Add-Sextante-Raster-Image doesn't. I will do some further tests later. > > -Jukka- > > > -----Alkuperäinen viesti----- > Lähettäjä: Sunburned Surveyor [mailto:sun...@gm...] > Lähetetty: ti 24.2.2009 17:23 > Vastaanottaja: OpenJump develop and use > Aihe: Re: [JPP-Devel] image data and vector data (pirol image loader bug?) > > Stefan, > > I'm not sure why you would be getting a 1 or 2 pixel offset. I'm > wondering when it would be worthwhile to tackle comprehensive support > for rasters in OpenJUMP. It seems like we are always trying to get > some raster plug-in form a third party to work well in OJ. :] > > Just thinking out loud... > > SS > > On Sun, Feb 22, 2009 at 7:45 PM, Stefan Steiniger <ss...@ge...> wrote: >> Hei, >> >> I just added the possibility to loaded images with the classes from >> Pirols/Jan Ruzicka's using the new dialog (look for option Add Sextante >> Raster Image). This was done to be able to use the raster analysis >> functions from Sextante in future. >> >> While testing with an image that was derived from vector data (using OJ) >> and loading the images with this new one and the old build-in loader >> (done by Jon) I realized that the Pirol Image loader introduces an offset. >> Not sure why this is, since it only "reads" the reference info from >> worldfile - but there is clearly an offset of about 1-2 pixels between >> both loaders. I assume that the build-in version is correct, since the >> edges are better overlapping with the vector data. >> >> Any comments/suggestions or further tests with other data? >> (I'm a bit tired now - to figure out what happens. So this email is >> rather a warning for people that digitize based on images.) >> >> cheers, >> stefan >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jum...@li... >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > |
|
From: Sunburned S. <sun...@gm...> - 2009-02-24 20:06:53
|
Sure thing. I just know the image support from JUMP 1.2 caused me some problems. I haven't tired the Pirol stuff just yet. SS On Tue, Feb 24, 2009 at 11:37 AM, Stefan Steiniger <ss...@ge...> wrote: > @Jukka, thank you for testing. I also noticed the antialiasing effect. > I discoverd the pixel shift by saving a vector graphics (with OpenJUMP) > as image, and then did load this images with both options. Would be good > to hear if you don't see a shift with "real" image data (if that would > be true, then it may be something that relates to image scaling and > rounding errors?). > > @Sunburned: > Well, you are right and wrong. The first image support came with JUMP > 1.2 and I included it for compatibility. It uses JAI. The second image > support, added the last days, comes from Pirol since this implementation > (based on JAI too) is accessible to do raster algebra operations. I > implemented it to allow a direct connection with Sextante, which > provides a lot of raster analysis functions. Hence, I am not going to > include any raster analysis functionality by now, since it is provided > by Sextante, but only added the necessary visualisation and navigation > options (i.e. the pirol image layer context menu). However, I did this > also since I deem some basic raster analysis functions provided by > Sextante necessary for every Desktop GIS - when looking on what people > get taught at the university in geography, (landscape) ecology, > environmental sciences and so on... I know, for a surveyor vector data > is the major data type - but these disciplines are keen on raster data > (probably because they do not have the archives yet, and lots of the > information is pulled from some sort of aerial images - also involving > infrared and other thermal information = fuzzy boundaryobjects) > Hope you understand these both points... > > stefan > > Rahkonen Jukka schrieb: >> Hi, >> >> I made a quick test with one topographic map in png format. I am not sure if I saw offset, but sure images look a bit different. In this case the native system seems to make some antialiasing while Add-Sextante-Raster-Image doesn't. I will do some further tests later. >> >> -Jukka- >> >> >> -----Alkuperäinen viesti----- >> Lähettäjä: Sunburned Surveyor [mailto:sun...@gm...] >> Lähetetty: ti 24.2.2009 17:23 >> Vastaanottaja: OpenJump develop and use >> Aihe: Re: [JPP-Devel] image data and vector data (pirol image loader bug?) >> >> Stefan, >> >> I'm not sure why you would be getting a 1 or 2 pixel offset. I'm >> wondering when it would be worthwhile to tackle comprehensive support >> for rasters in OpenJUMP. It seems like we are always trying to get >> some raster plug-in form a third party to work well in OJ. :] >> >> Just thinking out loud... >> >> SS >> >> On Sun, Feb 22, 2009 at 7:45 PM, Stefan Steiniger <ss...@ge...> wrote: >>> Hei, >>> >>> I just added the possibility to loaded images with the classes from >>> Pirols/Jan Ruzicka's using the new dialog (look for option Add Sextante >>> Raster Image). This was done to be able to use the raster analysis >>> functions from Sextante in future. >>> >>> While testing with an image that was derived from vector data (using OJ) >>> and loading the images with this new one and the old build-in loader >>> (done by Jon) I realized that the Pirol Image loader introduces an offset. >>> Not sure why this is, since it only "reads" the reference info from >>> worldfile - but there is clearly an offset of about 1-2 pixels between >>> both loaders. I assume that the build-in version is correct, since the >>> edges are better overlapping with the vector data. >>> >>> Any comments/suggestions or further tests with other data? >>> (I'm a bit tired now - to figure out what happens. So this email is >>> rather a warning for people that digitize based on images.) >>> >>> cheers, >>> stefan >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jum...@li... >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jum...@li... >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jum...@li... >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > |
|
From: Rahkonen J. <Juk...@mm...> - 2009-02-25 10:34:56
|
Hi, I made a few more tests and here are my bit uncertain results: 1) OpenJUMP "Save to image" is creating a correct world file and maps created this way have correct georeferencing. 2) Save to image is creating .pgw world file for png images which is the original ESRI way and correct in that sense. Funny, but OpenJUMP itself can't utilile .pgw world files with the native (or Vivid?) image reader but they need to be renamed as .tfw. This should be corrected either by changing image export so that it creates both .tfw and .pgw named world files, or by making Vivid image reader to accept also .pgw world files. I did not check what is the situation with jpeg images and .jgw world files. 3) Native image reader shows images a bit softened but the orientation of the opened images is probably correct. I did see an quarter pixel offset in one test but no offset in another. Some other viewers like OpenEV are softering the image in a similar way and I think it is not a bug. Obviously some programmers like it more softened and some as sharp. 4) I am pretty sure that Add-Sextante-Raster-Image does not locate images correctly. It seems to introduce an offset of exactly one image pixel both to the right and towards the bottom. -Jukka Rahkonen- > Stefan Steiniger wrote: > > @Jukka, thank you for testing. I also noticed the antialiasing effect. > I discoverd the pixel shift by saving a vector graphics (with > OpenJUMP) as image, and then did load this images with both > options. Would be good to hear if you don't see a shift with > "real" image data (if that would be true, then it may be > something that relates to image scaling and rounding errors?). > > |
|
From: Stefan S. <ss...@ge...> - 2009-02-25 18:12:50
|
Hei Jukka, thank you for the analysis. This helps to know where to resolve the issue. stefan Rahkonen Jukka wrote: > Hi, > > I made a few more tests and here are my bit uncertain results: > > 1) OpenJUMP "Save to image" is creating a correct world file and maps > created this way have correct georeferencing. > 2) Save to image is creating .pgw world file for png images which is the > original ESRI way and correct in that sense. Funny, but OpenJUMP itself > can't utilile .pgw world files with the native (or Vivid?) image reader > but they need to be renamed as .tfw. This should be corrected either by > changing image export so that it creates both .tfw and .pgw named world > files, or by making Vivid image reader to accept also .pgw world files. > I did not check what is the situation with jpeg images and .jgw world > files. > 3) Native image reader shows images a bit softened but the orientation > of the opened images is probably correct. I did see an quarter pixel > offset in one test but no offset in another. Some other viewers like > OpenEV are softering the image in a similar way and I think it is not a > bug. Obviously some programmers like it more softened and some as sharp. > 4) I am pretty sure that Add-Sextante-Raster-Image does not locate > images correctly. It seems to introduce an offset of exactly one image > pixel both to the right and towards the bottom. > > -Jukka Rahkonen- > >> Stefan Steiniger wrote: >> >> @Jukka, thank you for testing. I also noticed the antialiasing effect. >> I discoverd the pixel shift by saving a vector graphics (with >> OpenJUMP) as image, and then did load this images with both >> options. Would be good to hear if you don't see a shift with >> "real" image data (if that would be true, then it may be >> something that relates to image scaling and rounding errors?). >> >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jump-pilot-devel mailing list > Jum...@li... > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > |
Thanks for helping keep SourceForge clean.
X