AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
October 2006

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

Valid HTML 4.01!


2006.10.06 22:03 "Inverting color space values in a TIFF file", by Richard Nolde
2006.10.06 22:05 "Re: Inverting color space values in a TIFF file", by Toby Thain
2006.10.06 22:50 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.06 23:37 "Re: Inverting color space values in a TIFF file", by Richard Nolde
2006.10.07 00:44 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 01:35 "Re: Inverting color space values in a TIFF file", by Joris Van Damme
2006.10.07 02:02 "Re: Inverting color space values in a TIFF file", by Graeme Gill
2006.10.08 21:39 "Re: Inverting color space values in a TIFF file", by Edward Lam

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

Joris wrote:
> Richard,
> Richard Nolde wrote:
>> 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
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
> 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.
> 2) 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.
> 3) 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.
> 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.
> Best regards,
> Joris Van Damme
> Download your free TIFF tag viewer for windows here: