Talk:Grayscale image: Difference between revisions

(Terms)
Line 16:
:::How so? Color points are kept in a definite model. When plotted the device expects images in a certain format which includes color model specification as well. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 17:11, 16 January 2009 (UTC)
 
::::No. Color points are not "kept" in any model. The image storage is just a block of memory. The memory does not care what is stored in it. You only need to know how much memory you need to reserve. An RGB value is plotted into the image by writing the values of R, G and B in memory. The memorycolor modelspace used (gamma etc.) has no effect on this operation. --[[User:PauliKL|PauliKL]] 21:01, 16 January 2009 (UTC)
 
:::::Image storage is not a memory block. It is a set of language objects that used to store and process images. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 15:39, 17 January 2009 (UTC)
 
::::::Wrong. Image storage ''is'' a memory block. In ''some'' languages there may be sugar coating trying to hide this fact, but it does not change the fact that image is always stored in a block of memory. The functions used to process images have nothing to do with the ''storage''. --[[User:PauliKL|PauliKL]] 11:20, 23 January 2009 (UTC)
 
::The point is that the CIE conversion function mentioned requires linear color mode. If linear color model is ''not'' used, you could use just about any weighting factors for R, G and B, and it does not help to use so many decimal digits. A common function used in sRGB color space is <tt> L = 0.3*R + 0.59*G + 0.11*B </tt>. When this is applied to and sRGB image, the results are closer to CIE conversion than when you use the CIE function in sRGB color space. I just thought that this should be mentioned, in case someone is planning to use the code examples given here in a real application.
Line 27 ⟶ 29:
:::No, they work in any model, of course. It is so that the algorithm depends on the model, obviously. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 17:11, 16 January 2009 (UTC)
 
::::No, they do not work. An image editor performs an operation always the same way, it does not care about the memorycolor modelspace. If you order the program to add the values of two pixels, it adds the values of two pixels. And that works correctly only in linear color space. If you do not believe me, try it. The color space is only relevant when you perform conversion from one color space to another. In theory, it would be possible to convert each pixel separately to linear color space and back when performing each image editing operation, but that would make the image editor so extremely slow that nobody would want to use it. --[[User:PauliKL|PauliKL]] 21:01, 16 January 2009 (UTC)
 
:::::No, I don't believe you. Pixels are not numbers, you cannot add them unless you define a vector space of, supplied by a definition of the operation +. The operation + in that space corresponding to certain semantics (to be specified) is a part of a color model. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 15:39, 17 January 2009 (UTC)
 
::::::Wrong. Pixels ''are'' numbers, and of course they can be (and are) added, multiplied or whatever operations you are doing. Everything stored in computers memory is numbers. But adding two pixels in non-linear color space does not give correct results. That was my original message. If you are editing an image in an image editor and you want to do it right, you should first convert the image into linear color space. (In case of RGB to grayscale conversion, the image editor probably does the color space conversion automatically.) --[[User:PauliKL|PauliKL]] 11:20, 23 January 2009 (UTC)
Anonymous user