What are your favorite test images that you use to evaluate and compare various processing techniques? Name as many as you would like, specifying what you use each for. Yes, there is the censor cropped Lena but that is so passé.
The train picture in the posts where I discuss my software was a grab out of a bunch, but it has served well as I’ve programmed and learned. It’s a bit underexposed so there’s “good” noise in the shadows, but it also has a blown highlight in the locomotive headlight. It also has a bit of a blue cast, so it’s made a good topic for exploring white balance.
It doesn’t have red eyes or a variety of vivid colors, so I found other images to test tools working on those things. But, it serves well as a baseline for when I change things. Just worked one of those, and learned from it why using a calibrated camera profile for editing is not a good idea… 
Evening, Glenn,
Could you explain that in more words, please?
I fear that I do not understand what you mean 
Have fun!
Claes in Lund, Sweden
– at this time of year, also known as
Santa Claes. SInterclaes &c &c –
Ah, wrote that knowing I wasn’t saying enough, then got called down to breakfast…
Hope these screengrabs show up well here. I was incorporating Libraw 0.18 in rawproc, including the GPL2/3 demosaic libraries. So I opened the test image with these parameters:
input.raw.libraw.colorspace=raw
input.raw.libraw.gamma=linear
input.raw.libraw.wavelet_denoise=600
input.raw.libraw.cameraprofile=Nikon_D7000_Sunlight.icc
The first three parameters correspond to “dcraw -o 0 -g 1.0 -n 600”, and the last parameter assigns my calibrated camera profile to the image; I call it a “libraw” parameter, but it’s really my own concoction. Anyway, here’s a screenshot of a portion of the image in rawproc:
Notice the discoloration at the bottom of the smokebox, this won’t be there if the wavelet_denoise operation is omitted.
Ah, additional discovery as I’ve created these screenshots: originally, the first tool I applied was a convert colorspace to @elle’s Rec2020 g18 working profile, and the posterization went away. As I was recreating the situation to post here, I decided to try the g10 profile, and got the same discoloration. Sooo, it’s not the profile itself, but the wavelet denoise pushing some of the low values out of the data range. When I convert to the g18 profile, the gamma curve moved the shadows into the range and they don’t get clipped:
Thing is, wavelet denoise is being done prior to demosaic, so I’d think if values were clipped there, I’d get them clipped from libraw. This is behaving as if the clipped values were out-of-range but still captured in the floating point data, and the gamma application in the colorspace convert pulled them in. The histograms point toward that conclusion, but I’d need to dig further to actually make that assertion.
Of note is that the screenshot images are not of the actual working image, they’re the display image which is converted to the calibrated monitor profile. That might have something to do with it, but I don’t see anything like that at present.
Also of note is that I’m doing this in fits and starts, in between holiday events. So, I’ll compile and run something, note things like this, and have to leave it to go open Christmas presents or somesuch. When my wife asks me “why so distracted?”, if my explanation starts with terms such as “gamut” and “colorspace”, her expression just glazes over and she waits for me to finish…
@Claes and all, hope you’re having the best of the holidays, whatever may be your belief…
I don’t have a single test image, because it depends on what I’m testing.
I do have a standard demonstration image.
I have approximately 1161 versions of that image on my web site. That’s a lot of toes.
trainsMe, toes fetish? Moi?
I guess I’ve used many hundreds or thousands of different images for tests. Here’s one example:
If the forum software hasn’t mangled it, the word “red” is RGB(0,95%,0) and “blue” is RGB(77%,0,7%), but the embedded ICC profile makes those pixel values into colours that correspond to the words. So it tests whether software respects profiles.
These days, most software is fine. Gimp correctly shows “red” in red, whether I keep the original colorspace or not. Photo Flow correctly shows “red” in red. RawTherapee 5.3, umm, well, I guess it isn’t designed to read non-raw images, or perhaps it has an option somewhere that I need to tick. But it shows “red” in green, which suggests it is ignoring the profile.
3 Likes
I moved the discussion regarding this particular “red blue” image to:
The test image passed its test. It’s not just nominal.
How about for comparing smoothing and sharpening methods, respectively, and their parameters? I.e.:
- test images for comparing smoothing techniques
- for comparing sharpening ones
- for examining how parameter changes affect the result
I still use the train image. It’s got “good” noise in the shadows, good for testing denoising. And, it’s got edges all over, ripe for sharpening.
I do worry sometime that I’m developing myopic expectations based on this image. So, I try to “eat my own dog food” as much as possible, using the tools to do my regular processing as much as possible. On our recent vacation, I found myself one evening re-working some code and pushing it to the git repository, because the batch processing wasn’t working quite right for the general case…