Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas012.isp.belgacom.be (localhost [127.0.0.1])
        by inav001.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k9731ar1000748
        for <joris.at.lebbeke@skynet.be>; Sat, 7 Oct 2006 05:01:37 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx020.isp.belgacom.be (inmx020.isp.belgacom.be [195.238.5.139])
        by inas012.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k972kg8K032122
        for <joris.at.lebbeke@skynet.be>; Sat, 7 Oct 2006 05:01:33 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx020.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k96MrhEr010504
        for <joris.at.lebbeke@skynet.be>; Sat, 7 Oct 2006 00:53:44 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k96MmHmW010313;
	Fri, 6 Oct 2006 18:48:28 -0400
Received: from outmx010.isp.belgacom.be (outmx010.isp.belgacom.be
	[195.238.5.233])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k96MmCZb010310
	for <tiff@lists.maptools.org>; Fri, 6 Oct 2006 18:48:13 -0400
Received: from outmx010.isp.belgacom.be (localhost [127.0.0.1])
	by outmx010.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id k96Mm8q7016881
	for <tiff@lists.maptools.org>; Sat, 7 Oct 2006 00:48:08 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (222.175-245-81.adsl-dyn.isp.belgacom.be
	[81.245.175.222])
	by outmx010.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with SMTP id k96Mm29C016822; Sat, 7 Oct 2006 00:48:02 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <001601c6e999$c7506280$deaff551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Richard Nolde" <nrichard8@qwest.net>,
        "TIFF mailing list" <tiff@lists.maptools.org>
References: <200610051603.k95G3DSF021473@duke.maptools.org>
	<4526D2B8.5010406@qwest.net>
Subject: Re: [Tiff] Inverting color space values in a TIFF file
Date: Sat, 7 Oct 2006 00:50:08 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Cc: 
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00001b8c
X-MSP-STORE: Sat, 07 Oct 2006 05:01:44 +0200
Status:   

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.

> 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.

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.

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.

> 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.

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.

> 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
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
