Re: Representing image data

[Brian Drummond <brian_drummond@btconnect.com>]

On Wed, 11 Mar 2009 10:00:27 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Tue, 10 Mar 2009 21:26:29 GMT, Kenneth Almquist wrote:
>
>> I've been working on the design of an image decoding library.  The
>> basic idea is that the library will examine the first few bytes of
>> an image, determine the format, and call the appropriate decoder,
>> so that an application using the library can read images without
>> writing code for each image format it wants to handle.
>> 
>> I'm looking for suggestions on what the Ada interface to the
>> library should look like--and in particular how the image contents
>> should be provided to the application using the library.  The current
>> design has a C interface with no type checking on the image data.
>
>What sort of applications have you in mind? Digital filtration? Pattern
>recognition? Scene analysis? Rendering? 3D simulation? ... Depending on the
>application image representation format may vary.
>
>In any case there should be no "malloc" stuff as in your example.

I would suggest ditto on the access types. And on most of the "if ... null then
raise ..." These are a consequence of trying to replicate C in Ada instead of
actually using the language.

>>    declare
>>        type Image_Array is ...;
>>        type Image_Ptr is access all Image_Array;
          -- declares a type rather than a variable, surely?
>>    begin
>>        Image_Ptr := malloc(Imd.Sizeof_Image(Decoder));
>>        if Map_Ptr = null then raise Storage_Error; end if;
...
>>        Imd.Get_Image(Decoder, Image_Ptr.all'Address);

I have been using the following style. I'm posting it here (a) to point the OP
away from writing C in Ada and (b) on the age-old Usenet principle that the best
way to elicit a smart answer is to post a dumb one...

    declare
        type Image_Array is ...;
        Image : Image_Array(1 to Imd.Sizeof_Image(Decoder));
	-- The image size is unknown until runtime, but cannot vary within 
	-- this declare...begin...end block
        -- a real solution is 2D? but 2D arrays were not C's strong point
        -- as Dmitry says, image representation format may vary.
    begin
	-- Space is already allocated or exception raised by this point

        -- Read the image.
        Imd.Get_Image(Decoder, Image);	-- Image is an OUT parameter

        -- Process the image
        for i in Image'range loop
            -- process each Image(i)
        end loop
    end;

This won't work for very large images (like 1GB) with Gnat on its standard
settings (if the stack size is exceeded it'll just raise Storage_Error).
There are apparently means of setting its stack space allocation but I haven't
had any luck with them.

You can explicitly set the stack size for any task other than the main task, but
creating a task just to set stack size would be absurd, so I resorted to a
pointer...

    declare
        type Image_Array is ...;
        type Image_Ptr is access all Image_Array;
        Image_P : Image_Ptr := new Image_Array(1 to Imd.Sizeof_Image(Decoder));
        Image : Image_Array renames Image_P.all;
        -- now the loop body need never know about the pointer.
        -- It works without change whether or not you use a pointer.
    begin
        -- Read the image.
        Imd.Get_Image(Decoder, Image);	-- Image is an OUT parameter
        -- Process the image

	-- in my application, this scope was the end of the main program.
        -- Other cases may need to free(Image_P) here?
    end;

If there are better ways of accomplishing this I'm interested to hear them.

- Brian