Jump to content

All Activity

This stream auto-updates     

  1. Earlier
  2. cdschroer

    DLN:CC Beta - Locations

    There are some good ideas here. The easiest one to implement is adding a notes field. I'm not sure we can do the other ones in the current version because of time and budget constraints, but we'll talk it over. You can use the Notes field to store additional info - though it does have the drawback of not being as easy to find, and also not being mapped to the CRM, etc. Carla
  3. cdschroer

    RTI Hosting/processing for web viewing

    Have you looked at the WebRTIViewer? http://vcg.isti.cnr.it/rti/webviewer.php It's from the Visual Computing Lab in Pisa - and those folks have spent some time looking at compression and tiling and similar techniques for using big files over the internet. The project is open source. Contact info for Gianpaolo Palma is also on this page. He was the primary developer. They also support RTIs in the 3D Heritage Online Presenter (3DHOP) tool. It's from the same team. Carla
  4. Dave Martin

    DLN:CC Beta - Rights statement linkage

    p.s. is there any other format for beta comments that would be better? is there a tracker you would like them submitting to? Dave
  5. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Fully appreciate that the priority in the first beta was to expose all the functionality, but structure of the Dashboard might benefit from reorganisation - order? titles? move ‘paramaterisation’ items to a ‘Setup’ menu? System tray icon – when the focus is not on DLN:CC, the icon is just a blank white sheet – suggest something more meaningful would be useful – maybe something like the blue notebook DLN logo used on the web pages? or the CHI logo? Capture Teams – there are traces of ‘Teams’ (e.g. in export) but no UI access that I can spot anywhere in the dashboard. Suspect that Teams were at one point in there (something like equipment subassemblies) but have since been dropped, with which I personally would agree. Needs either maintenance and ability to use, or remove Teams from DLN:CC ?
  6. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 When creating or modifying entries on the reference lists, there doesn’t appear to be any check on whether a duplicate is being created. DLN:CC appears to (universally as far as I can see) allow the user to create duplicate entries. In the case of, say, Operator Roles, one can create two roles both called Supervisor. When one comes to associate Operators with an Image Set, you have to pick a role for the association, and you will see two indistinguishable Supervisor roles to choose from, and even if the tooltip / description had been populated, it isn’t visible. In some cases there may legitimately be multiple items such as tripod or light stand, but that would be covered by having Quantity > 1 in the equipment record as there would be no need to differentiate between them. I can envisage relatively few cases where near-duplicate entries might be required – but they would still need visually distinct names to allow them to be correctly associated. For example, if a user had two camera bodies of identical model, but different serial numbers – and the user wished to keep track of which body was used on a shoot because of the age of the body, or perhaps different firmware. Two equipment records could be created – but unless there was something distinctive about the names, the user would not know which body to associate with the image capture. It should be relatively easy for the alert user to monitor this on small lists (especially once they are sorted alphabetically) but once lists get longer, or perhaps a DLN:CC instance has multiple users, the risk of inadvertent creation of duplicate entries will increase. I would strongly suggest that DLN:CC shouldn’t allow creation of any records with identical names. List ‘shuffles’ – a disconcerting phenomenon – only seen, I think, on the Equipment Overview list. If you open the Equipment Overview and then highlight a row and click [Details], or double-click a row and then [Close] the details screen, the underlying list remains exactly unchanged. However, if you open the details and then change something (not necessarily the Name) and then click [Save], when you then [Close] the details screen, the entry you clicked on has, at first sight, disappeared! On further inspection though, it has either moved to display row 9 or the bottom of the list. This is somewhat disconcerting! If the operator has manually sorted the equipment list before activating & changing details, then the list seems to survive un-molested in the chosen order (unless the list was alphabetical and the name has changed in which case the resultant change to maintain alphabetical order is performed correctly).
  7. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 On the Image Set screens, as well as the ‘Created’ dates, it also exposes two date fields captioned ‘Data entry some time within’. At first, as these are only (as far as I can see) on image sets, I wondered if ‘Created’ was the capture date and ‘Data entry’ was the date on which the images were processed to build an RTI model or photogrammetric product. However, the ‘data entry’ fields are read-only, and appear to be some form of internal audit record which has both start and end date auto-populated with the date on which the record was keyed in DLN:CC? Suggest: ‘Created’ date might be better captioned ‘Capture’ date to make it clear it relates to the date the images were captured, not when the DLN record was created Audit fields not displayed elsewhere, so not needed here? It would, though, be useful to allow recording of date on which image sets were processed? (also, previous comments / discussions on date formats apply)
  8. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 On many list displays (e.g. Category/Type/Role) the first column of the tabular display, to the left of the ‘ID’ field, is a monotonically ascending integer which I suspect is a display index of some kind, which could be useful for debugging but can’t envisage functionality for normal users, and similarity in values with those in the ID column could potentially be confusing. Is this un-named column necessary? / should it be hidden or zero-width? Default sort order – appreciate that lists can be sorted by clicking on the column-head label, but would suggest that a consistent approach is taken to the order in which items are sorted for display when a screen first opens. This is currently not the case, for example: Equipment Categories defaults to alphabetically by name Person Overview appears to default to ascending ID Equipment Overview appears random – neither alphabetical or in ID order The list of Role options when associating an Operator with an Image Set - neither alphabetical or in ID order I would suggest that alphabetically A..Z for the ‘name’ of the item would be a reasonable and useful default.
  9. Dave Martin

    DLN:CC Beta - Rights statement linkage

    Hi Carla, Thanks very much for all the info, especially on Rights, and on Image Bundles. I’m glad to contribute a little bit back to the work CHI does; and from experience developing and leading development teams, and owning projects for deployment to users across all inhabited continents, I know how when a beta is exposed for scrutiny just merely having different pairs of eyes can raise questions, some of which are valid, others may be down to misunderstanding or differing expectation! Cheers Dave
  10. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 This is initially relates to silent corruption of a field in the Equipment Overview, but may have wider implications… If one is using DLN:CC Equipment Overview as a mini asset register as per the sample database, and populates a price, there are silent and insidious problems if one enters anything other than digits 0 to 9 or a decimal point by including say a currency symbol (e.g. £ for GBP) or a comma (used by many to delimit thousands, or in some regions as the separator twixt the integer portion and decimal fraction of a real number). What happens is: On the equipment overview details screen, the data entry field (whether adding a new record or editing an existing record) allows one to enter costs such as 123.45 1234.56 1,234.56 1.234,56 £123.45 £1,234.56 GBP 123.45 without any objection either when the Price field is exited or when the [Save] button is clicked. However, if one then saves, closes and goes back to view the record details, in all except the first two cases, the Price is now ‘0’. Without seeing the code, from the above it appears the failure is because the UI is accepting (meaningful and valid) ‘text’ but the database is only accepting a real with a decimal point separator. Insidiously, the whole database INSERT / UPDATE isn’t failing – if for example the serial number and price are changed, the serial number is saved/updated but the price can be corrupted to 0 if it contains anything except 0 to 9 or a decimal point. Couple of points: As there is unlikely to be any arithmetic on equipment prices, in this specific case might be best to just make the Price column in the database a text varchar, rather than numeric, column. More importantly though: 2. If there are restrictions as to what can be stored in a field, the UI needs up-front validation either when the field is exited or when the [Save] button is clicked. 3. IF the UI is posting the input from the user intact and it is being rejected by the database, then it raises the possibility that the result of commands which modify the database may not be being monitored. Dave
  11. Jessica Walthew

    RTI Hosting/processing for web viewing

    We are working with our digital team to integrate a live web RTI viewer into our museum's website (nested in our pre-existing website templates). We have already sorted out some of the front end presentation issues, but are seeking advice from anyone with experience with the back end file hosting. I'm wondering how others have dealt with image compression/downressing of files to facilitate speedy web access. Please let me know if you'd be willing to answer questions from us on this topic.
  12. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 A tick-box ‘Show associated’ appears in the Filter block on a number of screens. I fully understand this is a beta; I can understand what ‘Show associated’ does, but I’m not sure if it is needed (as much / at all), and if it is needed, its placing on the screen and its nomenclature. The data in DLN builds the database by associating, say, equipment, operators and documents with a project or image set. In pretty much every case, as it is a normalised database, one operator or document can be associated with multiple projects. What is in question here is the view ‘from the project’ side – and from the project perspective, the question of how many, and how, the higher-level objects are associated with, say, a project. ‘Show associated’ appears when the operator is given the opportunity to link higher-level objects with, say, a project. In the current beta, the left-hand pane displays a list of items that can be associated, and the right-hand pane displays a list of those have (already) been associated. Items can be added to and removed the associated list, and the corresponding entry appears/disappears in both right and left hand panes; the list on the left shows those that have not already been associated. The current system effectively operates a default mechanism to allow one of each type of entry to be associated with the project; ticking the ‘Show associated’ box populates the left-hand list with all possibilities, not just those which have already been associated. First two points: The ‘Show associated’ tick box is in the Filter pane at the top of the display, which otherwise filters the right-hand list – it would (if/when still needed) be more intuitive if ‘Show associated’ was above the left-hand pane which it influences, alongside the title of the left-hand list. The tick box’s name ‘Show associated’ would be more meaningful as ‘Show already associated’ (if/when still needed). Looking deeper though, I would question the need for ‘Show associated’ in many cases. Taking a few examples: Linking a Document to a Project – this, when established, is a direct, unqualified link. There would be no sense in linking the same document to the same project more than once, so having ‘Show associated’ on that screen is not needed. In this case, ‘Show associated’ isn’t needed. Linking Equipment to an Image Set - this, when established, is a direct, unqualified link. In this case though it is possible that multiples of the same item are used. The equipment list will probably be significantly ‘longer’ and only ‘shrink’ a little when an item is associated, so having ‘Show associated’ on that screen is of minimal benefit. If helpful validation was to be offered, then when an item is being associated, quickly check if it has already been associated and pop-up a quick message to ask the operator to confirm they wish to associate a second instance. Linking a Stakeholder to a Project – this establishes a qualified link as a role must be selected at the time the stakeholder is linked to the project. The default only allows a Stakeholder to be associated once; if a second role needs to be documented, the ‘Show associated’ needs to be ticked so that the stakeholder can be selected a second time and a second association recorded. However, there are no checks that a pre-existing role isn’t being duplicated, so by ticking ‘Show associated’ it is possible to accidentally assign a meaningless duplicate role. In this case, some safeguard is needed but ‘Show associated’ isn’t really the most appropriate – I would suggest the Stakeholder list is always left fully populated (i.e. no ‘Show associated’), and when an association is being created the pop-up linkage details screen either automatically limits the list of roles to those ‘… NOT IN …’ the existing, or quickly check before saving that it isn’t a duplication. So, 3. I would query the appropriateness or need for ‘Show associated’ as the data model is refined. Just to repeat, these are suggestions which could only be made after the valuable first beta; and I fully appreciate workflow and data model will evolve. ‘Show associated’ allowed testing to progress and these comments to be made! Dave
  13. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 In addition to the technique-specific fields on image sets, currently: there is an unformatted free-form ‘Notes’ or ‘Description’ field/area on many of the register screens; the Equipment Overview has a number of hard-coded auxiliary fields, which are enabled in specific cases if the equipment is a lens / lens filter, or illumination source / illumination filter; and the Subject Overview screen has an option to populate four free format label:value pairs, one of which whose label indicates it is intended to be ‘is part of’. The auxiliary fields on the Equipment records have fixed purpose and are stored in hard-coded columns. However, the auxiliary fields on the Subject are to all effects uncontrolled. As it stands, the user, on a per-subject basis, decides on the purpose they wish to use the field for that single subject and types in what they want the field name / item label to be and then types in the value to be stored – both of these are totally free format. What this means is that these auxiliary fields are, I would argue, of possibly even less value than the free-format Notes field – whereas the auxiliary fields could actually be so much more useful…. With the current system, there are two issues: There is no control over the labels, so on one record the user could type in “Gift of” as the title or label for the first field (as in the sample data), and on another subject, they could type in the first field’s label as “Donated by” or “Donor”. If the user then sought to search for all records where label1 = “Donor” … then they would miss ones where the label had been typed as “Gift of” or “Donated by”. (as it happens, I suspect “Gift of” as cited in the example database might actually be better as a stakeholder role, but the “Gift of” serves well to illustrate the point.) Also, as there is no control over which of the fields is used, even if there was standardisation to call an entry, say, “Catalogue number”, as that could be stored in subject auxiliary field 1, 2 or 3, then any query would have to be some form of (… WHERE subject_id1_lbl = ‘Catalogue number’) UNION (… WHERE subject_id2_lbl = ‘Catalogue number’) UNION ( … WHERE subject_id3_lbl = ‘Catalogue number’) As it stands, having the free-format labels and data fields allow highlighting (a bit like having the ability to underline or embolden text in the Notes field) but doesn’t contribute as much as it could in terms of structured data. I think that a simple change could resolve these, and add to the power of DLN. Instead of having multiple auxiliary fields embedded in the Subject rows, store the auxiliary data in a linked table, and control the list of possible labels via a ‘label type’ register?
  14. RachRosh

    PTMFitter software download link

    Never could get the dropbox download to work but there is an upload that worked for me here! At the end of the thread
  15. RachRosh

    Verify your PTMfitter path!

    @Fionn you are an actual angel!!!!! Thank you for saving me from a the most frustrating and hair pulling experience today!!
  16. RachRosh

    PTMFitter software download link

    Hi! I recently got a new computer (mac) and can't seem to get the new PTMfitter to work even using the newest zip file. When I go in and find the PTMfitter path for the first time and then press execute, it tells me to "verify my fitter path" every time. Can't seem to figure it out. Let me know if you have any troubleshooting ideas. Thank you so much!
  17. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Location entries need a ‘Notes’ section like most other registers Whilst some well-known institutions and monuments may have entries in the Getty Thesaurus of Geographic Names, possibly the majority of locations will not appear therein, or at least with insufficient granularity. Need field(s) in which the address can be entered. As mentioned by IainS earlier, the ‘GPS coordinates’ field needs provision to record information on projection etc. Need a field to use to store local coordinates and type thereof Suggest allow recording of EPSG code for sets of co-ordinates, and also ability to have local name for a co-ordinate system (e.g. “OSGB36(15)”)
  18. Hi Dave - and thanks for the detailed notes! Actually you can link rights to both the subject AND to the images of the subject. I admit it isn't as clear in the interface as it should be, and we are fixing that. The idea is that the subject may still be in copyright, and that's an important thing to know. So subjects can have rights statements, including noting whether it is in copyright. For our imaging work, we generally care more about the rights in the images, and we can do that too. But even if my organization has the rights in the images, if they are images of an artwork that is in copyright, we would want to record that. Also remember that you don't have to use all of the fields and associations that are there. So, if you don't want to note a rights statement about a subject you don't have to. Another important note about rights statements is that they are a high level way of noting what kind of rights are intended, but they aren't an actual license. So for material that is in copyright, you need to be able to say who is the copyright holder, and what is the general license (if there is one) This also lets people know where to go if they need to get a license for something different. We were just discussing this mechanism this week, as we are planning major updates for the tools. We want to make it possible to set up the rights at the project level, so that all the imaging sets that are part of that project automatically get those rights. Then if you need to do something different for a specific set of images for say an RTI - you could override that. We are also looking at how to make this more clear in the interface, so you can see the rights (and other attributes) and where they are coming from. In other words, are you getting those rights from the project, or are they local to this particular RTI (or photogrammetry) set. And this brings me to a new concept we will be introducing: Image Bundles. An Image Bundle is all of the images that will be processed together of the same subject (remember that a subject can be a scene, not necessarily a single object). An Image Bundle can be a single-set image bundle, or a multi-set image bundle. That is determined based on the technology. So RTI image bundles are single set, and Photogrammetry image bundles are multi-set. We will get rid of "groups of image sets" (it's still in the data model - but the interface will be much cleaner) We are adding single-set image bundles for documentary image sets. And finally - related to your prior comments, we will be adding an image set type, that is user defined. So, if you have a Documentary photos technology type, you can create subtypes for HDR, or stratigraphy, or small finds, or whatever is useful to you in organizing and finding and labeling your image sets. Thank you so much for taking a deep look at the tools, and for taking the time to write up your experience, questions and suggestions. We have been using the tools more and more, and also presenting them to others, and have run into some of the same issues. Some of them are harder to solve than others, though we feel the whole system is getting better. Cheers! Carla
  19. Dave Martin

    DLN:CC Beta - UI

    Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Other UI comments / across multiple registers: Deleting, for example, equipment entries – there is no check for dependencies so equipment which is associated with an image set can be deleted / referential integrity is not enforced. Would expect [Ctrl][F4] to activate [Close] as it does for almost every other Windows application Would expect [Esc] to activate [Cancel]/[Close] Some maintenance screens have an explicit [Close] button, others don’t To see / update details, some maintenance screens have button [Details], others have one called [Edit] Even without the use of accelerator keys, would suggest not ideal having three visually-similar buttons adjacent to each other [Details] [Duplicate] [Delete] Associating e.g. equipment with image set – currently works by highlight then click [ >> ] – it would be good if it also responded to the commonly used double-click to move. Where there is a sub-assembly, this allows filtering of the left-hand list. Would be good to be able to just associate the entries on the list. Filter block - most maintenance screens just have a [Clear] but some have an explicit [Filter] button? Filter block - several maintenance screens have [Export RDF] in the Filter block? File / About - more usually under Help / About? File / About - make the text on the screen so it can be copied and pasted into error reports etc. to ease reporting / accuracy
  20. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 1) If the user, when updating an equipment entry, just edits the Notes, [Save] is not active - you need to activate [Save] by ‘touching’ another field 2) The ‘Category’ filter resets without clicking clear (as soon as you click [Save]) 3) When creating or editing an equipment record, the [Tab] key skips the serial number field
  21. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Appreciate Rights included by default relate to the twelve promoted by ‘Rights Statements’ – but they’re not necessarily either applicable or appropriate, and they don’t necessarily apply in all jurisdictions either (and even the ‘Rights Statements’ organisation recognises that their twelve not universally applicable). Appreciate you don’t want anyone tampering with those twelve, but think probably need to allow for others to be added/edited as well.
  22. Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 Stakeholder’s rights are currently linked to a subject and I would query that. A subject is, say, an artefact, and in possibly the majority of cases, there’s no copyright in the object/artefact/subject, the copyright is in the work which documents it. If, say, Organisation A has a Greek sculpture on public display, and they commission a 3-D scan, and organisation ‘B’ has a photogrammetry/RTI campaign, and organisation ‘C’ takes a series of close-up images to document some specific details. Organisation A is linked to the subject as, say, its curator – but has no automatic rights to any representations of it. Organisation ‘A’ may well, though, have rights to the 3-D scan they commissioned. Organisation ‘B’ will probably have rights to their photogrammetry/RTI, and organisation ‘C’ will probably have rights to their documentary photographs. As the linkage is currently to the subject, then in the above case there may be three competing and possibly contradictory rights linkages, one from each organisation, and there would be no way to differentiate which set of images etc. was covered by which rights statements. Whilst there may (more rarely?) be a rights linkage between a stakeholder and a subject or artefact, I would suggest that as the rights really apply to a set of images or similar, it would be better to allow a rights statement to be associated with, say, an acquisition project rather than with the subject – that way it avoids possibility for competing/contradictory rights claims on a subject. Dave
  23. Hi Carla, Thanks all the above, and its great to hear that DLN is still alive. As I've used it quite a bit over the summer I have accumulated some specific comments on the beta (mostly minor UI points but also a couple of structural points) which I'll post here over the weekend. Glad to hear that acquisition type of 'Documentary Photography' will be added, that's very welcome. However, I don't believe it wouldn't be apposite to try and store say a magnetometer survey metadata under the description of "documentary photograph". Fully appreciate that allowing additional techniques names to be added in DLN:CC wouldn't cascade down to dedicated versions of DLN:Inspector. I had noted that certain auxiliary fields were turned on in DLN:CC for lenses and filters; if DLN:CC allowed a couple of other top-level technique names then as the kit would be of other equipment types, then those other fields wouldn't be activated. Allowing just a couple of alternative technique names could take it from a Digital Photography Notebook to more of a Digital Lab Notebook! Dave
  24. Hi Dave - Thanks for the notes and for using the tool! We are adding an additional technique type for "documentary photos." That will be in the next version (we are working on it now). We are also discussing adding support for multi-spectral image sets. I think with a documentary photos technology type - you could support additional kinds of image sets, because the Inspector would do a very minimal check on the images, and you could add a description or note for which kind of thing it was. Maybe we should think about subtypes within documentary photos? We don't want to add the ability to make top level new techniques, because there are significant smarts built in about what these techniques mean for Inspector, as well as how the data is grouped and saved. Further there are customizations for the image sets around the technologies, such as string length and sphere size for RTI - and differences between image sets for photogrammetry. There would be no way to have these kinds of technology specific customization for user defined technology types. I'll note that we realize that the use of image sets and groups of image sets is confusing. We are adding a notion of an Image Bundle - which is the images of a subject or scene that will be processed together. For RTI that's a single image set. For photogrammetry that's a group of image sets. For the new documentary photos that would also be an image set. This way you can see all the image bundles within a project, etc. We are working on some additional reporting functionality. We'd love to get your thoughts about this kind of approach and whether it would meet the needs you see. Carla
  25. TaylorDinkel

    RTI for Sigillography -- DIGISIG project

    Wow, these really look perfect and I also want them in my collection.
  26. Carla, Erich et al: I have used DLN:CC a number of times to record both RTI and photogrammetry sessions, and can see it does accumulate useful information. However, whilst the RTI/photogrammetry sessions have significant numbers of frames exposed, the biggest number of subjects are documents (and to a lesser degree artefacts) which are ‘just’ photographed. Whilst doing so, I keep thinking that DLN:CC would be a great way to record such imaging. Unfortunately DLN:CC only allows “RTI” and “Photogrammetry” projects, so I have tried fudging it by having collections of images in a (not really) photogrammetry project. My first suggestion is that DLN’s scope is extended to allow for Photography (or some other similar description) as well as RTI & Photogrammetry? Taking this a step further, whilst not wishing to dilute the project, I wonder if there's an opportunity to get even more value from DLN:CC. In particular, I've been thinking about geophysical and other similar surveys (where there are equipment categories, models, s/n, operators, etc. - just like RTI or photogrammetry). So, I wonder if it might be possible to have the list of 'Imaging techniques' (or just 'Techniques') able to be expanded - probably in the first case by just allowing a couple of other capture techniques to be named? This could mean that in the one DLN project for an archaeological investigation one could have metadata for, say: site photogrammetry (from UAS), magnetometer survey, GPR, resistance survey, topo survey, trench photography, trench photogrammetry, artefact photographs, artefact RTI, artefact photogrammetry.... merely by allowing the user to add extra techniques called 'Photography', 'Topographical survey', 'Magnetometer survey', 'Resistance survey' and 'GPR survey'. Dave
  1. Load more activity
×