Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: bjanes on January 18, 2008, 08:14:33 am
-
Raw has no color space. And it doesn't matter what you set your camera to (you're shooting Raw).
[a href=\"index.php?act=findpost&pid=163585\"][{POST_SNAPBACK}][/a]
Does a raw file have a color space?
The question is, “Does a raw file have a color space?” Some answer no for various reasons. Some say that the raw file can not have a color space because it is monochrome and contains no color. Of course, no file can contain color, since color is a perception and exists only in the eye and brain. What raw files and RGB files do contain is color information in the form of tristimulus color values that are perceived as color when projected on the retina. The RGB file contains three color values per pixel, for a complete RGB representation. The raw file of a Bayer array camera
contains only one color per pixel, and the other two are interpolated from adjacent pixels in the demosaicing process. Nonetheless, color information is present in the raw file and does not magically appear during demosaicing.
The recognition that the raw file does have a color space is useful in understanding how raw files are processed. Examples with code are available in DCRaw and Dng_verify, a command line program written by Thomas Knoll.
In the DNG program and DCRaw, 3 by 3 matrix conversions are used to convert from the camera space to an internal working space, in the same fashion as one would convert from ProPhotoRGB to Adobe RGB. In the case of DNG, the working space is linear ProPhotoRGB, while in the case of DCRaw, it is apparently CIE XYZ. DNG uses the dng_matrix & CameraToPCS () function to determine the white point x,y values. Thus, it is apparent that the raw file contains all the elements of a color space, either explicitly or implicitly in the form of metadata, camera profiles, or other information. Furthermore, in the source code quoted below, Thomas Knoll refers to the “camera native space” and “camera color space”, which would indicate that he thinks that the camera does have a color space that is represented in the raw file and the camera profile.
[span style=\'font-size:14pt;line-height:100%\']
Appendix[/span]
RGB Matrix profile (example is aRGB) :
Gamma 2.2
White point
K 6500
x, y: 0.3127, 0.3290
Primaries
x y
R 0.6400, 0.3300
G 0.2100, 0.7100
B 0.1500 0.0600
Raw File
Primaries: determined by CFA filters and silicon spectral response, stored in camera profile
Gamma 1.0
White point: stored in tag to raw file
White point x, y: recovered by dng_matrix & CameraToPCS () function in DNG_verify
3 by 3 matrix for Canon 1Ds, used by DCRaw
6517,-602,-867,
-8180,15926,2378,
-1618,1771,7633
Code Extracts
/*****************************************************************************/
// Copyright 2006 Adobe Systems Incorporated
// All Rights Reserved.
//
// NOTICE: Adobe permits you to use, modify, and distribute this file in
// accordance with the terms of the Adobe license agreement accompanying it.
/*****************************************************************************/
/* $Id: //mondo/dng_sdk_1_1/dng_sdk/source/dng_render.cpp#1 $ */
/* $DateTime: 2006/04/05 18:24:55 $ */
/* $Change: 215171 $ */
/* $Author: tknoll $ */
/*****************************************************************************/
for (int32 srcRow = srcArea.t; srcRow < srcArea.b; srcRow++)
{
// First convert from camera native space to linear PhotoRGB,
// applying the white balance and camera profile.
const dng_matrix & CameraToPCS () const;
/// Return the XY value to use for SetWhiteXY for a given camera color space coordinate as the white point.
/// \param neutral A camera color space value to use for white point. Components range from 0.0 to 1.0 and should be normalized such that the largest value is 1.0 .
/// \retval White point in XY space that makes neutral map to this XY value as closely as possible.
DCRAW
/*
Thanks to Adobe for providing these excellent CAM -> XYZ matrices!
*/
{ "Canon EOS-1Ds Mark II", 0,
{ 6517,-602,-867,-8180,15926,2378,-1618,1771,7633 } },
-
camera colour space
Yes i would agree with mr bjanes
In single chip cameras, Raw files tend to be 'sensor referred RGB' after demosaciaing.
Three chip cameras (and scanners) produce a 'sensor referred RGB' file, no demosaicing!
we also tend to refer to 'camera colour space' as device coordinates in order to differentiate from, for example CIE colour spaces, CIEXYZ or CIELAB etc or from output referred colour spaces such as sRGB , Adobe RGB, ProPhoto.
saves a bit of confusion – well for me at least!
-
Does a raw file have a color space?
When tryig to answer this (and other) questions, it is the very least useful to quote the opinion of other people. Instead, one needs to analyse the issue.
The first step is always to agree on the definition.
Examples, picked from the internet:
- A mathematical way to describe color information. In different color space schemes all the different formulas used essentially describe the same colors
- A model for representing color in terms of intensity values; a color space specifies how color information is represented. It defines a multidimensional space whose dimensions, or components, represent intensity values
- A system for ordering colors that respects the relationships of similarity among them. There are variety of different color spaces, but they are all three dimensional
now, that's general, isn't it?
- A map or chart of the visible portion of the spectrum
Even more generous.
- A two or three dimensional geometric representation of colors that can be seen or generated. RGB is an example of a two dimensional color space. LAB is a three dimensional color space
Refreshing news.
- A system for describing color numerically
A color model is an abstract mathematical model describing the way colors can be represented as tuples of numbers, typically as three or four values or color components. When this model is associated with a precise description of how the components are to be interpreted (viewing conditions, etc.), the resulting set of colors is called a color space
- A device color space simply describes the range of colors, or gamut, that a camera can see, a printer can print, or a monitor can display. Editing color spaces, on the other hand, such as Adobe RGB or sRGB, are device-independent. They also determine a color range you can work in
The definitions are quite different, and I am afraid there won't be any agreement on which one to use.
However, note that the rubbish "not a color space because it contains greyscale channels" can not be reasoned from any of these definitions.
Anyway, IMO the raw files have color spaces, namely the respective camera's color space.
A side note: DNG has nothing particular to do with ProPhoto RGB.
-
A two or three dimensional geometric representation of colors that can be seen or generated. RGB is an example of a two dimensional color space. LAB is a three dimensional color space
I dont think that bit is right RGB, 2D colour space?
who said that?
-
I dont think that bit is right RGB, 2D colour space?
who said that?
I don't remember from where I took it; it's irrelevant, my intention was to demonstrate the multitude of understandings.
-
I add one more definition:
The specific range of colors in a particular model
and the definition of model is
The dimensional coordinate system used to numerically describe colors
-
thats ok then
-
Does a raw file have a color space?
However, note that the rubbish "not a color space because it contains greyscale channels" can not be reasoned from any of these definitions.
Anyway, IMO the raw files have color spaces, namely the respective camera's color space.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=167975\")
Some prominent photographers have taken the rubbish route, including [a href=\"http://luminous-landscape.com/forum/index.php?showtopic=21046&view=findpost&p=155674]Jeff Schewe[/url] and Andrew Rodney.
Your caveat about definitions is important. Some make them up as they go along, while others quote selectively. For simplicity, I chose to compare the characteristics of aRGB with the Camera space, noting their similarities.
-
Some prominent photographers have taken the rubbish route, including Jeff Schewe and Andrew Rodney
Mistakes happen, This does not take away anything from their being prominent photographers.
I chose to compare the characteristics of aRGB with the Camera space, noting their similarities.
Those similarities are not greater, than the similarities to sRGB, for example.
Anyway, similarity is not a supplement for the definition. Saying "a color space is something like aRGB, but slightly different" does not cut it.
What definition do you take as basis for the discussion about the "color spacebility" of camera sensors?
-
Some prominent photographers have taken the rubbish route, including Jeff Schewe (http://luminous-landscape.com/forum/index.php?showtopic=21046&view=findpost&p=155674) and Andrew Rodney.
[a href=\"index.php?act=findpost&pid=168012\"][{POST_SNAPBACK}][/a]
Ok. . .what color space does the Canon 1DsM3 raw file have? What are the camera color's color coordinates? What are the spectral properties at D65 and tungsten? What are the separation filter properties of the Bayer RGGB photo sites?
The raw file has color information that, until somehow represented as color data (either via demosaicing or some other color interpretation) is grayscale values.
So, to me that makes it a grayscale file waiting to be interpreted as color data...but it's still grayscale until somebody somewhere does something to it.
If walks like a duck and quacks like a duck...
And one wonders what _YOUR_ definition of "rubbish" is? Garbage, worthless material or nonsense?
When I use DNG Validate to process a raw file without demosaicing...I get a linear grayscale file.
-
Ok. . .what color space does the Canon 1DsM3 raw file have? What are the camera color's color coordinates?
[a href=\"index.php?act=findpost&pid=168027\"][{POST_SNAPBACK}][/a]
Had you read my post, you would already know the answers to these questions. I don't have the matrix values for the 1DsMIII, but here are the values for the 1DsMII from DCRaw. I had already listed those for the 1Ds. What more do you want?
6240,-466,-822
-8180,15825,2500
-1801,1938,8042
"Canon EOS-1D Mark III"
What are the spectral properties at D65 and tungsten? What are the separation filter properties of the Bayer RGGB photo sites?
[a href=\"index.php?act=findpost&pid=168027\"][{POST_SNAPBACK}][/a]
The spectral characteristics of the RGGB sites are characterized in the matrix.
The spectral properties for D65 and tungsten have been developed by Thomas Knoll for use in ACR, and are included in his profile for that camera. All information does not need to be included in the actual file, but can be given by reference. If I save a file in ProPhotoRGB, without the tag, then I restore the meaning of the numbers when opening in Photoshop with the assign profile command. By analogy, the same principle applies to the raw file. The white point is also encoded in the file, and the dng_matrix & CameraToPCS () function is used to determine the white point x,y values.
When I use DNG Validate to process a raw file without demosaicing...I get a linear grayscale file.
[a href=\"index.php?act=findpost&pid=168027\"][{POST_SNAPBACK}][/a]
You are working with a file containing tristimulus color information. Whether or not you make use of it is up to you. A true grayscale file has no color information, only luminance values.
When I look at a TIFF image with a binary editor, I get only numbers. Where is the color? When I delete the red and blue channels from a TIFF, there is no color. What happened? Perhaps a different approach is needed. I agree with Panopeepr, you are taking the garbage route in your argument.
-
Ok. . .what color space does the Canon 1DsM3 raw file have?
The Canon 1DsM3 color space.
What are the camera color's color coordinates?
Nonsensical question.
What are the spectral properties at D65 and tungsten?
The sensor has spectral properties, not the image, nor the color space.
Perhaps you wanted to know, how the color space can be described in CIE terms.
at D65 the camera's color space a the result of the conversion from CIE XYZ using following matrix:
{{0.5859, -0.0211, -0.0930}, {-0.8255, 1.6017, 0.2355}, {-0.1732, 0.1887, 0.7448}}
I don't know it for tungsten.
What are the separation filter properties of the Bayer RGGB photo sites?
Again, you are mixing up the properties of the sensor with that of a colorspace.
Please note, that the question if the sensor has a color space does not depend on the fact, that you or I or anyone else knows the details of those properties or does not. What you are doing is something like seeing a bird over your head, and if I can't tell you the name of the bird, then you don't accept that it is a bird. Well, if you can't tell a bird and a Boing apart without knowing the model name, that's your problem.
The raw file has color information that, until somehow represented as color data (either via demosaicing or some other color interpretation) is grayscale values
The same can be stated re the sRGB channels. Going further: is Lab a color space? What color do the "a" and "b" channels have? What is the color of the "L" channel? Is a Lab image a color image at all without knowing, how to interpret the channels?
When I use DNG Validate to process a raw file without demosaicing...I get a linear grayscale file
You can complain about that for example on the Adobe DNG forum; or you can use Rawnalyze to see non-demosaiced color images.
On the other hand, you can see color RGB images on a black and white monitor. Where did the colors go? Do the characteristics of an image depend on how one looks at them?
-
Mistakes happen, This does not take away anything from their being prominent photographers.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=168020\")
That is quite true. But perhaps they should stick to their areas of expertise. In many areas, Jeff is quite accomplished and I rely on his new ACR book and enjoyed his contribution to the From Camera to Print video and will probably get the new ACR video when it comes out.
However, I'm not so naive as to take his every word as the absolute truth.
Those similarities are not greater, than the similarities to sRGB, for example.
Anyway, similarity is not a supplement for the definition. Saying "a color space is something like aRGB, but slightly different" does not cut it.
What definition do you take as basis for the discussion about the "color spacebility" of camera sensors?
[a href=\"index.php?act=findpost&pid=168020\"][{POST_SNAPBACK}][/a]
There does not seem to be one definition that covers all bases. You have made some good suggestions and perhaps can help supply a working definition.
When I use DNG Validate to process a raw file without demosaicing...I get a linear grayscale file.
[a href=\"index.php?act=findpost&pid=168027\"][{POST_SNAPBACK}][/a]
If you use switches with DNG_Verify to get gray scale output, it is not surprising that you get gray scale. BTW, there is a nice raw file analyzer program [a href=\"http://www.cryptobola.com/PhotoBola/RawnalyzeGuide.htm]Photobola Raw Analyze[/url] that can show color or gray scale without demosaicing.
With this program you can view in gray scale or color, as well as check clipping and many other characteristics. I think the program was written by Panopeeper, who is participating in this thread.
-
However, I'm not so naive as to take his every word as the absolute truth.
There does not seem to be one definition that covers all bases. You have made some good suggestions and perhaps can help supply a working definition.
I tend to ask other people who I respect as knowing more than I do. So I asked the follow people this morning and here are their replies. This may make you feel better, you seem to wish to prove your point as being correct and I would submit that the language of the past (essentially Grayscale) needs to be altered after asking the questions of these experts. So I should probably thank you for the efforts.
On 1/18/08 11:09 AM, "RikWalowit@aol.com" wrote:
<<Does a raw file have a color space?>>
Fundamentally, absolutely YES, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these primaries define the color space of the image.
Practically, it makes little difference unless you are interested in accurate scene-referred data. In the context you described, a simple transform is applied to convert from the camera primaries to a new set of primaries (eg CIE or working space) that have more desirable characteristics than the RAW primaries.
Mathematically, of course, you know the foregoing is true. Matrix algebra informs that if the final color image encoding is a "color space" then so must be all of its infinite number of linear transforms (lets ignore the 1 D non-linear transfer functions), including the original RAW encoding.
Eric Walowit
Tahoe
On 1/18/08 9:36 AM, "Thomas Knoll" wrote:
The fact that a mosaic array is “grayscale” is a red herring in this argument. An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result. For most cameras, if you just “assign” a working space RGB profile, you get a recognizable color image as a result, so it certainly seems like a color space.
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently. Any translation from camera color space to CIE XYZ space is an approximation because of this.
On 1/18/08 10:20 AM, "Chris Murphy" wrote:
I think we'd all agree that CIE XYZ, ProPhoto RGB, and sRGB are each a color space. We consider the whole of ProPhoto RGB a color space even though it contains imaginary colors, from a human point of view. And we consider the whole of sRGB a color space even though it contains less than the colors that we humans can see.
A camera has colors it really can capture and encode as unique values compared to others, that are imaginary to us. They don't exist. There are colors we can see, but the camera can't capture that are imaginary to it. So what to do with these captured values that humans can't see? Well they typically get mapped to something, possibly something that another rather different SPD is already mapped to. Two reds that appear the same to us, but have different SPDs, yet the camera sees them as different so it encodes them with two different RGB values. That's fugitive colors. It's nothing new in photography.
So yes a camera (and thus a Raw file) has a color space. The challenge is what to do with the real and "unreal" colors it's encoding. And how to deal with luminance and dynamic range which is still a really big weak area of the ICC workflow. This is not a one size fits all campaign, to get good results. Color appearance models can help us deal with this better, as getting a 1:1 correlation to XYZ is an appropriate starting point prior to color appearance and gamut mapping, but it's not a desirable end result either on-screen or in print.
If we had spectral sensitivities for the camera, that would make the job of mapping to XYZ better and easier, but we'd still have decisions on what to do with the colors the camera encodes, that are imaginary to us.
Chris
-
One should think of the raw file as a data file. (or interleaved rgb composite)
To call it a grayscale is probably not the most perceptual way to describe it.
Of course when it is opened in a imaging application as a composite, it is displayed as if it were a 'grayscale' as the application has no other way of interpreting the data.
I think to call it a grayscale gives it the personification of what most people would think of as a correctly exposed, processed etc black and white, monotone , greyscale etc picture.
In fact one could open any file containing numbers (providing it was encoded correctly) and it would display as grayscale.
For example: If asked 1000 random people at Picadilly Circus their age and entered that into an excell worksheet, then import into Matlab, reshape the vector to a 50x20 matrix and wrote the file out to a Tiff format, I could open it in photoshop and it would appear as a grayscale.
What it would look like is anyones guess!
But hey thats given me an Idea for a whole new genre of photography! Wow.
-
One should think of the raw file as a data file. (or interleaved rgb composite)
To call it a grayscale is probably not the most perceptual way to describe it.
[a href=\"index.php?act=findpost&pid=168051\"][{POST_SNAPBACK}][/a]
It has probably happened that RAW became notorious for "not having color" simply because of the geometry of CFAs, alone, since three color receptors can occupy a single channel, flat raster because they never occupy the same locations. Had all cameras detected full RGB at each pixel from the beginning, no one would be saying that RAW data is colorless; just dark (if linear), desaturated and slightly off-hue.
-
Andrew,
I appreciate your attitude.
-
There is one point to add, IMO, though I guess this can be debated as well.
Viewing the color space through the conversion matrix is not the ultimate wisdom. It is convenient for sure, and it is ok between orthogonal color spaces. For example sRGB, Adobe RGB, ProPhoto RGB has been defined with reference to CIE, in terms of conversion matrices, so the conversion with matices is natural.
However, cameras' color spaces can not be described in an orthogonal system based on the three (or four) color pixels, because of the overlap between the spectral responses. Therefor the conversion with the matrix (actually, with its inverse) is not satisfactory. I think this is the reason, that no matter how hard one calibrates ACR, one can not get all colors right, not even all colors of the small color checker.
-
I tend to ask other people who I respect as knowing more than I do. So I asked the follow people this morning and here are their replies. This may make you feel better, you seem to wish to prove your point as being correct and I would submit that the language of the past (essentially Grayscale) needs to be altered after asking the questions of these experts. So I should probably thank you for the efforts.
[a href=\"index.php?act=findpost&pid=168050\"][{POST_SNAPBACK}][/a]
Thanks for the info, Andrew. I certainly respect you more for having published comments by TK and CM that do not entirely agree with your previous statements. I don't know the other fellow, but I assume he is an expert also.
I did not want to engage in another flame war over this topic, and had written you privately concerning this matter. On receiving no reply I made the public post. I'm sure you all know more about photography than I do, but in this case I felt I was at least partially correct.
Your thanks are graciously accepted.
Bill
-
Thanks for the info, Andrew. I certainly respect you more for having published comments by TK and CM that do not entirely agree with your previous statements. I don't know the other fellow, but I assume he is an expert also.
[a href=\"index.php?act=findpost&pid=168059\"][{POST_SNAPBACK}][/a]
Eric is up there with color geeks like Thomas. He's got a patent that describes some core functionality within ColorSync and at one time was the fellow who ran ColorSavvy. Now he's a snow board guru. He's the first person I go to when asking about aspects of digital camera color management.
The "Essentially Grayscale" comments date back to another respected color geek and in my case, mentor, Bruce Fraser. I believe I quoted him from his book in the previous debated thread. IF Bruce were alive and had he asked the same questions to this group of experts and received the same answers, I suspect he, (as I will from now on), would use better language than "essentially Grayscale" to describe this aspect of Raw data.
-
Therefor the conversion with the matrix (actually, with its inverse) is not satisfactory. I think this is the reason, that no matter how hard one calibrates ACR, one can not get all colors right, not even all colors of the small color checker.
[a href=\"index.php?act=findpost&pid=168058\"][{POST_SNAPBACK}][/a]
In ACR the conversion matrices were made from a target based characterisation. A spectral characterisation method could produce more accurate results. (Far more complicated and time consuming, a day at least on the monochromator!)
But I think the problem with 3rd party raw processors is that they use a 'one characterisaion fit all'
approach for each camera. (Thomas Knoll uses two, illuminant A balanced and a D65 i think, correct me if im wrong).
What you have to remember is that characterisation is system specific. Ie only valid for that body lens, filter etc combinations.
If you have a different set up from the one used for the characterisation, this will put you at a disadvantage straight away.
I know that this will grate with some people but I would use the manufacturers RAW converter and compare with ACR – just a thought.
-
I find it essential for a raw processor to have analyzed the spectral respones of the sensors and base the comlor converson on that. I don't think the "system" issue is of relevance. The characteristics of a given sensor (with the filters) are important. I see the effect of non-neutral lenses in the area of white balancing, i.e. the set white balances, like daylight, incandescent, etc. should depend on the lens, but this iis independent of the method of color conversion.
It is well-known - except among the creators of raw processors - that the camera manufacturer's software yields the best color. Unfortunately, those raw processors are far from "professional" raw converters on the area of features and comfort.
-
The latest version of Canon's DPP (version 3.2.0.4) is very usable. If you have tried earlier versions and lost patience because of the impossible user interface, I understand. If you are a Canon shooter, well worth giving the newer version a few hours try.
And I agree, DPP gives the best RAW convert in color fidelity, sharpening, and shadow detail. Albeit not as flexible as Lightroom or ACR.
-
And I agree, DPP gives the best RAW convert in color fidelity, sharpening, and shadow detail. Albeit not as flexible as Lightroom or ACR.
I have found this to be true - with DPP anyway.
However, [and its a big however] - the workflow advantages of Lightroom make it a no brainer to us LR.
And.. you can actually get the same results [or better] than DPP - it just takes more work to get there.
As good as DPP conversions are it just cant compete with the power of LR for processing. And I am a big DPP fan.
-
The "Essentially Grayscale" comments date back to another respected color geek and in my case, mentor, Bruce Fraser. I believe I quoted him from his book in the previous debated thread. IF Bruce were alive and had he asked the same questions to this group of experts and received the same answers, I suspect he, (as I will from now on), would use better language than "essentially Grayscale" to describe this aspect of Raw data.
[a href=\"index.php?act=findpost&pid=168063\"][{POST_SNAPBACK}][/a]
Well, that's where my understanding and expectations come from as well. I have no problem accepting the words of Thomas and Chris...they obviously know more than I about the subject. But I still think it's wrong to attribute the term "color space" as defined by general acceptance because (even Bruce has pointed out) that it's more of a color mixing function and a camera sensor will have different spectral responses from different spectral sources. Hence the difficulties for creating a profile for a digital camera.
So, I'll also refrain from calling what the camera captures as "grayscale data" but I'n not convinced a camera has a fixed "color space" either...which is why ya gotta adjust for the white balance of the raw file.
-
Hello,
this is very interesting, but how does this help us processing our images better? can we profile better with this knowledge? where do we go from here?
Sorry if this is a trivial question
Henrik
-
quote=Schewe,Jan 18 2008, 08:44 PM]
I have no problem accepting the words of Thomas and Chris...they obviously know more than I about the subject[/quote]
Jeff, this entire discussion is totally inconsequent. Does it really matter if the raw image has a color space or not? Not the very least, *except* for a better understanding of the subject in general.
Therefor one should not accept anyone's word as a deus ex machine, but one should try *reasoning* to come to a result. This starts with the very basics, like
a camera sensor will have different spectral responses from different spectral sources
the sensor has only *one* spectral response per channel. The spectral response includes the response of the sensels of a given channel *for all visible light waves*. In other words, the spectral response shows, how the sensor behaves with *any* light source.
Hence the difficulties for creating a profile for a digital camera
The source of difficulties is, that the transformation between the camera's color space and another one (basically CIE, as that is the starter point for the others) is not as straightforward, as it is with the "artificial" color spaces, which have been defined just so, that they can be transformed to and from CIE via a matrix multiplication.
Look at the spectral responses of the three channels of different cameras and see, how different these responses are. Do you believe, that these can be described with only nine parameters? The transformation based on the conversion matrices is an approximation, sometimes better, sometimes worse.
I'n not convinced a camera has a fixed "color space" either...which is why ya gotta adjust for the white balance of the raw file
For the sake of your own understanding, do you mind explaining what you mean with the adjustment for white balance?
-
how does this help us processing our images better? can we profile better with this knowledge?
Not the least; it is academic pure.
-
Bjanes:
I would say, THE ANSWER IS NO. Andrew seems correct. At present most Raw files are numbers only, with no clear unambiguous color information. Sadly.
I need only refer to the below fragments of your own post: That EOS 1Ds2 matrix comes from Adobe. If the Raw was intended as a vehicle for colorimetric information surely some colorimetric data would be present in the file itself? Absent such "reference" data, why should the American "Adobe Interpretation" be accorded more credence than the Danish "Phase One Color Interpretation" or the privately held French "Edmund Ronald Color Interpretation" ? Just because Mr. Coffin has found Adobe the easiest place to liberate a Cam2xyz matrix from ?
Of course, were the camera manufacturer to cooperate and measure the colorimetric characteristics of the camera, eg spectral responses, and write this data into the Raw file, then the situation would change: A map with a clearly marked scale is a very different object from a map with no scale. Although of course there is just so much information about "color" to be derived from data viewed through the 3 filters in a Bayer array.
Oh, and by the way, I use camera profiling software I have written myself to determine the color of the images I take with my Phase back- I eat my own dogfood. I've had occasion to discuss camera color with quite a few other people and while all these smart guys have some working solution to the Raw color issues, everybody agrees that existing technology gets you only so far.
Edmund
PS. It has been described in detail how Thomas Knoll initially derived the matrices in ACR for various cameras by imaging a testchart exposed in a Gretag lightbooth switched to various light settings. While I have the greatest respect for Thomas and find the ACR interpolated matrix color model an ingenious solution to a difficult problem, there is no way he or anyone else would claim that this model yields any colorimetric ground truth.
Does a raw file have a color space?
The question is, “Does a raw file have a color space?” Some answer no for various reasons.
----snip----
Thanks to Adobe for providing these excellent CAM -> XYZ matrices!
*/
{ "Canon EOS-1Ds Mark II", 0,
{ 6517,-602,-867,-8180,15926,2378,-1618,1771,7633 } },
[a href=\"index.php?act=findpost&pid=167946\"][{POST_SNAPBACK}][/a]
-
Bjanes:
THE ANSWER IS NO. Andrew is correct. At present most Raw files are numbers only, with no clear unambiguous color information. Sadly.
well thats not completely right
a camera does have a 'colour space'- a very big 'colour space'!
The camera 'colour' space (or to be precise, sensor space) is determined by its spectral response.
its the raw file that doesn't have a 'colour space' as the data is yet to be correctly interpreted
A raw file is the un calibrated image data for a particular scene - sensor referred data - its not colormetric data, it has to be converted to that in the next step.! Via the camera matrix to CIE XYZ.
Now we have color data.
-
A raw file is the un calibrated image data for a particular scene - sensor referred data - its not colormetric data, it has to be converted to that in the next step.! Via the camera matrix to CIE XYZ.
Now we have color data.
[a href=\"index.php?act=findpost&pid=168138\"][{POST_SNAPBACK}][/a]
Absolutely right. I love the "It has to be converted". Reminds me of Leonardo, designing the helicopter saying well, all I need now is the engine
Edmund
-
well thats not completely right
a camera does have a 'colour space'- a very big 'colour space'!
The camera 'colour' space (or to be precise, sensor space) is determined by its spectral response.
its the raw file that doesn't have a 'colour space' as the data is yet to be correctly interpreted
A raw file is the un calibrated image data for a particular scene - sensor referred data - its not colormetric data, it has to be converted to that in the next step.! Via the camera matrix to CIE XYZ.
[a href=\"index.php?act=findpost&pid=168138\"][{POST_SNAPBACK}][/a]
Now we run full circle. The initial question was, does a Raw have a color space (not does a camera have a color space).
Just when we were getting somewhere....
-
Bjanes:
I would say, THE ANSWER IS NO. Andrew seems correct. At present most Raw files are numbers only, with no clear unambiguous color information. Sadly.
[a href=\"index.php?act=findpost&pid=168126\"][{POST_SNAPBACK}][/a]
There is no way to get any color from numbers only unless you know the meaning of those numbers. Furthermore, are you impervious to the statements made by Andrew's experts? As Mr. Knoll has stated, it is not possible to get perfect unambiguous colors from the CFA sensor, since the spectral characteristics of the filters do not match those of the human eye. Furthermore, recent research has shown that there are polymorphisms in human visual pigments and all people do not see color in the same way. Some are tetrachromats.
I need only refer to the below fragments of your own post: That EOS 1Ds2 matrix comes from Adobe. If the Raw was intended as a vehicle for colorimetric information surely some colorimetric data would be present in the file itself? Absent such "reference" data, why should the American "Adobe Interpretation" be accorded more credence than the Danish "Phase One Color Interpretation" or the privately held French "Edmund Ronald Color Interpretation" ? Just because Mr. Coffin has found Adobe the easiest place to liberate a Cam2xyz matrix from ?
Of course, were the camera manufacturer to cooperate and measure the colorimetric characteristics of the camera, eg spectral responses, and write this data into the Raw file, then the situation would change: A map with a clearly marked scale is a very different object from a map with no scale. Although of course there is just so much information about "color" to be derived from data viewed through the 3 filters in a Bayer array.
[a href=\"index.php?act=findpost&pid=168126\"][{POST_SNAPBACK}][/a]
The Adobe coefficients only approximate the behavior of the sensor. It may be best to allow each software vendor to use their own methods according to the circumstances and shooting conditions. A spectral power distribution taken over the visible spectrum at 1 nm intervals would take up a lot of space and you would still have to derive the coefficients. The current approach is to tag the file with a few key characteristics and the remaining data can be filled in by reference as is done with the DNG conerter. The absolute perfection you seek is not attainable, and compromises must be made and these involve judgment.
Oh, and by the way, I use camera profiling software I have written myself to determine the color of the images I take with my Phase back- I eat my own dogfood. I've had occasion to discuss camera color with quite a few other people and while all these smart guys have some working solution to the Raw color issues, everybody agrees that existing technology gets you only so far.
[a href=\"index.php?act=findpost&pid=168126\"][{POST_SNAPBACK}][/a]
Thus far we have been talking about Matrix Profiles, which apply only to relatively behaved devices such as CRTs and some sensors. I don't know what type of profiles you are generating, but most camera profiles generated by third party software are look-up table based and are much more involved than a few coefficients. These latter profiles may work under defined conditions, such as in the studio taking pictures of models under flash, but many authorities such as Bruce Fraser and Andrew Rodney are not enthused with their use under general conditions.
-
Now we run full circle. The initial question was, does a Raw have a color space (not does a camera have a color space).
Just when we were getting somewhere....
[a href=\"index.php?act=findpost&pid=168160\"][{POST_SNAPBACK}][/a]
Chris Murphy: "So yes a camera (and thus a Raw file) has a color space. "
-
Chris Murphy: "So yes a camera (and thus a Raw file) has a color space. "
[a href=\"index.php?act=findpost&pid=168167\"][{POST_SNAPBACK}][/a]
Yes he does. And a good lawyer could continue to use the above words of Thomas to try to sway the jury, for example:
An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result.
When is this early process step happening (before or after we have a raw)? If after, then the lawyer could say "well until that step, this Raw hasn't filled in the missing values, there's no color (yet)".
Chris further lumps the camera and the Raw color space issue into one:
So yes a camera (and thus a Raw file) has a color space.
We agree a camera has a color space/color mixing function but what about the Raw? He's somewhat unclear here.
The lawyer could even argue that what Eric says here doesn't apply to the Raw data:
The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these primaries define the color space of the image.
All heading us back to the "Essentially Grayscale", somewhat ambiguous original statement about the Raw data itself.
I'm not a lawyer and don't want to mince the words here.
The clincher here, for me is what Eric wrote:
In the context you described, a simple transform is applied to convert from the camera primaries to a new set of primaries (eg CIE or working space) that have more desirable characteristics than the RAW primaries.
Characteristic of Raw primaries is the key in my mind. He is associating the Raw to primaries which seems to strongly suggest color (space).
Of course the lawyer could nitpick his use of RAW instead of Raw (its not an acronym, a pet peeve of some) and try to get the jury to look the other way.
The lawyer could further use this from Thomas to say he doesn't seem to strongly believe the statement:
it certainly seems like a color space.
In the end, too many semantics!
-
If the Raw was intended as a vehicle for colorimetric information surely some colorimetric data would be present in the file itself?
What exactly do you miss?
1. the public knowledge of the colorimetric information?
This can not be made a condition for being a color space. If the characteristics of a color space are known only among a certain circle of people, then it is still a color space IMO.
2. the presence of it in the file?
If that is a condition, then sRGB, aRGB, etc. are no color spaces, because their characteristics are not present in the files.
Btw, DNG files do contain the conversion matrices. Does a DNG file have a color space, while the native raw file does not?
Absent such "reference" data, why should the American "Adobe Interpretation" be accorded more credence than the Danish "Phase One Color Interpretation" or the privately held French "Edmund Ronald Color Interpretation" ? Just because Mr. Coffin has found Adobe the easiest place to liberate a Cam2xyz matrix from ?
As any such matrix is an approximation only, this question is reduced to "who can approximate better". As such, it plays no role in the topic.
Of course, were the camera manufacturer to cooperate and measure the colorimetric characteristics of the camera, eg spectral responses, and write this data into the Raw file, then the situation would change: A map with a clearly marked scale is a very different object from a map with no scale
What if they would only publish that information, but not put it into the file? Just like sRGB?
-
Characteristic of Raw primaries is the key in my mind
Primaries exist only in an orthogonal system. Raw files do not have primaries.
Therefor raw files/images/cameras (pick whatever you like) do not have color spaces in the sense of those definitions, which expect the description of a color in orthogonal form, like this one of those I posted yesterday:
A color model is an abstract mathematical model describing the way colors can be represented as tuples of numbers, typically as three or four values or color components. When this model is associated with a precise description of how the components are to be interpreted (viewing conditions, etc.), the resulting set of colors is called a color space
This was the reason I suggested to lay done a definition first.
-
My fourth expert has responded. More food for thought:
On 1/19/08 10:11 AM, "Jack Holm" wrote:
I think a couple of things in Eric’s response could be confusing.
- Unless the camera spectral sensitivities are colorimetric, they do not define the intrinsic colorimetric characteristics of an image.
- Also, primaries are for synthesis and can cause some wrong thinking if discussed in relation to analysis.
The second paragraph of Thomas’ response is important.
The short answer to the question is:
Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry.
The same thing could be said about film negative densities.
Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like with film scanning).
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation. In the standards committees we decided it is useful to be able to talk about non-colorimetric color spaces so we allow them and use “colorimetric color spaces” when appropriate.
Jack
Jack often differs with Eric from clearly a semantic standpoint, something most of us here appear to be doing as well. We're talking two world class color scientist with extreme expertise in digital imaging from the point of digital capture.
-
this is good to see the views on such things
But it is obvious there is a lot of confusion over terminology and definitions
"In the end, too many semantics!"
The way I like to think is
Camera -sensor space-
RAW file - just a data file
CIEXYZ colour encoding space.
so any way im off to the pub for a pint and to see what the general consensus is! (any excuse)
have fun
-
Some here may recall another recent debate about colors outside the spectrum locus not being colors and the quote I got from another expert, Karl Lang:
Color, is a perceptual property. So if you can't see it it's not a
color. Color is not a particular wavelength of light. It is a
cognitive perception that is the end result of the excitation of
photoreceptors followed by retinal processing and ending in the
visual cortex. We define colors based on perceptual experiments.
A coordinate in a "colorspace" outside the spectrum locus is not a
color. We often refer to these as "imaginary colors" but this is by
and large also erroneous (you can't map an imaginary color from one
colorspace to another as the math (and experimental data) for each
colorspace breaks down outside the spectrum locus.
Jack's post seems to use the same ideas here to discuss non-colorimetric color space no?
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation
We seemed to agree about this post of Karl's and if so, now we have to rework our ideas about color spaces based on non colorimetric data I suspect. Chris also discusses this above (imagery colors).
-
Primaries exist only in an orthogonal system. Raw files do not have primaries.
RAW file - just a data file
So while we could agree its a data file (no arguments there), we still go back to the original writings of Bruce (essentially Grayscale) versus that of others (color data). Which is it?
Even the four color geeks (three true color scientists that do this for a living) seem to either somewhat disagree or use differing language.
Both Eric and Jack are members of the ICC and spend a great deal of time in the various committees (both part of the camera committee) trying to define these kinds of terms. What hope do we have here of coming to some agreement in terms???
-
Both Eric and Jack are members of the ICC and spend a great deal of time in the various committees (both part of the camera committee) trying to define these kinds of terms. What hope do we have here of coming to some agreement in terms???
[a href=\"index.php?act=findpost&pid=168204\"][{POST_SNAPBACK}][/a]
OK, so screw it. I'm gonna go back to saying a raw file is NOT yet a rendered color file (it's raw color data) and is essentially grayscale image data (with the pixels representing what the color could be) waiting to be interpreted into color as a result of a demosaicing process. I also still think that the raw file doesn't have "A" color space as the term "color space" is commonly used.
So now I've gone full circle and think Bruce was more right that Mr. Bill Janes...who seems hellbent on arguing about how many angels can fit on the head of a pin...my thought? One really fat angel or a bunch of really skinny angels but in the grand scheme, since I don't believe in angels, it's a moot point.
-
Yes he does. And a good lawyer could continue to use the above words of Thomas to try to sway the jury, for example:
When is this early process step happening (before or after we have a raw)? If after, then the lawyer could say "well until that step, this Raw hasn't filled in the missing values, there's no color (yet)".
Chris further lumps the camera and the Raw color space issue into one:
We agree a camera has a color space/color mixing function but what about the Raw? He's somewhat unclear here.
The lawyer could even argue that what Eric says here doesn't apply to the Raw data:
All heading us back to the "Essentially Grayscale", somewhat ambiguous original statement about the Raw data itself.
In the end, too many semantics!
[a href=\"index.php?act=findpost&pid=168180\"][{POST_SNAPBACK}][/a]
If we need to call in a lawyer, then we are in deep trouble. They know nothing about color theory but are very good at obfuscating and will advance any thesis that the client wants, as long as they get paid. They do not seek truth, but rather results for their client. After all, do you think OJ is innocent?
Thus far, no one has come up with an ironclad definition of a color space, and indeed there probably are many kinds of color space. What we have had is a good scientific discussion where most agree that the camera has a space with many but not all of the attributes associated with well defined matrix spaces and how camera tri-stimulus values may be rendered imperfectly into a better defined space such as ProPhotoRGB. I think it is time to close down this thread. I agree that semantics will get us nowhere. Everyone can declare victory (should that be necessary) and turn to the next topic.
Bill
-
OK, so screw it. I'm gonna go back to saying a raw file is NOT yet a rendered color file (it's raw color data) and is essentially grayscale image data (with the pixels representing what the color could be) waiting to be interpreted into color as a result of a demosaicing process. I also still think that the raw file doesn't have "A" color space as the term "color space" is commonly used.
I'd agree, its a non rendered image. I think going full circle, we're not too much closer to agreement. "Essentially Grayscale data" doesn't seem to be any more or less inaccurate and that Bruce was careful here using the important caveat of "essentially". None of the four color experts have dismissed this idea (yet) but I hope to hear back from them based on Jack's last post.
-
One of the citations above gives away the "secret":
A purist might argue that a color space not based on colorimetry is not really a color space
i.e. it is the question of definition. If your definition requires that a color space be colorimetric, then raw data does not qualify due to ambiguity.
However, this "greyscale" approach is still nonsense, independently of the accepted definition, and honestly, I find its endless repetition quite ridiculous. The question is not if the raw file represents a color image but how the colors can be described.
-
OK, so screw it. I'm gonna go back to saying a raw file is NOT yet a rendered color file
Since when is "rendered" a requirement for being a color space?
Btw, what is "rendered"? Is a JPEG in Exif format a "rendered" file? What about a Lab file?
-
A so called RAW image is just data. I tend to think of the bayer pattern as a clever form of image compression 3:1, and it only becomes an image again after demosaicing. Displaying the RAW data is perhaps useful for geeks like me who develop raw conversion software, but not for much else. It's just a visual representation of data, not an image, which to me is a representation of the image you wanted to capture with the camera. Once it's demosaiced to RGB it has a colour space, that being Camera RAW colour space for that particular camera.
Graeme
-
If we need to call in a lawyer, then we are in deep trouble. They know nothing about color theory but are very good at obfuscating and will advance any thesis that the client wants, as long as they get paid. They do not seek truth, but rather results for their client. After all, do you think OJ is innocent?
Lets look this over from the beginning. For me, it's Bruce's book that introduced me to the concepts and he states as we've heard over and over "Raw is essentially Grayscale data". I've used this sentence too (and that started this entire slew of posts after you decided that's not accurate). OK, I'm fine with that, lets look where we've come so far and see if we've learned anything useful. The word "essentially" may be considered a cop-out, but I suspect Bruce like the other four experts I've asked, understood this well and the term is necessary (he's not saying a Raw document IS Grayscale or that a Raw document is in a color space).
One side wants to call the Raw data essentially Grayscale, the other wants to say its data in a color space. The middle ground seems to say the data has the potential to be color data in a color space. One camp asks "if the Raw data isn't essentially Grayscale and is in a color space, what is it?" The other camp suggests this is defined or can be defined. One group suggests that by their definition of a color space, the colors have to fall within human vision (other wise, we're talking about "Imagery Colors" and colors we can't see are not colors at all). We have the issues of colors that fall outside human vision and possibly captured by the camera (and represented by the Raw?) as not being colors in a color space due not being non-colorimetric; that further muddies the waters. One side says that we need three defined primaries to even consider data in a color space. The 5 experts (four mentioned above, the 5th being Bruce who unfortunately can't comment here), seem to have subtle differences in what they define as a color space and in some cases refer to the camera not the Raw data, the root of this argument.
Are we any closer to agreement? I'm still no the fence. But I'm a Gemini.
It appears that without the spectral properties of the chip and some other necessary data, we can't even define the color space of the capture. Does that mean the Raw data defines a color space? Or a potential color space? What is the color space of an untagged RGB document? If we don't know, can we say that its composed of three Grayscale channels? (I'd say yes) but without that definition of the scale of the numbers, is it essentially Grayscale with a potential to be a color space we can define? Can we even say a set of values that represent multiple Grayscale values is a color space if we don't know the scale of the values?
-
Once it's demosaiced to RGB it has a colour space, that being Camera RAW colour space for that particular camera.
[a href=\"index.php?act=findpost&pid=168225\"][{POST_SNAPBACK}][/a]
No argument there! But what about before? The crux of debate. Is a Raw a color image? Is it in a color space? If I take an image in sRGB in Photoshop and split the color channels into three documents, is that still an sRGB image or do I have to merge the data (and assign a profile)? If a tree falls in the forest and no one is around.... Never mind.
Going back to square one, is calling a Raw "essentially a Grayscale file" any more or less accurate to saying its "essentially a color image"?
-
Thus far, no one has come up with an ironclad definition of a color space, and indeed there probably are many kinds of color space.
Here's mine:
Color model: A method of mapping color using a set of defined dimen-
sions. Some scientific color models such as x,y,Y or L*a*b* encompass all
of human vision and have a defined scale such that a particular color will
always have the same set of values. Other color models such as RGB or
CMYK have no standard defined reference or scale. In order to under-
stand a color in these models you must have a color space definition that
provides a scale and reference.
Color space: A color space is a scientifically defined portion of human
vision. A color space may be defined with any color model. The RGB
values R10,G100,B10 have no meaning by themselves other than the
color is mostly some kind of green. By using a color space definition, the
same set of values can be translated into one of the scientific color models,
giving the values exact meaning. Having a set of RGB values associated
with a color space allows for the exact reproduction of the color.
A color space is a color model that has a known reference and scale, in this case primaries (the
ingredients) and scale (specific quantities of these ingredients).
-
Here's mine:
[a href=\"index.php?act=findpost&pid=168228\"][{POST_SNAPBACK}][/a]
"Color space: A color space is a scientifically defined portion of human
vision. A color space may be defined with any color model. The RGB
values R10,G100,B10 have no meaning by themselves other than the
color is mostly some kind of green. By using a color space definition, the
same set of values can be translated into one of the scientific color models,
giving the values exact meaning. Having a set of RGB values associated
with a color space allows for the exact reproduction of the color. "
The above quote was without attribution, so I don't know whose definition that is nor do I know if it is accepted by the scientific community. However, if one does use that definition, then a raw file or a digital camera does not have a color space, since as Thomas Knoll has stated on 1/18/08 9:36 AM,:
"The fact that a mosaic array is “grayscale” is a red herring in this argument. An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result. For most cameras, if you just “assign” a working space RGB profile, you get a recognizable color image as a result, so it certainly seems like a color space.
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently. Any translation from camera color space to CIE XYZ space is an approximation because of this."
Since the model is an approximation rather than exact it would not fulfill the definition. If you and Jeff want to go through these contortions so as save face, that's OK with me. Since I am not a color expert, I would accept the analysis put forth by Thomas Knoll, Chris Murphy, and Eric Walowit.
-
OK, so screw it. I'm gonna go back to saying a raw file is NOT yet a rendered color file (it's raw color data) and is essentially grayscale image data (with the pixels representing what the color could be) waiting to be interpreted into color as a result of a demosaicing process. I also still think that the raw file doesn't have "A" color space as the term "color space" is commonly used.
So now I've gone full circle and think Bruce was more right that Mr. Bill Janes...who seems hellbent on arguing about how many angels can fit on the head of a pin...my thought? One really fat angel or a bunch of really skinny angels but in the grand scheme, since I don't believe in angels, it's a moot point.
[a href=\"index.php?act=findpost&pid=168208\"][{POST_SNAPBACK}][/a]
And I would propose that Thomas Knoll and Chris Murphy are more right than Mr. Jeff Schewe. He accuses me of arguing about how many angels fit on a pin, but what he seems to be trying to accomplish is having to retract any of his ill-considered statements and reach any common understanding of the scientific principles involved. His broken record method of debate reminds me of that used by Joseph Goebbels. As I have stated, I think the matter should be laid to rest, but Jeff just can't do that and is again attempting to malign my search for truth.
-
As I have stated, I think the matter should be laid to rest, but Jeff just can't do that and is again attempting to malign my search for truth.
[a href=\"index.php?act=findpost&pid=168233\"][{POST_SNAPBACK}][/a]
So, YOU start a thread...we wander all over the topic, we get the feedback and input from people who CLEARLY have more knowledge than all the posters in this thread combined, we (meaning Andrew and I) make an attempt at addressing the issue, definitions and what could be called misconceptions and you are whining that YOUR "search for the truth" is being "maligned" by me?
You gotta be kidding me...right?
Jeeesh...
-
No argument there! But what about before? The crux of debate. Is a Raw a color image?
[a href=\"index.php?act=findpost&pid=168227\"][{POST_SNAPBACK}][/a]
(http://www.pbase.com/jps_photo/image/91855154/original.jpg)
-
Uh huh. . .maybe Andrew should have said Is a Raw file a USABLE color file without demosaicing?
-
RAW data is just data. You can represent it in a number of ways, you can visualize that data in a number of ways. One way is a string of numbers. Do numbers have colour? No! Can they represent colour? Absolutely yes!
If you think RAW does not have a colour space because you visualize raw as a greyscale image, then surely that is because of the visualization, not because of the data, which when correctly interpreted does indeed have a colour space because it's an RGB image.
We must separate data from it's many possible visualizations. To ask a question about colour when you have a monochrome visualization in your head is to ask a meaningless question. To ask if RAW has a colour space, to me, means you're visualizing what the RAW data represents, which is an RGB image, and then the question is no longer meaningless.
Graeme
-
Fight! Fight! Fight!
Seriously, tho, do I need to know any of this? I mean does it help me process my images somehow?
-
You guys all make my head spin...
Just when I think I am getting a decent understanding of color science I read a thread like this.....
i think the last point above is a good one though..
does any of this really make a difference to how we process our images?????
Seems to me its mostly accademic - anyway as long as the debate is healthy its all good.
-
Fight! Fight! Fight!
Seriously, tho, do I need to know any of this? I mean does it help me process my images somehow?
[a href=\"index.php?act=findpost&pid=168259\"][{POST_SNAPBACK}][/a]
No. But for some, its interesting and useful to know what's happening under the hood.
Jack Holms just sent this and for those following the debate with interest, its useful to digest:
A raw image does have a color space if we allow non-colorimetric values to be called color space values. If we don’t allow this then only colorimetric cameras (of which there are very few) have color spaces.
I think it is easer to allow non-colorimetric color spaces and use “colorimetric color spaces” than to invent a new term for non-colorimetric color spaces. (Actually, about ten years ago I proposed the term “spectral space” in ISO but no one liked it.)
What I think is misleading is to give the impression that non-colorimetric cameras have a well-defined relation to colorimetry. Yes, we can estimate colorimetry well enough for practical purposes but different estimates can produce different results and be equally valid.
It is important that critical photographers understand this otherwise they might wonder why they get different results photographing the same scene with different cameras, even when they use the same raw converter. Or, why different conversions to scene-referred produce different results for the same scene and camera. You need to know there is judgment involved in designing the conversion otherwise you won’t know to perform evaluations to see what conversion you like best.
-
Been following along here. Interesting concepts being discussed.
The bayer pattern bird pick got me to thinking what that color space would be to get it to look correct which the bird seems to be already rendered correctly, but by RGB colorants as seen through my vLUT and Monitor colorants. I guess the color space of that image is now in is close to sRGB P22 colorants.
What are the colorants of the actual Bayer filter pattern used to filter the photons coming in to come up with the RGB filtered grayscale densities for each camera?
I've been reading the Help section of Raw Developer which has a custom matrix based profile builder you can build a profile visually by attempting to get the Raw image to render a scene as intended. It was too difficult. Better results using RD's L*a*b* curve tool.
Anyway, this is the quote from the RD Help section about editing and/or creating custom profiles in camera native space:
..."In general digital camera sensors are "linear" and record values proportional to the intensity of light striking the sensor. Most digital cameras also use a form of color filter array (known as a Bayer filter) which filters light into RGB components (red, green, blue) though the precise definition of what color "red" or "green" or "blue" may be is not specified. Some cameras use CMY (cyan, magenta, yellow) filters or other color filter arrangements or even other methods of color capture entirely."...
Are there other RGB colorant forumlas out there other than P22 phosphors and if so how do we find them? Wouldn't this help define the camera/Raw color space?
-
What are the colorants of the actual Bayer filter pattern used to filter the photons coming in to come up with the RGB filtered grayscale densities for each camera?
There is no such thing. It is important to understand, that
a. it is possible to create all or almost all visible colors with the mixing of at least three properly selected, fixed colors (primaries),
b. it is not sufficient to capture only such primary colors with the sensor; the sensor needs to capture *all* wavelengths. Thus the filters are not analogous to the phosphor or to the LED.
In fact, all three "colored" pixels capture the entire or almost the entire visible spectrum, but not all wavelengths equally. Any given wavelength can pass all three filters, but to different degrees in the three kind of filters.
As one would expect it, the red filter lets the light rays in the red range pass through to a higher degree, than other wavelengths (and even the different wavelengths in the red range result in different response). Therefor the three kind of pixels can be seen as the red, green and blue components of an RGB color and this way the original scenery can be reproduced quite well, but it does not come even close to the result of de-mosaicing and color transformation.
I attach two images, one converted by DPP with all neutral settings, the other is with the raw pixels interpreted directly as red, green respectively blue (white balanced on the same spot). Click on the thumbnails to see the larger image (a small crop of a 20D shot).
I added a third rendering: every pixel on the monitor shows only one color component, the one corresponding to the raw pixel's dominant color, the other two components are null. This is much sharper, but darker because of the lack of the two other color components. Furthermore, it is greenish, because half of the pixels are green.
-
There is no such thing. It is important to understand, that
a. it is possible to create all or almost all visible colors with the mixing of at least three properly selected, fixed colors (primaries),
b. it is not sufficient to capture only such primary colors with the sensor; the sensor needs to capture *all* wavelengths. Thus the filters are not analogous to the phosphor or to the LED.
In fact, all three "colored" pixels capture the entire or almost the entire visible spectrum, but not all wavelengths equally. Any given wavelength can pass all three filters, but to different degrees in the three kind of filters.
As one would expect it, the red filter lets the light rays in the red range pass through to a higher degree, than other wavelengths (and even the different wavelengths in the red range result in different response). Therefor the three kind of pixels can be seen as the red, green and blue components of an RGB color and this way the original scenery can be reproduced quite well, but it does not come even close to the result of de-mosaicing and color transformation.
I attach two images, one converted by DPP with all neutral settings, the other is with the raw pixels interpreted directly as red, green respectively blue (white balanced on the same spot). Click on the thumbnails to see the larger image (a small crop of a 20D shot).
I added a third rendering: every pixel on the monitor shows only one color component, the one corresponding to the raw pixel's dominant color, the other two components are null. This is much sharper, but darker because of the lack of the two other color components. Furthermore, it is greenish, because half of the pixels are green.
[a href=\"index.php?act=findpost&pid=168303\"][{POST_SNAPBACK}][/a]
Can you please point out for my benefit in laymans terms what those 3 images are being used to demonstrate? That DPP does a better convsion?
Thanks.
-
There is no need to prove, that DPP does a better conversion, because the other program does not do any (that's not a raw converter).
The second and third images show, that the original image can be reconstracted without a color conversion as well, however the color reproduction based on displaying raw channels as RGB channels is not a substitute for the "proper conversion". I posted these, because tlooknbill was apparently in the belief, that the pixels' filters are analogous to the light emitting sources of a monitor.
Apart from that, these images show, that the "greyscale" theory is unserious. As an addition, here are the images with only red, green or blue, respectively. These show tlooknbill, that the all three "kinds" of pixels are capturing practically the entire scene, but different colors to different degrees. The fourth image shows a selection on the red flower and the pixel statistics over that selection: although the red is dominant, there is much green there and considerable blue as well.
-
Panopeeper said...
"There is no such thing."
...In reference to Bayer Filter array needed to filter the random collection of photons from any given scene collected in the camera sensor's photosite cavity's or containers, buckets how ever you want to call them.
This site provides a simple explanation suggesting otherwise...
http://www.cambridgeincolour.com/tutorials/sensors.htm (http://www.cambridgeincolour.com/tutorials/sensors.htm)
It also says that 2/3 of the information or spectra collected in the scene is discarded. How the heck are you going to derive a color space from a process that throws that much of the full spectra of light away? What colors DO get thrown away? Can this be determined or measured?
I may not have explained it correctly but it still is a fact according to that site that the Bayer RGB primaries are used to filter out that 2/3rd's of light data that gets thrown away. So you can't tell me that the actual appearance/spectral properties of the red, green, blue filters used shouldn't be taken into account as part of the discription of the color space of the camera's sensor. There's just way to many variables in the process to measure from.
I'ld say the color space could be more determined by attaching the same lens used on the camera capturing the scene onto a device that actually measures light and build a profile from that then figure out some way of calculating discarding 2/3rd's of the information.
Looks to me with the dominance of green a table based profile would have to be built with calculations encoded to balance out the green without relying on human intervention in establishing white point color temp. What's the color temp of an overly green image?
-
It also says that 2/3 of the information or spectra collected in the scene is discarded. How the heck are you going to derive a color space from a process that throws that much of the full spectra of light away? What colors DO get thrown away? Can this be determined or measured?
[a href=\"index.php?act=findpost&pid=168314\"][{POST_SNAPBACK}][/a]
Good question! It's not clear to me how much overlapping takes place and how much total light is blocked out by the Bayer filters. Kodak has a patented CFA which includes fewer color filters and more panchromatic filters. If my memory serves, it's 50% panchromatic and 50% R,G, & B, resulting in a S/N improvement of 1-2 stops.
If the improvement is that great by making just half the pixels panchromatic, then the Bayer CFA must be blocking a significant portion of light. Perhaps not 2/3rds, but pretty close.
-
The second and third images show, that the original image can be reconstracted without a color conversion as well, however the color reproduction based on displaying raw channels as RGB channels is not a substitute for the "proper conversion". I posted these, because tlooknbill was apparently in the belief, that the pixels' filters are analogous to the light emitting sources of a monitor.
[a href=\"index.php?act=findpost&pid=168310\"][{POST_SNAPBACK}][/a]
They could be, to some degree. My dark green Yellow Warbler could have been on a monitor with the CFA pattern of the camera, making a 1:1 correspondence; the green pixels could have been weaker, and the red and blue more intense, to make the over-all effect properly white-balanced at a brighter level (I had to cut the intensity of each green in half here), and the image would only be a little bit off from accurate color. With properly designed filters on an LCD monitor, you could probably get close to displaying a RAW in good daylight WB without altering the intensities at all, if the monitor performed the gamma adjustment on the fly.
-
So while we could agree its a data file (no arguments there), we still go back to the original writings of Bruce (essentially Grayscale) versus that of others (color data). Which is it?
Even the four color geeks (three true color scientists that do this for a living) seem to either somewhat disagree or use differing language.
Both Eric and Jack are members of the ICC and spend a great deal of time in the various committees (both part of the camera committee) trying to define these kinds of terms. What hope do we have here of coming to some agreement in terms???
[a href=\"index.php?act=findpost&pid=168204\"][{POST_SNAPBACK}][/a]
Well I would say Bruce ( god bless his ) was talking crap!
He was a, photoshop monkey, not a colour scientist. Colouratti my foot!
RAW file just a data file.
Mr Holm said
"A raw image does have a color space if we allow non-colorimetric values to be called color space values. If we don’t allow this then only colorimetric cameras (of which there are very few) have color spaces.
I think it is easer to allow non-colorimetric color spaces and use “colorimetric color spaces” than to invent a new term for non-colorimetric color spaces. (Actually, about ten years ago I proposed the term “spectral space” in ISO but no one liked it.)
What I think is misleading is to give the impression that non-colorimetric cameras have a well-defined relation to colorimetry. Yes, we can estimate colorimetry well enough for practical purposes but different estimates can produce different results and be equally valid."
Specrtal space is a good term. I would go with Mr Holm on that one.
and this would sum up from Mr Holm
"What I think is misleading is to give the impression that non-colorimetric cameras have a well-defined relation to colorimetry. "
I know this so im out of here.
-
It also says that 2/3 of the information or spectra collected in the scene is discarded. How the heck are you going to derive a color space from a process that throws that much of the full spectra of light away? What colors DO get thrown away? Can this be determined or measured?
I suspect that you misunderstood that site (I have not read it). The filters do filter out a large portion of the light; the proportion depends on the actual filters.
However, they usually don't filter out a range of the visible spectrum, but reduce the intensities depending on the wavelength. If all three filters filter out some visible wavelength completely, then that is lost - and the camera sucks.
Look at the attached graphs of several cameras; they show, in what sense this "2/3 of the spectrum" is meant, namely one filter filters this part more, another that part.
So you can't tell me that the actual appearance/spectral properties of the red, green, blue filters used shouldn't be taken into account as part of the discription of the color space of the camera's sensor. There's just way to many variables in the process to measure from
Funny, that you are saying this. Not only that I have not stated that the spectral responses can be ignored, but I posted earlier in the thread:
Look at the spectral responses of the three channels of different cameras and see, how different these responses are. Do you believe, that these can be described with only nine parameters?
Do you prefer phantom discussions?
-
Look at the spectral responses of the three channels of different cameras and see, how different these responses are. Do you believe, that these can be described with only nine parameters?
[a href=\"index.php?act=findpost&pid=168377\"][{POST_SNAPBACK}][/a]
Rags Gardner ?
Anyway, here’s a comment by Thomas Knoll which I consider to be fundamental in this context. I’ve inserted two words [ ].
“Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix [space] can be used in software to recover the exact XYZ values.
If the filter set is not a [perfect] linear combination of the cone responses (which is the case for all current cameras), then any color calibration is going to be some kind of comprise, getting some colors correct and other colors incorrect. This is true even if you know the exact illuminant spectral curve and the exact filter spectral response curves.”
DPL
--
-
They could be, to some degree. My dark green Yellow Warbler could have been on a monitor with the CFA pattern of the camera, making a 1:1 correspondence
The question is, if the pixels' filters could be analogous to the light emitting sources of a monitor. This means in the context of that post, that the sensor filters would let only a single wavelength (or a very narrow range of wavelengths) pass through.
Such a sensor could capture only a small fraction of a scenery (I don't believe it is technically feasible to create such sensors).
-
If the filter set is not a [perfect] linear combination of the cone responses (which is the case for all current cameras), then any color calibration is going to be some kind of comprise, getting some colors correct and other colors incorrect. This is true even if you know the exact illuminant spectral curve and the exact filter spectral response curves
I think this is true only in the context of the conversion defined by a 3x3 matrix, like ACR is doing it, otherwise the linearity is not a necessary but sufficient condition. I believe (but I don't claim it) that there can be combinations of non-linearly responding filters yielding unambiguos colors. This is very important, for there are no filters with linear response anyway, i.e. one has to live with the the funny responses.
This does not mean, that all existing sensors are capable of delivering unambiguos results; maybe none of them is. However, I think that this is possible with the careful design of the filters; I admit, that this is based only on my "feeling".
-
Rags Gardner ?
Anyway, here’s a comment by Thomas Knoll which I consider to be fundamental in this context. I’ve inserted two words [ ].
“Actually, to create a camera filter set that is "perfect", it is not required to exactly the match the human cone responses (or the XYZ responses). All that is required is the filter responses be some linear combination of the human cone responses. If that is the case, then a simple 3 by 3 matrix [space] can be used in software to recover the exact XYZ values.
If the filter set is not a [perfect] linear combination of the cone responses (which is the case for all current cameras), then any color calibration is going to be some kind of comprise, getting some colors correct and other colors incorrect. This is true even if you know the exact illuminant spectral curve and the exact filter spectral response curves.”
DPL
--
[a href=\"index.php?act=findpost&pid=168400\"][{POST_SNAPBACK}][/a]
Peter,
I remember that quote well because I was participating in that thread on the Adobe forum. I could never quite figure out what "linear combination" meant. What is being plotted on the x and y axis to give a linear curve?
Bill
-
After reading this thread yesterday - Which I freely chose to do - my feeble intellect was somewhat challenged.
My initial reaction to rebuke the pointless nature of the post. I knew I wasn't going to learn something that would have a direct impact on my images.
On reflection, I've decided to invoke the politicians friend, the U turn. Ultimately it's fascinating and worthwhile to understand even just a little more about an important subject like color. It's made all the more worthwhile because there are a number of noteworthy and well informed contributors.
Feeling guilty for yet again spending time reading rather than doing photography, I sentenced myself to the F6 and a roll of Tri-X and proceeded to enjoy myself in a childlike manner. Tomorrow, once I've sobered up from the euphoria that is the simplicity of film I'll pass over the F6, pick up the D3 and realize that there really are some great advantages that ultimately offset the complexity of the digital medium.
Despite knowing the inevitable complexity we are going to face, it's good to peek under the hood from time to time.
Thankyou
-
"If the filter set is not a [perfect] linear combination of the cone responses (which is the case for all current cameras), then any color calibration is going to be some kind of comprise, getting some colors correct and other colors incorrect. This is true even if you know the exact illuminant spectral curve and the exact filter spectral response curves.”
"
Peter,
I remember that quote well because I was participating in that thread on the Adobe forum. I could never quite figure out what "linear combination" meant. What is being plotted on the x and y axis to give a linear curve?
Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=168412\")
Actually, the quote above has it backwards, you want the cone responses to be a linear combination of the filters. Which actually occurs if the opposite is true and the transformation is invertible.
The cone responses are how *you* see. The filter responses are how the *camera* sees. You ant to be able to get the values you would see from the values the camera sees.
In this case assume you have a filter set of spectrums (FR,FG,FB), and cone responses (l,m s) as [a href=\"http://blogs.mathworks.com/steve/2006/12/26/colorful-anniversaries/]described here[/url]. Then you want to have a simultaneous set of equations like
l= a*FR+b*FG+c*FB
m=d*FR+e*FG+f*FB
s=g*FR+h*FG+i*FB
which allows you to compute (l,m,s) -how you see- by a simple matrix multiplication (a linear vector operation) from FR, FG, FB.
Of course (l,,m,s) and (FR,FG,FB) are all spectral responses here, not numbers, so this is in practice never going to happen unless you use multispectral imaging to create FR,FG,FB synthetically (numerically) while using a multispectral camera.
I would strongly recommend that you read a standard colorimetry text and some elementary algebra, we all need a booster shot from time to time.
Edmund
-
Good question! It's not clear to me how much overlapping takes place and how much total light is blocked out by the Bayer filters. Kodak has a patented CFA which includes fewer color filters and more panchromatic filters. If my memory serves, it's 50% panchromatic and 50% R,G, & B, resulting in a S/N improvement of 1-2 stops.
If the improvement is that great by making just half the pixels panchromatic, then the Bayer CFA must be blocking a significant portion of light. Perhaps not 2/3rds, but pretty close.
[a href=\"index.php?act=findpost&pid=168336\"][{POST_SNAPBACK}][/a]
It would be nice to have Raw file from such a camera to see the exact difference, but I think 1 - 2 stops is a bit optimistic. Remember, these unfiltered pixels can only bring the total QE halfway up to the ideal, as only half of the pixels are idealized. I can not help but think that this really cripples the image chromatically in some way.
-
It would be nice to have Raw file from such a camera to see the exact difference, but I think 1 - 2 stops is a bit optimistic. Remember, these unfiltered pixels can only bring the total QE halfway up to the ideal, as only half of the pixels are idealized. I can not help but think that this really cripples the image chromatically in some way.
[a href=\"index.php?act=findpost&pid=168480\"][{POST_SNAPBACK}][/a]
Yes, I wondered about that. The maths doesn't seem to fit. Even if the claimed improvement were only one stop maximum, that would imply that the sensor as a whole was receiving double the amount of light with the same exposure.
But I guess the actual amount of light blocked is scene dependent. Less light is blocked when the scene is predominantly green and more when the scene is predominantly red or blue.
On second thoughts, the maths does fit, doesn't it? If half the sensor receives 3x the amount of light due to the removal of the color filters, then the sensor as a whole receives 1.5x the amount of light, ie. a 1.5 stop advantage.
Oops! Correction again. 1.5x the amount of light is not quite 1.5 stops. Maths is not my strong point .
-
Oops! Correction again. 1.5x the amount of light is not quite 1.5 stops. Maths is not my strong point .
[a href=\"index.php?act=findpost&pid=168486\"][{POST_SNAPBACK}][/a]
1.5x the amount of light is log(1.50)/log(2) = 0.585 stops more light. The reduction in shot noise, however, is only half of that, or 0.292 stops. Read noise, relative to absolute exposure is a full 0.585 stops better.
-
1.5x the amount of light is log(1.50)/log(2) = 0.585 stops more light. The reduction in shot noise, however, is only half of that, or 0.292 stops. Read noise, relative to absolute exposure is a full 0.585 stops better.
[a href=\"index.php?act=findpost&pid=168574\"][{POST_SNAPBACK}][/a]
So on average we're looking at something around one stop advantage, or slightly less?
This is what can happen when one has too many beers the night before. I know that double the amount of light equals one stop.
-
This might be of imterest
-
So on average we're looking at something around one stop advantage, or slightly less?
This is what can happen when one has too many beers the night before. I know that double the amount of light equals one stop.
[a href=\"index.php?act=findpost&pid=168575\"][{POST_SNAPBACK}][/a]
I don't know exactly what we're looking at, because a combination of things is going on, as the DR of the camera is being expanded (but not of the individual pixels). I was just commenting on the absolute sensitivity of photosites that collect 1.5x as much light, a figure you provided; that would mean 0.292 stops improvement in shot noise, and 0.585 for read noise, in those clear photosites.
-
I remember that quote well because I was participating in that thread on the Adobe forum. I could never quite figure out what "linear combination" meant. What is being plotted on the x and y axis to give a linear curve?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=168412\")
Bill,
Based on the CIE XYZ weighting functions, their x-axis is stated as Wavelength [nm]. For respective XYZ color filters, the y-axis would have to scale in terms of Transmittance; at least that’s what the logic of the [a href=\"http://www.fho-emden.de/~hoffmann/ciexyz29082000.pdf]Color matching experiment[/url] seems to suggest.
A linear combination is a blend of these curves as follows:
R-filter= a*X(nm) + b*Y(nm) + c*Z(nm)
G-filter= d*X(nm) + e*Y(nm) + f*Z(nm)
B-filter= g*X(nm) + h*Y(nm) + i*Z(nm)
If this is perfectly fulfilled, the camera’s unambiguously interpretable gamut would be one single matrix space – representing a subset of the corresponding CIE XYZ master space.
If this not perfectly fulfilled (metamerism index of the sensor < 100), we are in need of a Lut-type profile or a “best-fit” matrix space per illuminant, in order to come to a somewhat colorimetric interpretation and conversion of the Raw data into a CIE XYZ sphere again.
My 2ct.
& Best regards….
--
P.S.: fyi (http://white.stanford.edu/~brian/psy221/reader/Wandell.Color%20Reproduction.pdf)
-
Based on the CIE XYZ weighting functions, their x-axis is stated as Wavelength [nm]. For respective XYZ color filters, the y-axis would have to scale in terms of Transmittance; at least that’s what the logic of the Color matching experiment (http://www.fho-emden.de/~hoffmann/ciexyz29082000.pdf) seems to suggest.
[a href=\"index.php?act=findpost&pid=168645\"][{POST_SNAPBACK}][/a]
Peter,
Many thanks for the explanation of the x and y axis and the Wandell reference. It is now clear to me what linear refers to.
A linear combination is a blend of these curves as follows:
R-filter= a*X(nm) + b*Y(nm) + c*Z(nm)
G-filter= d*X(nm) + e*Y(nm) + f*Z(nm)
B-filter= g*X(nm) + h*Y(nm) + i*Z(nm)
If this is perfectly fulfilled, the camera’s unambiguously interpretable gamut would be one single matrix space – representing a subset of the corresponding CIE XYZ master space.
If this not perfectly fulfilled (metamerism index of the sensor < 100), we are in need of a Lut-type profile or a “best-fit” matrix space per illuminant, in order to come to a somewhat colorimetric interpretation and conversion of the Raw data into a CIE XYZ sphere again.
[a href=\"index.php?act=findpost&pid=168645\"][{POST_SNAPBACK}][/a]
To relate these principles to commonly used raw converters, I surmise that Camera Raw and many other converters use a global linear 3x3 matrix conversion and can not obtain a true colorimetric interpretation. Nonetheless, the results can be quite good, since pleasing rather than perfectly accurate color is sufficient for most general photography.
I'm not that familiar with Capture One, but understand that it can use LUT type profiles for a somewhat colorimetric interpretation, but this only works for a specific illuminant. This might be helpful in the studio with controlled lighting, but not for general field photography where the illuminant varies widely.
Wandell talks about polynomial fits and neural networks. Are these used in common raw converters?
Bill
-
Wandell talks about polynomial fits
I have them when I spent too much time reading pages of physics equations (research for a project unrelated to photography, at least for now)...
-
"Polynomial fits", indeed!
Thank you Bill and Jonathan for brightening my day.
-
"Polynomial fits", indeed!
Thank you Bill and Jonathan for brightening my day.
[a href=\"index.php?act=findpost&pid=168710\"][{POST_SNAPBACK}][/a]
I think this discussion is regressing toward infantility. Of course that's only a first approximation of my feelings
Edmund
-
I think this discussion is regressing toward infantility. Of course that's only a first approximation of my feelings
Edmund
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=168791\")
Edmund,
To each his own. Here is another take on this thread by some pretty knowledgeable people over on the [a href=\"http://forums.dpreview.com/forums/read.asp?forum=1021&message=26426262]DPReview Nikon D3 forum[/url]. There are also some interesting comments on the behavior of some contributers to the current thread.
Iiah Borg has written Raw Magick (http://www.rawmagick.com/), a highly regarded Nikon raw converter.
Bill
-
Here is another take on this thread by some pretty knowledgeable people over on the DPReview Nikon D3 forum (http://forums.dpreview.com/forums/read.asp?forum=1021&message=26426262).
[a href=\"index.php?act=findpost&pid=168919\"][{POST_SNAPBACK}][/a]
Well, Iliah doesn't seem to agree with ya when he says: "There is definition of what colour space is (in the sense we use it in image processing, and according to ICC standards), and raw data does not follow it."
So, I guess Iliah doesn't think raw captures (or cameras) have a color space either...
Cool!
:~)
-
Just found something new and interesting buried in this thead I've been exploring. I'm glad I hitched on to this discussion.
On page 26 of Gernot Hoffman's pdf posted in this thread are plotted coordinates of Optimized Primaries on the CIE locus. I've been wondering if such a thing actually existed and would be of some practicle use.
Entered them into Raw Developers custom matrix based profile builder and got a better rendering of a random test shot containing wide gamut colored objects and fleshtone-(the back of my hand) lit by golden hour sunlight.
I was able to bring out more distinction between subtle colors for example in a limestone rock fence included as a backdrop in the shot where I could tell more of a difference between the beige colored mortar, off white limestone rock and the bluish concrete foundation. The default internal profiles of two raw converters pretty much made them look as one color.
I also didn't have to go fishing around for scene referred color temp constantly adjusting red/green sliders. Just clicked on and applied small tweaks to each color gamut triangle corner points and center color temp dot and the white balance as I saw it fell into place. Better than using Hue/Saturation sliders, neutral eyedropper tool or working in LAB space.
This is like a completely different color correcting tool even though I'm not using it as it was intended. I get to work in native camera color space which clips far less than using RD's other CIELab space based color sliders.
I just set color temp to 5000K, output space and working space to ProPhotoRGB and start tweaking. Probably not the most accurate or efficient way of doing things I admit but I found the Optimized Primaries gave me a better starting point to work from in nailing the color as I saw it. No more reddish or overly yellowish fleshtones which is how both Raw Developer and Pentax's SilkyPix based converters' default settings rendered it in the test shot.
I haven't tested if the saved profile would render other images the same way on a consistant basis. I doubt it, but I thought it was a fun, interesting and new way of editing color I've never tried before.
You might say I "found" or "defined" the color space of my camera which seems to be based loosely on Optimized Primaries and 1.0 gamma.
-
At some point, and I think we're beyond that here, these discussions just turn into "the definition game".
Graeme
-
Entered them into Raw Developers custom matrix based profile builder and got a better rendering of a random test shot containing wide gamut colored objects and fleshtone-(the back of my hand) lit by golden hour sunlight.
[a href=\"index.php?act=findpost&pid=168945\"][{POST_SNAPBACK}][/a]
Is that the program by Iridient Digital, and if so where can you enter the primaries? Cant seem to find how
cheers
-
Is that the program by Iridient Digital, and if so where can you enter the primaries? Cant seem to find how
cheers
[a href=\"index.php?act=findpost&pid=168998\"][{POST_SNAPBACK}][/a]
It's probably been disabled by default. At least that's what RD's Help section indicates. Click on Enable Advanced Settings in Preferences.
At the bottom of the Input Tab will be a button that says Edit/Create Profile. You won't be able to edit RD's internal profile of your particular model of camera. What does get assigned/loaded as a starting point is standard sRGB primaries with a 1.0 gamma which will make the preview appear significantly desaturated and washed out depending on exposure and/or how different RD's internal profile is.
It really pays off to ETTR when messing around like this at least it was with my test image. Another option that can be a bit difficult but can grab quite a bit of dynamic range with very little noise in the shadows is editing RD's internal tone curve also in the Input Tab.
Editing for shadows in a linear space requires careful tweaking in a tiny area off the corner black point or else you'll kick up quite a bit of noise in the shadows. You'll be surprised how many tweak points you can cram into there.
Depending on the colors in your image you may have to increase saturation just as a starting point in the Input Color Matrix. Applying it in the other tab encodes in CIELab which can make the histogram go off the charts quite quickly even with Output and Working Space set to ProPhotoRGB. Though in my case it may be due to my using the standard 1.8 gamma ProPhotoRGB which isn't the same as ACR's internal 1.0 gamma version.
Just remember all adjustments in the Input tab only encodes in the linear camera native color space.
-
Well, Iliah doesn't seem to agree with ya when he says: "There is definition of what colour space is (in the sense we use it in image processing, and according to ICC standards), and raw data does not follow it."
So, I guess Iliah doesn't think raw captures (or cameras) have a color space either...
Cool!
:~)
[a href=\"index.php?act=findpost&pid=168931\"][{POST_SNAPBACK}][/a]
As with all of the experts who have commented, Iliah places qualifications on what he considers a color space. He is apparently talking about a colorimetric ICC type color space.The color space of the camera does not conform the ICC spec. He is apparently talking about a colorimetric ICC type color space.
RikWalowit wrote:
<<Does a raw file have a color space?>>
Fundamentally, absolutely YES, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these primaries define the color space of the image.
Practically, it makes little difference unless you are interested in accurate scene-referred data. In the context you described, a simple transform is applied to convert from the camera primaries to a new set of primaries (eg CIE or working space) that have more desirable characteristics than the RAW primaries.
Mathematically, of course, you know the foregoing is true. Matrix algebra informs that if the final color image encoding is a "color space" then so must be all of its infinite number of linear transforms (lets ignore the 1 D non-linear transfer functions), including the original RAW encoding.
Thomas Knoll wrote:
The fact that a mosaic array is “grayscale” is a red herring in this argument. An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result. For most cameras, if you just “assign” a working space RGB profile, you get a recognizable color image as a result, so it certainly seems like a color space.
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently. Any translation from camera color space to CIE XYZ space is an approximation because of this.
Chris Murphy wrote:
I think we'd all agree that CIE XYZ, ProPhoto RGB, and sRGB are each a color space. We consider the whole of ProPhoto RGB a color space even though it contains imaginary colors, from a human point of view. And we consider the whole of sRGB a color space even though it contains less than the colors that we humans can see.
A camera has colors it really can capture and encode as unique values compared to others, that are imaginary to us. They don't exist. There are colors we can see, but the camera can't capture that are imaginary to it. So what to do with these captured values that humans can't see? Well they typically get mapped to something, possibly something that another rather different SPD is already mapped to. Two reds that appear the same to us, but have different SPDs, yet the camera sees them as different so it encodes them with two different RGB values. That's fugitive colors. It's nothing new in photography.
So yes a camera (and thus a Raw file) has a color space. The challenge is what to do with the real and "unreal" colors it's encoding. And how to deal with luminance and dynamic range which is still a really big weak area of the ICC workflow. This is not a one size fits all campaign, to get good results. Color appearance models can help us deal with this better, as getting a 1:1 correlation to XYZ is an appropriate starting point prior to color appearance and gamut mapping, but it's not a desirable end result either on-screen or in print.
Your own arguments about a raw file being grayscale are specious and have been refuted by Thomas Knoll and others. You completely ignore opinion and evidence contrary to your own inflexible and narrow views and do not respond to explanations by others to your objections. Perhaps better not to respond than to argue the unarguable and hope no one will notice. I agree with the DPReview author that it is useless to argue anything with some resident "experts".
"He who corrects an arrogant man earns insult; and he who reproves a wicked man incurs opprobrium. Reprove not an arrogant man, let he hate you; reprove a wise man, and he will love you. Instruct a wise man, and he becomes still wiser; teach a just man, and he advances in learning."
-- Proverbs 9:7-9"
-
As with all of the experts who have commented, Iliah places qualifications on what he considers a color space. He is apparently talking about a colorimetric ICC type color space.The color space of the camera does not conform the ICC spec. He is apparently talking about a colorimetric ICC type color space.
Yes so in this context, its not a color space. Jack Holms said the same thing:
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation. In the standards committees we decided it is useful to be able to talk about non-colorimetric color spaces so we allow them and use “colorimetric color spaces” when appropriate.
So Jeff and Iliah are as Jack puts it, purists.
We've gone over this to death and it apparently will not end until we now define if the Raw represents a colorimetric space. Some say yes, some say no.
-
Yes so in this context, its not a color space. Jack Holms said the same thing:
So Jeff and Iliah are as Jack puts it, purists.
We've gone over this to death and it apparently will not end until we now define if the Raw represents a colorimetric space. Some say yes, some say no.
[a href=\"index.php?act=findpost&pid=169056\"][{POST_SNAPBACK}][/a]
Quite true. Iliah is a purist. To the best of memory, all experts in this thread have verified that raw is not colorimetric, at least with the current CFA filters. However, it still can be considered a color space according to a broader definition. The matter is more than semantics, since the nature of the color space has broad implications for rendering of the color. Dr. Wandell's article discusses ways to overcome non-colorimetric properties.
These distinctions seem to escape Jeff, who seems more like a bull in a china shop than a purist. His lack of insight and subtlety astonish me.
-
These distinctions seem to escape Jeff, who seems more like a bull in a china shop than a purist. His lack of insight and subtlety astonish me.
[a href=\"index.php?act=findpost&pid=169072\"][{POST_SNAPBACK}][/a]
Very little actually "escapes" me bud...and I have no desire nor intent to be "subtle", why should I? But for several years now, you've gone out of your way to be a pain in my arse because of some unknown (and prolly unintended) perceived injustice I committed against you on the Camera Raw User to User fourms...
If you think your petty and childish petulance will have any impact on my judgement or behavior, I suspect you've got other delusional problems as well.
There are things I know I know...there are things I think I know and there are things I would like to know. The sources of my knowledge are pretty varied...it helps to hang around geeks and absorb knowledge (which doesn't always come with understanding) and I'm more than happy to learn things I don't know. I am however, rightly skeptical about the alleged knowledge of many other people I don't know.
Take you for example...I've NEVER seen an actual PHOTOGRAPH from you that gives me any indication you do anything other than sit around with charts and graphs and a calculator. You sometimes seem to grasp some things while being incredibly stubborn about other things. But you couldn't prove it by me that you ARE a photographer...
This whole thread, for an example, is a lightly veiled attempt at disputing things that Andrew and I have said about raw files. Fine and dandy dooode...no, the actual raw image captured on card ain't grayscale...ok? But, it's more like a grayscale file than a color file at least until some sort of color interpretation or demosaicing is done.
You've tried to prove that cameras or raw captures have a "color space" because you either want to prove Andrew and I wrong and therefore enjoy some sort of superiority over us or try to embarrass us. If your true desire were an honest and noble "search for the truth", you wouldn't be throwing the zingers in the discussion about our supposed (or my supposed) boorish behavior.
If you truly were without fault, you wouldn't be stooping to those wasted attempts at behavior modification. I would suggest you look into the mirror dooode. Ask yourself, how are YOU behaving? You may be more "subtle" (something you seem to think has some perceived value) but I challenge you name yourself blameless...people in glass houses shouldn't be throwing stones, ya know?
So, the opening question and the premise of this whole thread "Does a raw file have a color space?" has been answered? Does it or doesn't it? What do _YOU_ think?
-
Quite true. Iliah is a purist. To the best of memory, all experts in this thread have verified that raw is not colorimetric, at least with the current CFA filters. However, it still can be considered a color space according to a broader definition.
[a href=\"index.php?act=findpost&pid=169072\"][{POST_SNAPBACK}][/a]
Yes, if you decide that's the definition that best makes your argument correct. At this point, that's where we're heading. It seems that unless everyone agrees with you that a Raw expresses a color space and to do that, we'd need to disagree with the experts that say its not colorimetric.
One could say, the broader definition is, Raw is essentially Grayscale but that didn't sit well with you. So at this point, I don't see why this thread needs to go any further. Broader or narrower, this is a debate that isn't going to come to full agreement. Why continue?
-
Edmund,
To each his own. Here is another take on this thread by some pretty knowledgeable people over on the DPReview Nikon D3 forum (http://forums.dpreview.com/forums/read.asp?forum=1021&message=26426262). There are also some interesting comments on the behavior of some contributers to the current thread.
Iiah Borg has written Raw Magick (http://www.rawmagick.com/), a highly regarded Nikon raw converter.
Bill
[a href=\"index.php?act=findpost&pid=168919\"][{POST_SNAPBACK}][/a]
I'm sorry, Bjanes, somebody else was talking about polynomial fits, which can be used as a form of the approximation method called regression. Regression is the approved doctrine for constructing camera profiles.
Last time I looked puns were still allowed on this forum. We went from throwing fits to regression, maybe what is funny to me isn't funny to you
From the list of participants here, seems to me we've done the expert bit quite adequately, and it might be time to wrap up and head home.
Andrew - I agree we've come full circle. Time to go have a virtual beer.
Edmund
-
One could say, the broader definition is, Raw is essentially Grayscale but that didn't sit well with you. So at this point, I don't see why this thread needs to go any further. Broader or narrower, this is a debate that isn't going to come to full agreement. Why continue?
[a href=\"index.php?act=findpost&pid=169092\"][{POST_SNAPBACK}][/a]
RAW is not "grayscale", any more than aRGB or sRGB is grayscale. The files or data for all contain numbers, numbers that are colorless until they are colored through some understood meaning.
The confusion comes, perhaps, from the fact that the most efficient and convenient way to store a RAW image is to lay it out flat in one plane, as opposed to three (since with CFAs, there is only one color plane used per 2D pixel location), and hence the RAW data "fits" into the greyscale image format. Its R,G, and B channels are just as distinct in meaning as are those in aRGB and sRGB.
-
Actually, the same can be said of many RGB formats which are often stored interleaved (ie non planar), RGBA, and can be interpreted as a greyscale mosaic.
I can see how people can discus "what do we mean by "colour space"", but to get into disagreements over RAW Bayer pattern data saying it can't be a colour space because it's greyscale are, I'm sorry to say, daft beyond belief. There are valid un-demosaiced interpretations of raw Bayer data that directly produce colour images that are as equally valid as the so called greyscale interpretation, just as I can easily produce a greyscale mosaic interpretation of some RGB data.
Graeme
-
RAW is not "grayscale", any more than aRGB or sRGB is grayscale. The files or data for all contain numbers, numbers that are colorless until they are colored through some understood meaning.
Ah but if we use the so called wider definition, sRGB is most certainly three Grayscale channels. You see, if you wish to define something widely, you can.
And you say "colored through some understood meaning" but an untagged document is an undefined color space. So what is it? We can define it as we wish, again using wider definition.
I was told I was being silly earlier in the thread by taking like a lawyer. But there's so much fudge factor here, we might as well end this by agreeing to disagree. But the color geeks have said pretty clearly that a non colorimetric Raw file isn't in a color space. But it is in the wider definition....
-
I was told I was being silly earlier in the thread by taking like a lawyer. But there's so much fudge factor here, we might as well end this by agreeing to disagree. But the color geeks have said pretty clearly that a non colorimetric Raw file isn't in a color space.
[a href=\"index.php?act=findpost&pid=169118\"][{POST_SNAPBACK}][/a]
You are in a state of denial.
RikWalowit wrote:
<<Does a raw file have a color space?>>
Fundamentally, absolutely YES
Thomas Knoll wrote:
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently. Any translation from camera color space to CIE XYZ space is an approximation because of this.
Chris Murphy wrote:
So yes a camera (and thus a Raw file) has a color space.
Case rested. Res ipsa loquitur
Why argue further with people who disregard the opinion of even their own experts and do not respond to reason?
-
You are in a state of denial.
RikWalowit wrote:
<<Does a raw file have a color space?>>
Fundamentally, absolutely YES
Thomas Knoll wrote:
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently. Any translation from camera color space to CIE XYZ space is an approximation because of this.
Chris Murphy wrote:
So yes a camera (and thus a Raw file) has a color space.
Case rested. Res ipsa loquitur
Why argue further with people who disregard the opinion of even their own experts and do not respond to reason?
[a href=\"index.php?act=findpost&pid=169121\"][{POST_SNAPBACK}][/a]
I think you're either in the same state or just "Have to be right".
Jack wrote:
Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries.
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation. In the standards committees we decided it is useful to be able to talk about non-colorimetric color spaces so we allow them and use “colorimetric color spaces” when appropriate.
That Thomas says "fundamentally" we'll ignore, it makes what you're saying easier to accept.
This is of course a totally black and white argument, everyone totally agrees with you that Raw is a color space, lets dismiss what Jack and Iliah are saying.
Case rested. OK, James, you're right, Jack is wrong, Iliah is wrong, Schewe is wrong, you're right. OK, feel better? Can we move on?
-
Case rested. OK, James, you're right, Jack is wrong, Iliah is wrong, Schewe is wrong, you're right. OK, feel better? Can we move on?
[a href=\"index.php?act=findpost&pid=169124\"][{POST_SNAPBACK}][/a]
Not so fast my fine doggy friend...our good friend Mr. Janes hasn't answered my simple question (nor the opening question of the thread)...does raw have a color space?
I've read through the entire thread and can't really find any single, simple statement that he does..he wanders around (and says he thinks I remind him of Joseph Goebbels which is kinda a cowardly way of calling me a Nazi) but to my reading, he STILL hasn't said what he thinks and defines what HE thinks a "color space" is.
-
Don't let Mr. Janes raise your blood pressure, Jeff. He's from Lake Forest, which, well, pretty much sums it up. There must be something in the water to the north of us that gives its residents a delusional superiority complex
Of course, Lake Forest is relatively close to the Windy City. If Mr. Janes truly has a set of brass ones, why doesn't he offer to meet with you in person, perhaps in a place with sufficient resources, and perhaps a good bottle of wine, and the two of you hash out this argument like a couple of color scientists.
Michael could act as referee and Chris could film the entire meeting of the minds. It could even be offered as a Luminous Landscape download called "The Great Color Space Shootout".
What do you say, Mr. Janes?
-
Michael could act as referee and Chris could film the entire meeting of the minds. It could even be offered as a Luminous Landscape download called "The Great Color Space Shootout".
Worth its weight in Gold :-)
But seriously.. this thread.. has been interesting.. but its probably time it was put to bed as it has started to get a little personal and warranted or not its never a good thing to thrash these things out in a public forum.
-
...but its probably time it was put to bed as it has started to get a little personal and warranted or not its never a good thing to thrash these things out in a public forum.
[a href=\"index.php?act=findpost&pid=169164\"][{POST_SNAPBACK}][/a]
Why is it not a good thing to thrash such matter out in public? This is at least the second time this topic has emerged in the past few months. If you don't sort things out and get a general concensus, the topic keeps re-emerging.
-
Why is it not a good thing to thrash such matter out in public? This is at least the second time this topic has emerged in the past few months. If you don't sort things out and get a general concensus, the topic keeps re-emerging.
[a href=\"index.php?act=findpost&pid=169169\"][{POST_SNAPBACK}][/a]
I agree with that.. its when it gets 'personal' that its best taken off the forums. If its on topic then its all good.
-
Why is it not a good thing to thrash such matter out in public? This is at least the second time this topic has emerged in the past few months. If you don't sort things out and get a general concensus, the topic keeps re-emerging.
[a href=\"index.php?act=findpost&pid=169169\"][{POST_SNAPBACK}][/a]
Ray,
I tried that approach. I sent Andrew an e-mail with the same essay that I eventually posted and suggested that perhaps he should consult his technical experts for an opinion. However, he did not respond.
The reason the topic recurs, is that these mafia "experts" keep making the same unqualified and misleading statements. This time around, we had a pretty good discussion that was joined by some true experts. I think I've make my point, which is supported by Thomas Knoll and Chris Murphy.
Iliah Borg summed up the substance of the matter:
"For me however the true meaning of the discussion is whether it is possible to build an accurate camera profile using ICC-type approach or not; even if for a particular light source. RIT and our own experiences both suggest resounding "no". That makes the methods used by Adobe look sub-optimal and some folks feel bad about that defending their beloved."
Bill
-
Not so fast my fine doggy friend...our good friend Mr. Janes hasn't answered my simple question (nor the opening question of the thread)...does raw have a color space?
I've read through the entire thread and can't really find any single, simple statement that he does..he wanders around (and says he thinks I remind him of Joseph Goebbels which is kinda a cowardly way of calling me a Nazi) but to my reading, he STILL hasn't said what he thinks and defines what HE thinks a "color space" is.
[a href=\"index.php?act=findpost&pid=169141\"][{POST_SNAPBACK}][/a]
See my post #51, and also post #94. To paraphrase Bill Clinton, that depends on what the meaning of "is" is. I think with proper qualification, one could say that raw does or does not have a color space. It is better to discuss the scientific principles involved rather than making an unqualified blanket statement that a raw file can't have a color space since it is grayscale.
-
Don't let Mr. Janes raise your blood pressure, Jeff. He's from Lake Forest, which, well, pretty much sums it up. There must be something in the water to the north of us that gives its residents a delusional superiority complex
Of course, Lake Forest is relatively close to the Windy City. If Mr. Janes truly has a set of brass ones, why doesn't he offer to meet with you in person, perhaps in a place with sufficient resources, and perhaps a good bottle of wine, and the two of you hash out this argument like a couple of color scientists.
Michael could act as referee and Chris could film the entire meeting of the minds. It could even be offered as a Luminous Landscape download called "The Great Color Space Shootout".
What do you say, Mr. Janes?
[a href=\"index.php?act=findpost&pid=169156\"][{POST_SNAPBACK}][/a]
I do not respond to ad hominem attacks other than to deplore them. FWIW, I've lived in Chicago for more years than in Lake Forest. How would you feel if I stated that your statements were invalid because you are from Chicago and are most likely a racist and gangster? That is not my view--I think Chicago is a great city and I thoroughly enjoyed my years living there.
-
Ray,
I tried that approach. I sent Andrew an e-mail with the same essay that I eventually posted and suggested that perhaps he should consult his technical experts for an opinion. However, he did not respond.
Ah, so its the lack of a response (something that makes even more sense now) that has you all up in arms and going after the so called pixel mafia.
You obviously missed all the posts (some would say too many) I contributed to this set of threads with information from various experts who would also ignore your emails if they knew how you behaved in public forums.
The reason the topic recurs, is that these mafia "experts" keep making the same unqualified and misleading statements.
That sound you may have heard was me throwing up. Misleading statements. Give us a break.
This time around, we had a pretty good discussion that was joined by some true experts. I think I've make my point, which is supported by Thomas Knoll and Chris Murphy.
Gee, where did they come from? And they only took your position part way. If you think you made your point, can you go away now and let us suffer in the huge humiliation you've subjected us to? We are not worthy! That sound was me throwing up again. What a mess.
Iliah Borg summed up the substance of the matter:
"For me however the true meaning of the discussion is whether it is possible to build an accurate camera profile using ICC-type approach or not; even if for a particular light source. RIT and our own experiences both suggest resounding "no". That makes the methods used by Adobe look sub-optimal and some folks feel bad about that defending their beloved."
He summed it up FOR YOU (he also said Raw wasn't colorimetric data, then Jack said.... Never mind, we've seen this all before, you just don't want to accept it. Its pretty obvious that the only reason you started all this was to be "right" so even when we try to make the child feel good and say "good boy, you're right (even if we don't fully believe it), you've got to continue acting like a little boy. What on earth did you contribute here other than acting like a spoiled child? I'm embarrassed now that I contacted the experts who would trash your emails in a second in an attempt to provide some useful data on the subject. This thread should be closed!
-
I do not respond to ad hominem attacks other than to deplore them. FWIW, I've lived in Chicago for more years than in Lake Forest. How would you feel if I stated that your statements were invalid because you are from Chicago and are most likely a racist and gangster? That is not my view--I think Chicago is a great city and I thoroughly enjoyed my years living there.
[a href=\"index.php?act=findpost&pid=169215\"][{POST_SNAPBACK}][/a]
"Ad Hominem" eh? So what, you're now a Latin Professor as well as a Color Scientist AND Camera RAW Evangelist?
Your previous posts in this thread have included a certain degree of "ad hominem", Mr. Janes.
I find it humorous that you are so quick to strike back with the good disciple mantra, though.
-
He summed it up FOR YOU (he also said Raw wasn't colorimetric data, then Jack said.... Never mind, we've seen this all before, you just don't want to accept it.
[a href=\"index.php?act=findpost&pid=169220\"][{POST_SNAPBACK}][/a]
I can't believe your selective quoting. You quote experts who agree with you and completely ignore those who don't, even when their statements are directly quoted back to you. I give up.
In a previous post, I said I had more respect for you when you published the responses from Knoll, Murphy, et al. But now I have to retract that statement, since you have backtracked when you received a couple more opinions, completely ignoring the qualifications that these latter experts placed on their statements. In my opinion, you are merely trying to save face (as was noted in the DPReview thread).
You say I only want to prove that I am correct, but I have said more than once that depending on one's definitions, one could reasonably conclude that raw does or does not have a color space. I've already acknowledged your viewpoint in that area, so how can you say that I am hellbent on proving that I am right?
Your initial unqualified statement that raw did not have a color space because it is grayscale is not logical.
-
This discussion is way out of my league and have turned into a flamewar. It will surely be closed. Hopefully I can get some useful answers before its closed. I'm not here to discuss, but to listen. Its not often I have a chance of asking leading experts in color management like Andrew Rodney.
Background:
I have a small business where we have to do our proofing ourselves. We make our own marketing material and uses pictures both for print (aRGB) and internet (sRGB). Since our photography skills is limited to "point and click", we need others to take pictures for us. We have rented studio, photographer and model for this purpose last year. On occation, we have borrowed a Cannon 400D camera for taking pictures of our work in the field. Some pictures have been bought over the internet from various sites as well.
Since we are not taking the pictures ourselves, we are at the mercy of the photographer, and since we are a small business, errors can cost relatively much.
The print service offers fresh printer profiles and paper type, so we can do softproofing at least.
Still, its important to know what we are doing and why, and when I see people with this much knowledge unable to reach a middle ground, I get uncertain of my own understanding of this.
If anyone could point out my misunderstanding in this, I'd be greatful:
Raw:
My understanding is that this is the digital equivalent of a negative. It contains no colors until its "developed" or processed. Colors and colorspaces are assigned upon conversion and there are no colors or colorspaces before that, only raw data that can be translated into colors. Even the colors are not a an unchangable illuminant, since the color itself depends on the color space you assign to it.
Raw is not very standardized and can differ from camera to camera.
Colorspace:
In my work, I use the one defined by CIE. Its my understanding that its a theoretical (since impression of colors differ from eye to eye) mathematical expression of colors which are within the visible spectrum of the eyes.
Color spaces have clear borders defined by gamut inside CIE. The CIE borders represent visible colors for the eyes, though colors reach beyond that. If it doesn't have defined borders, its not a color space.
Since I work with different white points for print and internet, and also have different color spaces, raw should be my preferred choice. I can alter white point without loss of bit depth and color gamut. Especially since I need to softproof the images anyway. It gives me more flexibility to make the pictures as I want, since I have no skills in taking them myself.
-
Does a raw file have a colour space?
So what the out come Yes or No
Can the forum moderator add a poll feature( as seen in other forums) so we all can vote.
-
If anyone could point out my misunderstanding in this, I'd be greatful:
Raw:
My understanding is that this is the digital equivalent of a negative. It contains no colors until its "developed" or processed. Colors and colorspaces are assigned upon conversion and there are no colors or colorspaces before that, only raw data that can be translated into colors. Even the colors are not a an unchangable illuminant, since the color itself depends on the color space you assign to it.
Raw is not very standardized and can differ from camera to camera.
I think it would be useful (depending on the behavior of some to be unnamed) if you started a new post with these excellent questions. In the meantime however, you should probably read this piece Jack and I wrote for the ICC which should help in understanding the differences in rendering and encoding (and the differences in scene and output referred colorimetry):
http://www.color.org/icc_white_paper_20_di...ment_basics.pdf (http://www.color.org/icc_white_paper_20_digital_photography_color_management_basics.pdf)
-
Does a raw file have a colour space?
So what the out come Yes or No
[a href=\"index.php?act=findpost&pid=169243\"][{POST_SNAPBACK}][/a]
Yes.... No... Yes.... No.... She's my daughter, she's my sister.... Slap.
-
I think it would be useful (depending on the behavior of some to be unnamed) if you started a new post with these excellent questions. In the meantime however, you should probably read this piece Jack and I wrote for the ICC which should help in understanding the differences in rendering and encoding (and the differences in scene and output referred colorimetry):
http://www.color.org/icc_white_paper_20_di...ment_basics.pdf (http://www.color.org/icc_white_paper_20_digital_photography_color_management_basics.pdf)
[a href=\"index.php?act=findpost&pid=169245\"][{POST_SNAPBACK}][/a]
Thanks! I think this is what I've been looking for! Its crucial to us to get this right, so its much appreciated.
-
As a non-expert I have been following this thread eagerly, hoping for illumination (with or without a Color Space). For the past couple of thousand posts it has seemed as if every poster is either (1) arguing for one or another definition of "color space" or (2) accepting the idea that there may be different definitions used by different people (even by "experts").
I decided to make an inquiry of one more Expert in the field, the esteemed Humpty Dumpty, and here is the conversation as well as I can recall it:
'When I use a word,' Humpty Dumpty said, in a rather scornful tone,' it means just what I choose it to mean, neither more nor less.' 'The question is,' said Alice, 'whether you can make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
Your previous posts in this thread have included a certain degree of "ad hominem", Mr. Janes.
I find it humorous that you are so quick to strike back with the good disciple mantra, though.
[a href=\"index.php?act=findpost&pid=169230\"][{POST_SNAPBACK}][/a]
A good point, Jeff, but there are differences. TGPhoto's post was completely ad hominem with no supporting logic or facts. Perhaps the intent of my Goebbels comparison escaped you. I had become frustrated by your habit of repeating the same thing over and over again (broken record), while failing to respond to arguments put forth by others. As you may recall, Goebbels said if you tell an untruth 1000 times, people will begin to believe it. Not to say that your assertions were lies, but merely incomplete and unqualified.
-
A good point, Jeff, but there are differences. TGPhoto's post was completely ad hominem with no supporting logic or facts. Perhaps the intent of my Goebbels comparison escaped you.
[a href=\"index.php?act=findpost&pid=169251\"][{POST_SNAPBACK}][/a]
Uh, even your own inline quote should have alerted you to the fact you should have been responding to TGPhoto, not me dooode. And no, the "Goebbels comparison" didn't escape me...yes, I knew he was in change of the Nazi propaganda machine...but it's interesting to note that with a German last name, you choose a Nazi to compare me to. You're just lucky I'm not Jewish (Andrew is and might find a Nazi comparison rather distasteful–I just find it indicative of your general sleazy approach).
Post 51 says:
However, if one does use that definition, then a raw file or a digital camera does not have a color space
Post 94 says:
However, it still can be considered a color space according to a broader definition.
So, which is it Bill...did you or did you not have sex with that woman–Monica Lewinsky?
See, even _YOU_ are going around in circles...
-
(as was noted in the DPReview thread).
[a href=\"index.php?act=findpost&pid=169232\"][{POST_SNAPBACK}][/a]
If you are trying to compare LL with DPreview, your logic is fuzzy at best. I've been a member of both forums for about the same length of time, and the MISinformation which is spewed forth on DPreview as gospel truth is simply amazing.
At this point, I could care less if you think RAW has a color space or not. Your personal attacks on Jeff and Andrew, coupled with your unwillingness to accept the expert opinions of pioneers such as Thomas who are at the forefront of this technology, makes it very difficult for anyone here to take you seriously.
You made your point, and re-made it several times over. The forum thinks otherwise. At what point do you step down off your podium? Your bull stubborn approach does little to help your cause.
Keep yapping Bill as I am sure we'd all love this thread to go on for another 47 pages with you spewing the same mantra over and over again like a broken record. Doing so doesn't doesn't mean anyone here is going to change their opinion to suit your personal agenda.
So come on, since I know you can't stand to step down (it's always the smallest dogs that have the loudest barks...coincidence?) why don't you ask the question again....does RAW have a color space?
-
Uh, even your own inline quote should have alerted you to the fact you should have been responding to TGPhoto, not me dooode. And no, the "Goebbels comparison" didn't escape me...yes, I knew he was in change of the Nazi propaganda machine...but it's interesting to note that with a German last name, you choose a Nazi to compare me to. You're just lucky I'm not Jewish (Andrew is and might find a Nazi comparison rather distasteful–I just find it indicative of your general sleazy approach).
Post 51 says:
Post 94 says:
So, which is it Bill...did you or did you not have sex with that woman–Monica Lewinsky?
See, even _YOU_ are going around in circles...
[a href=\"index.php?act=findpost&pid=169264\"][{POST_SNAPBACK}][/a]
Jeff,
As I stated, I will not waste time replying to ad hominem debating techniques other than to denounce the approach. OK, the Goebbels comparison was over the top, and I retract it and offer my apologies. With respect to your final question, that depends on what the meaning of "is" is. With proper qualification, I think that either argument is acceptable, and that is the consensus of the experts who have given their opinions. I find it interesting that you have yet to acknowledge any limitations in your own arguments.
I agree it is time to close down this thread, since both views have been well represented. I would encourage the sysop to mark the thread as read only.
-
At this point, I could care less if you think RAW has a color space or not. Your personal attacks on Jeff and Andrew, coupled with your unwillingness to accept the expert opinions of pioneers such as Thomas who are at the forefront of this technology, makes it very difficult for anyone here to take you seriously.
[a href=\"index.php?act=findpost&pid=169276\"][{POST_SNAPBACK}][/a]
Really, I would regard the statements by Thomas Knoll and Chris Murphy as supportive of my viewpoint and nowhere have I refused to accept their opinions. Since you have apparently not taken the time to read this thread and determine what actually was said, I regard your comments as completely irrelevant and misleading.
-
I regard your comments as completely irrelevant and misleading.
[a href=\"index.php?act=findpost&pid=169288\"][{POST_SNAPBACK}][/a]
Right back at ya bud! Keep drinking the water up there in Lake Forest, Billy Boy. It seems to suit you just fine.
I'll stick with science & research, backed by expert opinion and real world experience.
If you ever do decide to come down from whatever you are on and join reality, be sure and let us know if RAW has a color space.
Cheers!
-
Getting back on topic, the screenshots below are my attempt at finding an approximate color space of my Pentax K100D RAW file in the language of CIExyz using Raw Developer's eyeball profile creator. With all the subtle color variances I get between Raw converters it seems interpretation by software should be considered as part of the color space recipe. I can't see how you could separate this.
The images are a representation of these variances. It also shows how easily color errors can be induced if just a smidgeon off the xyz radial axis adjust for each primary and color temp transform which causes me to think that software is far more part of the equation in determining the color space of any digital RAW file rather than the camera's lens/sensor characteristics in how it records spectral reflectance properties of any given scene.
I used the J.Worthy primaries as a starting point to get the test image to look as I saw it at capture. The variances I got of the different cyan hues in the LuLu doll, the different colors in the limetone brick work, fleshtone and pink bow makes it hard to find the exact color space because I can't tell if it's the software or the scene causing the variances.
Determining the color space of a Raw file seems like an unknowable thing.
[attachment=4875:attachment][attachment=4876:attachment][attachment=4877:attachm
ent][attachment=4878:attachment]
-
Determining the color space of a Raw file seems like an unknowable thing.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169398\")
That is because the camera space is not colorimetric. See this post for an excellent explanation: [a href=\"http://luminous-landscape.com/forum/index.php?showtopic=22471&view=findpost&p=168050]Post 14[/url].
There are approaches other than a 3x3 matrix transform that can circumvent some of these problems.
Bill
-
I just find it indicative of your general sleazy approach).
[a href=\"index.php?act=findpost&pid=169264\"][{POST_SNAPBACK}][/a]
I'm sleazy for pointing out your fuzzy logic (grayscale) and deficient debating style (broken record, ignoring and failing to respond to valid objections to your argument, and out right refusal to accept expert opinion that does not agree with your viewpoint--Knoll, Murphy et al)?
There was a glimmer of sunshine when you acknowledged that Thomas Knoll and Chris Murphy might know more than you to, but on seeing the opinion of a couple of more experts and taking their opinions out of context and ignoring the qualifications they placed on their statements, you reverted to your old broken record tactics.
Using your lexicon, I would call you congenial .
-
That is because the camera space is not colorimetric. See this post for an excellent explanation: Post 14 (http://luminous-landscape.com/forum/index.php?showtopic=22471&view=findpost&p=168050).
There are approaches other than a 3x3 matrix transform that can circumvent some of these problems.
Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169459\")
Hi Bill!
I've paid attention to this discussion (and your previous one) about raw files and color space. My understanding for this when it comes to practical use for my firm got fortunately resolved earlier in this thread thanks to some help.
But, I'm still curious about why this is discussed. For a non-expert like me, it seems as following:
You are saying that raw is a cake because you have flour, egg, sugar, salt, baking soda etc.
Digital dog and Schewe says that you need to bake the cake by mixing and cooking before it becomes one and the flavor depends upon what receipt you use. For now you only have the raw materials.
I read this one too, in an attempt to understand the discussion better:
[a href=\"http://www.cambridgeincolour.com/tutorials/RAW-file-format.htm]http://www.cambridgeincolour.com/tutorials...file-format.htm[/url]
Could you explain your point of view a bit easier for us non-experts?
Edit: I understand much of what you say and much seems logical. I think what I have biggest problems understanding, is how to define raw as color space with the absense of scaling. As far as I've read here, you assign a scale afterwards and the raw file doesn't have a predetermined scale before this.
This is where I have a hole in my knowledge. How can a raw file have a color space when its values aren't predetermined upon a standardized scale? It would be easier to understand if raw had a scale like CIE. Even if the camera then didn't have a color space of its own, it would be a % of a color space if being open minded. At least a non-colormetric color space. Same as with screens. XXX% of aRGB, XX% of sRGB etc.
In my logic it just as hard as determin length without any measurement units. I can't see how it works without a defined scale.
-
Bill,
Hope you don’t mind an unusually open comment as follows:
As we all know: The Raw file is just a “gray moth“ until the #1 Raw converter turns it into a “beautiful butterfly“. A kind of ab initio Genesis of color, close to a religious dogma.
Marketing messages have to be simple!
Hence, it’s easy to conflict with Adobe evangelists. Provocation and escalation are just part of the game to drive you in a corner. The pattern is unchanged since years, through various discussions and accross different forums. Even worse, often enough any third-class cheerleaders feel obliged to fill-in and then you can typically forget about it.
Ignore it. Whenever you quote such nonsense you are repeating it, you’re duplicating the message. On the other side, many reasonable guys have contributed here (including Andrew’s initial post). So I just can recommend to focus on this part … and you might find more support than expected, whether explicitly given or in between the lines.
Have a nice weekend.
& Best regards, DPL
--
-
Bill,
Hope you don’t mind an unusually open comment as follows:
As we all know: The Raw file is just a “gray moth“ until the #1 Raw converter turns it into a “beautiful butterfly“. A kind of ab initio Genesis of color, close to a religious dogma.
Marketing messages have to be simple!
Hence, it’s easy to conflict with Adobe evangelists. Provocation and escalation are just part of the game to drive you in a corner. The pattern is unchanged since years, through various discussions and accross different forums. Even worse, often enough any third-class cheerleaders feel obliged to fill-in and then you can typically forget about it.
Ignore it. Whenever you quote such nonsense you are repeating it, you’re duplicating the message. On the other side, many reasonable guys have contributed here (including Andrew’s initial post). So I just can recommend to focus on this part … and you might find more support than expected, whether explicitly given or in between the lines.
Have a nice weekend.
& Best regards, DPL
--
[a href=\"index.php?act=findpost&pid=169531\"][{POST_SNAPBACK}][/a]
Peter,
I appreciate your comments. Misinformation, fuzzy logic, carrying water for the master, and arrogance rub me the wrong way, but your recommendation is sound.
Bill
-
But, I'm still curious about why this is discussed. For a non-expert like me, it seems as following:
You are saying that raw is a cake because you have flour, egg, sugar, salt, baking soda etc.
Digital dog and Schewe says that you need to bake the cake by mixing and cooking before it becomes one and the flavor depends upon what receipt you use. For now you only have the raw materials.
Could you explain your point of view a bit easier for us non-experts?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169484\")
Tamlin,
Please do not include me among the experts. I am an amateur photo enthusiast and would like to be considered as an intelligent layman with some background in science and math (my profession is medicine).
A raw file from a Bayer sensor contains the color information in the form of a mosaic, as explained very well by Sean MacHugh (by the way, a chemical engineer) on the Cambridge in color site. It contains all the information captured by the sensor, and should not be considered gray scale or monochrome, because the latter type of file contains only luminance information.
Since the mosaic image contains only one color per pixel, the other two colors are filled in by demosaicing early in the conversion process, and you have a 3 or 4 channel image as a result ([a href=\"http://luminous-landscape.com/forum/index.php?showtopic=22471&view=findpost&p=168050]Thomas Knoll[/url]).
The RGB values in the raw file are determined by the spectral characteristics of the sensor and the light falling on the sensor. An intermediate step in raw processing is to convert these color values to those of the internal working space of the raw converter, usually CIE XYZ or linear ProPhotoRGB in the case of ACR.
As Mr. Knoll explained, a perfect conversion could be obtained if the color filters in the camera had a linear relationship to the response of the human eye. Such a sensor is termed colorimetric. Unfortunately, real world sensors vary somewhat from the ideal and are non-colorimetric. In this case, an exact conversion to the CIE XYZ space can not be made, and only an approximation can be accomplished. For a somewhat technical explanation of these processes, see p. 19 of the Wandell reference which discusses colorimetric and non-colorimetric conversions. According to the methods employed, different raw converters may give different approximations. However, at this stage the recipe is relatively precise.
The next step in the raw conversion is to render the intermediate image into a standard colorimetric working space such as Adobe RGB. This rendering is a complicated process and involves considerable compression of the dynamic range to something than be used by a printer or display device. In addition, out of gamut colors have to be mapped into the working space and saturation may be boosted for a better appearance. Excellent discussions of this process are on the Adobe forum (Krogh and Lang). IMHO, this rendering is where the major variations in the recipe occur, and these variations have little to do with whether or not the sensor is colorimetric.
Edit: I understand much of what you say and much seems logical. I think what I have biggest problems understanding, is how to define raw as color space with the absense of scaling. As far as I've read here, you assign a scale afterwards and the raw file doesn't have a predetermined scale before this.
This is where I have a hole in my knowledge. How can a raw file have a color space when its values aren't predetermined upon a standardized scale?
In my logic it just as hard as determin length without any measurement units. I can't see how it works without a defined scale.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169484\")
The scale of the raw file is determined by the characteristics of the sensor, and is often expressed as coefficients for a 3x3 matrix conversion. Unlike as with a standard CIE space, these coefficients are not embedded in the raw file but are implicit, according to what camera is being used. However, for a non-colorimetric sensor, the scale is somewhat ambiguous. This is where the argument as to whether a raw file has a color space or not comes in. Some authorities state that a space must be colorimetric and allow an unambiguous interpretation. According to this definition, a raw file does not have a color space. Other authorities do not require that a color space be colorimetric (including Thomas Knoll and Chris Murphy) and affirm that a raw file does have a color space. It is more important to understand concepts than get hung up on semantics. To me it makes sense in the understanding of the conversion process to regard the raw file as having a color space that can be converted to the intermediate space and then the final working space by standard methods.
References:
[a href=\"http://white.stanford.edu/~brian/psy221/reader/Wandell.Color%20Reproduction.pdf]Wandell[/url]
Krogh (http://www.adobe.com/digitalimag/pdfs/non_destructive_imaging.pdf)
Lang (http://wwwimages.adobe.com/www.adobe.com/products/photoshop/family/prophotographer/pdfs/pscs3_renderprint.pdf)
-
Thank you for the time and information you have provided! One thing I've learned from philosophy studies, is that there is not nessesarily only one truth and one truth doesn't make the other false. I find this topic interesting and even though it might not result into a conclution, it will still be a learning process that would be useful. I'll read the information and links you have provided and hopefully be wiser and have a better understanding of the discussion!
Edit: I've started reading now and backtracking a bit. Just so I know I'm on the right track, I'd like to ask (and unfortunately I need to invent a word, so you get what I mean. I'm not native english and don't know the correct word for it):
We are talking about a non-colorimetric color space here, not defined as we are used to by CIE reference space with a standardized scale for all raw file, yes?
And the scale and colorspace referred to here, is an inherited color space (invented, I know, but can't find a word for it). The scale of the colorspace is defined by the spectral characteristics of the sensor and the light falling on the sensor, not a standardized colorspace and this is the reference color space.
So what we do, is to convert the non-colorimetric inherited (from camera) colorspace into a colorimetrical color space as defined by CIE reference space when we convert raw into a picture targeted with our output-referred device?
-
Thank you for the time and information you have provided! One thing I've learned from philosophy studies, is that there is not nessesarily only one truth and one truth doesn't make the other false. I find this topic interesting and even though it might not result into a conclution, it will still be a learning process that would be useful. I'll read the information and links you have provided and hopefully be wiser and have a better understanding of the discussion!
Edit: I've started reading now and backtracking a bit. Just so I know I'm on the right track, I'd like to ask (and unfortunately I need to invent a word, so you get what I mean. I'm not native english and don't know the correct word for it):
We are talking about a non-colorimetric color space here, not defined as we are used to by CIE reference space with a standardized scale for all raw file, yes?
And the scale and colorspace referred to here, is an inherited color space (invented, I know, but can't find a word for it). The scale of the colorspace is defined by the spectral characteristics of the sensor and the light falling on the sensor, not a standardized colorspace and this is the reference color space.
So what we do, is to convert the non-colorimetric inherited (from camera) colorspace into a colorimetrical color space as defined by CIE reference space when we convert raw into a picture targeted with our output-referred device?
[{POST_SNAPBACK}][/a]
(http://index.php?act=findpost&pid=169572\")
Tamlin,
Your conceptualization more or less similar to mine, but I'm not a color scientist. For us non-experts, I think it is more important to have a general conceptual overview of the process than trying to delve into the details, which are quite complex and likely beyond our grasp as shown reading the Wandell reference.
Finally, we should note that color is a perception by the eye and brain rather than a physical attribute. [a href=\"http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html]Poynton[/url] sums it up in his color FAQ: "Sir Isaac Newton said, 'Indeed rays, properly expressed, are not coloured.' SPDs exist in the physical world, but colour exists only in the eye and the brain."
It is interesting to note that Dr. Wandell is in the psychology department at Stanford, not the physics or engineering departments.
Bill
-
I'm sleazy for pointing out your fuzzy logic (grayscale) and deficient debating style (broken record, ignoring and failing to respond to valid objections to your argument, and out right refusal to accept expert opinion that does not agree with your viewpoint--Knoll, Murphy et al)?
[a href=\"index.php?act=findpost&pid=169460\"][{POST_SNAPBACK}][/a]
No...I would call the following ad hominem attacks which YOU seem to decry when aimed at you, but seem perfectly acceptable when coming from YOU...that's what I consider sleazy because you don't seem to have the capacity to understand (nor control) your own outbreaks.
See:
#8
"Some prominent photographers have taken the rubbish route, including Jeff Schewe and Andrew Rodney. "
#52
"He accuses me of arguing about how many angels fit on a pin, but what he seems to be trying to accomplish is having to retract any of his ill-considered statements and reach any common understanding of the scientific principles involved. His broken record method of debate reminds me of that used by Joseph Goebbels. "
#86
"Here is another take on this thread by some pretty knowledgeable people over on the DPReview Nikon D3 forum. There are also some interesting comments on the behavior of some contributers to the current thread."
#92
""He who corrects an arrogant man earns insult; and he who reproves a wicked man incurs opprobrium. Reprove not an arrogant man, let he hate you; reprove a wise man, and he will love you. Instruct a wise man, and he becomes still wiser; teach a just man, and he advances in learning."
-- Proverbs 9:7-9""
#94
"These distinctions seem to escape Jeff, who seems more like a bull in a china shop than a purist. His lack of insight and subtlety astonish me."
#131
"Misinformation, fuzzy logic, carrying water for the master, and arrogance rub me the wrong way, but your recommendation is sound."
#108
"The reason the topic recurs, is that these mafia "experts" keep making the same unqualified and misleading statements. This time around, we had a pretty good discussion that was joined by some true experts."
So, it's ok for YOU to resort to ad hominem debate methodology but it's considered poor form when you are the brunt (or your ad hominem is thrown back at ya)? That's what I think is a sleazy method of behavior. And yes, you did say
"OK, the Goebbels comparison was over the top, and I retract it and offer my apologies."
And if I thought for a New York Minute you were sincere I might consider it, but no, alas, you continue to squeal like a stuck pig claiming innocence while lashing out at every potential opportunity (or so it seems). So, from my point of view, the statement was made, insufficiently (or dishonestly) retracted and you aren't the less bit inclined to show any sort of honest contrition.
Oh, yeah, this whole thread was a sleazy (my opinion) attempt at trying to use the guise of scientific discussion to try to discredit statements by Andrew and myself and I point to these following words as guidance...
"I did not want to engage in another flame war over this topic, and had written you privately concerning this matter. On receiving no reply I made the public post."
So, you posted this whole thread as a thrown gauntlet, right? And you don't see anything sleazy in that?
OK, so, since you are just being you (and I am being me) what do you say if I just ignore you as a user? That way I won't be tempted to respond to you...so now you join two others who I have chosen to ignore on the forums. See ya, bye!
-
After looking through all of the posts by all of the experts, I see some important distinctions between a RAW file and a standard LAB or ProPhoto RGB image:
1. The color data in the RAW is not as strictly defined. The spectral characteristics of the camera CFA are not included in the RAW data. And even if they were, choosing the best way to handle the mismatches between the CFA response and that of the human eye boils down to a judgment call, and no one method is always superior. The best we can do so far is to make an approximation that works in as many situations as possible, but there is no perfect method yet.
2. The RAW data must have a white balance assigned to it before any color conversion to LAB or a standard RGB editing space can occur. This is another judgment factor, and varying this can change the accuracy of the color conversion dramatically. Even if there is a WB reference in the RAW image, it still falls on the photographer to select the part of the image that constitutes the WB reference, and even then the WB setting will be tweaked to some degree in many cases.
While the RAW data does have color information, there are 2 factors that prevent that color information from being as precisely defined in a RAW file as it is in a LAB or a standard RGB space. And those two factors are significant distinguishing characteristics between a fully defined color space such as LAB or ProPhoto and what one has in a RAW file.
-
Dear Jonathan ,
"Colour space" simply does not work for raw data for the purpose of raw conversion, it is not an operative term here. Not only the nature of raw data is very different from what "colorimetric colour space" describes; but there is also an instrumental difference. In colour space we define such operations over the colours (like in colour correction) which leave the resulting colour in the same colour space. Operations over the raw data that leave it in raw state is an oxymoron.
Minor things that may be worth mentioning.
CFA response is not all we need to take into account, silica response is no less important. Sensor changes its response substantially across its surface, and depending on the heat which is also non-uniform across the sensor and other elements in the pipeline. Some cameras include autocalibration to account for that, even changing white balance coefficients that go into metadata; some don't.
In a lot of cases with printers we also have problems with ambiguous colour transforms and need to address them based on our personal preferences - that is, lack of precise definition of colour is not one of the reasons that put raw data so much apart from anything else. Even when converting from a large colour space like Lab to a smaller one, like AdobeRGB, the way we map colours sometimes is not straightforward and may be the case to use softproofing.
There are different ways to demosaic raw data. In some cases we do not apply white balance before demosaicing; in some we apply both white balance and gamma transform - and then go to demosaicing. Demosaicing is not always act over the RGBG data, and some demosaicing algorithms even do not consider the raw data to be RGBG. That is not to mention we have different sensor structures, CMY, RGBW, RGBE, RrGgBbGg etc. Even in traditional sensors responses from G1 and G2 are not always the same, G1 allowing to better approximate luminosity while G2 - colour.
-
I agree with your minor points except for one thing:
What happens when one maps colors that fall within the source space but are out-of-gamut in the destination is an entirely separate situation from RAW conversion. When converting a ProPhoto image to sRGB, we know exactly what the source colors are. When converting RAW to ProPhoto, we do not. The colorimetric meaning of the RAW data changes depending on the WB setting chosen, as well as the method used to demosaic and interpolate to RAW RGB, and then convert from the RAW RGB to ProPhoto or whatever. At best, we have an educated guess regarding what the color is supposed to be, often sacrificing technical accuracy for a subjective "looks better" result. When converting from ProPhoto to sRGB, we know exactly what the source colors are, the question is merely how to intentionally alter those colors in the least damaging way so that they fit in the destination space.
If there are no out-of-gamut colors, one can convert back and forth between LAB, sRGB, and ProPhoto, and the only alteration to the color channel values will be due to rounding errors, which can be minimized by performing the calculations in 16-bit mode. Each space has a unique definition for a given color.
This is not true of RAW. For any given color, there are any number of RAW values that could match that color. For example, shooting the same scene in tungsten, fluorescent, direct sunlight, open shade, etc. will result in different RAW values. But with a well-designed RAW converter and a decent WB reference, the ProPhoto conversions of these divergent RAWs will be reasonably similar.
-
No...I would call the following ad hominem attacks which YOU seem to decry when aimed at you, but seem perfectly acceptable when coming from YOU...that's what I consider sleazy because you don't seem to have the capacity to understand (nor control) your own outbreaks.
See:
#8
"Some prominent photographers have taken the rubbish route, including Jeff Schewe and Andrew Rodney. "
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169638\")
You do not seem to understand the meaning of ad hominem. Here is the defintion from Dictionary.com:
ad ho·mi·nem
–adjective
1. appealing to one's prejudices, emotions, or special interests rather than to one's intellect or reason.
2. attacking an opponent's character rather than answering his argument.
Rubbish route was used by another poster to describe your faulty logic. It refers to a defect in logic rather than to your person or character and is not ad hominem.
#52
"He accuses me of arguing about how many angels fit on a pin, but what he seems to be trying to accomplish is having to retract any of his ill-considered statements and reach any common understanding of the scientific principles involved. His broken record method of debate reminds me of that used by Joseph Goebbels. "
[a href=\"index.php?act=findpost&pid=169638\"][{POST_SNAPBACK}][/a]
I have printed out 68 pages of this thread and can't find any significant scientific contribution from Jeff, despite his alleged expert status. All he does is obstruct the discussion. It is impossible to debate with him because he does not respond to counter arguments at all or merely repeats the assertion that was challenged.
[a href=\"http://luminous-landscape.com/forum/index.php?showtopic=22471&view=findpost&p=168039]Post 11[/url] Jeff poses questions in an attempt to prove his point. Both Panopeeper and I post detailed responses. Not a peep out of Jeff.
Post 52 (http://luminous-landscape.com/forum/index.php?showtopic=22471&view=findpost&p=168233) Selective quoting and broken record. Jeff initially acknowledges statements made by Thomas Knoll, Chris Murphy, and Eric Walowit. Then he hears another opinion and without any explanation or qualification, he says "screw it" and goes back to his original position. The broken record method is used mainly to ignore the truth of other arguments and to avoid admitting error. One of the best known practitioners of this style was Joseph Goebbels. That doesn't mean Jeff is a Nazi, but merely that he uses the methods of a person who was very adept at avoiding the the truth and who was not open to reason.
#86
"Here is another take on this thread by some pretty knowledgeable people over on the DPReview Nikon D3 forum. There are also some interesting comments on the behavior of some contributers to the current thread."
#92
""He who corrects an arrogant man earns insult; and he who reproves a wicked man incurs opprobrium. Reprove not an arrogant man, let he hate you; reprove a wise man, and he will love you. Instruct a wise man, and he becomes still wiser; teach a just man, and he advances in learning."
-- Proverbs 9:7-9""
[a href=\"index.php?act=findpost&pid=169638\"][{POST_SNAPBACK}][/a]
Jeff, follow your own advice and look in the mirror.
OK, so, since you are just being you (and I am being me) what do you say if I just ignore you as a user? That way I won't be tempted to respond to you...so now you join two others who I have chosen to ignore on the forums. See ya, bye!
[a href=\"index.php?act=findpost&pid=169638\"][{POST_SNAPBACK}][/a]
That is fine with me. You have contributed nothing significant to this thread and it is a waste of time to debate with you for the reasons given above.
-
Dear Jonathan,
The point is that ambiguity of the colour transform is not something new and unexpected, and is not the reason to separate raw. The nature of the ambiguity is different, but as it often happens it can be dealt with exactly in the same manner as with real colour spaces. Raw converter is soft proofer, for this matter. All the controls you have there are just for that. In many ways we deal with raw in the same manner as we deal with images untagged with colour space. We chose one that gives acceptable rendition and correct from there.
One more minor point - I do not see why you brought ProPhoto to this. However I leave it to you.
-
You have contributed nothing significant to this thread and it is a waste of time to debate with you for the reasons given above.
Dear Bill, I can't agree with you at all. Jeff contributed his photographic vision of the matter. For a photographer it is quite obvious that today the whole colour space concept does not work for raw data. It is just plain visible.
-
Lastly back (?) to a discussion based on reasoning instead of emotions and face-saving activities.
1. The color data in the RAW is not as strictly defined. The spectral characteristics of the camera CFA are not included in the RAW data
The color data of the raw image is strictly defined by the spectral characteristics of the sensor and filters.
IMO it is irrelevant if the characteristics included in the file or not.
a. Let's assume, that we add an array per filter color to the raw file, describing the spectral responses in 1 nm steps, which is more than enough. Would the color information suddenly become a color space?
b. Billions of sRGB JPEG images do not carry any color space information in the file. Are their colors in a color space or not?
c. Is it enough to know, which color space applies to a given image, or is it necessaruy to include the color space's description in each file? A raw image file carries the identification of the camera, which implies the characteristics.
even if they were, choosing the best way to handle the mismatches between the CFA response and that of the human eye boils down to a judgment call, and no one method is always superior. The best we can do so far is to make an approximation that works in as many situations as possible, but there is no perfect method yet
In other words your definition includes the requirement, that there be the knowledge in public domain, how to do the best transformation. Fair enough.
Btw, the claim that no one method is always superior is unsupported.
The RAW data must have a white balance assigned to it before any color conversion to LAB or a standard RGB editing space can occur. This is another judgment factor, and varying this can change the accuracy of the color conversion dramatically
What about an in-camera TIFF or JPEG with incorrect WB setting? What about the image after raw conversion with a WB setting, which has to be changed later? Do such images become "color space-less" suddenly?
Not only the nature of raw data is very different from what "colorimetric colour space" describes
The existence of the two distinct terms color space and colorimetric color space implies, that these are not the same.
No-one claimed, that (all) raw images are colorimetric.
Operations over the raw data that leave it in raw state is an oxymoron
Raw state is not a color space. However, for example Canon 1DsMkIII raw image implies a color space (IMO). Many operations on the raw image leave that unchanged, for example white balancing, lightness adjustment, black point and white point setting.
Sensor changes its response substantially across its surface, and depending on the heat which is also non-uniform across the sensor and other elements in the pipeline. Some cameras include autocalibration to account for that, even changing white balance coefficients that go into metadata; some don't
This is supposed to be an argument for or against what?
in some we apply both white balance and gamma transform - and then go to demosaicing
Again, this is irrelevant, but I doubt it anyway ("gamma transform" before de-mosaicing). Though there is no limit of making something worse and worse.
-
One more minor point - I do not see why you brought ProPhoto to this. However I leave it to you.
I was just using ProPhoto as an example of a fully-defined, unambiguous RGB color space. That is all.
-
Dear Bill, I can't agree with you at all. Jeff contributed his photographic vision of the matter. For a photographer it is quite obvious that today the whole colour space concept does not work for raw data. It is just plain visible.
[a href=\"index.php?act=findpost&pid=169758\"][{POST_SNAPBACK}][/a]
Iliah,
Thanks for your comments. I guess I'm more into the science of the discussion and "the vision thing" escapes me.
I should point out to our readers that you are the author of Raw Magick, a well regarded but little used raw converter for Nikon raw files. Adobe Camera Raw does appear to use a 3x3 matrix transform to transform the "camera space" into a colorimetric working space and you criticized this approach in the DPReview thread: "That makes the methods used by Adobe look sub-optimal and some folks feel bad about that defending their beloved." Since Jeff is an ACR proponent and his mentor is Thomas Knoll, it seems strange that he would object to the non-colorimetric color space 3x3 transform approach that Adobe uses. Has he actually objected?
Could you explain briefly how Raw Magick and possibly Nikon Capture differ in interpreting non-colorimetric data and how the results differ subjectively and in terms of delta E?
Finally, I have received a number of private e-mails congratulating me for standing up to the "bullies". These persons do not wish to go public and be subject to the abuse that would ensue. Perhaps I misinterpreted the intent of your Proverbs quotation. How is it to be interpreted?
Regards,
Bill
-
Lastly back (?) to a discussion based on reasoning instead of emotions and face-saving activities.
The color data of the raw image is strictly defined by the spectral characteristics of the sensor and filters.
a. Let's assume, that we add an array per filter color to the raw file, describing the spectral responses in 1 nm steps, which is more than enough. Would the color information suddenly become a color space?
You're forgetting one extremely important factor, the color characteristics of the lighting of the subject. It is not enough to know exactly the color behavior of the camera sensor and CFA. In order to process the RAW properly, we must define white balance somehow. This is the fundamental ambiguity I'm talking about. Regardless of how well documented the camera/sensor behavior, there are a large number of materially different unique RAW files that can correspond with a given subject, depending on the spectral distribution of the lighting.
IMO it is irrelevant if the characteristics included in the file or not.
b. Billions of sRGB JPEG images do not carry any color space information in the file. Are their colors in a color space or not?
c. Is it enough to know, which color space applies to a given image, or is it necessaruy to include the color space's description in each file? A raw image file carries the identification of the camera, which implies the characteristics.
In other words your definition includes the requirement, that there be the knowledge in public domain, how to do the best transformation. Fair enough.
Not exactly. I'm proposing the notion that a full-fledged color space has one and only one unambiguous numeric designation for a color that falls within its gamut. If you take the sRGB color R215, G133, B37 you have a particular shade of orange. If you convert that color to LAB or ProPhoto, you have one and only one set of values that represents that color in those spaces. This is not true of RAW data.
Let's consider a Foveon RAW to eliminate the complications of demosaicing and color interpolation. You can shoot a Color Checker in a variety of lighting conditions and the RAW data values will be materially different, even though the colors of the subject have not changed. With a good selection of white balance values for each conversion, one can make all of them match quite closely after converting to ProPhoto. The proper colorimetric interpretation of the RAW data is dependent on what the meaning of "is" is, AKA the WB setting. This is not true of a properly converted JPEG image, whether or not it has a profile tag. As long as we know what the correct profile is, we can display the image with unambiguously correct colors. But with RAW, we can't tell from the RAW data alone (even with detailed camera spectral response data) the difference between a white object illuminated by an orange light source and an orange object being illuminated by a white light source.
I think ultimately the solution to more accurate color from RAW will be to use a conversion process that accounts for the spectral response of the camera sensor + CFA and the spectral characteristics of the lighting. This would reduce or eliminate changes in the output color palette when shooting with spiky light sources like sodium vapor lamps vs. continuous spectrum sources like sunlight.
-
I think if you all look at the following chapters in
Colour Engineering, Achieving Device Independent Colour, (2002) Eds Phil Green and Lindsay Macdonald. John Wiley & Sons Ltd, England.
ISBN 0-471-48688-4.
For PANOPEEPER
"The color data of the raw image is strictly defined by the spectral characteristics of the sensor and filters.
IMO it is irrelevant if the characteristics included in the file or not. "
Chapter 6
Overview of characterization Methods - Phil Green.
Give a good outline of device characterization and the relationship with CIE colorimetry.
And for the rest of the contributers to this thread I hope this will eventually clear thins up.
Chapter 8
Methods for characterizing colour scanners and digital cameras -Tony Johnston.
Chapter 9
Colour processing for digital photography - Jack Holm, Ingeborg Tastl, Larry Hanlon and Paul Hubel.
Chapter 17
Managing color in digital image libraries- Sabine Süsstrunk
There is enough content to settle this debate - just read and enjoy!
-
Adobe Camera Raw does appear to use a 3x3 matrix transform to transform the "camera space" into a colorimetric working space
Dear Bill, I would call the above an oversimplification.you criticized this approach in the DPReview thread: "That makes the methods used by Adobe look sub-optimal and some folks feel bad about that defending their beloved."
This was targeted at you, Bill. Sorry. You are defending in this thread things that you do not understand. Watching you in this thread I thought first we have a case of stolen identity. I never saw you before insulting people that way.Since Jeff is an ACR proponent
Maybe not when it comes to blindly accepting default colour from ACR/LR. You should remember this response from Jeff, as you participated in that thread:
"The way I do it is open the image in DPP running iin the background and open the image in Camera Raw in the foreground and then adjust the Camera Raw renderings to match (more or less) the DPP renderings. Yes it involves adjusting the Calibrate sliders after careful WB and tone settings that may include curves...if you find a setting you like or matches the DPP rendering, save it out as a saved setting or subsetting. "
https://forum.adobe.com/webx/.3bbd164e.3bbf2d76?14 (https://forum.adobe.com/webx/.3bbd164e.3bbf2d76?14)I should point out to our readers that you are the author of Raw Magick, a well regarded but little used raw converter for Nikon raw files."
Do you have the number of users to claim it is "little used"?
-
"The color data of the raw image is strictly defined by the spectral characteristics of the sensor and filters.
No it isn't. Your statement is equivalent to saying that exposure is defined by shutter speed irrespective of aperture and ISO. The camera sensor/CFA characteristics are only half of the equation. The spectral characteristics of the lighting are equally pertinent to the RAW values that are recorded, which is why every RAW converter has a White Balance setting. If RAW data was unambiguously colorimetric like LAB or ProPhoto RGB, then a white balance setting would be unnecessary.
-
Sorry Johnathan
that was supposed to be a quote from Panopeeper
My mistook. ill use the qoute button next time.
-
I think if you all look at the following chapters in
Colour Engineering, Achieving Device Independent Colour, (2002) Eds Phil Green and Lindsay Macdonald. John Wiley & Sons Ltd, England.
ISBN 0-471-48688-4.
Chapter 9
Colour processing for digital photography - Jack Holm, Ingeborg Tastl, Larry Hanlon and Paul Hubel.
Chapter 17
Managing color in digital image libraries- Sabine Süsstrunk
There is enough content to settle this debate - just read and enjoy!
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=169783\")
Papa,
I'm sure your references would be helpful in understanding the issues, but how many people do you think are going to buy these references? The Green et al book appears pretty technical and may be more than most of us need.
[a href=\"http://www.amazon.com/s/ref=nb_ss_gw/103-2409157-8372632?url=search-alias%3Daps&field-keywords=Colour+Engineering&x=17&y=15]Color Engineering [/url]: US $132 at Amazon.com
Some online references would be more helpful.
Bill
-
Maybe not when it comes to blindly accepting default colour from ACR/LR. You should remember this response from Jeff, as you participated in that thread:
"The way I do it is open the image in DPP running iin the background and open the image in Camera Raw in the foreground and then adjust the Camera Raw renderings to match (more or less) the DPP renderings. Yes it involves adjusting the Calibrate sliders after careful WB and tone settings that may include curves...if you find a setting you like or matches the DPP rendering, save it out as a saved setting or subsetting. "
https://forum.adobe.com/webx/.3bbd164e.3bbf2d76?14 (https://forum.adobe.com/webx/.3bbd164e.3bbf2d76?14)
[a href=\"index.php?act=findpost&pid=169784\"][{POST_SNAPBACK}][/a]
In that thread Jeff was merely telling us how he gets the output ACR to more or less match that of DPP. He did not state which default color was preferable or more accurate and certainly he made no mention of undesirable characteristics in the non-colorimetric rendering by ACR, nor did he mention the conversion methods used by DPP. He mentions the calibrate tab of ACR; as I understand it, the calibrate procedure adjusts the matrix coefficients for the transform and makes use of the ACR approach of matrix conversion rather than negating it.
Of course, this may be an oversimplification and I don't have more than a general concept of the process. Perhaps you can offer some clarification?
Do you have the number of users to claim it is "little used"?
[a href=\"index.php?act=findpost&pid=169784\"][{POST_SNAPBACK}][/a]
Not at the tip of my fingers. I've seen surveys that list ACR/Lightroom at the top of the list followed by the camera makers programs, Bibble, and a few others. I have not seen Raw Magick on the lists. Perhaps you can give us some figures. I am a registered user of Raw Magick and like it, but personally I use ACR because it does a good job and fits into my work flow. I use Raw Magick and even Nikon Capture NX on selected important images.
That said, I do not consider myself a cheerleader for ACR or its conversion methods, but merely stated that Thomas Knoll considered that raw files have a color space, which differs in certain respects from some more common working spaces.
Regards,
Bill
-
Unfortunately there's not much at that level on the web.
Technical, yes but I think if you really want an understanding of current issues facing digital photography and colour management, I would recommend it.
Its well written and for those who have been in this thread I dont think it would be beyond them.
It took me several reads to digest it! Burp!
A good site is of course the ICC
http://www.color.org/index.xalter (http://www.color.org/index.xalter)
and the guy to ask is Phil!
He will put you right!
or here is set of link that might helphttp://www.digitalcolour.org/Links.htm (http://www.digitalcolour.org/Links.htm)
-
Sorry Johnathan
that was supposed to be a quote from Panopeeper
Oops. My mistake. Regardless of who made the statement, my objection to it is still the same.
-
The camera sensor/CFA characteristics are only half of the equation
That is unquestionable; I understood my
The color data of the raw image is strictly defined by the spectral characteristics of the sensor and filters
regarding the raw data in general, not a specific image. The specific white balance is a characteristic of the particular image, which has to be assigned independently of the color space in use.
As ACR demonstrates it, the WB can be (re)set even in JPEG form.
If RAW data was unambiguously colorimetric like LAB or ProPhoto RGB, then a white balance setting would be unnecessary.
Again: no-one claimed the raw images (in general) to be colorimetric (colorimetric implies unambiguousity).
If you convert that color to LAB or ProPhoto, you have one and only one set of values that represents that color in those spaces
This is a fundamental mistake; please re-evalute this point, which may influence your opinion on the topic.
-
Adobe Camera Raw does appear to use a 3x3 matrix transform to transform the "camera space" into a colorimetric working space
ACR uses two transforms for two different illuminations (I have not see anything else but "Standard illuminant A" and D65). The matrices for other illuminations are interpolated based on these two.
-
This is a fundamental mistake; please re-evalute this point, which may influence your opinion on the topic.
Please explain what you mean. sRGB 215, 133, 37 has one and only one equivalent color value in ProPhoto (161, 124, 51) or LAB (63, 27, 61). In contrast there are many RAW values that can be converted to this shade of orange, depending on the spectral characteristics of the lighting.
-
sRGB 215, 133, 37 has one and only one equivalent color value in ProPhoto (161, 124, 51) or LAB (63, 27, 61). In contrast there are many RAW values that can be converted to this shade of orange, depending on the spectral characteristics of the lighting
That's right, in this direction. However, your statement was
you have one and only one set of values that represents that color in those spaces
The backward conversion is ambiguous.
-
The backward conversion is ambiguous.
Ambiguous how? If you're in 16-bit mode in PS, you can convert back and forth between sRGB, ProPhoto, and LAB numerous times before rounding errors change any of the 8-bit versions of the channel values. It's anything but ambiguous. It's only when you try to convert from sRGB back to RAW that things get ambiguous.
-
If you're in 16-bit mode in PS, you can convert back and forth between sRGB, ProPhoto, and LAB numerous times before rounding errors change any of the 8-bit versions of the channel values. It's anything but ambiguous
Not so. How do you think the projection from a larger set on a smaller one can be unambiguous?
I suggest you to pick an image with strong (saturated) colors, or use this shot of colorful silk flowers: http://www.panopeeper.com/Download/RawDemo_40D_3.CR2 (http://www.panopeeper.com/Download/RawDemo_40D_3.CR2)
Convert it in ProPhoto with ACR and load it in PS, in 16bit. Check out the gamut (Shift-Ctrl-Y), there must be quite a few places warning of conversion problem.
Make four copies of it and convert them in sRGB with the four different intents.
Copy these as layers together and compare them against each other in difference mode; the differences are tiny, but they are there (you need to magnify the differences, for example by a curve). The saturation against the perceptual shows no difference, but the difference is undisputable against the relative version.
But that's nothing. Make another copy and convert it in sRGB with saturation intent, but this time using the Microsoft engine. Layer that one to the others and be surprized.
-
Make four copies of it and convert them in sRGB with the four different intents.
Four? That those profiles only have a colorimetric table. Absolute will likely look funky. RelCol is going to be what you get with Saturation or Perceptual selected in Photoshop since those tables don't exist.
-
Four? That those profiles only have a colorimetric table. Absolute will likely look funky. RelCol is going to be what you get with Saturation or Perceptual selected in Photoshop since those tables don't exist.
I remember to have read, that not all of them have been realized, but I did not remember, which one not. Now I compared all against the others.
First, the Adobe engine:
- saturation shows tiny differences against absolute and more against relative, but none against perceptual.
- perceptual shows tiny differences against absolute and more against relative.
- absolute shows much difference against relative.
According to the above, perceptual and saturation are identical. Absolute is close to these two, but not completely identical - what can cause the difference?
With the Microsoft engine:
- saturation against perceptual: small but clear, against absolute: huge, against relative: small but clear
- perceptual against absolute: huge, against relative: none
- absolute against relative: huge
So, perceptual and absolute are the same.
Anyway, all that does not change the fact, that the transformation from ProPhoto to sRGB is ambiguous.
-
Not so. How do you think the projection from a larger set on a smaller one can be unambiguous?
First of all you need to pay closer attention to what you read. I'm starting from sRGB in my example, which means there cannot be any out-of-gamut colors when converting to ProPhoto or LAB.
Second, your argument is totally irrelevant. If the source color is outside the destination space, defining its location in the destination space is not ambiguous, it's impossible. The best we can do is attempt to select an alternate color within the destination space that is as close as possible to the original color. The process we use to select alternate in-gamut colors may be ambiguous, but that does NOT mean we don't know exactly what the source color is. When the source colors fall within the destination space, we can convert back and forth at will with no ambiguity at all. sRGB (215, 133, 37) = ProPhoto (161, 124, 51) = LAB (63, 27, 61).
Contrast that to a Foveon RAW pixel with RGB value 215, 133, 37 (scaled to 8 bits). That RAW RGB value could represent anything from orange to white, depending on the lighting illuminating the subject. Even if we have perfect knowledge of the sensor's color behavior, we still do not know what color that RAW RGB value represents until we choose a white balance setting. The white balance setting chosen can make that pixel almost any color at all after RAW conversion. That is what I mean by ambiguity. The RAW data by itself, even if tagged with detailed camera color response data, cannot distinguish between an orange object shot in white light and a white object shot in orange light. The correct interpretation can be found only when white balance is set properly. A properly converted RGB image does not have this issue; if a sRGB pixel has the value 215, 133, 37 we know unequivocally that pixel is a specific shade of orange. There are no other factors that affect how one should interpret that color.
-
So, perceptual and absolute are the same.
Anyway, all that does not change the fact, that the transformation from ProPhoto to sRGB is ambiguous.
[a href=\"index.php?act=findpost&pid=169874\"][{POST_SNAPBACK}][/a]
I'm not discussing ambiguity, you guys can go at it.
There's only ONE table in simple matrix profiles (all working spaces including ProPhoto RGB): Colorimetric. Doesn't matter what you select with what engine. You can't get perceptual. You get either RelCol or Absolute. At some point, V4 Profiles should change this (the only V4 working space profile I know of is a specialized version of sRGB).
This is one reason, as you report that the differences are so small.
Output profiles (complex LUT based profiles) have two other tables; Perceptual and Saturation.
-
No it isn't. Your statement is equivalent to saying that exposure is defined by shutter speed irrespective of aperture and ISO. The camera sensor/CFA characteristics are only half of the equation. The spectral characteristics of the lighting are equally pertinent to the RAW values that are recorded, which is why every RAW converter has a White Balance setting. If RAW data was unambiguously colorimetric like LAB or ProPhoto RGB, then a white balance setting would be unnecessary.
[a href=\"index.php?act=findpost&pid=169785\"][{POST_SNAPBACK}][/a]
Contrast that to a Foveon RAW pixel with RGB value 215, 133, 37 (scaled to 8 bits). That RAW RGB value could represent anything from orange to white, depending on the lighting illuminating the subject. Even if we have perfect knowledge of the sensor's color behavior, we still do not know what color that RAW RGB value represents until we choose a white balance setting. The white balance setting chosen can make that pixel almost any color at all after RAW conversion. That is what I mean by ambiguity. The RAW data by itself, even if tagged with detailed camera color response data, cannot distinguish between an orange object shot in white light and a white object shot in orange light. The correct interpretation can be found only when white balance is set properly. A properly converted RGB image does not have this issue; if a sRGB pixel has the value 215, 133, 37 we know unequivocally that pixel is a specific shade of orange. There are no other factors that affect how one should interpret that color.
I have to say I'm puzzled by this line of reasoning. The spectral characteristics of the lighting are what they are, the sensor doesn't change its physical properties according to what the light source is. Indoor light simply has less blue, and that's why the raw data under such lighting will have a very underexposed blue channel. The sensor records that fact (filtered by the spectral transmissivity of the CFA filters; why is that not colorimetric?
An orange object shot in white light and white object shot in orange light both look orange to my eyes; and they will both be recorded as orange by a camera sensor. If you want to make the white object look white after the fact by monkeying with the controls in Photoshop, that's up to you but that's not the spectral composition of the light just after it reflected off the object at the scene.
Just thinking out loud here, isn't the need for white balance related to the gamma correction applied to the raw data? If the illuminant had one EV less blue than green and red, then applying a gamma curve will amplify the green and red 2^gamma more than the blue and throw the colors out of whack relative to what they were at the scene. This suggests to me that the white balance is needed due to some historical artifact -- that the common display device used to be a CRT with gamma around two or so. If the standard were changed and LCD's used a linear gamma instead of trying to match the old CRT display's gamma~2, then white balance correction shouldn't be needed. An output device with linear gamma would reconstruct precisely (leaving aside issues of spatial interpolation) the colors of the scene from the linear raw data.
-
You still need white balance on linear light data too. Also, remember the gamma curve of the CRT is approximately the inverse of the encoding gamma curve.
Tungsten light is blue deficient, and silicon sensors are less sensitive to blue too, making the problem compounded.
Graeme
-
An orange object shot in white light and white object shot in orange light both look orange to my eyes; and they will both be recorded as orange by a camera sensor. If you want to make the white object look white after the fact by monkeying with the controls in Photoshop, that's up to you but that's not the spectral composition of the light just after it reflected off the object at the scene.
Hogwash. A white tablecloth looks white to the eye under incandescent lighting, but if you process a RAW shot of said tablecloth with daylight WB, it's going to look orange. The human eye does a pretty good job of adapting to ambient lighting conditions, but no camera does any such thing.
-
If the source color is outside the destination space, defining its location in the destination space is not ambiguous, it's impossible
It is not impossible, it needs to be defined, what has to happen to such colors. See rendering intent.
The process we use to select alternate in-gamut colors may be ambiguous, but that does NOT mean we don't know exactly what the source color is. When the source colors fall within the destination space, we can convert back and forth at will with no ambiguity at all. sRGB (215, 133, 37) = ProPhoto (161, 124, 51) = LAB (63, 27, 61)
If one of the color spaces is larger than the other one, then an unambiguous projection between them is impossible. You are trying to prove your point with sRGB vs. raw, while the same problem exists between ProPhoto and sRGB as well.
Even if we have perfect knowledge of the sensor's color behavior, we still do not know what color that RAW RGB value represents until we choose a white balance setting. The white balance setting chosen can make that pixel almost any color at all after RAW conversion. That is what I mean by ambiguity
We are back at the beginning: you can make your own definition of what a color space is. If there are ten definitions, then why could not be one more?
However, the fact is, that there is no such generally accepted definition of "color space", which would include the conditions you like to include.
You stated at the beginning of this sub-thread:
a full-fledged color space has one and only one unambiguous numeric designation for a color that falls within its gamut
You expanded this by the requirement of unambiguous projection from that color space to another (which is nonsense), and now added the condition, that setting of WB be not necessary.
You can expand your definition with "the documentation is written in Chinese and published in PDF format" as well. The issue is, that others may not agree with that definition. Luckily, it does not matter, tha camera's whatever (what you don't call a color space) can be transformed into other whatevers, even if ambiguously.
-
You still need white balance on linear light data too
I for myself need white balance only on the linear data.
remember the gamma curve of the CRT is approximately the inverse of the encoding gamma curve
So what? It has nothing to do with virtually anything, except the misguided notation of "gamma curve".
-
"a full-fledged color space has one and only one unambiguous numeric designation for a color that falls within its gamut"
It may be worth mentioning here that cameras do not have gamuts.
For example, quoting from the F.A.Q. on the Munsell Color Science Laboratory (Rochester Institute of Technology) web site.
"Digital image sensors (such as those used in digital cameras) use red, green, blue ink-based color filters to generate color. Do they therefore have a color gamut that limits the range of colors that they can detect?
Let's start with the short answer to your question; there is no such thing as a camera, or scanner, gamut. A gamut is defined as the range of colors that a given imaging device can display. To say that a camera had a gamut would be to imply that you could put a color in front of it that it could not possibly respond to. While it is certainly possible that two colors that are visually distinct might be mapped into the same color signals by a camera that does not mean that the camera could not detect those colors. It just couldn't discriminate them. For example, a monochrome sensor will map all colors into a grayscale image and encode it as such. Certainly the encoding has a gamut (in this case a lightness range with no chroma information), but did the camera responded to all the colors put before it. It is the encoding that imposed the gamut. In the color world, encoding is based on some explicit or implied display. For example, sRGB is a description of a display and therefore defines a gamut (but only if the sRGB values are limited in range). If a camera encodes an image in sRGB, that doesn't mean that the range of colors the camera detected are only from within the sRGB display gamut, but it means the camera data have been transformed to best use that sRGB encoding. As long as a camera has three or more sensors that span the visual spectrum, then it will respond all the same stimuli as our visual system. Whether the camera can discriminate colors as well as the human visual system will depend on the encoding of the camera signals, quantitization, and the details of the camera responsivities. (To return to the black and white system, that camera encodes all the colors into a gray scale. They could then be displayed as any color within a given display, but many colors from the original scene would be mapped to the same values.)
Since there is no such thing as a gamut for an input device, then there is no way to compute it or calculate a figure of merit. Generally, the accuracy of color capture devices is assessed through the accuracy of the output values for known inputs in terms of color differences. Also, sensors are sometimes evaluated in terms of their ability to mimic human visual responses (and therefore be accurate) using quantities with names like colorimetric quality factor, that measure how close the camera responsivities are to linear transformations of the human color matching functions. Doing an internet search on "colorimetric quality factor" will lead you in the right direction."
http://www.cis.rit.edu/mcsl/outreach/faq.php?catnum=0#255 (http://www.cis.rit.edu/mcsl/outreach/faq.php?catnum=0#255)
Should be noted that pretty much every camera registers far beyond visible light, and in any case the recording is not uniform and invariant to changing conditions, especially heat.
-
It is not impossible, it needs to be defined, what has to happen to such colors. See rendering intent.
Bullcrap. If a color is outside the destination gamut then there is no possibility to put the exact color inside the destination space. All you can do is select an in-gamut alternate color, which is what rendering intents try to do. But no matter what you do, you cannot fit ProPhoto 0, 255, 0 into sRGB. It is out of sRGB's gamut and always will be. Different rendering intents will select various in-sRGB-gamut alternate colors, but none of them will be the same color as ProPhoto 0, 255, 0.
You are trying to prove your point with sRGB vs. raw, while the same problem exists between ProPhoto and sRGB as well.
Again, bullcrap. In a ProPhoto-tagged TIFF file, we have everything we need to unambiguously determine the color of every pixel in the file. With RAW, we do not, even if we know the exact spectral response characteristics of the camera's sensor and CFA. It is not possible to look at an out-of-focus shot of a flat surface and say exactly what color that surface is. We can make that flat surface be any color at all depending on the WB setting we choose. And if we only know the RAW data and camera characteristics, any WB setting is just as likely to be correct as any other.
In real-life images we can look at objects and make reasonably accurate, but judgments regard to correct WB and colorimetric rendering of RAW data. But this is still a judgment process, not precise colorimetric definition. If you give a RAW image to 10 different people to convert, it is unlikely that any two people will select the exact same WB setting for conversion.
The difference between RAW and ProPhoto is that Prophoto has a precise colorimetric definition for each pixel. RAW does not; it requires interpretation and informed judgment to even get close.
-
Some of the definitions of color gamut:
- The range of colors possible with any color system. For example, the original picture, a specific color monitor or a specific paper/ink/press combination
- Range of colors that can be formed by all combinations of a given set of light sources or colorants of a color reproduction system
- The range of colors a device can capture
- The entire range of hues possible to reproduce using a specific device, such as a computer screen, or system, such as four-color process printing
- The subset of colors which can be accurately represented in a given circumstance, such as within a given color space or by a certain output device
- The complete set of colors found within an image at a given time
- A range of colors that can be displayed on a digital TV, or seen by the human eye
- The complete range of hues and strengths of colors that can be achieved with a given set of colorants such as cyan, magenta, yellow, and black inks on a specific substrate
- Complete subset of colors
I don't see any reason to accept such an idiotic definition, which would exclude amond others ProPhoto from having a gamut.
-
Raw has no color space. And it doesn't matter what you set your camera to (you're shooting Raw).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=168063\")
According to Andrew, raw does not have a color space, but he confirms that a digital camera does indeed have a color space. See his [a href=\"http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf]Color Space White Paper[/url] on the Adobe web site, which states:
Classes of Color Spaces
There are classes of color spaces that define the behavior of a capture device like a scanner or digital camera.
According to the above, the camera does have a color space, but its output in the form of a raw file does not. This contradicts one of Andrew's quoted experts, Chris Murphy, who stated, "So yes a camera (and thus a Raw file) has a color space." Since a digital camera does not have a gamut, one can conclude by extension that not all color spaces have a gamut. Interesting.
-
OK, still puzzled though, and trying to understand the chain of custody of color as it makes its way from the original scene to output device (monitor or print), and its implications for color rendering. Let us ignore the output side of the problem, and concentrate on capture. For that aspect of the problem, one has the following:
The original scene has some light source with some spectral power distribution (SPD), and contains some objects with pigments of given spectral reflectivity. Light bounces around and comes through the lens and incident upon the sensor having a given spectral power distribution -- the intensities of the various constituent frequency components of the light. Let us for present purposes set aside issues of demosaicing, eg we have a scene without fine detail at the pixel level which would distinguish different interpolation algorithms.
The color filters in the CFA have a transmissivity dependent on frequency. Underneath the filter, the sensel responds to the transmitted light, and so integrates over the incident spectral power distribution convolved with the filter's spectral transmissivity and the spectral response of the photodetector. The integration averages over spectral information and therefore data is lost.
1. Because I am assuming that one can set aside interpolation issues, one has color data for each pixel in the form of raw values from the three different types of pixel in the CFA. Let us call this camera color data, the three numbers R_c, G_c,B_c. As some have said in this thread, the camera defines its own notion of color space (or if that is too charged a terminology, call it "color data") through the sensor response to various SPD's. We now wish to use that color data to reconstruct "color" according to some other measure(s).
2. Human vision has its own set of spectral response functions (SRF's) of the cones in the eye, somewhat quantitatively measured by researchers of decades past. An observer looking through the camera viewfinder sees colors that are characterized by three numbers, again the SPD integrated against these SRF's of human vision. Again information is lost since the true SPD of various components of the scene is a function of wavelength; a generic function of one variable cannot be fully characterized by the three numbers, call them R_e,G_e,B_e, that one gets by integrating the SPD against the SRF's of the three kinds of receptor. Nevertheless our brain takes this information and somehow interprets it as color. Let us call this eye color data (ECD).
3. Yet another characterization of the scene are the tristimulus values XYZ, which are the SPD integrated against the CIE's color-matching functions (distinct from the cone response functions of human vision, but meant to model them). Let us call this CIE color data, the values XYZ.
Because three numbers do not specify a function, neither the camera color data, the eye color data, nor the CIE color data are sufficient to reconstruct the original SPD of the original scene. That, in a nutshell, seems to be the source of the problem of mapping between the three sorts of color data layed out above. Of course, ideally that is what one would like so that one can convey to someone elsewhere, later, the experience of the scene where and when one records an image. The best one can hope is that one can reconstruct a reasonable approximation to the SPD using three numbers. Unless of course the SRF's of the camera are the same as human vision or CIE, in which case the corresponding sets of color data will correspond for any input SPD.
There is by now a whole industry built around the CIE convention using XYZ. It seems reasonable to use that as a starting point, and not concern ourselves with the map between CIE color data and eye color data (leaving that to the CIE to refine, though since the SRF's of the CIE standard for XYZ are not the same SRF's of human vision, the relation between CIE color data and eye color data is as fraught with ambiguity as the relation between camera color data and CIE color data, or between camera color data and eye color data).
Setting aside the relation to visual perception, and concentrating on relating the camera's color data to CIE conventions, one wants a map from camera data R_c,G_ c,B_c to X,Y,Z that is bijective (maps in both directions unambiguously). Of course, that is a bit of a non-starter, since for example the degeneracies (metamers) of the two sets of data -- the sets of SPD functions that yield the same XYZ or R_c G_c B_c -- are in general quite different. However, it seems reasonable that one could set up an optimization problem to average over various SPD's to make an "optimal" map between different representations of color data.
I suppose what I am trying to get at is that the camera raw data is color data that is no more or less valid than CIE color data insofar as it is related to the color data of human vision; it is just less standardized. Because the three numbers comprising that color data represent averages over SPD's convolved with SRF's, one cannot map one set of color data uniquely to the other. Constructing a map amounts to choosing a convention rather than deriving a rigorous relation; one tries to construct the map so that the map is roughly accurate with respect to a wide variety of SPD's (the aforementioned optimization problem). There is absolutely no reason why the map need be a linear (matrix) transform, a linear map is simply the crudest and simplest approximation one could make; a lookup table is a more general way of encoding such a map.
Anyway, a long-winded exposition of a few thoughts about which I'd be happy to hear comments.
-
You still need white balance on linear light data too. Also, remember the gamma curve of the CRT is approximately the inverse of the encoding gamma curve.
Tungsten light is blue deficient, and silicon sensors are less sensitive to blue too, making the problem compounded.
Graeme
[a href=\"index.php?act=findpost&pid=169990\"][{POST_SNAPBACK}][/a]
Quite right, gamma is a red herring; never mind.
But I'm still puzzled as to why white balance should be necessary. The sensor is a passive device, simply responding to the input given it. To the extent that one can use that data to direct a display device to emit the same tristimulus values, white balance seems superfluous. What is the white balance accomplishing in terms of matching the display's SPD to that of the scene when it was recorded by the camera?
-
You just need to look at the graph showing sensitivity to colours of light of a unfiltered silicon based sensor. It's sensitivity to blue is a lot less than green than red. So the only white light that will appear white without any white balance processing is a light that is very strong in blue. So, you basically end up having to gain up blue a lot under the vast majority of lighting conditions.
Now you've done that, you're still not going to get white out looking white because in the real scene, the eye/brain adapts to the changing colour temperature of the light - it effectively has a very powerful auto-white balance circuit. The camera doesn't so you have to either guess (and they do a pretty good job these days) or pick a white with a white balance picker. Once the computer knows what colour the white is recorded in the raw data as, you can adjust accordingly.
So, if your display had the inverse characteristic to the sensor, and filled enough of your field of vision that it fooled your eye into adapting the white balance automatically, you'd be probably ok, but that's practically never the case.
Graeme
-
You just need to look at the graph showing sensitivity to colours of light of a unfiltered silicon based sensor. It's sensitivity to blue is a lot less than green than red. So the only white light that will appear white without any white balance processing is a light that is very strong in blue. So, you basically end up having to gain up blue a lot under the vast majority of lighting conditions.
Now you've done that, you're still not going to get white out looking white because in the real scene, the eye/brain adapts to the changing colour temperature of the light - it effectively has a very powerful auto-white balance circuit. The camera doesn't so you have to either guess (and they do a pretty good job these days) or pick a white with a white balance picker. Once the computer knows what colour the white is recorded in the raw data as, you can adjust accordingly.
So, if your display had the inverse characteristic to the sensor, and filled enough of your field of vision that it fooled your eye into adapting the white balance automatically, you'd be probably ok, but that's practically never the case.
Graeme
[a href=\"index.php?act=findpost&pid=170134\"][{POST_SNAPBACK}][/a]
OK, but lack of blue sensitivity is a fixed property of the sensor. Why won't a fixed choice of relative gain among channels compensate for it (depending on camera model of course)? Why do we need a slider that changes from image to image?
Perhaps the problem is that I'm not understanding the phrase "the only white light that will appear white without any white balance processing is a light that is very strong in blue". Is the point that any two "opposite" colors can be combined to make white, and as the higher-frequency member of the pair tends toward blue, the lack of response of the sensor in blues leads to sensor color data that "seems" less and less white? In other words, is this one aspect of different SPD's leading to the same perceived color (in this case white)?
-
Quite right, gamma is a red herring; never mind.
But I'm still puzzled as to why white balance should be necessary. The sensor is a passive device, simply responding to the input given it. To the extent that one can use that data to direct a display device to emit the same tristimulus values, white balance seems superfluous. What is the white balance accomplishing in terms of matching the display's SPD to that of the scene when it was recorded by the camera?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170131\")
If you merely want to record the characteristics of the light falling on the sensor and are not interested in correlating the sensor response with the perceived color appearance of the target under the existing viewing conditions, white balance does seem superfluous. Indeed, according to [a href=\"http://www.adobeforums.com/webx?14@@.3bc2e802/0]Thomas Knoll[/url], the CIE XYZ space does not have a white point (if that is the same as white balance).
BTW, your previous essay is very helpful for the intelligent layman, since it is from the viewpoint of a physicist rather than a color scientist; the specialized jargon of the latter sometimes confuse the issue (Note to readers: Emil is a professor of physics at the University of Chicago).
Bill
-
Why won't a fixed choice of relative gain among channels compensate for it (depending on camera model of course)? Why do we need a slider that changes from image to image?
A constant compensation would not include the effect of change in the light source.
You do realize, that different cameras (with different microfilters) response differently to different captured light. This means, that if you capture the very same scenery lit by the very same light source, then two cameras will result into different pixel values, even if the sensors' SPD is compensated for. So, without a further adjustment, we would get a camera-dependent image.
There is a second point, "visio-psychological" (I think I just made up this term, but who knows).
Even using the very same camera, the recorded pixel values are varying depending on the light source. One could say that this does not matter (or only in larger variations), because the eyes are adjusting to the actual lighting.
This is true in real life, but not on picture. I think the analogy is correct: when you are in a city with tall buildings and look upwards, you don't notice, that the buildings appear much narrower at the very top. However, when you see that scenery on a picture, you can't ignore (or at least I can't) the effect: what looks perfect in real life, is abhorrend, when ripped out of the reality and presented in a totally strange, unnaturel setting, namle on a picture.
I think the very same phenomenon causes us to notice the "incorrect" color on a picture, while ignoring (not even noticing) that in life.
(Sorry, no citations, I can't blame anyone for the above idea.)
-
Let me ask the question a bit differently. Suppose we were to construct a device that records color data directly as CIE XYZ values, that has the CIE spectral response functions built into it. Would the color data need to be "white balanced" when we go to display data recorded under various lighting choices with different color temperatures?
If yes, then the issue of white balance is separate from the issue of using camera color data to define a color space, since something that all agree should be called a color space has the same issue. If no, then what is different about the camera sensor? Naively it's just a different trio of spectral response functions.
-
Let me ask the question a bit differently. Suppose we were to construct a device that records color data directly as CIE XYZ values, that has the CIE spectral response functions built into it. Would the color data need to be "white balanced" when we go to display data recorded under various lighting choices with different color temperatures?
If yes, then the issue of white balance is separate from the issue of using camera color data to define a color space, since something that all agree should be called a color space has the same issue. If no, then what is different about the camera sensor? Naively it's just a different trio of spectral response functions.
[a href=\"index.php?act=findpost&pid=170171\"][{POST_SNAPBACK}][/a]
Since the CIE XYZ space lacks a white point, then information tagged in the raw file must be used when one is converting from the CIE XYZ space to the output space which does have a white point. As you pointed out so eloquently, "The color filters in the CFA have a transmissivity dependent on frequency. Underneath the filter, the sensel responds to the transmitted light, and so integrates over the incident spectral power distribution convolved with the filter's spectral transmissivity and the spectral response of the photodetector. The integration averages over spectral information and therefore data is lost." No white balancing seems to be involved at this stage, and it would be meaningless since the CIE XYZ space lacks a white point.
As Jonathan has pointed out, the sensor would have no way to tell the difference between an orange target illuminated by white light or a white target illuminated by orange light. The sensor output would be the same and the white balance would have to be accomplished later in processing.
-
Since the CIE XYZ space lacks a white point, ...
I thought white was X=Y=Z; or is there a distinction between the terms "white" and "white point"?
And BTW Bill, I don't have any special qualifications or claim to authority for this discussion. Just eager to learn.
-
I thought white was X=Y=Z; or is there a distinction between the terms "white" and "white point"?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170246\")
Emil,
I do not think X=Y=Z=white. The XYZ space is not perceptually uniform, unlike L*a*b and the common matrix spaces. See [a href=\"http://en.wikipedia.org/wiki/CIE_1931_color_space]Wikipedia[/url]
I don't know the answer to your question about "white" and "white point".
And BTW Bill, I don't have any special qualifications or claim to authority for this discussion. Just eager to learn.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170246\")
I think you are being too modest. A professor of physics at the University of Chicago is more likely to have a grasp of scientific concepts than the average photographer on this forum. You can explain the science as few others in this thread can, and others can fill in on color theory, which is not your specialty.
Bill
Let the readers judge for themselves:
[a href=\"http://theory.uchicago.edu/~ejm/]Emil Martinec[/url]
Sensor Analysis (http://theory.uchicago.edu/~ejm/pix/20d/posts/tests/D300_40D_tests/)
-
If in CIE colour space we chose 2 colours, any colour that is on the straight line connecting those 2 colours can be obtained by mixing those 2 colours. No colour that is not on that line can be obtained by mixing those 2 colours.
Another thing here:
To start with, please look at the spectral sensitivity characteristics of a sensor. For numeric example we will use here curves of SONY ICX285AQ, see p.7 of SONY publication
http://products.sel.sony.com/semi/PDF/ICX285AQ.pdf (http://products.sel.sony.com/semi/PDF/ICX285AQ.pdf)
Digitizing the curves on page 7, we will have a table similar to:
400nm 450nm 500nm 550nm 600nm 650nm 700nm
R 0.03 0.02 0.04 0.07 0.96 0.94 0.82
G 0.03 0.13 0.56 0.9 0.31 0.04 0.15
B 0.22 0.66 0.55 0.04 0 0.01 0.01
Now let's take 4 wavelengths, 450, 500, 550, and 600nm; and play with them a little. Can we find a source that emits 450 and 550 nm that will provide a response equivalent to another source of light, emitting 500 and 600nm? Solving a simultaneous linear equation, we see that sensor will respond to first power source, emitting 65.4mW at 450nm and 41.6mW at 550 nm exactly the same way as to the second power source, emitting 81.5mW at 500nm and 1mW at 600nm.
Further, it is easy to see that we can find an infinite number of mixtures of those 4 wave lengths that will produce exactly the same sensor response. That means that for ICX285AQ a lot of colours between cyanish blue and cyanish green will trigger the same sensor response.
Reproduction of many shades of reds is even more challenging then that. If the series of wavelengths is 400, 500, 600, and 700nm with this sensor orange, brown, and even some shades of green trigger same response.
The above problem is emphasized when shooting conditions are far from native sensor colour temperature, and with "wrong" exposure. Yes, resulting colour depends not only on the white balance, but on exposure too. Speak of ETTR
It is important that this kind of metamerism is very far from the way our human perception tends to interpret colours. The example above shows the colours where humans see distinctly different colour. To prove this one can compute tristimulus values computed as per CIE.
Here are two examples of rendition of ambiguous colours mentioned above - the particular sensor will render them into the same numbers, and demosaicing will further interprete them as a same colour:
cyanish blue to cyanish green:
(http://pochtar.com/cgb.png)
orange-brown-green:
(http://pochtar.com/orbg.png)
You can have a better view in a colour-savvy application. Images are in sRGB colour space.
-
In Lab L is perceptually more or less uniform, especially with corrected conversion constants. "a" and "b" are not - you can see that when changing the saturation. More on the issues:
http://brucelindbloom.com/LContinuity.html (http://brucelindbloom.com/LContinuity.html)
http://brucelindbloom.com/UPLab.html (http://brucelindbloom.com/UPLab.html)
-
I thought white was X=Y=Z; or is there a distinction between the terms "white" and "white point"?
One could say that CIE has a "white line" and a "white region". The curve with the numbers on it represents the Planckian locus on the attached image, which is the locus of color temperatures of black bodies. Other light sources are in the "white" region, characterized not solemnly by temperature but tint as well.
-
I suppose what I am trying to get at is that the camera raw data is color data that is no more or less valid than CIE color data insofar as it is related to the color data of human vision; it is just less standardized. Because the three numbers comprising that color data represent averages over SPD's convolved with SRF's, one cannot map one set of color data uniquely to the other. Constructing a map amounts to choosing a convention rather than deriving a rigorous relation; one tries to construct the map so that the map is roughly accurate with respect to a wide variety of SPD's (the aforementioned optimization problem).
As I see it, the distinction between RAW data and CIE color data (I'm assuming you mean LAB or defined RGB spaces like ProPhoto, sRGB, etc) is the white balance issue. With ProPhoto RGB, we can unambiguously plot the coordinates of a given pixel's color value in LAB space. But with RAW data, we cannot, until we choose a WB value to put the RAW RGB data in the proper context (distinguishing between a white wall lit with orange light or an orange wall lit wit white light).
RAW data requires 3 data sets to map a specific pixel value to a point in LAB space: the spectral response of the camera sensor and filter array, the spectral composition of the lighting, and the RAW data itself. In contrast, only 2 data sets are needed for sRGB or ProPhoto data: the ICC profile, and the RGB image data.
-
As I see it, the distinction between RAW data and CIE color data (I'm assuming you mean LAB or defined RGB spaces like ProPhoto, sRGB, etc) is the white balance issue.
White balance is per channel exposure. You can't restore values with white balance if some parts of the spectrum are not recorded due to the nature of the capture process. And it is always the case.
Raw data can't be unambiguously restored to Lab also because of metamerism. Good conversion needs to take into account true exposure (light values, independent of ISO trickery), as it affects mapping.
-
RAW data requires 3 data sets to map a specific pixel value to a point in LAB space: the spectral response of the camera sensor and filter array, the spectral composition of the lighting, and the RAW data itself. In contrast, only 2 data sets are needed for sRGB or ProPhoto data: the ICC profile, and the RGB image data.
[a href=\"index.php?act=findpost&pid=170271\"][{POST_SNAPBACK}][/a]
MMM what do you mean by the "spectral composition of the lighting"
This is not intrinsically available from sensor data. This is one of the problems in digital imaging –
Illuminant estimation.
-
In Lab L is perceptually more or less uniform, especially with corrected conversion constants. "a" and "b" are not - you can see that when changing the saturation. More on the issues:
http://brucelindbloom.com/LContinuity.html (http://brucelindbloom.com/LContinuity.html)
http://brucelindbloom.com/UPLab.html (http://brucelindbloom.com/UPLab.html)
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170264\")
Ihah, thanks for the links and your input.
[a href=\"http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html]Poynton[/url] discusses perceptual uniformity in his Color FAQ and L*a*b was an attempt to achieve perceptual uniformity. As discussed previously in this thread, mathematical models often are less than perfect in describing the behavior of a device, much less human perception.
"Finding a transformation of XYZ into a reasonably perceptually-uniform space consumed a decade or more at the CIE and in the end no single system could be agreed. So the CIE standardized two systems, L*u*v* and L*a*b*, sometimes written CIELUV and CIELAB. (The u and v are unrelated to video U and V.) Both L*u*v* and L*a*b* improve the 80:1 or so perceptual nonuniformity of XYZ to about 6:1."
Nonetheless, when one is editing in L*a*b, if a* = b*, the color is assumed to be neutral. This is not the case with CIE XYZ.
Bill
-
As I see it, the distinction between RAW data and CIE color data (I'm assuming you mean LAB or defined RGB spaces like ProPhoto, sRGB, etc) is the white balance issue. With ProPhoto RGB, we can unambiguously plot the coordinates of a given pixel's color value in LAB space. But with RAW data, we cannot, until we choose a WB value to put the RAW RGB data in the proper context (distinguishing between a white wall lit with orange light or an orange wall lit wit white light).
RAW data requires 3 data sets to map a specific pixel value to a point in LAB space: the spectral response of the camera sensor and filter array, the spectral composition of the lighting, and the RAW data itself. In contrast, only 2 data sets are needed for sRGB or ProPhoto data: the ICC profile, and the RGB image data.
[a href=\"index.php?act=findpost&pid=170271\"][{POST_SNAPBACK}][/a]
No, I meant XYZ color space. After reading a bit more, I think I see what you are getting at; the transformation between XYZ and LAB color coordinates requires not just the XYZ coordinates of the sampled light, but some reference coordinates X', Y', Z' of the light source used to illuminate the scene.
I have to say the latter seems to me not well-defined: I sit here in a room with incandescent sources, there is the light emitted by my computer screen, and sunlight coming in through the window, suppose I also used flash to take a picture of the scene -- the light coming into different points on the camera sensor, or different parts of my retina as I view the scene, will have been coming from quite different superpositions of these disparate sources with different SPD's, and there is nothing I would call "the" XYZ values of "the" light source).
But putting this quibble aside, transforming XYZ values to LAB does indeed involve another piece of data, the XYZ coordinates of "the" light source. That would be true even for a hypothetical device whose spectral response was precisely the CIE's spectral response functions that define X,Y,and Z; such a device would still require an X'Y'Z' of "the light source" to map the X,Y,Z that it records to a set of L,A,B values. And yet XYZ is called a color space. Various RGB color spaces incorporate this data implicitly by defining themselves wrt a reference light source (eg D65 or D50); so they don't eliminate this piece of information, they incorporate it into their very definition. But before introducing this extra complication, the hypothetical CIE-sensor records the scene directly in XYZ color space. The need to define and use the X'Y'Z' of the light source only comes later when you want to start processing this color data in a manner that is consistent with the way the brain processes its tristimulus data.
And the non-CIE sensor in a DSLR seems no different in principle.
The important issue seems to me that of the difference in spectral response functions among human vision, CIE, and camera sensor. Iliah's examples illustrate that beautifully.
-
This is not intrinsically available from sensor data. This is one of the problems in digital imaging –
Illuminant estimation.
My point exactly. In order to convert a RAW, we must estimate the characteristics of the lighting before we can meaningfully convert the RAW data to LAB or a standard RGB color space.
-
No, I meant XYZ color space. After reading a bit more, I think I see what you are getting at; the transformation between XYZ and LAB color coordinates requires not just the XYZ coordinates of the sampled light, but some reference coordinates X', Y', Z' of the light source used to illuminate the scene.
I have to say the latter seems to me not well-defined: I sit here in a room with incandescent sources, there is the light emitted by my computer screen, and sunlight coming in through the window, suppose I also used flash to take a picture of the scene -- the light coming into different points on the camera sensor, or different parts of my retina as I view the scene, will have been coming from quite different superpositions of these disparate sources with different SPD's, and there is nothing I would call "the" XYZ values of "the" light source).
I've made exteriors of buildings under mixed light sources with wildly varying SPD, late-evening twilight, fluorescent, incandescent, sodium vapor, and tiki torches all in the same frame. The only way to get "natural looking" color under such circustances is to do a RAW conversion balanced specifically for each light source, and then manually blend each conversion together into a single final image.
-
I've made exteriors of buildings under mixed light sources with wildly varying SPD, late-evening twilight, fluorescent, incandescent, sodium vapor, and tiki torches all in the same frame. The only way to get "natural looking" color under such circustances is to do a RAW conversion balanced specifically for each light source, and then manually blend each conversion together into a single final image.
[a href=\"index.php?act=findpost&pid=170542\"][{POST_SNAPBACK}][/a]
If you can't turn each light on independently. If you have the power to control the lights, you can take a separate exposure for each light, balance it the way you want it, and then add them together.
-
I've made exteriors of buildings under mixed light sources with wildly varying SPD, late-evening twilight, fluorescent, incandescent, sodium vapor, and tiki torches all in the same frame. The only way to get "natural looking" color under such circustances is to do a RAW conversion balanced specifically for each light source, and then manually blend each conversion together into a single final image.
[a href=\"index.php?act=findpost&pid=170542\"][{POST_SNAPBACK}][/a]
This example illustrates the importance of separating the photometry of the scene, as opposed to the image processing to be undertaken later. In vision (perhaps I'm oversimplifying here), the eye is the sensor (photometer) and the brain is post-processing. IMO it seems unreasonable to ask the DSLR sensor to be both eye and brain; rather we should only ask it to be eye, and thus carry out the photometric task and forget about "the vision thing", leaving post-processing in Photoshop (such as in your example) to supplant the role of brain in interpreting the scene. The camera sensor should hardly be blamed for any shortcomings of post-processing software in rendering the spectral data in a way that parallels human vision.
This demarcation is mimiced (albeit in cartoon form) by the distinction between XYZ and LAB color spaces. XYZ is more photometric -- an average of the spectral power distribution of the light signal against the spectral response functions of the color receptors, no judgments about light source required. LAB is mapped to from XYZ through a function of X/X', Y/Y', Z/Z' where X'Y'Z' are the color coordinates of the light source; this already brings in elements of post-processing, and a rough attempt to mimic the way the brain processes the tristimulus data that the eye presents to it by incorporating the way the brain responds to ambient lighting and contextual data.
It seems to me more important (for the purpose of color accuracy) that the DSLR sensor spectral response parallel as closely as possible that of the eye** (for instance having roughly similar degeneracies, ie metamers), and less important to worry about how the sensor is supposed to infer the structure of the light source from this data.
With similar responses, the camera sensor matches the tristimulus data of the eye well, and becomes a color space closely approximating XYZ. Having that in hand, future improvements in post-processing software, fed by advances in the science of vision, can translate that data into a close facsimile of the way the brain interprets the data it receives from the eye, so that we can reproduce it accurately for our eyes to enjoy.
** though I'm sure that devotees of IR and astro photography will heartily disagree!
-
This example illustrates the importance of separating the photometry of the scene, as opposed to the image processing to be undertaken later. In vision (perhaps I'm oversimplifying here), the eye is the sensor (photometer) and the brain is post-processing. IMO it seems unreasonable to ask the DSLR sensor to be both eye and brain; rather we should only ask it to be eye, and thus carry out the photometric task and forget about "the vision thing", leaving post-processing in Photoshop (such as in your example) to supplant the role of brain in interpreting the scene. The camera sensor should hardly be blamed for any shortcomings of post-processing software in rendering the spectral data in a way that parallels human vision.
This demarcation is mimiced (albeit in cartoon form) by the distinction between XYZ and LAB color spaces. XYZ is more photometric -- an average of the spectral power distribution of the light signal against the spectral response functions of the color receptors, no judgments about light source required. LAB is mapped to from XYZ through a function of X/X', Y/Y', Z/Z' where X'Y'Z' are the color coordinates of the light source; this already brings in elements of post-processing, and a rough attempt to mimic the way the brain processes the tristimulus data that the eye presents to it by incorporating the way the brain responds to ambient lighting and contextual data.
It seems to me more important (for the purpose of color accuracy) that the DSLR sensor spectral response parallel as closely as possible that of the eye** (for instance having roughly similar degeneracies, ie metamers), and less important to worry about how the sensor is supposed to infer the structure of the light source from this data.
With similar responses, the camera sensor matches the tristimulus data of the eye well, and becomes a color space closely approximating XYZ. Having that in hand, future improvements in post-processing software, fed by advances in the science of vision, can translate that data into a close facsimile of the way the brain interprets the data it receives from the eye, so that we can reproduce it accurately for our eyes to enjoy.
** though I'm sure that devotees of IR and astro photography will heartily disagree!
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170819\")
Even with colorimetric rendering where the camera XYZ closely approximates the tristimulus response of the eye, [a href=\"http://www.athle.com/asp.net/main.medias/display.aspx?mediaid=17272§ion=52&day=0&month=0&year=0&mode=]Wandell et al [/url] note that the color reproduction will be accurate only when the original and reproduction are viewed under similar conditions, including surround, ambient lighting, and field of view. Since the actual scene is being reproduced, presumably "white balance" considerations are eliminated as in Emil's model.
If the white point needs adjustment, there are further complications as Bruce Lindbloom (http://brucelindbloom.com/) outlines in the article on chromatic adaption on his web site. He concludes, "...You can see from the table that Bradford is superior to von Kries, which in turn is superior to XYZ Scaling. You can also see that the adaptation is only an approximation to the true value, and that this approximation is worse when the two reference illuminants are very different from each other. Adaptation also becomes progressively less perfect as the color is farther away from neutral.
Wandell also discusses non-colorimetric sensors, where a 3x3 matrix conversion will give only an approximate result. He mentions simple linear transformations that vary smoothly with the input data (interpolation--presumably what is done with ICC camera profiles used by some raw converters). He also mentions non-linear polynomial functions, and methods based on simple neural networks. Another approach is to use memory colors (e.g. flesh tones, foliage, blue sky) as a reference for further adjustment. Some of these methods are propriatory.
Bill
-
If you can't turn each light on independently. If you have the power to control the lights, you can take a separate exposure for each light, balance it the way you want it, and then add them together.
That wasn't even remotely possible, as two of the 5 light sources were ambient outdoor light and sodium-vapor streetlignts, and I was shooting the restaurant with actual customers dining...
(http://www.visual-vacations.com/ProfessionalServices/Advertising/187U0615.jpg)
Your suggestion doesn't really save any time, as the most time-consuming part is manually blending all of the pieces together either way.
-
That wasn't even remotely possible,
but sometimes it is, so it is good to keep it in mind.
Your suggestion doesn't really save any time, as the most time-consuming part is manually blending all of the pieces together either way.
[a href=\"index.php?act=findpost&pid=170957\"][{POST_SNAPBACK}][/a]
You can never get a blend with all the lights in one scene, exactly right. Every surface has a complex blend of the lighting. Exposing each light color separately guarantees the natural complexity.
-
I stand by what I said. In my example image, the upstairs windows have incandescent illumination, except for the rightmost two by the grill, which are lit primarily by fluorescent fixtures. I had to blend/fade the opacity of the incandescent-WB and fluorescent-WB layers along the transition area between the fluorescent-lit and incancescent-lit areas. I would have had to do exactly the same thing if I had shot each light source separately, so your suggestion has a net time savings of exactly zero. In addition, using a single RAW capture as the source (processed multiple times with different WB settings) guarantees zero registration issues when blending the layers together. That can be a big issue when there are ceiling fans, fountains, trees, or foliage along the boundary between one lighting type and another.
-
Just for fun, I did a little exercise. Noting that the sensor referred to in Iliah's post has a substantial response in the IR, it seems that it's important to use the SRF of an actual DSLR with IR filter in place, otherwise the SRF's are overweighted toward the IR and have no hope of matching human vision.
I found a measurement of the Nikon D70 SRF at
http://scien.stanford.edu/class/psych221/p...h/spectral.html (http://scien.stanford.edu/class/psych221/projects/05/joanmoh/spectral.html)
(http://theory.uchicago.edu/~ejm/pix/20d/posts/tests/Color/NikonD70_SRF.jpg)
The sensor data are linear in the inputs, and so it seems after all that the best one can attempt is to fit the CIE XYZ spectral response functions to a linear combination of those of the camera. I discretized the above at 10nm intervals and did a least squares fit to the best linear transform, and the result is
(http://theory.uchicago.edu/~ejm/pix/20d/posts/tests/Color/D70_SRF-CIEbestfit.jpg)
The lighter lines are the CIE XYZ spectral response functions, the heavier lines are the best fit linear combinations of the D70 SRF's. As is clearly evident, the best fit red channel can't capture the double hump character of the CIE X channel SRF, and the best fit green channel has a cleft in the maximum where it wants to reproduce the smooth maximum of the Y channel. Overall the fit is decent but not spectacular.
I suspect is is this sort of linear transform that ACR is applying in mapping demosaiced camera data to map it to XYZ data.
-
Noting that the sensor referred to in Iliah's post has a substantial response in the IR
All of them do unfortunately. That is why I used wavelengths that are rather far from IR. Experimentally, it is very interesting to shoot rainbow formed by a prism (or formed some other controlled way - keeping in mind that AA filters sometimes have polarizing effect).
-
All of them do unfortunately. That is why I used wavelengths that are rather far from IR. Experimentally, it is very interesting to shoot rainbow formed by a prism (or formed some other controlled way - keeping in mind that AA filters sometimes have polarizing effect).
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=171148\")
Most all DSLRs have an IR cutoff filter which removes most light with λ > 700 nm. Some IR does get through and one can still take IR photos by using a filter which cuts off visible light and passes IR. Up to +10 EV exposure compensation is necessary with this approach, so the IR response normally would be pretty much limited to the shadows.
[a href=\"http://www.astrosurf.com/~buil/350d/350d.htm]Christian Buil[/url] shows data for a Canon 350d with and without the IR filter. Interestingly, IR response without the filter is not limited to the red channel.
Bill
-
Most all DSLRs have an IR cutoff filter which removes most light with λ > 700 nm.
Lets look at the previous then.
"Noting that the sensor referred to in Iliah's post has a substantial response in the IR"
"All of them do unfortunately."
Emil just made a note why he would not use that sensor data sheet for his analysis; and went further using experimental data obtained from a fully assembled camera.
I'm talking about sensor, not dSLRs. It was clear from the post. There is no need to discuss IR in the context of the wavelengths suggested for analysis - those have nothing to do with IR at all. I mentioned that too.
As far as your double "most" - point your IR remote to the lens of a camera with a Sony sensor and see if you are getting purple blobs on the image. That may explain why external hot mirror filters from Schneider and Heliopan are still in high demand.
-
Christian Buil (http://www.astrosurf.com/~buil/350d/350d.htm) shows data for a Canon 350d with and without the IR filter. Interestingly, IR response without the filter is not limited to the red channel.
Bill
[a href=\"index.php?act=findpost&pid=171202\"][{POST_SNAPBACK}][/a]
you have to remember its the spectral response of the bayer filters that is being measured not the chip
so ir can be detected if the green or blue etc filter is defective in the ir regions or uv
-
you have to remember its the spectral response of the bayer filters that is being measured not the chip
so ir can be detected if the green or blue etc filter is defective in the ir regions or uv
[a href=\"index.php?act=findpost&pid=171287\"][{POST_SNAPBACK}][/a]
Papa,
I do not think that is correct. In the Stanford D70 measurements, the SRF was obtained by removing the lens from the camera and taking exposures with 35 center wavelengths from a monochromator, with wave lengths from 400 nm up to 730 nm in increments of 10 nm. The responses were recorded as NEFs and the raw data were read by MATLAB and the average RGB pixel values were determined within that program. I don't know if the data were derived from the raw data channels directly or if a demosaicing was performed, but as EJ Martin has pointed out, it makes no conceptual difference.
What they were measuring was the response of the silicon _AND_ the CFA filters _AND_ the IR filter. I don't know what methodology Christian Buhl used, but he noted: "The colored dye of the bleue and green pixels filters are also nearly transparent in the infrared.": For the green and blue pixels, this would mean that the measurement in the infrared is primarily that of the silicon response, not that of the filters.
From what Emil and Ihiah have contributed, it seems the the derivation of the camera XYZ response is relatively straightforward (accepting non-colorimetric limitations), but the real problem is in obtaining a white balanced image as I mentioned in my previous post. When one is converting between D50 and D65 spaces, the illuminants are relatively similar and well defined, whereas a digital camera has to deal with a wide range of illuminates with an unknown spectral frequency distribution.
Bill
-
yes
its the filter dyes that give the spectral curves.
heres a D70s spectral response I did on a bentham monochromator late last year and one from Image Engineering.
Mine is scaled to unity but you can see the "bumps" are in the right place.
Just finishing the spectral characterisation using a double grating configuration of the bentham from 350nm to 750nm.
I got my characterisation down to an average of 2.25 Delta E LAB on the macbeth 24 patch colour checker. Room for improvement!
-
heres the d70s i did
-
yes
its the filter dyes that give the spectral curves.
heres a D70s spectral response I did on a bentham monochromator late last year and one from Image Engineering.
Mine is scaled to unity but you can see the "bumps" are in the right place.
Just finishing the spectral characterisation using a double grating configuration of the bentham from 350nm to 750nm.
I got my characterisation down to an average of 2.25 Delta E LAB on the macbeth 24 patch colour checker. Room for improvement!
[a href=\"index.php?act=findpost&pid=171336\"][{POST_SNAPBACK}][/a]
Thanks for that! Do you have or know of any similar characterization of Canon sensors?
BTW, are you sure that it's the filter dyes that give the spectral curves? They should be only one factor. I would have thought the response is the product of the transmissivity of the IR filter, the CFA color filter, and the response of the silicon. Granted all color channels would be the same without the CFA, but the response curve would not be flat.
-
I dont have the spectral response of the chip without the filters of the IR
Its a sony chip in the D70 and D70s. Ill try to get hold of it.
-
I dont have the spectral response of the chip without the filters of the IR
Its a sony chip in the D70 and D70s. Ill try to get hold of it.
[a href=\"index.php?act=findpost&pid=171341\"][{POST_SNAPBACK}][/a]
Sorry, I should have written Canon DSLR's. I'm not interested in the chip w/o all that comes with it in an actual camera body.
-
How much can the intensity of the output of a monochromator vary at different wavelengths?
-
It changes over wave length with the brightest about 500nm.
should look something like this
-
yes its the filter dyes that give the spectral curves.
heres a D70s spectral response I did on a bentham monochromator late last year and one from Image Engineering.
Mine is scaled to unity but you can see the "bumps" are in the right place.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=171336\")
BTW, are you sure that it's the filter dyes that give the spectral curves? They should be only one factor. I would have thought the response is the product of the transmissivity of the IR filter, the CFA color filter, and the response of the silicon. Granted all color channels would be the same without the CFA, but the response curve would not be flat.
[a href=\"index.php?act=findpost&pid=171340\"][{POST_SNAPBACK}][/a]
Papa,
The sophistication of your measurements indicates that you are a high level color person, but your statement that the filter dyes determine the spectral response puzzles me. I'm no expert, but Emil's explanation seems more likely. Without any filters, all the channels would be the same but the response curve would not be linear across the wavelength spectrum.
The spectral response of a typical CCD is shown [a href=\"http://www.andor.com/learn/digital_cameras/?docid=315]here.[/url] To create an electron, the photon must reach the depletion layer of the chip. Below about 350 nm, photons are absorbed by the gate structures (the silicon has a low transmittance at this wavelength) or reflected. As the wavelength lengthens, more photons reach the depletion layer and produce electrons. In the example, response is greatest at about 600 nm (yellow-red). In the far infrared region, photons can pass through the depletion layer and not be detected.
Similar explanation and a nice Java Tutorial is presented on the Olympus Microscopy Site. (http://www.olympusmicro.com/primer/digitalimaging/concepts/quantumefficiency.html)
In the case of the D70 chip, the Stanford SRF was obtained with the CFA and IR filters in place. Papa's SRF is similar, but shows relatively more response at about 625 nm.
The output of the pixel is dependent on the photons reaching the depletion layer of the chip and the spectral response of the silicon, which varies markedly with wavelength. The filters shape the response by limiting what wavelengths fall on the pixel, but the spectral response of the silicon plays an important role.
Since the SRF is obtained by observation of an intact camera sensor, there is no way to determine the individual contributions of the filters or silicon other than by a controlled experiment where the responses are determined individually.
Bill
-
Hi bill
sorry must have mis-understood what you were talking about.
The underlying response of the chip is a factor that cant be changed (unless you use another chip!) but the filter pattern and dye set can be (albeit by the manufacturers only)!
So what i meant is its the filter sets that give the final spectral response particular to that camera.
Im just talking characterization of the camera as a whole.
-
It changes over wave length with the brightest about 500nm.
I guess you have incorporated this when you created the response graph, have not you?
Btw, how do you know the relative light intensity of the monochromator? Does it come with the documentation of the equipment? I guess it depends mainly on the light source, and perhaps on the quality of the grating.
-
had to measure it at each wavelenght interval with a spectroradiometer.
Stepped from 380 to 730 at 5nm intervals.
I think the last chart was the spd of the source at zero grating setting (white only) from the integrating sphere.
-
Hi bill
sorry must have mis-understood what you were talking about.
The underlying response of the chip is a factor that cant be changed (unless you use another chip!) but the filter pattern and dye set can be (albeit by the manufacturers only)!
So what i meant is its the filter sets that give the final spectral response particular to that camera.
[a href=\"index.php?act=findpost&pid=171571\"][{POST_SNAPBACK}][/a]
Papa,
Yes, it was apparently a misunderstanding that is now cleared up. EJMartin had a similar misunderstanding. BTW, you don't list your background in your profile, but from the sophistication of your equipment and analysis, I infer that you must be a color scientist?
Bill
-
Curves taken from dissolved dyes add nicely to typical silicon response, result is what you have from the sensor with stripped AA/IR filter. AA component adds polarization (usually circular, but not always) above all which can heavily interfere with measurements.
-
I dont know if this question is a bit offtopic, but Id like to know how could it be possible to make a conversion from the raw data to XYZ with the provided adobe matrices, I mean these ones:
DCRAW
/*
Thanks to Adobe for providing these excellent CAM -> XYZ matrices!
*/
{ "Canon EOS-1Ds Mark II", 0,
{ 6517,-602,-867,-8180,15926,2378,-1618,1771,7633 } },
Is it possible to obtain with this matrix an approximated measured XYZ value like the one from an spectroradiometer knowing the values of each element in the Bayer array ?
Thanks a lot.
-
I dont know if this question is a bit offtopic, but Id like to know how could it be possible to make a conversion from the raw data to XYZ with the provided adobe matrices, I mean these ones:
DCRAW
/*
Thanks to Adobe for providing these excellent CAM -> XYZ matrices!
*/
{ "Canon EOS-1Ds Mark II", 0,
{ 6517,-602,-867,-8180,15926,2378,-1618,1771,7633 } },
Is it possible to obtain with this matrix an approximated measured XYZ value like the one from an spectroradiometer knowing the values of each element in the Bayer array ?
Thanks a lot.
[a href=\"index.php?act=findpost&pid=182094\"][{POST_SNAPBACK}][/a]
Well, it might if Adobe correctly color calibrated their raw converter; there is some doubt about that, given that many feel the need to run calibration scripts to get accurate color from ACR.
But yes, the matrix is very likely a best fit linear map from the camera's spectral response curves to those of the XYZ color matching functions (minimizing the difference between the mapped curves and the XYZ cmf's), along the lines that I posted above in this thread.
-
Well, it might if Adobe correctly color calibrated their raw converter; there is some doubt about that, given that many feel the need to run calibration scripts to get accurate color from ACR.
But yes, the matrix is very likely a best fit linear map from the camera's spectral response curves to those of the XYZ color matching functions (minimizing the difference between the mapped curves and the XYZ cmf's), along the lines that I posted above in this thread.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=182788\")
The following links may help clarify some of the principles involved in converting from the camera space to CIE XYZ or the camera space directly to sRGB or some other working space. Of course, this implies that the camera does indeed have a space and largely negates statements to the contrary. Although the papers apply to Foveon sensors, which have 3 colors per photosite, they also should apply to Bayer sensors since, as Thomas Knoll pointed out, the missing color information in the Bayer sensor is filled in by demosaicing and interpolation early in the conversion process and the "monochrome" issue is a red herring.
As the first paper indicates, a set of color matching functions can be generated by finding a matrix that maps the spectral response into a tristimulus response using techniques such as least square matrix inversion. Depending on the error constraint goals, the matrix may yield either a balanced error or biased error, favoring some metamers over others.
[a href=\"http://billjanes1.home.comcast.net/~billjanes1/binary/KopieSensorChar.pdf]X3 Sensor Characteristics[/url]
Image Sensor with Layered Photodiodes (http://billjanes1.home.comcast.net/~billjanes1/binary/FoveonSenosrPaper2.pdf)
Bill
-
Thanks a lot for your replies,
What I dont really understand is how to make use of those matrices to make this kind of conversion. I mean, if you take two pictures at different shutter speed values of the exactly same scene, then the values of a little area of the picture would have the same XYZ values but the RAW data of the camera should be different, so this matrix should only be useful for specific shutter speed, and so, isnt it ?
Thanks again and excuse me if say anything that makes no sense, I'm just learning in this extremely interesting subject.
Regards,
Carlos.
-
What I dont really understand is how to make use of those matrices to make this kind of conversion. I mean, if you take two pictures at different shutter speed values of the exactly same scene, then the values of a little area of the picture would have the same XYZ values but the RAW data of the camera should be different, so this matrix should only be useful for specific shutter speed, and so, isnt it ?
[a href=\"index.php?act=findpost&pid=184154\"][{POST_SNAPBACK}][/a]
No, the XYZ values would not be the same in the 2 cases. Why should they be? Both the XYZ (D50) and camera RGB values would be lower in the case where the exposure time is longer (i.e., slower shutter speed).
Eric
-
But yes, the matrix is very likely a best fit linear map from the camera's spectral response curves to those of the XYZ color matching functions (minimizing the difference between the mapped curves and the XYZ cmf's), along the lines that I posted above in this thread.
[a href=\"index.php?act=findpost&pid=182788\"][{POST_SNAPBACK}][/a]
More precisely, the matrices map (non-white-balanced) linear camera coordinates to XYZ with a D50 white point.
-
No, the XYZ values would not be the same in the 2 cases. Why should they be? Both the XYZ (D50) and camera RGB values would be lower in the case where the exposure time is longer (i.e., slower shutter speed).
Eric
[a href=\"index.php?act=findpost&pid=184172\"][{POST_SNAPBACK}][/a]
Sorry, maybe I didnt explain myself properly, Lets say that I have an spectroradimeter and I point it to a place that doesnt change in illumination, the spectroradiometer would give me the XYZ values. Then, i put a camera on the same place pointing at the same direction and I take de bayer array values of the place where the spectroradiometer was pointing at. If I take to pictures at different exposures, is there a way of getting with the camera approximately the same XYZ values obtained with the spectroradiometer independently of the exposure?
Thanks a lot.
-
I thought white was X=Y=Z; or is there a distinction between the terms "white" and "white point"?
And BTW Bill, I don't have any special qualifications or claim to authority for this discussion. Just eager to learn.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=170246\")
Just in case it wasn't already answered, the white coordinates in XYZ depend on the illuminant. Y is 1 but X and Z are generally not. For example, the D50 white point is about X = 0.9642, Y = 1.0, Z = 0.82521. You can see this page for the XYZ coordinates of various common white points:
[a href=\"http://www.brucelindbloom.com/Eqn_ChromAdapt.html]http://www.brucelindbloom.com/Eqn_ChromAdapt.html[/url]
-
Thanks a lot for your replies,
What I dont really understand is how to make use of those matrices to make this kind of conversion. I mean, if you take two pictures at different shutter speed values of the exactly same scene, then the values of a little area of the picture would have the same XYZ values but the RAW data of the camera should be different, so this matrix should only be useful for specific shutter speed, and so, isnt it ?
[a href=\"index.php?act=findpost&pid=184154\"][{POST_SNAPBACK}][/a]
Changing the exposure time by a factor X linearly rescales the raw data by X. In order not to screw up this linearity, any attempt to fit camera raw values to XYZ values should be linear (XYZ values are also linear wrt change of luminosity). So the general map is
"X" = a1 R +a2 G + a3 B
"Y" = b1 R +b2 G + b3 B
"Z" = c1 R +c2 G + c3 B
where "X", "Y" and"Z" are the best approximation the camera can make to XYZ values of the recorded scene, RGB are the camera raw values for the three color channels (suitably interpolated, and ignoring any issues stemming from such interpolation), and the coefficients ai, bi, and ci (i=1,2,3) are determined by fitting the spectral response functions of the camera to the XYZ spectral response functions as best as possible via a linear map.
-
Yes, it's just a linear scaling, and hence will be preserved with a linear transform such as Adobe's camera/XYZ matrices.
-
I am trying to convert RAW image data with no header info into a usable DNG. ATM, I am using this color matrix
Color Matrix values 1 to 3...: 1.0048828125 -0.27294921875 -0.04931640625
Color Matrix values 4 to 6...: -0.56689453125 1.34936523437 0.20776367188
Color Matrix values 7 to 9...: -0.2919921875 0.34936523438 0.63916015625
I am getting gaps in the picture after conversion. Stippling?
https://dl.dropboxusercontent.com/u/9906333/fc2_save-0000.jpg
I used a jpg here but can see the same issue in the DNG file in preview or Irfan View.
There seems to a multicolor bands when zooming in on the darker areas.
I was wondering if this could be due to the color matrix ?
I saw other matrices here - http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
-
I am trying to convert RAW image data with no header info into a usable DNG. ATM, I am using this color matrix
Color Matrix values 1 to 3...: 1.0048828125 -0.27294921875 -0.04931640625
Color Matrix values 4 to 6...: -0.56689453125 1.34936523437 0.20776367188
Color Matrix values 7 to 9...: -0.2919921875 0.34936523438 0.63916015625
I am getting gaps in the picture after conversion. Stippling?
https://dl.dropboxusercontent.com/u/9906333/fc2_save-0000.jpg
I used a jpg here but can see the same issue in the DNG file in preview or Irfan View.
There seems to a multicolor bands when zooming in on the darker areas.
I was wondering if this could be due to the color matrix ?
I saw other matrices here - http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
This is an old thread, but it contains much useful information. Many arguments against considering a camera as having a color space are dispelled by this post (http://www.fastrawviewer.com/viewing-raw-is-not-impossible) from the developers of Fast Raw Viewer. In the end, semantics are involved in what is a color space.
Bill
-
This is an old thread, but it contains much useful information. Many arguments against considering a camera as having a color space are dispelled by this post (http://www.fastrawviewer.com/viewing-raw-is-not-impossible) from the developers of Fast Raw Viewer. In the end, semantics are involved in what is a color space.
Argument 1, Viewing RAW is Impossible seems silly to me. I've always found BayerDemosaic by Marc Rochkind to be a great teaching tool to illustrate this. For example:
http://www.digitaldog.net/files/raw.jpg
(http://www.digitaldog.net/files/raw.jpg)
Argument 2 "The color on RAW data is wrong" isn't the same as raw has no color space IMHO. I think we came to agreement here or elsewhere about this. Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The piece you outline states:
A RAW image is recorded in the sensor's "color space." So nothing is really new here. As usual, all we need to do is assign proper "color space" to the data.
Ah, so what is that color space?
Argument 3: RAW images are very dark". That's of course untrue and the article discusses why. For many years, when doing classes on why we need to have proper profiles assigned to image data, I showed a capture from an old Kodak DCS camera which allowed a gamma 1.0 capture as an option. I would place info palette sample points on the image which at the time was 'assumed' incorrectly to be sRGB. Using Assign Profile command, I would select the ICC profile that defined the data. The numbers didn't change, the image got lighter and appeared correct. So yes, these images are not dark, they are being previewed with the wrong profile.
Interestingly we see the same silly assumptions with Adobe RGB (1998) being 'dull' instead of sRGB when it is being previewed improperly. The same false ideas about Adobe RGB (1998) and these raw files populate the web. There's nothing wrong with the data. There's something wrong about how the data is interpreted, an incorrect assumed profile.
-
Argument 2 "The color on RAW data is wrong" isn't the same as raw has no color space IMHO. I think we came to agreement here or elsewhere about this. Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The piece you outline states: Ah, so what is that color space?
Yes, I think we did come to agreement on that matter after an interesting discussion. The camera does not have a colorimetrically defined space. However, we can convert from the "camera space" to a colorimetric space using an experimentally derived 3*3 matrix. As I understand it, the coefficients of that matrix are often derived from a least squares approximation that minimizes error. Different workers can derive different coefficients, but useful results can be obtained via this approach. See my thoughts on this matter in a post (http://forum.luminous-landscape.com/index.php?topic=96491.msg817969#msg817969) to Iliah regarding Fast Raw Viewer and his response on how this could be done in FRV. Your input would be appreciated.
Regards,
Bill
-
Yes, I think we did come to agreement on that matter after an interesting discussion. The camera does not have a colorimetrically defined space. However, we can convert from the "camera space" to a colorimetric space using an experimentally derived 3*3 matrix. As I understand it, the coefficients of that matrix are often derived from a least squares approximation that minimizes error. Different workers can derive different coefficients, but useful results can be obtained via this approach. See my thoughts on this matter in a post (http://forum.luminous-landscape.com/index.php?topic=96491.msg817969#msg817969) to Iliah regarding Fast Raw Viewer and his response on how this could be done in FRV. Your input would be appreciated.
Regards,
Bill
The 3 channels of the camera are measurements of intensity within 3 spectral bands. I guess that color-science stuff are also intensities at either single wavelengths or some other spectral bands. Then mapping one to the other by a linear 3x3 transform allows you to approximate the true camera response to that of some idealized reference, generalizing the response of one particular camera to a reference response (with some errors)? I am an engineer, not a scientist. Color science makes me dizzy.
I have been frustrated by camera color profiles in Lightroom. Are you aware of any tools that can be used to visualize the difference between such profiles? I have a distinct subjective perception that Adobe profiles for my Canon camera are over-saturated and with wrong hue in deep reds vs my Colorchecker passport profiles. But having a graph makes the discussion more concrete...
-h
-
I read about this yesterday. I won't go into the discussion. Just thought this link could help you:
https://sites.google.com/site/chromasoft/Profiles
and
http://chromasoft.blogspot.se/2009/02/visualizing-dng-camera-profiles-part-1.html
-
The 3 channels of the camera are measurements of intensity within 3 spectral bands. I guess that color-science stuff are also intensities at either single wavelengths or some other spectral bands. Then mapping one to the other by a linear 3x3 transform allows you to approximate the true camera response to that of some idealized reference, generalizing the response of one particular camera to a reference response (with some errors)? I am an engineer, not a scientist. Color science makes me dizzy.
I have been frustrated by camera color profiles in Lightroom. Are you aware of any tools that can be used to visualize the difference between such profiles? I have a distinct subjective perception that Adobe profiles for my Canon camera are over-saturated and with wrong hue in deep reds vs my Colorchecker passport profiles. But having a graph makes the discussion more concrete...
-h
may be something like dcp2icc tool will help somewhat ? easier to find tool to visualize color transforms stored in icc containers... just my $0.00000000002
-
Yes, I think we did come to agreement on that matter after an interesting discussion. The camera does not have a colorimetrically defined space. However, we can convert from the "camera space" to a colorimetric space using an experimentally derived 3*3 matrix.
That's how I also see it, although we can even do better than a simple 3x3 matrix. With the use of RawDigger, we can take the result of a controlled shot of a colorchecker type of target (the larger Digital SG version is better suited than the simple 24 patch version), and output a CGATS text file directly from the Raw data, even before demosaicing.
That CGATS data file can then be used by e.g. the Argyll CMS to build a profile for the camera and illuminant used. There is even a 'simple' wrapper made by Iliah Borg for the specific Argyll application that creates the ICC profile, called MakeInputICC , I believe a Windows and a Mac version is available. This allows to create a simple matrix kind of profile, but also LUT versions. The colorspace primaries will be part of the profile.
As I understand it, the coefficients of that matrix are often derived from a least squares approximation that minimizes error. Different workers can derive different coefficients, but useful results can be obtained via this approach.
Yes, either via the matrix coefficients, or via the CGATS derived profile primaries, one is able to do further work based on that data.
Cheers,
Bart
-
That's how I also see it, although we can even do better than a simple 3x3 matrix.
in some discussions there was a reference to
http://www.cis.rit.edu/jwgu/research/camspec/
the idea is to shot a proper target, try to find out a good approximation of CFA transmission curves (in the absence of monochromator setup to get that directly) and then it is pure math, you have that and illumination spectrum and you can create "virtual" targets with as many patches of whatever required reflectance and calculate LUT profiles arguably better than before... somebody with a good grasp of matlab and math can try that... the link has some matlab code supplied to do the first part.
-
but also LUT versions.
it seems that old Gretag ProfileMaker can teach Argyll a lesson when it comes to creating "usable" LUT profiles from targets with limited amount of patches.
-
That's how I also see it, although we can even do better than a simple 3x3 matrix.
Cheers,
Bart
Of course, one can do better than a 3x3 matrix, by using a higher-dim matrix. For e.g., in the link below it was stated that a Quattro camera, which uses a Foveon sensor, could not match human luminous response (CIE Y) if a 3x3 transformation of the Fovean sensor 'primaries' was done:
http://www.dpreview.com/forums/post/54071772
(http://www.dpreview.com/forums/post/54071772)
However, in a 9-dim setting, which is still yields a linear CCM matrix, I got the following response, which is quite close. Interesting thing to note here is that the extra 6 parameters were derived from the camera/sensor r, g, b. Hence, no change to camera hardware needs to be made.
http://www.dpreview.com/forums/post/54094414 (http://www.dpreview.com/forums/post/54094414)
The reason is that the while the extra dims so obtained are correlated with the original 3, but they are linearily independent of them. And, adding extra linearily independent terms to a linear model can make one move closer to the desired target. There could be a noise penalty though, when such extra terms are added, though.
More info below:
http://www.dpreview.com/forums/post/54094878 (http://www.dpreview.com/forums/post/54094878)
http://www.dpreview.com/forums/post/54095986 (http://www.dpreview.com/forums/post/54095986)
-
However, in a 9-dim setting, which is still yields a linear CCM matrix,
isn't that actually already a non linear transform hidden behind some "matrix"
-
isn't that actually already a non linear transform hidden behind some "matrix"
No. The transform is linear, of the y = AX variety, where y, and x are vectors, and A is the matrix. The matrix A coefficients are however non-linearily derived from R, G, and B, so the basis functions are non-linear, which gives it more power than linear-only basis functions. But that doesn't change the nature of the transformation, which remains linear.
-
No. The transform is linear, of the y = AX variety, where y, and x are vectors, and A is the matrix. The matrix A coefficients are however non-linearily derived from R, G, and B, so the basis functions are non-linear, which gives it more power than linear-only basis functions. But that doesn't change the nature of the transformation, which remains linear.
so the matrix A coefficients are in fact functions and not constants, no ... by that logic any LUT transform can be "claimed" also linear
-
so the matrix A coefficients are in fact functions and not constants, no ... by that logic any LUT transform can be "claimed" also linear
Functions of R,G,B. They are 'constants' once you decide what powers of R, G, and B you are going to use with a given set of certain R, G, and B data. After that one does not change the matrix A. It is the same methodology used in a 3x3 matrix case, where for the matrix A, the 3 columns are R, G, and B themselves directly. BTW, if you plot those R, G, B, they are typically nonlinear, and not linear at all. Even in a 3x3 setting. In the higher dim-setting I mentioned, one uses nonlinear mappings of these R, G, B. However, that has nothing do to with the transformation being linear of the form y = Ax.
A nonlinear LUT would typically not be able to cast in a linear model of the form y = Ax.
-
so the matrix A coefficients are in fact functions and not constants, no ... by that logic any LUT transform can be "claimed" also linear
According to my error-prone understanding:
Nonlinear functions are a super-set of linear functions. Thus, one would expect them to:
1) Provide a better (or at least as good) fit to any given problem
2) To be harder to find
If you can decide on the nonlinear functions before-hand (through e.g. superior manual brain work), and expect that some (unknown) linear combination will always produce good results, then the actual weights can be found using methods optimized for linear problems.
-h
-
it seems that old Gretag ProfileMaker can teach Argyll a lesson when it comes to creating "usable" LUT profiles from targets with limited amount of patches.
I would disagree here. In many comparisons I've made only if space cube steps are in the target PM makes a LUT profile I find useful. SG does not include those steps. DC target was dropped because photographers are not equipped to shoot it (flare, light uniformity).
Much of the failures of profiling is due to trying to make things cheap and keep it simple. No flat field, no targets suitable for multiple shots with bracketing, no software that can "stitch" multiple CGATS based on single reference file. No lighting setups for targets that are easy to reproduce. No simple ways to keep the target flat and not to cast shadows.
However, due to CFA improvements and better in-camera noise control matrix profiles become more and more adequate. With many current cameras a simple matrix profile allows for 6 dE97.
-
I would disagree here.
nope... I specifically wrote " "usable" " (and use quotation marks around the word), you wrote "I find useful"... I think there is a BIG distance between these two ;)
no software that can "stitch" multiple CGATS based on single reference file.
that at least you can do in any text editor, combine text from CGATS files and from reference files (if you want to use several different targets) - just takes your time, and even with ProfileMaker you can combine shots of targets in photoshop to make a synthetic tiff and combined reference files for it using a text editor.
no targets suitable for multiple shots with bracketing
can you please explain (for posterity at least) how the bracketing might be useful with a given target, what is to gain ? a simpleton premise 'd be that we want to expose to get both good S/N for all patches and to avoid getting too close to the area (too close to clipping) where a particular camera might start suffer some ill-effects (something non linear) - I might assume there might be some use to make many shots with the same exposure and average, but bracketing ?... so what is to gain by making a lesser exposure of the same target ? unless you are trying to craft a profile with some hue twists based on lightness - but then correct me if I am wrong, no publicly available software can do that (unless you achieve that manually)
-
The gain is that if one is to compose a LUT, current profiling engines prefer more data on luminosity for a more accurate cube. Bracketing also takes care of some non-linearities in colour response.
-
current profiling engines prefer more data on luminosity
but what do we do with the reference data for patches ? for example we have several different (exposure wise) exposures of the same patch, but only one reference data for it... I am sorry, but how does the available (publicly) software deals with that technically ?
-
Spectral data is easy to scale.
I never mentioned publicly available software. On the contrary, I said it is trivial to do, but it is missing.
-
Spectral data is easy to scale.
like what - just multiple (or divide) the numbers for each 10nm step (from a regular .cie type of file that you have or get by using your own spectrophotometer/target) by the same constant to reflect the increase or decrease in exposure under the same spectrum ? what pair (patch exposure data - unmodified spectral data) will be the base one then... the brightest exposure + unmodified spectral data and then going down ?
-
SG does not include those steps. DC target was dropped because photographers are not equipped to shoot it (flare, light uniformity).
ProfileMaker it seems is using white/grey/black patches around the both (SG and DC) targets for some corrections and then ProfileMaker allows you (if I remember correctly) to exclude several difficult patches in one column in DC if you think that they have improper reflections..
-
+1EV is 2x SPD, right?
Flat field can't be obtained by just border patches, especially if a photographer makes a mistake of filling the frame with the target.
-
+1EV is 2x SPD, right?
it just seems so to me (but then may be the there is some catch, may be things are not linear there), but what is the base pair... you shall select some exposure as the one matching your measurements and go from there matching bracketed shots with modified spectral data or it is jut trial and error to find a match.
Flat field can't be obtained by just border patches, especially if a photographer makes a mistake of filling the frame with the target.
well, mistake of filling the frame and being punished with mechanical/optical vignetting and what was that called somewhere (???) - "4th power of the cosine rule" (when light hits a sensor at some angle further from the center) is easy to correct by instructions (stop down, fill 1/4-1/3 of a frame)... as for the borger patches vs flat field shot... isn't something (guess based on border patches) still better than nothing at all... again as ProfileMaker takes tiff files then some enterprising person can find a way to flatfield the shot (tiff) in photoshop... also you can use LCC profile (like in C1 or Adobe converters) in addition (albeit it is not flatfielding of the taget in the shot)
-
Base pair is determined by the exposure that matches the G value of the brightest patch in a neutral RGB space with gamma = 1. If it is impossible to match within ±1 G unit on 0..255 scale, the readings need to be scaled.
The sensors are not uniform, and the reading is not uniform too. One of the ways to avoid the problem is to take 2 shots rotating the camera by 180° and taking the second shot; and averaging data between 2 shots.
-
again as ProfileMaker takes tiff files then some enterprising person can find a way to flatfield the shot (tiff) in photoshop
oops, why PS - you can do flatfielding with rawdigger and then feed flatfielded CGATS file for example to BabelColor patchtool and export it from there to tiff and feed that to ProfileMaker... shall work
-
The sensors are not uniform, and the reading is not uniform too. One of the ways to avoid the problem is to take 2 shots rotating the camera by 180° and taking the second shot; and averaging data between 2 shots.
isn't it easier to rotate the target ?
-
You want to keep lighting as it is, so, no, target rotation is not an option here.
-
Base pair is determined by the exposure that matches the G value of the brightest patch in a neutral RGB space with gamma = 1. If it is impossible to match within ±1 G unit on 0..255 scale, the readings need to be scaled.
ok, if I understand correctly - I am taking .cie with spectral data, getting that .cie file into babelcolor patchtool (for example, as it is what I have), looking then at RGB of the brightest patch there (from .cie data) and then I am matching my exposure ... so that "242" ("magic number") in rawdigger comes from that approach ?
PS: what is "neutral RGB space", I mean "neutral" part of the wording
-
You want to keep lighting as it is, so, no, target rotation is not an option here.
but assume the target illumination is the best one can do and we use flat fielding to further address any unevenness - why not then... rotating the target will expose the different part of sensor to different set of patches just like rotating the sensor... or I am missing something very obvious here
-
You can open a spectral cie in PatchTool (no RGB data allowed in it) and set the RGB space to something like AdobeRGB or any other, but with gamma = 1. Neutral colour space means that grey is always R=G=B. Normally, any work colour space is neutral. Next, you check the reading on the brightest patch. This is the number you want in RawDigger as max.
-
Rotating the camera is simpler when the light is already adjusted.
-
thank you, now I just need to gather a strength & time to try to test a new knowledge...