discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

color spaces, calibrated and device


From: Riccardo Mottola
Subject: color spaces, calibrated and device
Date: Tue, 24 Feb 2004 20:13:55 +0100
User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hello

maybe the main person that should be the adressee of this email should be
Fred Kiefer, but I send it to the list so more people can read/contribute.

I posted a bug report about this, but it was still incomplete since a
gnustep class implementation was incompelte. Gregory finished it and now
comparisons can be clearer.

>From what alexander malmberg expaliend to me, the problem is essentially
that -xlib backend doesn't handle calibrated color spaces correctly, not
only it doesn't calibrate them, but it treats all spaces as rgb...

The problem that I have is that WhiteCalibrated and BlackCalibrated
greyscale tiffs are treated wrongly and they invert.

This is noticeable when using PRICE. Now that alexm patched art the two
backends behave the same way, a strange way. On art I also get some
segfaults from time to time...

I specify that the _same_ code of price works fine on MacOS-X ! no trouble
at all.

Internally in price I use only the WhiteCalibrated color space. This means
that if an image has a BlackCalibrated imageRep, I make a new image rep,
invert all pixels, release the old and add the new one. At load time.

The interesting thing is that even with this conversion, all greyscale
tiff's display fine! So where lies the problem?

When I apply a filter! A filter releases the old representation and inserts
a new one which contains the filtered output. Note that I always generate a
WhiteCalibrated color space! So I don't udnerstand where the trouble should
be!

But it happens that some filters look correct after filtering, some other
look inverted! (but they al looked correct after loading).
As far as I can tell the images that look inverted are the white-calibrated
images, which is mroe absurd, since they were correct since the beginning.

The whole thing behaves correctly on os-x..So now that both -art and -xlib
behave identically... I'd say it is more mysterious. Either a deeper bug in
NSImage NSImageRep.. or a bug that is common to both backends... But it
could be also that my code is buggy and that MacosX is more permissive? I
have no clue.

-Riccardo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]