Subscribe to this thread
Home - Cutting Edge / All posts - Manifold

10,391 post(s)
#13-Feb-23 14:18

SHA256: ca3fafc524b602a1e73c35dfb4d5e58837a74a943942be4e368048121dd63d43

SHA256: 4f5f8f2400ce6b2d8a7f99283b0b974cb133f0fabd8aba47efdc46bfdb7ab19e

SHA256: d639454d5f760352e7d394c6f3fe6b3f047fd2d40ed4e095b3058943044b1ea5


10,391 post(s)
#13-Feb-23 14:19


(Fix) Reading a TIFF file reads local offsets from tiepoints even if the file contains no pixel scales.

(Fix) The TileRenderXxx query functions used by Save as Image correctly restore RGB values for semi-transparent pixels. (This gets rid of multiple rendering issues over transparent background: semi-transparent layers looking darker than they should, light halos for drawing objects or labels having dark edges, etc.)

The Save as Image dialog shows the approximate size of the produced image in bytes as a reference. This helps gauge whether the produced image will be small enough to fit into an email / small enough to print / big enough for the desired level of detail / etc.

The Save as Image dialog allows specifying the render DPI. The default is 96 = the default screen DPI on Windows. The render DPI is used to scale styles for vector shapes and text. Rendering web images such as Bing retrieves image data as if the DPI was at most 96, to make vector shapes and text in retrieved data sized similarly to other layers.

The TileRenderXxx query functions include a new parameter to specify the render DPI. The render DPI must be greater than zero.

(Fix) Attempting to save an image using the Save as Image dialog in 'full view' mode on a drawing whose bounding box has zero width or height (mostly happens when the drawing contains a single point or a single horizontal or vertical line) no longer produces no tiles.

The Save as Image dialog in 'full view' mode sets the render area to include all layers that are turned on, instead of all layers whether they are turned on or off. This avoids producing images with empty space near borders.

The Save as Image dialog includes a new view named 'custom view'. The extent of the custom view can be edited by pressing the Edit button which opens the Edit View dialog. The Edit View dialog allows entering the xmin / xmax / ymin / ymax coordinates of the view as projected coordinates (in units used by the coordinate system, with local offsets removed). The Edit View dialog also allows setting the extent of the view to that of the current view / full view, or to the extent of a specific layer that contains some data (layers that contain no data are not listed in the dialog). By default, the extent of the custom view is set to that of the current view.

New query functions:

GeomCoordX / Y / Z - take a geom and a coordinate index, return the X / Y / Z value of the specified coordinate.

End of list.

733 post(s)
#13-Feb-23 16:29

GeomCoordX / Y / Z- take a geom and a coordinate index, return the X / Y / Z value of the specified coordinate.

Thank you!!

254 post(s)
#13-Feb-23 19:39

It's nice to see that thinks discussed in release topic, that give more flexibility, are added.

2 questions:

a) Suppose the user wants to specify the pixel size in real world units (such as meters). Is there a mathematic formula that connects zoom scale, DPI, and pixel size in meters, that we could use to make the image have the pixel size we want?

b)I render a bing image using the default 96 dpi and then 150dpi. The second image seems blurry. 300 dpi looks even more blurry. Is that the expected behaviour?


10,391 post(s)
#14-Feb-23 13:36

(a) We will allow specifying the pixel size in real-world units directly with no manual computations needed. However, if you want to try specifying the pixel size by setting absolute scale, the formula is: scale = sizeOnGround / sizeOnScreen = (taking 1 inch of screen) dpi * metersPerPixel * 100 / 2.54. With dpi of your screen likely being 96. So, if you want to zoom so that 1 pixel covers 10 meters, zoom to 1: (96*10*100/2.54) = 1:37795.

(b) Yes, if you render a Bing image at 150 DPI, it will appear significantly blurrier than you render it as 96 DPI. That's because it's a Bing image, the system fetches tiles from the level where the text in the image is sized more or less like normal text in other layers (neither crazy big like 30 points, nor crazy small like 3 points) = from the level that corresponds to 96 DPI, because that's how these images were rendered, and then every 96 pixels get scaled to 150 pixels (the image is stretched). Try a regular image, it will look much crispier.

Mike Pelletier

2,087 post(s)
#21-Feb-23 18:47

It would be nice if there was a more intuitive way to portray how (b) works. If the background is an aerial image it is especially confusing. Perhaps the solution to (a) will help.

733 post(s)
#14-Feb-23 04:49

Feature suggestion for discussion.

When georeferencing an image, I have to use trial and error (or read the manual) to figure out what needs to be selected in the box that has the default text "Current Window". Most times I get it wrong and I have start over.

What if there were two boxes instead of one? Both boxes will drop down and show the possibilities. See the mock-up I made below to show what I mean in the Register pane. This would make the selection clear and the user can start selecting control points either in the source or target component. This makes the process more intuitive and less prone to operator error.

In the current arrangement, it's not clear when to select a layer/component and whether it's the target or the source. Then when putting control points on the target, the "current window" shows the source. A bit confusing.

Mock-up of for the Register Pane


10,391 post(s)
#14-Feb-23 13:53

We could put a text label 'Register:' to the left of the single box that we have. Then we would have 'Register: (current window)' in the source window (which could be read as 'register current window to some other window') and 'Register: Component 1' in the target window (which could be read as 'register window named Component 1 to current window'). Would that be clearer? Then again, the tab is already named 'Register', so having 'Register:' appear as a label too might be a little redundant?

Or what if we changed '(current window)' to read '(register current window)'? Or '(register current window to another window)'?

We considered the design with two boxes before, it wasn't working great. Eg, in the source window, you get nothing from controlling the target window. And in the target window, it doesn't make sense to switch the target window away from yourself (because if you do, how can you even place the control points?). So all you get from the two boxes is seeing whether you are the source or the target. There should be a way to see this clearly with just one box. (But, of course, if needed, we can do radio buttons for 'I am a source' and 'I am a target' plus a combo box near 'I am a target' to pick the source.)

733 post(s)
#14-Feb-23 17:32

Hi Adam

In the current workflow, the source doesn't appear in the drop down list in the Register pane until I've put at least one control point on the source. Before that the drop down list just says <current window>. Then after I've put at least one point on the source and switch to my target, only then is the drop down list populated. However, it's confusing because the current window is the target. Perhaps <current window> doesn't convey neither an instruction nor information. Also, I can place control points on the target without choosing an image layer in the dropdown list. Then I have to start over because I overlooked selecting a source.

What if instead of <current window> the label read <source to georegister> and secondly, if the source is open then immediately allow the user select the source before even putting one control point on the source? That would clarify the workflow.


Open Source

Open target (or in reverse order, target first, source next)

Go to Register pane, select <source> (source would already appear in the drop down list

Start putting control points starting either in the target or the source


10,391 post(s)
#15-Feb-23 13:01

We'll think about it. Thanks!


7,233 post(s)
#14-Feb-23 19:21

Feature suggestion for discussion.

Georeferencing has nothing to do with build 179.2. Please keep comments in this thread directly relevant to the new build. Start a new thread if you want to discuss something unrelated to 179.2 - that way, people interested in georeferencing can see a thread relevant to their interest and participate.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.