«

"Richard Heathfield" <> wrote in message
news:...
> superpollo said:
>
>> Richard Heathfield wrote:
>>
>>> I wrote a bitmap library (in straight ISO C, so I can use it
>>> anywhere) which I find useful when I want to produce any kind of
>>> graphics for my own use.
>>
>> is it available anywhere?
>
> No, I haven't released it, but it's not hard to write your own. You
> can get the bitmap spec from here:
>
> http://www.wotsit.org/list.asp?al=B
>
> All you have to do is define an internal graphics format (of your
> own design), and then provide, at a bare minimum, the following
> functionality:
>
> 1) load a bitmap image into a frame buffer
> 2) set a given pixel to a given colour
> 3) save a frame buffer into a bitmap file

And, possibly, get the colour of a given pixel.

--
bartc

"Richard Heathfield" <> wrote in message
news:F-WdncKq-...
> bartc said:
>
>>
>> "Richard Heathfield" <> wrote in message
>> news:...
> <snip>
>>>
>>> All you have to do is define an internal graphics format (of your
>>> own design), and then provide, at a bare minimum, the following
>>> functionality:
>>>
>>> 1) load a bitmap image into a frame buffer
>>> 2) set a given pixel to a given colour
>>> 3) save a frame buffer into a bitmap file
>>
>> And, possibly, get the colour of a given pixel.
>
> Not actually essential. Certainly very useful, though. It would
> probably be the fourth feature you'd add.

How would you, for example, invert an image (in any sense) without the
ability to read image data?

If this is only for creating original data, you only need 2) and 3). If you
are implying that the frame buffer has random read/write access anyway, you
only need 1) and 3).

--
Bart

bartc wrote:
> "Richard Heathfield" <> wrote in message
> news:F-WdncKq-...
> > bartc said:
> >
> >>
> >> "Richard Heathfield" <> wrote in message
> >> news:...
> > <snip>
> >>>
> >>> All you have to do is define an internal graphics format (of your
> >>> own design), and then provide, at a bare minimum, the following
> >>> functionality:
> >>>
> >>> 1) load a bitmap image into a frame buffer
> >>> 2) set a given pixel to a given colour
> >>> 3) save a frame buffer into a bitmap file
> >>
> >> And, possibly, get the colour of a given pixel.
> >
> > Not actually essential. Certainly very useful, though. It would
> > probably be the fourth feature you'd add.
>
> How would you, for example, invert an image (in any sense) without the
> ability to read image data?

Save a copy of the date before loading it into the frame buffer.
Invert the saved copy. Load the inverted saved copy into the frame
buffer.

"jameskuyper" <> wrote in message
news:34419732-9441-4bd3-9fce-...
> bartc wrote:
>> "Richard Heathfield" <> wrote in message
>> news:F-WdncKq-...
>> > bartc said:
>> >
>> >>
>> >> "Richard Heathfield" <> wrote in message
>> >> news:...
>> > <snip>
>> >>>
>> >>> All you have to do is define an internal graphics format (of your
>> >>> own design), and then provide, at a bare minimum, the following
>> >>> functionality:
>> >>>
>> >>> 1) load a bitmap image into a frame buffer
>> >>> 2) set a given pixel to a given colour
>> >>> 3) save a frame buffer into a bitmap file
>> >>
>> >> And, possibly, get the colour of a given pixel.
>> >
>> > Not actually essential. Certainly very useful, though. It would
>> > probably be the fourth feature you'd add.
>>
>> How would you, for example, invert an image (in any sense) without the
>> ability to read image data?
>
> Save a copy of the date before loading it into the frame buffer.
> Invert the saved copy. Load the inverted saved copy into the frame
> buffer.

So, have another API in addition to the 3-function one proposed; but one
that has read access? Wouldn't it be easier just to add that missing
function?

--
Bart

bartc wrote:
>
> "jameskuyper" <> wrote in message
> news:34419732-9441-4bd3-9fce-...
>> bartc wrote:
>>> "Richard Heathfield" <> wrote in message
>>> news:F-WdncKq-...
>>> > bartc said:
>>> >
>>> >>
>>> >> "Richard Heathfield" <> wrote in message
>>> >> news:...
>>> > <snip>
>>> >>>
>>> >>> All you have to do is define an internal graphics format (of your
>>> >>> own design), and then provide, at a bare minimum, the following
>>> >>> functionality:
>>> >>>
>>> >>> 1) load a bitmap image into a frame buffer
>>> >>> 2) set a given pixel to a given colour
>>> >>> 3) save a frame buffer into a bitmap file
>>> >>
>>> >> And, possibly, get the colour of a given pixel.
>>> >
>>> > Not actually essential. Certainly very useful, though. It would
>>> > probably be the fourth feature you'd add.
>>>
>>> How would you, for example, invert an image (in any sense) without the
>>> ability to read image data?
>>
>> Save a copy of the date before loading it into the frame buffer.
>> Invert the saved copy. Load the inverted saved copy into the frame
>> buffer.
>
> So, have another API in addition to the 3-function one proposed; but one
> that has read access? Wouldn't it be easier just to add that missing
> function?

RH provided no more a very high-level overview of a minimal graphics
system, with no details. The idea that what I'm talking about requires
another API implies a more complicated system than I was envisioning
from his summary - I was imagining nothing more complicated than direct
manipulation of the array or simple flat file containing the data to be
displayed. Certainly a pixel query function would be one of the next
features to add, and RH has said as much. But it's not a requirement for
a minimally useful system. It's always possible to keep track on your
own what the contents of the pixel should be; depending upon what you're
doing, the value that the pixel should be displaying may be more useful
than the value that it actually is displaying (because the cursor
happens to be passing over that pixel at the moment of the query, for
example).

On Jul 18, 1:36*pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Malcolm McLean said:
>
> > "Richard Heathfield" <r...@see.sig.invalid> wrote in message news:
> >>> How would you, for example, invert an image (in any sense)
> >>> without the ability to read image data?
>
> >> To extend your question a little, if I may:
>
> >> Q: How would you do <foo>?
> >> A: By adding the <foo> feature.
>
> > With a readpixel writepixel and querydimensions I can perform any
> > operations I want on my image.
> > Admittedly the code on top might be extremely complex, but it is a
> > complete buffer API.
>
> My lib does not attempt to address the screen at all - it's purely
> for in-memory image manipulation. It can currently:

> 3) get the colour of the pixel at a given point in the image;
> 4) set the colour of the pixel at a given point in the image;

> As you can see, it is far from complete!

It has the most essential bits.

--
Bart