PUT_DIB_BLOCK@ limitations

This is not the definitive word, but it represents my experience of using this function to create JPEG and BMP files. This is just a heads up for anyone developing an application that creates or manipulates an image and uses PUT_DIB_BLOCK@.

Let me start off by saying that having the facility is absolutely awesome. It has save me a great deal of time and effort.

My application creates an 'image', a representation of the data as if it is an image. This image is then imported into other software for use. The image must be at least 100 DPI to accurately show the data for the user. The program I created was sized for a 300 DPI image. The resolution is under the user's control. The image could be up to 8.5' wide and 300' long.

For BMP, I was unwilling to have the file size so huge (with 24-bit color), so found a bit of code (qdbmp, written in 'C') that allowed writing of 256 color images. Works well, even at 300 DPI.

The JPEG image, not so well at 300 DPI. What I have found is that if the image is requested at higher than 150DPI and nearly fills the available image space, the PUT_DIB_BLOCK will crash. Unfortunately, it does not usually crash in a pretty way. Sometime, Windows 7 just says it is not working. No trace, nothing to let you know.

After playing around with the code for better than a day, I've discovered that the key is the resolution and the image size being requested for conversion (I limit the size to the actual area being filled, so I don't try to convert the entire 2552900003 image space). It would appear that once called, PUT_DIB_BLOCK will allocate an internal image that is of the proper size, then create the JPEG file from that. With the arrays as big as they need to be, this means that the 32-bit limit for program allocated memory will (sometimes) be exceeded. While I haven't caught it at the 4-GB memory limit using the Task Manager, it's clear image creation is asking for a LOT of memory, and that is what causes the 'crash'.

I mention this not as a need for help in solving a problem, but just as a heads-up to anyone else who might run into a similar problem using PUT_DIB_BLOCK@.

Bill,

I am surprised that PUT_DIB_BLOCK will require a lot of memory. Haven't you allocated memory for this previously when creating the memory image ? If it is crashing then it must require a temporary memory buffer to generate the BMP format. Allocating sufficient space is subject to the limits of the memory allocation routine, which may be the problem. ( your image is about 660 mb, so 1.3gb if a copy is to be made ) Have you tried alternative formats, such as .gif or .png output, as this may require less temporary memory for the compression algorithm. The support for DIB formats is confusing and I have forgotten the details. From memory, there are 2 separate groups of routines to manage this, one using handles and the other using arrays. Perhaps changing to the other group may help. Export_image@ associated with a virtual graphics region has worked well for me, although this may require more 660mb surfaces.

John

Thanks for the reply, John.

The arrays I use are statically allocated; they are shared (via common) between many of the image creation routines.

The way I figure it is PUT_DIB_BLOCK makes a temporary copy of the original image, based on the size parameters passed as inputs. From that, the process of creating a JPEG may (or may not) require a 'working copy' of the image into which the compressed data is placed. The reason being the compression process uses the original data and is 'stepped through' with the appropriate algorithm. This would imply the original image would not be modified. It is possible that only the original image (my array) would be used as the source for the compression.

So, now we're up to at least 1.32 GB. Add into that the data arrays that the program uses to create the images, and I'm easily up over 2 GB. Not counting the code contribution to the total memory used.

Yes, I tried the GIF output. The result is a 24-bit color image. The image I actually create only has 256 colors, so I used a different 'C' routine to take the data and format it for 8-BPP. PUT_DIB_BLOCK can only create the 24-bit color version.

PNG is not a format supported by the external program. I wish it was; it would likely be better than JPEG!

From what I read, EXPORT_IMAGE@ requires a window to be created onto which the image is drawn. I already have the data in memory and drawing onto a graphic surface is unnecessary (although it could be done).

My first attempt was to take a BMP version of the image, read it back in and then write it back out as JPEG. But, in turns out, with the same disastrous results.

A few folks have asked questions about reading images in and manipulating them using the GET_DIB* and PUT_DIB* routines. This was my attempt to give them a heads up about limits imposed in the 32-bit environment.

If I could run 64-bit, then I would imagine there'd be no issues!! Unfortunately, some of my customers use Win2K, so 32-bit it is!! After reading several posts by Paul and others regarding memory allocation, it is likely that there is either some fragmentation preventing memory from being allocated of sufficient size, or it just gets too darn big. Don't know which is true (ie either is true), but it surely is repeatable!

Bill,

Huge bitmaps are, well err - huge. I'd find it interesting to know how the image was created, and what it consists of. If it is 256 colours, then jpeg compression is going to be poor, and it doesn't appear to me that the image is in any way photographic with that few colours.

If you created the image yourself in your application using FTN95 graphics, then it is going to be a series of graphics elements (lines, shapes, text) and you will get a much smaller file if you treat it as vector rather than raster. You have a variety of formats for vector based files, which include SVG (can be read by both CorelDraw and Adobe Illustrator, HPGL (CorelDraw for certain) or AutoCAD DXF (again, I only know CorelDraw for certain).

I have some very primitive routines for SVG and HPGL if you are interested. They write the coordinates and drawing commands in fixed format, which makes reading them back in extremely easy!

Eddie

Hi Eddie,

Perhaps it was unclear in my earlier posts, but the application to which these images are destined does not accept vector representations. I already generate DXF and PDF files of these images. These vector forms are not acceptable inputs to the other application.

Yes, the bitmap is huge, and yes, the image is not photographic. I do not use FTN95 graphics routines except for PUT_DIB_BLOCK@(). I have my own, proprietary bitmap generation routines that have been honed for exceptional speed over the last 30 years (even on Win2K, single processor, 300'x8.5' at 150 DPI, processes over 750000 line drawing vectors/second into the bitmap). It is really pretty simple stuff, and the overhead is minimal. Except the memory requirements. 'Back in the day' when you had only 64**[u:a553df031c]K[/u:a553df031c]** of memory, these same routines with a slightly different interface (transparent to the user) were used to create these same images that ran for hundreds of inches at 180 DPI.

Regarding compression: the JPEG compression (50% quality) for these images is actually pretty good. The image compresses, as compared to an 8 bit per pixel BMP file, to about 1/6th the BMP (8-bit) size. The comparison to a 24-bit per pixel BMP is, as one would expect, proportionally smaller. I am impressed with the usefullness and ease of interface that this routine gives. As an aside, I have found that the JPEG quality of 30% is quite marginal (for my data) due to blurring of the text data and the blurring of the symbologies displayed, causing them to possibly be mistaken (visually).

Referencing SVG and other vector formats: I already generate vector representations of these images. Being able to produce the bit mapped equivalent is saving my customers an additional conversion step (which I can handle for them in my SW should they chose to convert the PDF to a bitmap using a conversion application), and saves them whatever money they would spend on that commercial product to convert the vector to bitmap. And, before you suggest using free alternatives; yes, some exist, but sometimes they don't behave well with other software; one product deletes the source image after conversion with no option to stop this behavior. Others have different limitations, like image size or bit-depth.

Thanks for your comments, Bill

http://www.cjdsoftware.com/images/50PercentQuality.JPG Small example

Hi Bill,

Now that I've seen your example borehole log, it looks like a run length encoding bitmap format could be even better than JPEG, as it would be lossless, and you have very big areas of the same colour. Have you tried PCX, and how does it compare with 50% JPEG compression?

Eddie

Eddie, thanks for the suggestions.

However, you completely missed the point: PCX is not a legitimate format for the external application that I am targeting. BMP and JPG [u:2da984a846]are[/u:2da984a846].

While an interesting thought experiment, PCX, EPS, etc. are of [u:2da984a846]no use[/u:2da984a846] to me until and unless the external using program(s) require it.

Bill,

Have you tried to transpose the image ? It may be that PUT_DIB_BLOCK@ works in the other direction for it's compression, assuming it has a row or column, rather than area compression technique.

John

John, no, if I transpose it, the orientation is off for the user.

The compression is working just fine. It's just the image size that becomes an issue when the image truly fills the available space!