Skip to content

docs(readme): record colour handling, and the new 4:2:0 10-bit format - #77

Merged
StuartCameronCode merged 1 commit into
mainfrom
docs/readme-colour-handling
Aug 19, 2026
Merged

docs(readme): record colour handling, and the new 4:2:0 10-bit format#77
StuartCameronCode merged 1 commit into
mainfrom
docs/readme-colour-handling

Conversation

@StuartCameronCode

Copy link
Copy Markdown
Owner

Three gaps between the README and what 1.0 actually ships.

  • Output colour format was missing 4:2:0 10-bit (added in fix: NVENC and QSV cannot encode 4:2:2 (#74) #76). The row now also says why it matters beyond playability: no NVIDIA card before the RTX 50 series can encode 4:2:2 at all, so for a 10-bit source this is the option that keeps the precision and still encodes.
  • Hardware encoding now says a format the GPU can't take is converted rather than failing the job, and that the panel says which and why first.
  • Colour tagging was undocumented entirely — despite being one of the larger behavioural fixes in this release. Without it every output was untagged and therefore read as BT.601 limited, shifting the colours of any BT.709 or full-range source. That, the per-pass depth handling, and the 8-bit-units convention behind every threshold in the interface now have a <details> block, covering the same ground as the new in-app explanation.

The filter table itself was already current — #75 refreshed it, and #76 added no passes.

Docs only, so ci-test.yml's paths-ignore skips the test gate.

Three gaps against what 1.0 actually ships.

The output colour format list was missing 4:2:0 10-bit, added so a 10-bit
source can keep its grading through a GPU encoder — no NVIDIA card before the
RTX 50 series can encode 4:2:2 at all, which the row now says, since "matching
the source" being unplayable is only half the reason to change it.

The hardware encoding row now says a format the GPU cannot take is converted
rather than failing the job, and that the panel says so first.

And colour tagging went undocumented entirely, despite being one of the larger
behavioural fixes in this release: without it every output was untagged and so
read as BT.601 limited, shifting the colours of any BT.709 or full-range
source. That, the depth handling, and the 8-bit-units convention for every
threshold in the interface now have a details block of their own — the same
ground the new in-app explanation covers.
@StuartCameronCode
StuartCameronCode merged commit 32dc73c into main Aug 19, 2026
@StuartCameronCode
StuartCameronCode deleted the docs/readme-colour-handling branch August 19, 2026 00:58
StuartCameronCode added a commit that referenced this pull request Aug 19, 2026
…our-handling"

This reverts commit 32dc73c, reversing
changes made to 29dd1c3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant