Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Color Management Code Merged Into Wayland/Weston

  1. #11
    Join Date
    Mar 2013
    Posts
    17

    Default

    Quote 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.

  2. #12
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    205

    Default

    Quote 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.

  3. #13
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,738

    Default

    Quote 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.

  4. #14
    Join Date
    Feb 2013
    Posts
    37

    Default

    Quote 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?

  5. #15
    Join Date
    Dec 2011
    Posts
    1,931

    Default

    Quote 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.

  6. #16
    Join Date
    Nov 2012
    Posts
    191

    Default

    Quote 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?

  7. #17
    Join Date
    Dec 2011
    Posts
    1,931

    Default

    Quote 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.

  8. #18
    Join Date
    Nov 2012
    Posts
    191

    Default

    Quote 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.

  9. #19
    Join Date
    Dec 2011
    Posts
    1,931

    Default

    Quote 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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •