Should all asset tags be visible in Info panel?

Support
1

I think I ought to be able to see all asset tags for an image in the info panel, but am not for some reason. Here’s what I see in PhotoStructure, in Windows Explorer (tags I’ve edited are on the right), and the image itself. I’ve also sent the image itself to support@photostructure.com in case the forum messes with the metadata.

image
image888×374 56.8 KB
image
image673×520 29.3 KB
test
test2500×1289 219 KB

I’m using v2.1.0-alpha.7 on Docker. I added some tags to an image in Windows Explorer, then copied that image into my library. After re-syncing the asset, I expected to see the tags in the Info panel. However I see none besides the date, camera maker, and camera model.

In the FAQs What’s a hierarchical tag? and How does PhotoStructure extract keywords from my photos and videos?, I get the impression that only these seven tags are supported:

  • CatalogSets
  • Categories (this is typically XML-encoded)
  • HierarchicalSubject
  • Keywords
  • LastKeywordXMP
  • Subject
  • TagsList
  • XPKeywords (these are keywords added by the Windows Explorer)

Wait – are “keywords” and “tags” the same thing?

In any case, then here in the forum you say

2

Howdy!

It seems that everyone uses “tags” and “keywords” quite loosely, and frequently interchangeably.

I try to be consistent with these definitions:

A “tag” is any metadata associated with a file. Wikipedia has a section on photo metadata. The library I wrote for PhotoStructure, exiftool-vendored, lists out the most common 5,000 (!!) seen tags here (it’s a huge page, it may make a mobile browser hang!). Common image file tags would include Make, Model, Rating, GPSLatitude and GPSLongitude.

A “keyword” is used for either “flat” values, like dog or beach, or a hierarchical values, like pets/meowsers or where/nature/beach.

So: back to your question: why not just show all tags in the info panel?

Because that’s not what you’d want: my iPhone, for example, produces 140 different tags for every image–that’s 140 rows, mostly of garbage that doesn’t make sense to anyone other than the engineer that designed the camera. Here’s some examples:

  "MakerNoteVersion": 14,
  "RunTimeFlags": "Valid",
  "RunTimeValue": "1242618580516166",
  "RunTimeScale": 1000000000,
  "RunTimeEpoch": 0,
  "AEStable": "Yes",
  "AETarget": 175,
  "AEAverage": 181,
  "AFStable": "Yes",
  "AccelerationVector": "0.05225707593 -0.9513861539 0.3851839302",
  "FocusDistanceRange": "5.45 - 5.70 m",
  "LivePhotoVideoIndex": 1112547584,
  "HDRHeadroom": 1.560478449,
  "SignalToNoiseRatio": 54.6400146,
  "FocusPosition": 61,
  "HDRGain": 0.0002253835701,
  "AFMeasuredDepth": 90,
  "AFConfidence": 28,
  "SemanticStyleRenderingVer": true,
  "SemanticStylePreset": true,
  "ColorMatrix1": "1.2271626 -0.5454787016 -0.2612876594 -0.454685688 1.517779708 -0.0426504463 -0.04093803838 0.1636143029 0.591345787",
  "ColorMatrix2": "0.9145434499 -0.3222275078 -0.1262248605 -0.4288679957 1.309540987 0.09467574954 -0.1062918678 0.2350454628 0.4307328463",
  "AnalogBalance": "2.210449219 1 1.825439453",
  "AsShotNeutral": "1 1 1",
  "BaselineExposure": 3.005051136,
  "BaselineSharpness": 1.5,
  "CalibrationIlluminant1": "Standard Light A",
  "CalibrationIlluminant2": "D65",
  "NoiseReductionApplied": 0.9499999881,

To prevent excessive local file I/O when browsing, the info panel renders only information provided from the library database. If that implementation holds, adding Title, Author, and other fields would need to be added to the AssetFile table (which I certainly could do).

Alternatively, the info panel could initially show the db data, and then asynchronously fetch file metadata and update the UI with those fields as they were found (the additional I/O and CPU load would probably be just fine for most servers).

Any field I add to the db means it can be searchable, so I’d probably want to add those to the table.

“Bonus” fields (like, say, you wanted to show one of the above tags for some reason), could be a setting.

3

Thanks for explaining. I suggest adding those definitions to one of the two FAQs I linked. I do agree by default, I would not want to be inundated by the useless tags you shared.

I like your idea to initially show db data, then asynchronously fetch the rest of the file metadata, as long as there’s a status indicating Search files for more metadata in progress… This ensures any metadata manually added to files using any external program is always still visible in PhotoStructure.

Deciding whether additional fields like Title or Caption should be added to the db table can be left to other feature requests I think. For example https://forum.photostructure.com/t/adding-a-short-note-to-a-photo-title-description/ already exists, which is all I’m interested in at this time. A single text field for the tag Title, Caption, Description, or whatever, is all I’m interested in for now.