p4WIN: Image storage 
Author Message
 p4WIN: Image storage

I need to store many scanned, page-size images within p4WIN databases, if at
all possible.

Conversion from PCX/TIF etc. and storing as Graphic is fine, as is
using the result. HOWEVER, the storage efficiency is appalling,
because Graphic format is really just Windows BMP.

My best option at this stage seems to be to store the images either in
their original file format or some even better format as Binary
objects, and convert them on-the-fly back to Graphic for display or
printing.

Thus I must ask:

a) Paradox itself has routines which convert from one format to
another. Are the required DLL calls documented, useable and
(preferably) memory-based as opposed to disk-based (in that working in
memory is a damned sight faster)? If the information is available, I'm
2/3 of the way there... What I'd need is the calling specifications
(from within ObjectPAL) for bidirectional routines between TIF & BMP,
and PCX & BMP, preferably using Binary and Graphic types as
appropriate.

b) If the above can't be used, is anyone aware of any third-party DLLs
which will convert to/from the above formats (again, in memory) and
callable from ObjectPAL? Even better if they support an ultra-
compressed intermediate format which can be used as the Binary object!

I expect others will have similar questions over time -- when I called
the local Borland folk they said that the .DB format would be hard to
change to support internal graphic compression -- I hope they change
their mind eventually!

cheers,
.peter

==============================================================================
             Peter Hyde, South Pacific Information Services Ltd
             New Zealand -- life on the outer edge of the planet



Wed, 03 Jul 1996 09:51:03 GMT
 p4WIN: Image storage


Quote:
>I need to store many scanned, page-size images within p4WIN databases, if at
>all possible.
>Conversion from PCX/TIF etc. and storing as Graphic is fine, as is
>using the result. HOWEVER, the storage efficiency is appalling,
>because Graphic format is really just Windows BMP.
>My best option at this stage seems to be to store the images either in
>their original file format or some even better format as Binary
>objects, and convert them on-the-fly back to Graphic for display or
>printing.
>Thus I must ask:
>a) Paradox itself has routines which convert from one format to
>another. Are the required DLL calls documented, useable and
>(preferably) memory-based as opposed to disk-based (in that working in
>memory is a damned sight faster)? If the information is available, I'm
>2/3 of the way there... What I'd need is the calling specifications
>(from within ObjectPAL) for bidirectional routines between TIF & BMP,
>and PCX & BMP, preferably using Binary and Graphic types as
>appropriate.
>b) If the above can't be used, is anyone aware of any third-party DLLs
>which will convert to/from the above formats (again, in memory) and
>callable from ObjectPAL? Even better if they support an ultra-
>compressed intermediate format which can be used as the Binary object!
>I expect others will have similar questions over time -- when I called
>the local Borland folk they said that the .DB format would be hard to
>change to support internal graphic compression -- I hope they change
>their mind eventually!

What I would recommend is to store the actual path and file name of the graphic
in an Alpha field, and then define an undefined graphic on your form on the fly.
This way you do not store the graphic twice, and you can leave the graphic
in its orignal form.  

You could also use an execute or DDE to call a third party graphics viewer
if you did not need to see the data and graphic at the same time.

--
                    Limax Computing - Paradox Questions?




Wed, 03 Jul 1996 06:49:16 GMT
 p4WIN: Image storage

 > >My best option at this stage seems to be to store the images either in
 > >their original file format or some even better format as Binary
 > >objects, and convert them on-the-fly back to Graphic for display or
 > >printing.
 >
 > What I would recommend is to store the actual path and file name of the graphic > in an Alpha field, and then define an undefined graphic on your form on the >  fly.
 > This way you do not store the graphic twice, and you can leave the graphic
 > in its orignal form.  

Except that I'd prefer to have unitary file management rather than
lots of independent files all over the place. Nevertheless, what you
suggest is one of the options I am considering.

 > You could also use an execute or DDE to call a third party graphics viewer
 > if you did not need to see the data and graphic at the same time.

Indeed. Unfortunately, I *do* need to see 'em together.

Thanks for the suggestions.  I hope for more in the 3rd-party line or
perhaps one day Borland will move to offer compression of graphic data.

cheers,
peter
==============================================================================
             Peter Hyde, South Pacific Information Services Ltd
             New Zealand -- life on the outer edge of the planet



Sat, 06 Jul 1996 06:48:32 GMT
 
 [ 3 post ] 

 Relevant Pages 

1. Sql Server Image storage

2. Image storage and retrieval - still having problems!

3. image storage design question.

4. Need help on image storage...

5. SQL 2000 Image Storage

6. the storage size of rows of image data type

7. Need help with image storage..

8. Image Storage

9. Image File Storage in VB

10. IMAGE data storage / retrival

11. Storage a Image

12. Help! Image Storage and retrieval using Sql-server


 
Powered by phpBB® Forum Software