About
wind&oil, Weblog
Syndicate:
Subscribe to a syndicated feed of my weblog,
brought to you by the wonders of RSS.
Projects:
www.behrmann.name
www.oyranos.org
ColourWiki
CinePaint
Others Bogs:
Color hacks
mulebakken.net
Linux Photography
home :: imaging
Wed, 14 Jan 2009
Nouveau Compiling on openSUSE
after Hal V. Engel suggested the nouveau driver because of its good
XRandR-1.2 support, I installed the driver from the X11:Driver:Video
repository. With that alone Oyranos has now a basic XRandR support.
Today I wanted to use the current development version of Nouveau
and build on my local openSUSE-11.1 installation. It worked not very well.
So here comes some suggestions on which packages are needed to sucessfully
build the driver. RPM's which should be present are kernel-source, which is
huge, xorg-x11-server-sdk and the various xorg-x11-*-devel packages.
With them installed the instructions of the Nouveau developers can be followed:
InstallNouveau.
After uninstalling all of the nouveau distribution binaries and drm kernel
modules X started successful.
/imaging | no comments | permanent link |
Fri, 14 Nov 2008
ICC DevCon08
was a great opportunity to meet colour people in person. Many thanks to ICC
for opening the door to speek at the
conference about
Linux. It was a fairly
small talk compared to what others provided. But it was as well for many the
first introduction about the possibility to do colour management on Linux at all.
So first of all I gave a introduction about licensing and commercials, as this
is most often confused by IT managers.
It was very nice to meet Max Derhak, who implemented the mpet tag and developed
on the multiProcessElementsType for better support of floating point processing
inside ICC profiles. The tag was developed to better support colour conversions
for the motion pictures industry. Great to see that there is communication
possible to that extent. We looked over the license issue of SampleICC and
figured out how to best solve that. He has interessting things on the plan
together with ICC.
Meeting people on the streets of Portland, and I do not think this is specific
to this city, had a flair like wild west. Many pedestrians where distant at more
than a arm's lenght and keept a cautious tone at a first glance. The border
between civilised politeness and the feeling of attention in face of a tiger
was very fuzzy. Instinctively I had to think about the citicens right in the US
to own gun wappons. On the other hand I saw many signs of openness as I found
in Europe, if I may compare, mostly in Amsterdam. So I found a nice place of
showing quite some tensions.
/imaging | no comments | permanent link |
Thu, 04 Sep 2008
HP's DreamColor displays and the 30-bit advancement
cool
10-bit per channel powered by modern graphic chips. Given the last generations
of chips with high bit depth frame buffers, dual link dvi and HDMI it seems not
so astonishing. Anyway HP can be praised to have brought this to designers and
graphics studios at a reasonable price. Congratulation.
(Of course I hope this technology becomes pretty standard and will become even
more affordable.) Would be
interessting to know how Dreamworks deploys this under Linux -
Ati : Nvidia?
/imaging | no comments | permanent link |
Tue, 08 Apr 2008
Cairo in motion
is a small code example
for how to do animation in Cairo. Click on the below image to download a 5MB
mpeg preview.
The red arc has a mouse over effect and the right below spline with the red line
is interactive.
/imaging | no comments | permanent link |
Wed, 16 Jan 2008
Joel Cornuz
asked me some questions to publish on his blog. As I know him from
discussions and like his gallery, I agreed and sent him my answeres:
Hello Kai-Uwe
As one of the lead developers of Cinepaint and a very active contributor in
Color Management (CM) on Linux, you are a key-person when it comes to using
Linux for photography. Thank you very much for taking the time to share your
thoughts with us and help us understand better what is going on in the Color
Management field on Linux.
Read the whole interview on Joels blog...
/imaging | no comments | permanent link |
Tue, 13 Nov 2007
Pixel naming in Cairo
I find it always confusing to say CAIRO_FORMAT_ARGB32 and mean a 8-bit
per channel thing. At a first glace I seriously expect it to be a IEEE
float format, which it is not. Most users will expect to multiply by the
channels count to get the pixel size not to divide the pixel size by the
channel count.
If you consider, most of the imaging world has changed its pixel naming to
a per channel base, it would be nice to see Cairo following this too.
It is pretty common to say 16-bit image processing, which means per
channel. Or 8-bit monitor displaying, which is again per channel. The
monitor LUT's are sometimes 10/12 or even 14-bit, again per channel.
The pixel numbers dont say anything about the colour resolution.
Why bit per channel instead of bit per pixel?
For instance a 16-bit Gray X-Ray image, properly displayed, can be
superior compared to a 32-bit/pixel CMYK representation. In this case the
numbers are non relevant to the lightness distinction. The example makes
clear, what counts are the shades of gray.
Tricks like dithering dont count. Otherwise all people would still use
indexed gif's for photos. But I dont know any camera or scanner doing so.
On the other side a 32 bit chunck with 3*10 bit RGB inside would be harder
to describe. Is such thing still in use for hardware and must be
supported? At least it is not present in cairo_format_t. Out of scope?
Possibly someone can point me to a document describing the necessity of
Cairos per pixel naming as is. Is it something to do with tradition?
Nethertheless the non selfexplanatory behaviour today makes it feel much
like a pitfal.
To exemplify (a F stands for floating point):
colour bit/channel bit/pixel cairo_format_t sheme --------------------------------------------------------------- RGB 8 24 CAIRO_FORMAT_RGB24 RGBA 8 32 CAIRO_FORMAT_ARGB32 Gray 8 8 GrayA 8 16 Alpha 8 8 CAIRO_FORMAT_A8 CMYKA 8 40 RGB 16 48 CAIRO_FORMAT_RGB48 RGBA 16 64 CAIRO_FORMAT_ARGB64 Gray 16 16 GrayA 16 32 CMYKA 16 80 RGB[A]... 16-bit float/channel use the same pixel size as the 16-bit per channel integers. RGB IEEE Half 16 48 CAIRO_FORMAT_RGB48F RGBA IEEE Half 16 64 CAIRO_FORMAT_ARGB64F ... IEEE floats and 32-bit integers: RGB FLOAT 32 96 CAIRO_FORMAT_RGB96F RGBA FLOAT 32 128 CAIRO_FORMAT_ARGB128F ... IEEE doubles: RGB DOUBLE 64 192 CAIRO_FORMAT_RGB192F RGBA DOUBLE 64 256 CAIRO_FORMAT_ARGB256FThe later can easily be confused with a 256 shades of Gray per channel naming.
Do you really expect a user to always divide the pixel values by the channels count to get an idea about the colour resolution?
To remember the marketing inflation of having 16 million colours and so on is long gone away. Today it is in, to say a software supports 16-bit, which is much more meaningful.
As a side step, manufacturers suggesting theire consumer camera to deliver the full range of 16-bit is still a joke. Such anouncements are demystified regularily.
Windows and osX have long inherited pixel naming conventions.
Cairo as a young project does not. Cairo could express pixels much closer to our current language in cairo_format_t.
Lets end here and come to a suggestion for a new sheme:
CAIRO_FORMAT_ARGB32 -> CAIRO_FORMAT_ARGB_8 CAIRO_FORMAT_RGB24 -> CAIRO_FORMAT_RGB_8 CAIRO_FORMAT_A8 -> CAIRO_FORMAT_A_8 CAIRO_FORMAT_A1 -> CAIRO_FORMAT_A_1 #define CAIRO_FORMAT_ARGB32 CAIRO_FORMAT_ARGB_8could ashure compatibility.
Later Cairo could add
CAIRO_FORMAT_ARGB_16 CAIRO_FORMAT_RGB_16 CAIRO_FORMAT_RGB_HALF CAIRO_FORMAT_RGB_FLOAT... and so on.
/imaging | 21 comments | permanent link |