Metadata customisation

[JawedAshraf]

The dialog for Focus Points shows lots of really great metadata.

I think there's an opportunity to allow a user to customise what's shown. At minimum, to add or remove tags.

The reason for my suggestion is that I found two metadata tags that seem very useful: Hyperfocal Distance and Focus Distance 2. These were found in a RAW file from my Sony A7Cr.

It might be preferable for you to not make this a user-customisation function, as such. I imagine that's a lot of work (a whole new dialog I expect) and instead merely take this suggestion for extra tags that could be added for Sony cameras.

[capricorn8]

Thank you for your feedback!

There was already a suggestion of and discussion about Sony's Focus Distance 2 with the result to not include this tag.

I have been thinking about ways how users can tailor the displayed metadata to their own needs. I'm hesitant to implement a user interface for this, because it will require some effort and probably it will be used by few people only.

In fact, if you look at the code adding (or removing) tags on this level is super easy. Example for Sony:

function SonyDelegates.getFocusInfo(_photo, props, metadata)
  local f = LrView.osFactory()

  -- Create the "Focus Information" section
  local focusInfo = f:column {
      fill = 1,
      spacing = 2,
      addInfo("Focus Mode"          , metaKeyAfFocusMode      , props, metadata),
      addInfo("AF Area Mode Setting", metaKeyAfAreaModeSetting, props, metadata),
      addInfo("AF Area Mode"        , metaKeyAfAreaMode       , props, metadata),
      addInfo("AF Tracking"         , metaKeyAfTracking       , props, metadata),
--    addInfo("PDAF Point Used"     , metaKeyAfFocalPlaneAFPointsUsed, props, metadata),
      addInfo("Focus Distance",     "Focus Distance 2",       props, metadata),
      addInfo("Hyperfocal Distance", "Hyperfocal Distance,  props, metadata),
      }
  return focusInfo
end

In this example, PDAF Points Used has been removed (commented out) and the Focus Distance 2 and Hyperfocal distance have been added.

I will add a detailed description and explanation how do this to the user manual in V3.3, as a first step to support customized metadata display.

[JawedAshraf]

That's fantastic!

I added those two and it's working great. I fixed the missing quotation mark in the Hyperfocal Distance line...

As to the complaints about Focus Distance 2 being "unusable" I think it's worth remembering that with a wide angle lens hyperfocal distance means the camera might land anywhere in a very large range to consider what it thinks is focussed, and so "random" focus distances should be expected.

For me this is a nice prompt in learning the particulars of some of my lenses, e.g. my 20-70 at f8 has hyperfocal distance of 1.66m for the 20mm focal length. Naturally circle of confusion is still relevant here and it may well be my undoing, but it's a start :)

In the end the general flexibility simply by editing the source code is fantastic.

Rather than adding a whole new dialog it might be an idea to create a generic metadata specification adder:

-- Read the specified text file which contains a set of comma-separated metadata specifications that can be added, one line per specification
-- Specification consists of:
-- cameraMaker - to match with the delegate functions and to allow a user to have multiple camera makers configured simultaneously
-- renderSection - the name of the section in the FocusPoints dialog where the customisation should appear
-- description - text for the entry in the dialog
-- key - either an internal key definition or a string that corresponds with the raw metadata
function readUserMetadataSpecification (filename)
[...]
end

Maybe have either another file that specifies unwanted metadata or add a section to this file that specifies deletions

[capricorn8]

That's an interesting approach! I'm currently traveling so I don't have the time and the abilities to get to elaborate this further. Would you like to sketch your idea in more detail? It does not need to be ready to run code and it doesn't need to be Lua as well. Any high level syntax will do.

[JawedAshraf]

I think a single file should be used. The filename could be fixed, e.g. TailorMetadata.txt. I've discussed this with an AI and we've produced a file:

# Edit this file in a text editor and save into the plugin folder to enable (opt-in).

# cameraMaker should be one of these values:
# apple,canon,fujifilm,nikon corporation,olympus,panasonic,pentax,sony,generic

# Acceptable renderSection values:
# imageInfo, shootingInfo, focusInfo

# Usage examples
# ADD lines: ADD, cameraMaker, renderSection, description, tag
# Example: add a custom focus X value to the Focus Information section
# ADD,canon,focusInfo,Custom Focus X,custom_focus_x

# Example: add a generic custom AF mode to the Image Information section
# ADD,generic,imageInfo,Custom AF Mode,custom_af_mode

# DELETE lines: DELETE, cameraMaker, tag
# Example: remove an obsolete tag for Nikon
# DELETE,nikon corporation,old_focus_tag

The file might be placed in the required position within the plugin folder, but that would risk wiping out the user's already defined tailoring.

Alternatively it could be placed somewhere else in the repository, e.g. in the installation instructions.

The biggest problem I see here is that the plugin has "keys" that are either specific to the camera or are generic across cameras. For example the code displays the "Make" key in the Shooting Information section of the dialog. If a user wants to delete that item from the dialog, they would (could, should?) know the key name, rather than the raw metadata tag name.

I haven't studied the code closely enough to identify all of the keys that are rendered on the dialog to determine the list of the full set of keys used by default. It might be 20 items or it might be 100. So this complicates how a user would delete items.

Maybe it's easier to expect the user merely to know raw tag names, "make" (in this case key and tag are the same) or "camera model name" which corresponds with the displayed value called "Model" or key "cameraModel".

This problem isn't just a problem with deletion, in theory it's also a problem with addition. I was lucky, I found the raw metadata tag names courtesy of the "Show metadata" dialog and just ignored the concept of "keys" :)

Finally, I'm unsure whether the cameraMaker field should be specified for deletions.

[JawedAshraf]

Parsing, worked out with AI:

-- UserMetadataSpecs.lua
-- Simple parser that returns a table of adds/deletes keyed by normalized camera make.
-- No quoted fields, '#' starts a comment, comma-separated.

local M = {}

local function trim(s)
  if not s then return s end
  return (s:gsub("^%s*(.-)%s*$", "%1"))
end

local function split_simple_csv(line)
  local res = {}
  for field in line:gmatch("([^,]+)") do
    table.insert(res, trim(field))
  end
  return res
end

local function normalize_maker(maker)
  if not maker or maker == "" then return "generic" end
  return trim(maker):lower()
end

-- readUserMetadataSpecification(path)
-- Returns: specs_table, warnings_table_or_nil, err_string_or_nil
-- specs_table: { [maker] = { adds = { { renderSection, description, tag }, ... }, deletes = { tag, ... } } }
function M.readUserMetadataSpecification(path)
  if type(path) ~= "string" or path == "" then
    return nil, nil, "invalid path"
  end

  local fh, err = io.open(path, "r")
  if not fh then return nil, nil, "cannot open file: " .. tostring(err) end

  local specs = {}
  local warnings = {}
  local lineno = 0

  for raw in fh:lines() do
    lineno = lineno + 1
    local line = trim(raw)
    if line == "" or line:match("^#") then
      -- skip blank or comment
    else
      -- split by comma (no quoted fields supported)
      local parts = split_simple_csv(line)
      local action = (parts[1] or ""):upper()

      if action == "ADD" then
        -- expect 5 fields: ADD, cameraMaker, renderSection, description, tag
        if #parts < 5 then
          table.insert(warnings, string.format("line %d: ADD requires 5 fields, got %d", lineno, #parts))
        else
          local _, cameraMaker, renderSection, description, tag = table.unpack(parts, 1, 5)
          cameraMaker = normalize_maker(cameraMaker)
          renderSection = trim(renderSection or "")
          description = trim(description or "")
          tag = trim(tag or "")

          if tag == "" then
            table.insert(warnings, string.format("line %d: ADD missing tag field", lineno))
          else
            specs[cameraMaker] = specs[cameraMaker] or { adds = {}, deletes = {} }
            table.insert(specs[cameraMaker].adds, {
              renderSection = renderSection ~= "" and renderSection or "imageInfo",
              description = description ~= "" and description or tag,
              tag = tag,
            })
          end
        end

      elseif action == "DELETE" then
        -- expect 3 fields: DELETE, cameraMaker, tag
        if #parts < 3 then
          table.insert(warnings, string.format("line %d: DELETE requires 3 fields, got %d", lineno, #parts))
        else
          local _, cameraMaker, tag = table.unpack(parts, 1, 3)
          cameraMaker = normalize_maker(cameraMaker)
          tag = trim(tag or "")
          if tag == "" then
            table.insert(warnings, string.format("line %d: DELETE missing tag field", lineno))
          else
            specs[cameraMaker] = specs[cameraMaker] or { adds = {}, deletes = {} }
            table.insert(specs[cameraMaker].deletes, tag)
          end
        end

      else
        table.insert(warnings, string.format("line %d: unknown action '%s' (ignored)", lineno, parts[1] or ""))
      end
    end
  end

  fh:close()
  if #warnings > 0 then
    return specs, warnings, nil
  else
    return specs, nil, nil
  end
end

return M

Today is the first time I've ever looked at Lua, so I really have no idea about the quality of this code. In general I find AI fails badly for languages that are "old" or "not used that much".

There's also the problem of how to wire-in this functionality, since there are generic aspects (all cameras will show things like "make") whereas some tags are make or model specific. The hierarchy in the code has rather more complexity than I first expected, so I'm not sure I should say much more.

Using "generic" in the cameraMaker field for deletions is a decent solution to the problem of deleting tags regardless of make.

[capricorn8]

Thank you for your inputs and sorry for the delayed response!

I have been travelling and am now faced with some unexpected matters, so it will take me a little longer to look into this topic.

My current priority is to release V3.3 to the public with the 'Straightening Images' feature, which will require some updates to the documentation.

A well-thought-out custom metadata concept would be a valuable addition to the feature set of the Focus Point Viewer. Depending on the complexity of its implementation, it could be the standout feature of version 3.4 or 3.5!

[JawedAshraf]

In the end, it seems this will be a feature for those users who feel unsure about editing the code.

Perhaps there's not much demand, too.

Finally, in the context of a plug-in about focus metadata, there is probably not much metadata that could be added as the information provided is already excellent.

It might be interesting to see if there are other Lightroom plugins that provide user-customisable metadata. If they're open source then they might reduce your effort :)