From: Dmitry A. Kazakov on
On Sun, 2 May 2010 08:09:35 -0700 (PDT), Gautier write-only wrote:

> On May 2, 11:19�am, Andre <avsa...(a)hotmail.com> wrote:
>
>> The first question which comes up in mind is: where do you want to use
>> it for? Is it an initial step for your Ada based browser?
>
> Many things, from image manipulation without display, loading of
> textures for GL (there it would replace the "input" part of the GL.IO
> provided with GLOBE_3D), display into a rectangle of a GUI system and
> an in-memory cache (good guess: for a browser :-) ),...

Do you plan image processing stuff? I have somewhere half-written pyramid
and region-growing segmenting in Ada.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Gautier write-only on
On 2 mai, 17:21, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:

> Do you plan image processing stuff?
Not yet - maybe one day...
> I have somewhere half-written pyramid and region-growing segmenting in Ada.
Sounds good!
G.
From: Gautier write-only on
On 2 mai, 13:45, brian <brian.cat...(a)gmail.com> wrote:

> Have you thought about supporting the FITS (http://fits.gsfc.nasa.gov/) format?

Do you know what maximum color depth there is with FITS ?
I guess it might be more than 255 per fundamental color, but I got
lost in the docs.
Perhaps I should let this 255 boundary as a generic parameter as well.

Gautier
From: Brian Drummond on
On Sun, 2 May 2010 12:24:13 -0700 (PDT), Gautier write-only
<gautier_niouzes(a)hotmail.com> wrote:

>On 2 mai, 13:45, brian <brian.cat...(a)gmail.com> wrote:
>
>> Have you thought about supporting the FITS (http://fits.gsfc.nasa.gov/) format?
>
>Do you know what maximum color depth there is with FITS ?
>I guess it might be more than 255 per fundamental color, but I got
>lost in the docs.
>Perhaps I should let this 255 boundary as a generic parameter as well.

If it's not just for viewers, but also for photography and graphic arts,
it would be well worth supporting 16-bit per channel colour depths.
(Some scanners are 12-bit but that is often padded to 16 anyway.)

- Brian
From: tmoran on
> >I guess it might be more than 255 per fundamental color, but I got
> >lost in the docs.
> >Perhaps I should let this 255 boundary as a generic parameter as well.
>
> If it's not just for viewers, but also for photography and graphic arts,
> it would be well worth supporting 16-bit per channel colour depths.

Generic handling at the pixel level will surely be slower than direct
coding that knows what it's operating on, and that will be an issue
if there's any significant pixel level processing. CLAW uses tags to
distinguish images with different memory layouts, so image processing
dispatches to the correct code for the image at hand.
Picture : Claw.Bitmaps.Root_DIBitmap_Type'Class
:= Claw.Bitmaps.Root_DIBitmap_Type'Class'Input(Stream);
The different images have arrays of, e.g.,
for RGB555_Color_Type use record
Blue at 0 range 0 .. 4;
Green at 0 range 5 .. 9;
Red at 0 range 10 .. 14;
Alpha at 0 range 15 .. 15;
end record;
for Triple_Color_Type use record
Blue at 0 range 0 .. 7;
Green at 1 range 0 .. 7;
Red at 2 range 0 .. 7;
end record;

But is your package aimed more at processing images, or at doing IO on
the myriad file formats of images? And how about video?