Announcement

Collapse
No announcement yet.

Color Management Code Merged Into Wayland/Weston

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Ericg View Post
    Not afraid to claim ignorance here... How exactly does Color Management work? With Wayland especially. Wayland's mandate is: every frame is perfect. I know this was more meant in the idea of tearing, but wouldn't that extend to "Every pixel is perfect"? Meaning: "Every pixel is exactly how the client meant for it to be drawn." So why would you need Color Management anyway? I guess color management would be useful for visually impaired users (flipping all colors to be the inverse in black and white)
    Color management doesn't help if all you want to say is simply "draw that pixel at R=25, G=27, B=105".

    Where it helps is when you want to display say a JPEG that is tagged with color info. In that case, there will be a table which essentially says: here is how to convert RGB values (which have no INTRINSIC ie OBJECTIVE meaning) into specific frequencies and amplitudes of light (ie something that is objective).
    The color management software takes that table, uses it in conjunction with a table associated with the display device (which likewise says how specific RGB values sent to it will translate into specific frequencies of light appearing on the device), and maps each pixel in the JPEG through these tables. The end result, when done properly, is that the JPEG will appear the same on all screens, and the way it looked when the image was captured. (Subject, of course, to HW limitations.)

    Likewise when you now want to print your JPEG.

    Comment


    • #12
      Originally posted by Ericg View Post
      "Every pixel is perfect"? ..... So why would you need Color Management anyway?
      Because nearly every monitor is imperfect and it is allot easier to try to get the colors on you display to display properly using software, than trying to do it by pushing the buttons on your monitor. (Smaller increments, also there is hardware to help automate the process if you have the cash).

      People who do photo editing professionally consider it a big deal to have their monitor show the same colors that their prints.

      Hoped that helped.

      Comment


      • #13
        Originally posted by ua=42 View Post
        Because nearly every monitor is imperfect and it is allot easier to try to get the colors on you display to display properly using software, than trying to do it by pushing the buttons on your monitor. (Smaller increments, also there is hardware to help automate the process if you have the cash).

        People who do photo editing professionally consider it a big deal to have their monitor show the same colors that their prints.

        Hoped that helped.
        Between you and Name's response, it did. Thanks for clearing that up guys.

        Comment


        • #14
          Originally posted by ua=42 View Post
          Because nearly every monitor is imperfect and it is allot easier to try to get the colors on you display to display properly using software, than trying to do it by pushing the buttons on your monitor. (Smaller increments, also there is hardware to help automate the process if you have the cash). <....>
          alright, but why does that have to happen in a daemon?
          couldnt the aforementioned color conversion tables be contained in (say, EGL - or printer) drivers so that they're applied once when pixel data is sent to the device?
          why the need for a separate process?

          Comment


          • #15
            Originally posted by silix View Post
            alright, but why does that have to happen in a daemon?
            couldnt the aforementioned color conversion tables be contained in (say, EGL - or printer) drivers so that they're applied once when pixel data is sent to the device?
            why the need for a separate process?
            I don't know.
            I agree with you.
            It shouldn't be in a daemon.

            Comment


            • #16
              Originally posted by uid313 View Post
              I don't know.
              I agree with you.
              It shouldn't be in a daemon.
              Applications need to query *something* for the color profile of a device. So if not a daemon, what else would you use?

              Comment


              • #17
                Originally posted by kigurai View Post
                Applications need to query *something* for the color profile of a device. So if not a daemon, what else would you use?
                Oh, I see. I didn't know.
                I thought maybe X.org Server or Weston would do the color management instead of the applications.
                But I guess the applications need to do it too..

                Uhm maybe a service, maybe D-Bus?
                I don't know.

                Comment


                • #18
                  Originally posted by uid313 View Post
                  Oh, I see. I didn't know.
                  I thought maybe X.org Server or Weston would do the color management instead of the applications.
                  But I guess the applications need to do it too..

                  Uhm maybe a service, maybe D-Bus?
                  I don't know.
                  I think http://www.freedesktop.org/software/colord/intro.html will explain to you how all this is supposed to work.

                  Comment


                  • #19
                    Originally posted by kigurai View Post
                    I think http://www.freedesktop.org/software/colord/intro.html will explain to you how all this is supposed to work.
                    Thanks!

                    Comment

                    Working...
                    X