>>problem with image item in OracleForms 4.0

From: Zhou Jian <zhou_at_igd.fhg.de>
Date: 28 Feb 95 19:53:49 GMT
Message-ID: <zhou.794001229_at_batida>


>I want to load an image of size 324x216x8 into a form
>by using the built-in function READ_IMAGE_FILE.
>However, OracleForm always resizes my image
>permanently to a lower resolution.
 

>The image item used has a width of 330 and height
>of 220, the Max Length property is set to 32000.
>(I got error message "no enough memory" if I set
>the Max Length property higher, although my PC
>has 16MBytes main memory). The OracleForm reference
>P3-255 says:
> "The Max Length property controls the size of the image Oracle
> Forms can load into the form. If you want to see the entire
> image at the full size, set the Max Length property equal
> to the size of the file"
> ^^^^^^^^^^^^^^^^^^^
> "If Max Length is not large enough to display the image
> at full size, Oracle Forms will scale the image so the entire
> image is displayed in th eimage item. ..."
 

>Can anyone help me to understand the "the size of the file"
>mentioned above? My original image (324x216x8) is jpeg compressed
>and has a size of 10914 bytes, but Oracle resized it!!!

I think your might be a number of reasons to your problem

  1. The JPEG Decoder in forms 4.0 is crap (my slightly biased opinion).
  2. Although the size of the file is only 10914 bytes, the size of the decoded image is 324*216 = 69984 bytes. This size exceeds the maximum amount of memory that can be allocated for buffered records in a base table block (max 64K), under Microsoft Windows. I believe that it is the decoded image that is stored.
  3. The 64 K availiable has to be shared between the number of buffered records in the block containing the image item. The minimum buffered record possible is 3. So in fact you have at most 64 K/3 = 21,3 K availiable for each image item in Forms 4.0 under windows (nice isn`t it).

Possible workarounds :

  1. If possible load the image in another format (tiff), this will not solve your problem with lack of memory, but at least the loading of the image is faster and better.
  2. Asuming you use MS-Windows, use DDE.APP_BEGIN (see OF for Windows installation guide) to start an external wiever. I did this myself, and the application reads JPEG images both from file and database.
  3. Forms 4.5 released these days is said to not have the 64K limit.

>Any suggestion and work-around are highly appreciated.

Thanks a lot for your reply to my question in the news group comp.databases.oracle concerning image item in OracleForms 4.0.

>2. Asuming you use MS-Windows, use DDE.APP_BEGIN (see OF for Windows
>installation guide) to start an external wiever. I did this myself, and the
>application reads JPEG images both from file and database.

I succeded to call an external program from Forms by using DDE.APP_BEGIN. However, I haven't found a way to transfer data between Forms and the external program (it is a normal C program which can open a file and read an image into a variable). Since I used to work on Unix plattform, I am not famaliar to DDE stuff under Windows. Are the DDE calls DDE.POKE and DDE.REQUEST the correct solutions? How I can receive data in my C program and send data to Forms from my C program? I would appreciate any help with this.

Another open point in this solution:
Suppose I could transfer the data(image) into a PL/SQL variable in Forms, since the LONG RAW data type of PL/SQL has a limitation of 32KBytes (Version 2.0), does this mean that I still cannot store an image larger than 32KB into databases?

Regards,

Jian Zhou


|   |   |_|_|_|_|                                                         |
 ___|___|_|_|_|_|  Fraunhofer Institute for Computer Graphics             |
|   |   |_|_|_|_|                                                         |
|___|___|_|_|_|_|  Jian Zhou            email : zhou_at_igd.fhg.de           |
|  /--- /   /---|  Wilhelminenstr. 7    phone : (+49) 6151-155-131        |
| /--  /_  / __ |  D-64283 Darmstadt    fax   : (+49) 6151-155-199        |
|/    / / /___/ |  Germany                                                |
|_______|_______|_________________________________________________________|
Received on Tue Feb 28 1995 - 20:53:49 CET

Original text of this message