Dave Martin

Re: and and I haven't evaluated this effect using Kintsugi, but whilst fully agree with Carla that disabling scale-containing images would mean as you say that they wouldn't be 'seen' by Kintsugi, they will however still have an effect with potentially introducing reflected illumination in other non-disabled images. I wonder if, in addition to disabling images as Carla suggested, once sufficient frames have been captured with the scales, maybe the scales could be carefully covered with a suitably optically-dead / black material to prevent (or significantly attenuate) any spurious extra light reflected from the scales in the images to be used by Kintsugi? Dave

Rich, not directly answering your Kintsugi 3D question, but if the files aren't 'massively' too big, there may be a short-term workaround. I don't know if it is still the case, but it used to be that the limit on Sketchfab was actually on the physical upload file size - and whilst you can upload the model files as-generated, Sketchfab used to also accept them as a 'zip' archive, which compression could help if the upload was marginally over (but not if it was orders of magnitude too big!). Dave

Michael, Although the specific article links are broken, I've just had a quick look and there is still some info in Marcin's posts on LinkedIn https://www.linkedin.com/in/marcin-klebowski/recent-activity/all/ Dave

Ian, that's brilliant, thanks for sharing.

As you suspected, you definitely don't want to stitch images before processing. One thread I've found is: https://forums.culturalheritageimaging.org/topic/542-stitching-together-multiple-rtis/ I seem to recall a discussion (but can't find the thread right now) on merging RTIs of columns, but can't spot that thread right now. As well as the long-standing RTI generator, there is the new 'Relight Lab' under development, would suggest you enquire there (sub-forum here as well). Dave

Hi Annalisa, first few quick thoughts. GCP targets can be coded or un-coded; I guess from your question you're thinking about un-coded. First thing I would suggest is that you need to work from your proposed flight(s) and know the GSD and the accuracy you aspire to, that will help guide the size of target you plan to lay. I don't know what background or substrate you plan to lay your targets on, but from the air I would be concerned that the red carpet might not be that distinct? You mention using CDs - whilst the playing surface of a CD can 'blink' when, say, the sun strikes it, at other times they can be quite dark from other directions; the un-printed top white surface of a printable CD/DVD is though visible against a dark background. A very significant proportion of targets used for UAS/drone aerial photogrammetry use black and white for maximum contrast, and the chequer board pattern of two quarters white and two quarters black, with the reference point at the central intersection - that type of target is distinctive and also draws the eye in when working with them on-screen. (If you were using coded targets, then that centre can be found automatically to pretty good accuracy). If you are wanting to use carpet as your target material, could I suggest investing in cans of black and white paint and a roll of masking tape? In terms of logistics, you also need to remember that as well as a suitably-distributed set of GCPs, you also need a similar number of check points in your area that won't be used to constrain the resultant model, but will be used to assess the accuracy of the survey/model. As this is an issue wider than (just) cultural heritage, I might also suggest reading/searching/joining groups on UAS/drone aerial photogrammetry and photogrammetry more generally? Three that I could suggest on FaceBook are: Drone Photogrammetry Drone mapping, 3D modelling and GIS Agisoft Metashape (not sure if you're using Metashape, but target info will transcend software used) (disclosure: I'm admin/moderator for those groups) Dave

Thanks René, let us know how you get on - ideally some side-by-side screen grabs of the same area to show the impact. That would be a great service to the community too! cheers Dave

René, every use case will be different, but I would suggest it may not be ideal to have illumination so low, especially when using the highlight method. The software uses the spot of light on the surface of your reflective sphere to work out the exact position of the light. As the light gets lower, the spot becomes more and more on the increasingly vertical equator of the sphere. Geometrically, that is OK for azimuth but it becomes increasing inaccurate for elevation. So, I guess it won't 'break' things but the edge face results won't be as accurate as if you had stopped at the recommended 15 degrees lower limit, and having both 15 degree and 7.5 degree might be worse than just 15 degree - think of it as 'blurring' due to inclusion of inaccurate data. If you were using the dome method, with precisely known light positions (from measurement, not from a highlight run), then it might be better. Dave EDIT: I think that the only way you can tell if there is an improvement, or no better, or worse, would be set of tests on an artefact with low, distinctive, clear relief - Shoot it with conventional set from 65 degrees down to your 7.5 degrees and make two projects - process one with photos just down to the recommended 15 degrees (i.e. omit the 7.5 degree photos) and then process again with all i.e. including the 7.5 degree ones; then compare a range suitably sensitive areas of the lowest possible relief. My suspicion is that you'll see negligible improvement if you look across a range of relief features/orientations, and I suspect it be worse. Depending on scale, a suitable object might be a coin or medallion with raised text, preferably not too worn from circulation or pockets.

Richard, an interesting question! I'm not sure if RTI is the (best) way to go about this. I've never done this, but I'm certain that if you used photogrammetry to make a textured 3D model of your object, sculpture etc., you could then use a modelling package (such as blender) to re-light your model and follow a camera track to view it from different aspects. Dave

Hi John, Glad you're working OK now, and thanks very much for letting us know. To help anyone else who has a similar problem in the future, could you be so kind as to explain what you did that finally fixed things for you? Thanks & regards Dave

Hi John, thanks for sharing the new XML file. Looking at test03.xml it looks like RTI Builder has found the PTM fitter OK now, so that's a step forward. Re this below, sorry can't see any attachments etc. A couple more things to try, which might shed light on where the problem lies: 4) Can you make a new project and process it using the HSH rather than PTM fitter? 5) CHI offer a couple of sets of sample images on their web site which are known to work - can you download fish_fossil-data-set_2000.zip from https://culturalheritageimaging.org/What_We_Offer/Downloads/Process/index.html and try that with both HSH and PTM on your workstation? cheers/Dave

Hi John, Thanks for sharing the log file. I too had wondered about spaces in the image file name/path, but that doesn't look to be the case, with a typical image being located at C:\Users\wcj83\Desktop\RTIProject\jpeg-exports\_DSC3411.jpg Looking at the tail of the log, it does though reveal that the RTI builder is getting 'unknown' errors when it tries to invoke the PTM Fitter. It alternates between looking (and apparently not finding it) in the default/normal location of C:\RTIbuilder_v2_0_2\Plugins\PTMfitter\PTMfitter\PTMfitter.exe and in a location which I guess you've specified E:\Dropbox Windows_4\PTMfitter.exe So, I guess either it isn't in the latter location, or the RTI Builder can't invoke it because there is a space in the name of the folder where you've saved the Fitter. Suggestions: 1) Confirm that it is indeed in the folder on E: and, if you can, just rename that folder where you have saved the PTM Fitter to remove the space in the file name between 'Dropbox' and 'Windows_4' (and tell RTI Builder where it now is). 2) If you can't rename that folder, just create another one with no spaces in, and try that; 3) If that doesn't fix it, try copying the fitter to the Plugins (sub)folder where the RTI Builder ought to find it (exact path as above). Let us know how you get on - I can assure you it does work, and is worth it! cheers/Dave

John, Not clear from your question if it is during installation or when trying to run it. If the latter, can you share the XML file for the project please? - that should give a clue. (It is in the top-level of your project folder, file name = <project name>.xml Dave

Hi Kira, Glad you're sorted and thanks for reporting back. Dave

Happy twentieth birthday to CHI, and thanks to all the team (including those who have contributed in CHI's first 20 years but aren't there any more). Dave