darktable-org / darktable-org/lua-scripts

Allow programatically reading / setting output color profile of an image to be exported

Offen
#522 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

API change req'd enhancement
Vorherrschende Sprache
Lua
Sterne
219
Forks
142
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

Forked from pixls.us thread:

In a script, I'm using the following code to export an image to JPG:

local exporter = dt.new_format("jpeg")
exporter.quality = 95
exporter:write_image(src, dest)

That code is dependent on the export module's output color profile currently selected in the UI. I would like to either force a specific profile (let's say Display P3 RGB), or detect when an invalid profile (for my purpose) is used, to be able to warn the user. My options with the current API are:

  1. dt.gui.action("lib/export/profile", 0, "selection", "first", 0.0) + dt.gui.action("lib/export/profile", 0, "selection", "next", 10.0) as Display P3 RGB is currently the 11th one displayed; that's hardcoded in colorspaces.c.

    Pro: Unobtrusive.
    Con: Depends on DT internals without their proper representation through the API. If DT profile order ever changes, the script forcefully selects a different profile.

  2. dt.gui.action("lib/export/profile", 0, "selection", "popup", 0.0)

    Pro: Doesn't depend on DT internals, user could select their own ICC profiles too.
    Con: Obtrusive; user is prompted to the action even if the current settings are correct, they are also asked to select the only correct option.

  3. Export, then check the resulting file metadata, and error out post factum.
    Pro: Unobtrusive.
    Con: Suboptimal UX, as I cannot prevent the error from happening, or implement input data validation before triggering the action. Possibly the metadata won't be there if export doesn't have the EXIF.

  4. Export outside of DT
    Pro: Total control over the output.
    Con: Needs an intermediary export in DT to a format that isn't sensitive to color profile (does it even exist?) to retain changes done to the RAW in DT, like cropping etc.

All of the workarounds above would not be needed if the Lua API allowed for:

  • Setting output color profile in dt_imageio_module_format_t.write_image, or
  • Reading/setting output color profile of dt_lua_image_t (this might be through #414). I could then use image settings profile in export, which is the first option in the combobox, or
  • Reading/setting the combobox options by their name in export's profile combobox (the item: prefix doesn't seem to work there)

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit den Lua-API-Einstiegspunkten dt.new_format("jpeg") und dt_imageio_module_format_t.write_image, überprüfe anschließend die referenzierte Profilreihenfolge in colorspaces.c und Issue #414. Vergleiche die angeforderten Möglichkeiten, das Exportprofil zu lesen oder festzulegen, und definiere den Abschluss so, dass ein Skript das Ausgabeprofil auswählen oder untersuchen kann, ohne sich auf die Reihenfolge in der UI zu verlassen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
lua
Bereich
api
Issue-Typ
Feature
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.