bugpyFormex - Bugs: bug #43990, Create contour lines from the...

 
 

bug #43990: Create contour lines from the OpenGL rendering

Submitter:  Benedict Verhegghe <bverheg>
Submitted:  Mon 12 Jan 2015 08:40:45 PM UTC
   
 
Category:  Rendering Severity:  1 - Wish
Item Group:  Feature request Status:  Ready For Test
Privacy:  Public Assigned to:  bverheg
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 18 Jan 2015 05:32:43 PM UTC, comment #5: 

0e8a6fc implements the Canvas.outline method, computing the outline of the current rendering, with the following methodology:
1a: using an offscreen rendering
1b: taking the luminance
2: using the current camera transforms to transform back to world

To do:

- add resolution scaling
- add bgcolor removal

Benedict Verhegghe <bverheg>
Group administrator
Sat 17 Jan 2015 07:33:21 PM UTC, comment #4: 

1a. It turns out we already use offscreen rendering when saving an image with another size than the displayed canvas. I will split off this functionality into a separate function that can be used for this and other purposes. I think the function will have options to return a QImage or a numpy array, an option to remove the alpha channel or not, and an option to replace a specified background color with black. The user can the save the result to a file if he wishes (we should probably create a separate function for that).

1b. I think the default will be luminance. We can probably add some other options: mean, or a list of 3/4 floats to weight the
RGB(A) channels. Thus mean would be equivalent with
[ 1/3., 1.3., 1/3., 0. ]

Benedict Verhegghe <bverheg>
Group administrator
Sat 17 Jan 2015 05:10:16 PM UTC, comment #3: 

We should probably split the first item in two:

1a. Where to get the pixel data: from an image file, from an offscreen rendering, from the current rendering.

1b. How to translate the pixel data (3/4D) to 1D data: in the IsoContour example I used the mean RGB value. Maybe we can define some standard useful conversions, like the luminance as defined in color.py. And provide something to replace the background color with an extreme value.

2. Scale the resulting contour (if you want it as geometry, not just drawn on the current rendering). The contour should indeed always be computed in the xy plane of the camera. So the user will decide in what global direction the view is.

- solution 2.1: Therefore we will have to scale the resulting contour with respect to the size of the scene in the camera xy directions. I think we have a directionalWidth method that could be used for this. Width alone should suffice for the scaling, as our camera always keeps an aspect ratio equal to one (I think). And if someday we introduce a non-unity aspect ratio, it will be stored in the camera and can then be used to adjust vertical scaling.
- solution 2.2: If we directly use the screen rendering buffer, or an offscreen buffer of the same size, we can use the camera functionality. If I remember well, the unProject() method, but that should be checked.

Benedict Verhegghe <bverheg>
Group administrator
Sat 17 Jan 2015 04:14:47 PM UTC, comment #2: 

Two remaining problems need to be resolved/decided:

1. How to get the proper pixel data:
I think this depends on the user needs. maybe an option to get a only the border of the object ( with flat and single color rendering) or specify a range of values or better the total number of isolines (the pixel data from the current OpenGL rendering, and change all the background pixels to and extreme value. )

2. How to scale the resulting contours back to world coordinates
again here I would let the user decide. we should get the contour on the view of the camera,
but on the other hand I suppose that in many post processing the user would like to have on a plane with normal oriented with the cartesian axis (let s say xy)

francesco <francio>
Group Member
Thu 15 Jan 2015 07:08:57 PM UTC, comment #1: 

In 1a2834b an accelerated isoline function was added. It creates contour lines through a 2D grid of values. It should now become easy to create contour lines from the OpenGL rendering.

Two remaining problems need to be resolved/decided:

1. How to get the proper pixel data:
- save the rendering in an image, and then use the technique from the IsoContour example,
- create an OpenGL rendering in an offscreen buffer, with flat and single color rendering,
- directly use the pixel data from the current OpenGL rendering, and change all the background pixels to and extreme value.

2. How to scale the resulting contours back to world coordinates
- use the technique Francesco implemented in vtk_itf's ViewContour, adapted for not working in xy plane
- use the camera transformation matrices/functions

Am I missing anything?

Open for discussion.

Benedict Verhegghe <bverheg>
Group administrator
Mon 12 Jan 2015 08:40:45 PM UTC, original submission:  

Note: this request was original posted by Gianluca as
https://savannah.nongnu.org/bugs/?43977#comment1
It was moved to a separate bug by the administrator, because it concerns another issue than the original post of the above bug.

 
Very nice feature. I was wandering if this could be done (and improved) also without vmtk:
- display an object in pyFormex
- get the pixels from the screen (e.g. save as image.png and read back the image.png in pyFormex). Assign prop 0 to pixels of background.
- getborderMesh() of the pixels without prop 0 (2D quad mesh) = line mesh of contour

1) The accuracy of the contour could be chosen by choosing the pixel resolution of the image.

2) An advantage of this method would be that if the object is colored by a field (e.g. a stress field from FEA) the contour line could inherit the colors of the pixels, generating a colored contour line. What do you guys think?

Benedict Verhegghe <bverheg>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by francio (Posted a comment)
  • -email is unavailable- added by bverheg (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-23 bverheg Open/ClosedOpen Closed
    2015-01-18 bverheg StatusIn Progress Ready For Test
    2015-01-15 bverheg StatusNone In Progress
        Assigned toNone bverheg

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code