home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / graphics / 12124 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  5.3 KB

  1. Path: sparky!uunet!mcsun!uknet!mucs!lilleyc
  2. From: lilleyc@cs.man.ac.uk (Chris Lilley)
  3. Newsgroups: comp.graphics
  4. Subject: Re: Color Sample to RGB Conversion
  5. Keywords: color conversion
  6. Message-ID: <6799@m1.cs.man.ac.uk>
  7. Date: 19 Nov 92 13:52:19 GMT
  8. References: <hewitt.721337021@usafa.af.mil> <6759@m1.cs.man.ac.uk> <1992Nov18.180555.24920@netcom.com>
  9. Sender: news@cs.man.ac.uk
  10. Organization: Dept Computer Science, University of Manchester, U.K.
  11. Lines: 124
  12.  
  13. In article <1992Nov18.180555.24920@netcom.com> kudzu@netcom.com
  14. (Michael Sierchio) writes:
  15.  
  16. >In article <6759@m1.cs.man.ac.uk> lilleyc@cs.man.ac.uk (Chris Lilley)
  17. writes:
  18.  
  19. >>In article <hewitt.721337021@usafa.af.mil> hewitt@usafa.af.mil (W. Joe
  20. >>Hewitt) writes: 
  21.  
  22. >>>     I am looking for a way to generate a color on a workstation
  23. >>>that closely  matches a given sample from a color plate.  
  24.  
  25. >>The simple answer is, mix it by eye.
  26.  
  27. >This is less than satisfying, and less than satisfactory.
  28.  
  29. As indeed I stated in my article. It will however give accurate
  30. results, simply.
  31.  
  32. >>>     I have tried scanning the image (24 bit scanner) with little success.  
  33. >>>The scanning software only gives percentages of the R,G, & B components.  
  34. >>>Using a little math I converted each percentage to a value in the range 
  35. >>>0..255 (24 bit color system) for each RGB component.  
  36.  
  37. >>>The problem is that the new color doesn't look very much like the
  38. >>>original sample.   
  39.  
  40. >>No, it won't. Red, green, and blue are very loose specifications for
  41. >>colours. They differ between different monitors, and between different
  42. >>scanners. 
  43.  
  44. >This is false.  
  45.  
  46. Sorry to trouble you, but my statement is absolutely correct and it is
  47. you that is wrong. If you want figures, just let me know. Or you could
  48. look up an introductory book on colour science.
  49.  
  50. >The RGB of NTSC video are quite standard.  
  51.  
  52. Yes, they are. So?  Did Joe Hewitt say he had an NTSC video monitor perched
  53. on his workstation? I find that unlikely. They are pretty rare things
  54. - even TV studios don't use them nowadays, they use SMPTE monitors
  55. instead.
  56.  
  57. And if you know of a scanner whose filters are closely matched to the
  58. NTSC phosphor chromaticities and gamma, please post the details  ;-)
  59.  
  60. >A properly
  61. >adjusted RGB monitor will give good results.  The key is the get the
  62. >input from an RGB Camera, whose RGB signals are designed to match an
  63. >RGB monitor.
  64.  
  65. This sad misconception is one reason why people have so many problems
  66. with colour matching.
  67.  
  68. >>As you have realised, RGB is not the way to go. You basically have two
  69. >>options. 
  70.  
  71. >RGB is how the colors are represented on input and display devices.
  72.  
  73. This statement is correct, but the inferences you draw from it are not.
  74. If you had bothered to read my post properly you would have realised
  75. that each devices RGB is different. I suggest you go read it again.
  76.  
  77. >There exist color spaces that attempt to preserve the perceptual range --
  78. >this isn't relevant to the discussion. 
  79.  
  80. The original poster stated that he was having a problem with colours
  81. not matching perceptually. I gave a brief introduction to the
  82. standardised, tried and tested methods of achieving a match.
  83. Therefore, those colour spaces are precisely relevant to the
  84. discussion. It is your sadly naive view that all RGB devices are
  85. exactly equivalent and all precisely matched to the NTSC standard that
  86. is irrelevant. Go read up a little.
  87.  
  88. >>your scanner RGB --> CIE XYZ --> your monitor RGB
  89.  
  90. >Nope.  RGB -> XYZ -> RGB -> screen
  91.  
  92. >What's the point?  
  93.  
  94. Let me spell it out for you. 
  95.  
  96. The scanner red value will not be the same number as the monitor red
  97. value. The scanner green value will not be the same number as the
  98. monitor green value. The scanner blue value will not be the same
  99. number as the monitor blue value.  
  100.  
  101. However - and *this* is the point - the perceived colour on
  102. screen will now match the colour of the plate, which is what the
  103. original poster was asking about.
  104.  
  105. >There will never be any more information than in
  106. >the original RGB image.
  107.  
  108. The number of bits of information has not changed, but the bit
  109. patterns have. The extra information, if you want to look at it that
  110. way, has come from the data on the chromaticities of the monitor
  111. phosphors and the scanner filters.
  112.  
  113. Your general point about scanning in a colour image as RGB and
  114. displaying it on an RGB monitor is an acceptable way to get colour
  115. into the computer for low quality applications where the colour
  116. matching is irrelevant. Putting pictures of military jets and half
  117. dressed women on a workstation root window, for example ;-)
  118.  
  119. I do not blame you for not understanding this - it is a common
  120. misconception. But understand that your suggested approach is 
  121. inadequate when the colour match is required to be of moderate or 
  122. high quality.
  123.  
  124. >>>     I am looking for a way to generate a color on a workstation
  125. >>>that closely  matches a given sample from a color plate.  
  126.  
  127. I think that counts as a requirement for high quality.
  128.  
  129. --
  130. Chris Lilley
  131. ---------------------------------------------------------------------------
  132. Technical Author, ITTI Computer Graphics and Visualisation Training Project
  133. Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
  134. Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
  135. Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
  136. ---------------------------------------------------------------------------
  137.