darktable-org / darktable-org/lua-scripts

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

オープン
#522 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

API change req'd enhancement
主要言語
Lua
スター
219
フォーク
142
PR マージ指標
30日以内にマージされた PR はありません

説明

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)

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

Start with the Lua API entry points dt.new_format("jpeg") and dt_imageio_module_format_t.write_image, then review the referenced colorspaces.c profile ordering and issue #414. Compare the requested ways to read or set the export profile and define completion as a script being able to select or inspect the output profile without relying on UI ordering.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
lua
領域
api
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。