macbethcal error

Howdy.

So, I'm trying to use the macbethcal utility for the first time, and am getting an odd error. The first time I tried to create a calibration file I got an "out of gamut" error, which I understand points to a poorly exposed gretag photo. Before re-photographing everything, I thought maybe cropping my gretag image to the registration marks may help (lazy Sunday thinking). But now, after cropping the photo and re-creating the pic file, I now get the following error when running macbethcal (macbethcal -d debug.pic mbscan.pic colorcal.cal):

macbethcal: non-increasing neutral patch

The resulting debug.pic is 59 bytes and is useless. Two questions: how can I get a better image to avoid the out of gamut error, and what caused the error above? I was using northern skylight on a fairly cloudless day for my lighting, and f2.0 1/125 for all exposures.

Hi Rob,

I suspect that the corners of your image are not specified in the proper coordinates, or are not the right corners -- assuming you used the -p option to macbethcal. Remember that the y-coordinate from Photosphere is reversed from that produced by ximage, which is what macbethcal expects...

-Greg

P.S. If you're still stuck, send me your image and I'll see what I can do with it.

···

From: Rob Guglielmetti <[email protected]>
Date: February 5, 2006 10:36:16 AM PST

Howdy.

So, I'm trying to use the macbethcal utility for the first time, and am getting an odd error. The first time I tried to create a calibration file I got an "out of gamut" error, which I understand points to a poorly exposed gretag photo. Before re-photographing everything, I thought maybe cropping my gretag image to the registration marks may help (lazy Sunday thinking). But now, after cropping the photo and re-creating the pic file, I now get the following error when running macbethcal (macbethcal -d debug.pic mbscan.pic colorcal.cal):

macbethcal: non-increasing neutral patch

The resulting debug.pic is 59 bytes and is useless. Two questions: how can I get a better image to avoid the out of gamut error, and what caused the error above? I was using northern skylight on a fairly cloudless day for my lighting, and f2.0 1/125 for all exposures.

Gregory J. Ward wrote:

Hi Rob,

I suspect that the corners of your image are not specified in the proper coordinates, or are not the right corners -- assuming you used the -p option to macbethcal. Remember that the y-coordinate from Photosphere is reversed from that produced by ximage, which is what macbethcal expects...

-Greg

P.S. If you're still stuck, send me your image and I'll see what I can do with it.

Hey Greg, I think I got it. Thanks. I think it was cropped too closely, is all. I ended up re-shooting the whole thing (a few times), anyway. I'd send or post a copy of the new debug image, but I'm having a problem with my internet connection here at home, and can't send any large files at the moment. =8-/

I was getting a lot of patches out of gamut with my northern light images, so I did it again under direct sun, and only had two patches with the diagonal lines on them which I guess is good. (?) The greyscale sequence at the bottom row was perfect, but the colors were less so. Maybe this is a white balance issue? I fixed it at "sunlight", but I'd like to do some more tests when I have sun at my disposal again.

Interestingly, I got some variation on some paint color swatches that were photographed twice with two different backgrounds. I have two different materials (sofa cushions) that I wanted to sample, onto which I taped three paint color swatches that I also wanted to sample. I photographed each cushion with the same three swatches taped on, ran them through pomb with my .cal file generated with macbethcal, but the rgb values (plucked from ximage) for the three swatches differ somewhat:

sample1

···

======
greenish background: .56 .52 .38
brownesque background: .58 .55 .41

sample2

greenish background: .35 .30 .22
brownesque background: .47 .41 .29

sample3

greenish background: .41 .35 .25
brownesque background: .38 .32 .24

sample2 shows the most variation, but truthfully I'm not sure what's an acceptable range here. sample1 and sample3 have very similar rgb values in both images, which gives me a warm fuzzy feeling about the whole process. But sample2 seems pretty variate. Is this as good as I should hope for, or is my technique off here? These samples were photographed within seconds of each other, under direct (Colorado!) sun, so I think the lighting is pretty consistent.

- Rob Guglielmetti

Hi Rob,

Glad you got it working. My experience with macbethcal is that the simple linearization plus 3x3 matrix transform employed works well with common scanners, but less so with digital cameras, who seem to use more exotic color mappings (probably 3-D lookup tables). My efforts to make a more general tool based on lookup tables didn't go so well, so I tabled it (haha).

My best advice is to shoot in RAW mode if you want precise color. There is much less to go wrong, as dcraw.c and Photoshop use a simple color matrix transform to go from the sensor space to sRGB, and produce fairly consistent colors in my tests. I know I said a lot of disparaging things about RAW, and I still don't care for it as a general concept, but unfortunately the camera manufacturers don't provide any other reasonable path for accurate color at the moment. They're much more focused on getting the consumer "preferred" look. (That will be my next rant.) I've also found RAW to be a good path to absolute luminance values, but only for some cameras.

-Greg

···

From: Rob Guglielmetti <[email protected]>
Date: February 5, 2006 4:32:27 PM PST

Hey Greg, I think I got it. Thanks. I think it was cropped too closely, is all. I ended up re-shooting the whole thing (a few times), anyway. I'd send or post a copy of the new debug image, but I'm having a problem with my internet connection here at home, and can't send any large files at the moment. =8-/
I was getting a lot of patches out of gamut with my northern light images, so I did it again under direct sun, and only had two patches with the diagonal lines on them which I guess is good. (?) The greyscale sequence at the bottom row was perfect, but the colors were less so. Maybe this is a white balance issue? I fixed it at "sunlight", but I'd like to do some more tests when I have sun at my disposal again.
Interestingly, I got some variation on some paint color swatches that were photographed twice with two different backgrounds. I have two different materials (sofa cushions) that I wanted to sample, onto which I taped three paint color swatches that I also wanted to sample. I photographed each cushion with the same three swatches taped on, ran them through pomb with my .cal file generated with macbethcal, but the rgb values (plucked from ximage) for the three swatches differ somewhat:

sample1

greenish background: .56 .52 .38
brownesque background: .58 .55 .41

sample2

greenish background: .35 .30 .22
brownesque background: .47 .41 .29

sample3

greenish background: .41 .35 .25
brownesque background: .38 .32 .24

sample2 shows the most variation, but truthfully I'm not sure what's an acceptable range here. sample1 and sample3 have very similar rgb values in both images, which gives me a warm fuzzy feeling about the whole process. But sample2 seems pretty variate. Is this as good as I should hope for, or is my technique off here? These samples were photographed within seconds of each other, under direct (Colorado!) sun, so I think the lighting is pretty consistent.
- Rob Guglielmetti

Greg Ward wrote:

My best advice is to shoot in RAW mode if you want precise color. There is much less to go wrong, as dcraw.c and Photoshop use a simple color matrix transform to go from the sensor space to sRGB, and produce fairly consistent colors in my tests. I know I said a lot of disparaging things about RAW, and I still don't care for it as a general concept, but unfortunately the camera manufacturers don't provide any other reasonable path for accurate color at the moment.

But it's an awesome argument for me to get a new camera, since mine doesn't do RAW. =8-)

Thanks for the feedback, Greg.