Jump to content

Search the Community

Showing results for tags 'processing'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • FAQ
    • Project Information
  • Digital Lab Notebook (DLN) tools
    • DLN:CaptureContext (DLNCC) tool
    • DLN:Inspector tool
  • Capturing Data
    • Dome Method
    • Highlight Method
    • Photogrammetry
  • Processing RTI Data
    • Processing RTI Data
  • Viewing and Analyzing RTI Results
    • All Viewers
    • Dissemination
    • RTI AHRC Project (UK)

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 4 results

  1. Hello everyone, I have an issue, let me explain a little about my project, I have high quality 3d historical scan data and have rendered about 50 images of the object, all with different sources of light. I have also done the same thing with a black sphere. My plan was do create a project using the black ball and then using that .lp file to import my object images. My issue is after i've converted my rendered images to DNG, then back into JPG, I am not able to import the picture. I was trying to select multiple images but it would not let me do that. I have also tried updating Java. Any Help? It would be very helpfull.
  2. kathrynpiquette

    Crop dimensions error

    Hi all, Has anyone encountered the following error when processing an HSH? "Problem with crop dimensions. Verify the crop area to continue." (see attached screen shot) The data fit just fine when I fit without cropping, but when trying again to process a cropped version, the same error came up. I also tried changing the cropped area, deselecting and re-selecting, but no luck. Any ideas what the problem might be? I have checked the usual suspects (spaces in file name, upper and lower case, umlauts, etc.). I am processing to and from an external hard drive due to the lack of space on my work computer and had just completed a successful HSH fit prior to this new data set that produced the error. Thanks for any pointers - Kathryn
  3. After creating a new project in RTI Builder and selecting the images to be processed, I received an "Error when opening the XML carrier" message when I pressed "next" to proceed to the screen to find the light positions. When the screen opens to select the area to use to identify the spheres, none of the project images appears in the top window, and I can't select the area for finding the spheres. I tried starting over to create a new project, and this time I didn't receive an error message, but still no images appear in the window when I get to the screen to highlight the spheres. However, when I closed the RTI Builder program and started over, I again got the "error when opening the XML carrier" message. Can you suggest a way to fix this error? Thanks!
  4. I recently captured over 60 Gb of images of a 36 x 50 inch 19th century landscape painting, which included both photogrammetry and over 40 RTIs in visible and two IR wavebands at resolutions ranging from about 350 to 2600 ppi. Some of the images in the RTI sequences are less than ideal, but still contain useable data, and I'm wondering whether it's better to exclude these images from the RTI processing sequence, or if I can include them with the knowledge that the processed RTI files would be slightly compromised in some areas. It's a tradeoff between using images that have relatively minor flaws to get a more complete range of light source directions in the final processed RTI files; cropping the entire set of images to eliminate discrete shadows from a few light source directions; or excluding the images that have relatively minor problems from the RTI sequence and thereby rejecting otherwise useable data. When capturing RTIs of a large surface at high resolution, it's unavoidable for some light directions to create distinct shadows from the reflecting spheres or the support, such as parts of the easel. These shadows generally affect only a small portion of the image, but cropping them out entirely would significantly reduce the area of the final RTI image, while most of the area of these images contain useful reflectance data for constructing the surface normals. Is it better to exclude these images from the RTI to avoid the shadows appearing in the RTI file, or to include them in the RTI sequence to have a more complete and accurate calculation of normal directions for the rest of the image? How fault-tolerant is the RTI Builder software to the inclusion of partly compromised images (e.g., those with discrete shadows) or to the exclusion of entire images that represent a subset of light directions? When working solo to capture the RTI image sets, it's a little more difficult to get perfect images every time--simultaneously holding the string, aiming the flash, and triggering the shutter can be a yoga challenge for some light directions. Also, when capturing macro images where the lens is close to the subject surface, there is less room for error in aiming the flash to avoid shadows. In some of the macro images, a very diffuse shadow might appear in a portion of the image that could be due to a part of the string or the pointing device on the flash falling into the path of the light source. Is it better to exclude these images entirely or can one include them for the useful data that they provide? When an RTI sequence is approaching 30 or fewer images, I'm reluctant to exclude an image that has such flaws but also contains much useable information. Can the RTI Builder software accurately calculate normals from the images for other light directions, if a portion of a single or few images in the sequence are partly affected by a diffuse shadow? Another related question is whether any pre-processing of individual images is possible to correct flaws. For example, if some images have a recurring darkened spot of unknown origin (possibly some dust on the sensor or the lens filter). Can a spot that is visible against a constant color field, such as the color checker card, be corrected in an image sequence without compromising the RTI quality?
×