Bugs item #3077786, was opened at 2010-09-28 23:38
Message generated for change (Comment added) made by michaudm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3077786&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General / Other
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: michael michaud (michaudm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Image layer display

Initial Comment:
I loaded a jpg image of 500x500 pixels with Layer>Add an image layer
I have no referencing file
The bounding box displayed in image metadata is 0,-500, 500, 0
The image displayed in the view ranges between -0.5, -499.5 and 499.5, 0.5

Michaël

----------------------------------------------------------------------

>Comment By: michael michaud (michaudm)
Date: 2012-11-10 10:02

Message:
The problem was a bit more complex as there was an inconsistencies between
information in the tfw, the feature envelope.

----------------------------------------------------------------------

Comment By: Jukka Rahkonen (jratike80)
Date: 2012-09-06 10:00

Message:
Adding the test jpeg image without world file is effectively the same as
using the following world file

1.0
0.0
0.0
-1.0
0
0

It means: pixel size is one unit in both x and y direction, and the centre
point of the top-left pixel is at coordinates 0,0
Half-a-pixel shift makes the image extents to be -0.5, -499.5 and 499.5,
0.5
If we want image extents to begin allways from 0,0 OpenJUMP should behave
so that is internally using this world file as default

1.0
0.0
0.0
-1.0
0.5
-0.5

Now there is a need to decide whether to search where in the code the
default behaviour is handled and make the half unit shifts there, or let
OpenJUMP behave as is behaves and close the ticket.


----------------------------------------------------------------------

Comment By: michael michaud (michaudm)
Date: 2011-02-09 14:11

Message:
Just attached a simple lightweighted 500 x 500 jpg image for tests

----------------------------------------------------------------------

Comment By: michael michaud (michaudm)
Date: 2011-02-09 14:09

Message:
I made more tests :

1) Loading a 500 x 500 image without tfw with old framework (Layer > Add
Image) 
image envelope minx = -0.5, maxy = 0.5 (width=500, height=500)
2) Loading a 500 x 500 image without tfw with new framework (giving minx=0,
maxy=0 from UI)
image envelope minx = 0, maxy = 0 (width=500, height=500)
3) Loading a 500 x 500 image without tfw with new framework (no
coordinate)
image envelope = rectangular area filling the current view

After all there is nothing which can really be called a bug.
As soon as a worldfile is created, both loaders load it at the same correct
place.

However, I think the 3 methods should import the image without tfw at the
same place (I would say, at xmin=0 ymin=0, with size 500, 500)

Michaël

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2011-02-09 01:25

Message:
can you send me the data and please add some more details. I didnt get
maybe my fault

----------------------------------------------------------------------

Comment By: michael michaud (michaudm)
Date: 2010-10-02 09:05

Message:
I think that the problem is more with images having a associated world
file.
There is an issue with worldfiles because the upperleft coordinates written
in world files are the terrain coordinates of the center of the upperleft
pixel.

I think GeoTiffImage, GraphicImage and Raster image have all their way to
parse and to use world files. Some of them do not take the half-pixel
offset into account properly, but I could not find exaclty what is wrong
until now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3077786&group_id=118054

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jump-pilot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to