Jump to content

enkidu

Members
  • Content Count

    10
  • Joined

  • Last visited

  • Days Won

    3

enkidu last won the day on September 26 2016

enkidu had the most liked content!

Community Reputation

7 Neutral

About enkidu

  • Rank
    Member

Contact Methods

  • Website URL
    http://www.tgraichen.de

Profile Information

  • Gender
    Not Telling
  1. Dear RTInauts, I've been conducting some accuracy test on the highlight detection method as well as the generall surface normal accuracy of RTIs using a controlled virtual environment in Blender. The tests are ongoing, and I will try emulating Lindsay MacDonald's method for more accurate normal map generation using Python at some point. In the meantime, please check out my MO and results here and feel free to comment below! All the best, Tom
  2. Hi guys, I think I've found a nice and cheap way to display most of the surface topography without commiting to one (or multiple) lighting positions in the RTIViewer: Basically, I combine my cropped assembly images to an albedo-map of my object (below, left), and combine it with the desaturated red and green channels of the normalmap (below, middle) extracted using the RTIViewer. The resulting image (below, right) displays almost all topography without self shadowing from raking light. The process is very easy and straight-forward, using only GIMP in addition to the RTIViewer. What do you guys think? Check out my website for more examples and detailed instructions! All the best, Tom
  3. Hello fellow RTI enthusiasts, Back in the day I was doing some rudimentary testing on this subkect, and posted about it on the CHI-forums. (I didn't want to resurect a 2 year old thread, so I'll just point to it here.) I have since done some follow up tests and would like to share them with you guys. Since the approach and results are already neatly formated on my website, i would like to invite you to check it out on this link and comment using this post. Best regards, Tom
  4. Quick math question: How does using multiple reflective spheres impact light position calculation accuracy? Is the use of two spheres advised only as a redundancy? Or does the HSH-Algorithm calculate a mean value of the respective light-positions? If so, wouldn't it be better to use 4 spheres (one in each corner of the image) to improve accuracy? All the best, Tom
  5. Hi, I'm trying to get a normalmap of my RTIs with the highest possible resolution. Is there a way of taking full resolution screenshots in the RTIViewer? I mean without having to manually stitch together detail shots? Best regards, Tom
  6. You are right, at this stage this doesn't improve the actual mesh's depth or normal data. You could use it to imrove your point cloud's normals though. Reliable low frequency depth and vertex-normal (dense cloud) is derived from the photogrammetric/SfM scene, and high frequency surface normal data with high relative accuracy is accquired using photometric stereo/RTI (as George pointed out above). When you reconstruct a mesh from a point cloud, each vertex coordinate in space as well as its normal are taken into consideration. What about replacing these low frequency normal values with the high frequency ones from the RTI-data, before actual surface reconstruction? At least in theory, this is how it could be done using meshlab: 1. Import the textured mesh (see above), 2. Import the dense cloud 3. Transfer texture color from mesh to vertex color of point cloud 4. convert each vertices' RGB-values to normal vector values and apply those to respective vertices 5. Apply surface reconstruction. This would require some coding for steps 3 and 4. You would also lose normal precision using the color coded normals, since you are workinging with integers from 0-255 for each axis, whereas the RTI works with float values from -1 to 1 (I'm not sure how many decimals though, but i thinks it´s more precise than Int 0-255). Also, I'm not sure how noticable the improvement would be. Tom
  7. hi all! back in april 2013 i've been doing some very rudimentary tests on that, but since i have little to no coding background, all i've managed to do is trick photoscan into using the extracted normal snapshot as a texture: My workflow is as follows: -capture RTI sequence, take one last photo under ambient lighting conditions ('A') -unscrewed camera from the copy stand/tripod, capture a photogrammetric sequence of the object -processed the PTM/RTI (no cropping!) and take a normalmap-snapshot ('B') -process photogrammetric sequence in Agisoft Photoscan (including 'A') up until mesh generation -close project, swap A and B (also rename 'B' to 'A') -reopen project, generate texture using single photo, choose 'A' I am aware that this is a very cheap solution, since the color-coded normal visualization is not as precise as the stored normals in the rti-file (i think). but it could be used to calculate detailed depth maps from the normals using the coarse depth information from the mesh, this way elliminating the accumulating error when trtying to convert normals to depth. what do you guys think?
  8. Dear Carla, thanks for your quick reply and sorry for my delayed response. I am on a windows 7 machine running java v.7.0.0.
  9. this may or may not be useful: my canon post processing software (Digital Photo Professional) converts into jpegs using capital extension letters. RTI-fitting doesn't seem to have a problem with capital extensions, but PTM fitting sure does (at lest for me), resulting in "unknown error" in the fitting stage... i have made it part of my workflow to batch rename the files` extensions....to do this shift+rightclick on the jpeg-exports folder and select "open command window here" and enter "ren *.JPG *.jpg" (w.o. quotation marks)...took me a while to figure this out, thought i`d share it, if this is common knowledge please ignore this reply best regards, tom
  10. dear fellow RTI enthusiasts, i ´ve had this dillema on my laptop and my desktop-pc, anyone else experiencing this problem? when i take a snapshot, my set parameters for the filters are ignored, and i get a snapshot with the default values of the respective filter instead..so far this only occurs when viewing PTMs, snapshots with custom values of RTIs work like a charm. thanks for any ideas! tom
×
×
  • Create New...