Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-base gst-plugins-base
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 645
    • Issues 645
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 88
    • Merge requests 88
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gst-plugins-basegst-plugins-base
  • Issues
  • #737

Closed
Open
Created Mar 09, 2020 by Sebastian Dröge@slomo🍵Owner

Colorimetry defaults based on resolution cause visible color differences

The following pipeline is going to select BT709 for the UYVY part of a.jpg and BT601 for b.jpg (because a.jpg has height >= 720 and b.jpg not). jpegdec puts the same colorimetry on both. Compositor will then get BT601/BT709 on its two pads and convert that to xRGB, and in the output the colors of both bars are visibly different.

gst-launch-1.0 -v filesrc location=a.jpg ! decodebin ! videoconvert ! video/x-raw,format=UYVY ! imagefreeze ! c.   filesrc location=b.jpg ! decodebin ! videoconvert ! video/x-raw,format=UYVY ! imagefreeze ! c.    compositor name=c sink_1::xpos=60 ! video/x-raw,format=xRGB ! videoconvert ! xvimagesink

a.jpg b.jpg

This is either inherent to the BT601/BT709 conversions being lossy or there's a bug in their implementations.

Assignee
Assign to
Time tracking