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

List:       kde-kimageshop
Subject:    Pixels and pixel representations
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2004-12-02 9:27:00
Message-ID: 200412021027.02919.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


I've started working littlecms'ing Krita, and I think that it's useful to
 make a little list of what kinds of classes we currently have for pixels and
 colors (because a single color definition is quite close to a single pixel)
 and what we need to do with them.

 KisPixelRepresentation
 KisPixelRepresentationReadOnly
 KisPixelRepresentationRGB|CMYK|GRAY

Design: These classes contain one QUANTUM* pixel and allow access per
'channel' -- only, a channel must always be a QUANTUM. I think we first need
to get rid of the RGB and other specialisations.

Function: These classes are intended to be used from the iterators. You get
them one by one; it won't mean much memory overhead if we make it slightly
more intelligent

 QUANTUM*

Design: a pointer to a a chunk of memory containing one or more pixels.

Function: efficient bitBlting, conversion, image loading. But also in
conversion code in the color strategies. LittleCMS wants the data it is going
to transform in this format.

 KoColor

Design: a complex class that can transform pixel data using its own
 colorspace conversion algorithms.

Function: in the UI, for instance color selectors. In conversion code in the
color strategies.


I want to propose two classes, KisPixel & KisPixelRO that take the function
of KoColor and KisPixelRepresentation*, for when you want a pixel from the
iterators or define a colour. 

KisPixel & KisPixelRO are Cyrille's KisPixelRepresentation(ReadOnly) with some 
additions, like a separate getter for the alpha channel and for substance 
channels like wetness, grainyness, weight and thichness -- once we implement 
those things. It's no problem to make this class a little heavier, since we 
won't store our pixels as instances of this class, it's just a wrapper for 
code that messes with pixels.

I want to get rid of KoColor, QRgb and QColor -- we can use KisPixel for 
those.

QUANTUM* should become Q_UINT8* and be hidden as much as possible and
certainly never used where you need to get channel values, it's just internal
to the paint device and the colour strategy. KisPixel* can be templated for
various channel types (byte, int, float, double).

We may also need an iterator on paint devices that returns as large a block
of pixels in one iteration as possible, for instance for conversion
operations, loading or saving.

In the meantime, I've integrated most of littlecms, done a colour settings 
dialog, a colour mode conversion plugin and a new new image dialog (but that 
one got lost because I was hacking late yesterday evening and made a 
mistake). And you can move a selection again. I hope to be able to commit 
Saturday at the latest.


--
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


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