AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2006.09.27 13:31 "[Tiff] Horizontal prediction for 16bit data", by Joris Van Damme
2006.09.27 13:36 "[Tiff] Re: Horizontal prediction for 16bit data", by Joris Van Damme
2006.09.27 22:56 "Re: [Tiff] Horizontal prediction for 16bit data", by Chris Cox
2006.09.27 23:09 "Re: [Tiff] Horizontal prediction for 16bit data", by Joris Van Damme
2006.10.09 12:49 "Re: [Tiff] Horizontal prediction for 16bit data", by Andrey Kiselev
2006.10.09 14:22 "Re: [Tiff] Horizontal prediction for 16bit data", by Joris Van Damme
2006.10.06 22:03 "[Tiff] Inverting color space values in a TIFF file", by Richard Nolde
2006.10.06 22:05 "Re: [Tiff] Inverting color space values in a TIFF file", by Toby Thain
2006.10.06 22:50 "Re: [Tiff] Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.06 23:37 "Re: [Tiff] Inverting color space values in a TIFF file", by Richard Nolde
2006.10.07 00:44 "Re: [Tiff] Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 01:35 "Re: [Tiff] Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 02:02 "Re: [Tiff] Inverting color space values in a TIFF file", by Graeme Gill
2006.10.08 21:39 "Re: [Tiff] Inverting color space values in a TIFF file", by Edward Lam

2006.10.06 23:37 "Re: [Tiff] Inverting color space values in a TIFF file", by Richard Nolde

I'm working a an extension to tiffcrop that will invert the color space of an image.

'invert' seems like an easy word, but it is in fact very hard to come up with a meaningful definition when applies to imagery.

I'd personally think this is image editing library stuff, not quite a tiff tool job.

My reasons for adding it to the tiffcrop tool are to be able to "fix" these inverted scans in an image processing pipeline that does not have any human interaction. Obviously, there is much room for error and only knowing the specifics of the input data make it viable. As an example, bar code recognition software by definition looks for runs of BLACK pixels or grayscale pixels darker than a certain threshold. It is possible to scan the entire image and figure out if there are on average, more dark pixels than light ones, but that is a huge overhead when the barcode may be only a tiny fraction of the image.

Knowing that someone retrieved a document from a microfilm reader that produced a negative image instead of a positive one, it makes sense to be able to invert the pixels. The bar code reader does not have to have special code to handle TIFF images and invert the black and white, though it certainly could if we were sure to always write our own bar code readers...

For Bilevel and Grayscale images, this makes sense. I use it to convert a negative microfilm image to a positive one.

In bilevel imagery, there can be only one definition, turn black into white and vice versa. So that's feasible and unambiguous.

The way you're doing it now probably involves changing the image data, judging from your description further down this mail. You may want to consider just changing the PhotometricInterpretation, turning PHOTOMETRIC_MINISWHITE into PHOTOMETRIC_MINISBLACK and vice versa.

I was aware that the PHOTOMETRIC MINISXXX would need to be updated as well, though in

my case that will not solve the problem for downstream applications in the pipeline that are not smart enough to do it themselves. I don't write ALL our software...

In greyscale imagery, there is the exact nature of the greyscale space to think of. The way I read the TIFF spec, multibit PHOTOMETRIC_MINISWHITE and PHOTOMETRIC_MINISBLACK should not be interpreted as R=G=B, as in sRGB, but as uniform, which corresponds best to the L channel of Lab. However, I suspect most readers and writers do read and write R=G=B, as in sRGB, therefore reading and writing data that is quite different from L in a non-linear way, therefore reading and writing data that is quite different from human vision and doesn't map uniform to the latter.

I don't have the background to under the LAB issue, so I will probably only handle the simple

cases and opt out via an error for the others. I was aware that it wasn't as obvious or simple

as I construed it originally, which is why I asked the TIFF list if it were worth undertaking at all.

So stuff start being more complicated. You need to think about whether 'inversion' should make sense to human vision (L as in Lab), or to the cathode ray tube voltage regulators (R=G=B as in sRGB). Next, you need to think about whether you prefer to go with a strict interpretation of the TIFF spec, or at least my interpretation of the TIFF spec (which may be a different thing altogether), or whether you want to instead aim at compatibility with mainstream readers and writers, or at least my suspicions as to what these do mostly (which may be... etc).

People may argue that thinking too hard on this is not worth it. The difference in results of the different choices you could make is significant, but it's not huge.

I'll offer what I know how to do for now and make the code available to anyone who wants to

add to it or correct it to be less ambiguous/restricted in scope. >> However, is there a meaningful inversion of a palette colour or an

RGBA image and would this be done by modifying the palette rather than the data that points

into the palette/lookup tables? What sort of algorithm should be applied to the

data in the palettes? Eg for 8 bit grayscale, I just subtract the value from 255

and for bilevel data, I just invert the bits with ones complement operator. Doing

the same for palette images produces viewable but bizarre images. Instead, should I simply subtract the values in the palette from 255 for 8 bit per color

images?

It is clear you need to change the palette, not the image data.

As to actual definition of 'inversion', this is even harder in the realm of full-colour. These are some of your options:

  1. You can of course define inversion as inversion of the encoded data, whatever the colour space. That means inversion of an RGB image is quite different from inversion of an image that is stored as Lab, for instance. So it may make numeric sense, but it will surely not make any sense to any user.

I'll probably drop color conversions altogether, but it would be nice to find a subset of color spaces that can be handled with simple palette reversal. Again, I don't need it for my projects, but I like to make the code as capable as possible if it does not do incorrect things, which seems to be the case

for all but bilevel and simple 8 bit grayscale images. Can you refer me to a source of documentation on LAB for my future study? I'd at least like to understand it better.

  1. If you need to make sense to a visual system of a user, you really need to go with Lab here, the difference is huge in this case. But still, there's two options, and both do another visually meaningful thing. You can define inversion to work on the L channel only. That means dark red becomes light red, light blue becomes dark blue.
  2. The second option when working on Lab is to invert the L value, and negate the a and b values (the numeric operation depends of course on the exact encoding of Lab, that is different for CIE Lab, ICC Lab, and ITU Lab Photometrics, but I'm referring to the actual CIE L*a*b* values as commonly regarded in the range [0..100,-128..128,-128..128]). This is more or less the effect of a negative in analogue photography.
  3. An image editor or image editing library might want to offer both option

2) and 3), as both or meaningful to the human user, and might want to refer to 2) as 'Brightness inversion' and to 3) as 'Negative' to make a clear distinction.

Thanks for your help. I'll see how far I get with things,

Richard Nolde

I assume an Alpha Channel value would not be modified.

That seems the most meaningful option. It is also the only options that works when alpha is premultiplied and equal to 0.

Is there any point in allowing such images to be Inverted?

I think the answer is above, because another way to ask the same question is 'Is there a (visually or otherwise) meaningful and useful definition of inversion?', and also 'Is this something that is logically correctly situated in the domain of a TIFF tool, or a file format independent image editing operation that fits more conveniently and logically in a image processing library layer?'.

I think the answer is certainly 'Yes' when applied to binary black and white data. In the greyscale case, I have some doubts. In the full colour case, I've many doubts.