[Lazarus] fpimage use of Lazarus

Mattias Gaertner nc-gaertnma at netcologne.de
Sat Feb 16 21:41:34 CET 2008


On Sat, 16 Feb 2008 20:49:57 +0100
Marco van de Voort <marcov at stack.nl> wrote:

> On Sat, Feb 16, 2008 at 07:15:05PM +0100, Mattias Gaertner wrote:
> > > On Sat, Feb 16, 2008 at 05:35:13PM +0100, Marco van de Voort
> > > wrote:
> > > 
> > > Addition to self:
> > > 
> > > I've studied intfgraphics some more and my scheme means that maybe
> > > some lazarus specific tricks need less lazarus specific
> > > implementation
> > 
> > Great.
> > What tricks?
> > Keep in mind that the goal of TLazIntfImage is to eventually access
> > directly the widgetset images instead of copies. Of course this can
> > only work on some widgetsets.
> 
> Well, it is partially exactly like that. It just pulls the defining
> parameters (width, height, bpp, rowpitch (aka bytes per row) of the
> storage requirements into the abstract class. Not the storage itself.
> 
> If the storage of a native type can be descibed like that, a laz
> specific image can still store in the native struc, but use the
> normal readers and writers.
> 
> So to summon up, the storage properties and assumptions are:
> 
> 1. width + height in pixels
> 2. size of a pixel in bits. If pixels are non packed (24-bits stored
> as 32-bit), this is about the _actual_ storage value, so 32-bit.
> 3. size per row in bytes or pixels. (alignment reasons) I'm used to
> pixels, but maybe bytes is better.
> 4. If one has the address of the first pixel of a row, the address of
> the next pixel can be calculated by adding the amount of bits.
> (bitpacking into account)
> 5. a property that signals if 1..4 hold true. If not the reader/write
> must revert to the current (pixel based) behaviour.
> 
> The 4th condition goes wrong if e.g. byte arrays are stored as integer
> arrays on little endian systems, then you get
> 
> b3 b2 b1 b0 b7 b6 b5 b4 ... etc.
> 
> I don't know if there are fileformats who do this (hope not), but if
> they do, it is the readers responsibility to revert to "per pixel"
> addressing via the pixels property.
>
> I'm thinking about adding a property that signals if you can jump
> between rows by adding a fixed amount of bytes (usually bytesperrow,
> but maybe negative). But I'm not doing that until I at least have
> implemented the above.
> 
> > > mask support is not needed in bpp. Bytesperline is probably a
> > > similar crucial param as bpp, so I propose to pull this into
> > > fpimage too. (supports (var bpp, var bytesperline));
> > 
> > I still wonder what happen to the other properties, like depth, bit
> > order, rgb order, alpha depth, etc.
> 
> Those are all to interpret pixel data (depending on what you mean by
> depth). Not to extract or allocate storage.

Does this mean every function that uses scanline must support all
these things? OR it allocates an image in a 32bit format and later the
whole image is converted to the needed format.

 
> Note that this is all still just about the pixel data. 
> 
> One of the reasons that laz has own readers and writers seem to be
> palettes. I'm still investigating that. This is all just in the
> "sparring and brainstorming" stage.


Mattias



More information about the Lazarus mailing list