[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Krayon - color spaces
From:       Thomas <zander () xs4all ! nl>
Date:       2000-10-07 9:08:59
[Download RAW message or body]

It would indeed be a great help to be the first unix program to do
more then 8 bits per channel, which is possible you said.

Let me then ask you for a next step; more then 3 channels. 

It is known that for print you have to have your images in CMYK, that is
4 channels. Typically with procentile values (so 100 steps instead of
the 256 8 bits produces)

It would be very nice to see CMYK support as well, meybe even with 16 bits
per channel.

Just daydreaming...  :)

> Right now the number of bits per channel is not hard coded, so there is
> theoretically no limit (except the size of the long long int) but the
> actual rendering to a display is limited to 24 bits.  The default right
> now is only 8 bits for a new image created from scratch.  Everything has
> to be converted to a QPixMap, I think, to actually display the image. 
> But processing on the image need not be limited to 24 bits.  
> 
> I can understand the need for a higher number of bits per channel for
> certain medical and scientific apps, but then the significant thing is
> to display small contrasts using false color so these contrasts are
> perceptible to humans looking at the screen or printout.  On the other
> hand for some kinds of analysis no visual presentation need be made -
> that's an area for statisticians to comment on.  Also, patterns may be
> encoded and/or searched for or data may even be encrypted using high
> bits per pixel. All this goes far beyond an app primarily for artists
> and web graphics designers.  I believe using patterns or fractals you
> can actually store more data than you have bits as these patterns add
> significance.
> 
> Using C++ is would seem not too diffucult to use different methods if a
> higher number of bits per channel than normal for display is specified,
> and to process the data and save it in that format.  At least nothing
> currently in KImageShop prevents that.  Of course the values would have
> to be converted down for display.  I'm not sure what the conventions are
> for the "extra" bits but even that can remain open and flexible. It's
> probably best handled with plugins.
> 
> We are a long way from that right now, but it is something to leave open
> as the app continues to evolve.  Just so these things are not hard
> coded, which they don't appear to be, the app can remain flexible enough
> for such things.
> 
> John
> 

The other Thomas..


-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[prev in list] [next in list] [prev in thread] [next in thread]