Occasionally corrupt png images

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
Post Reply
ptast

Occasionally corrupt png images

Post by ptast »

Hi all,

Im using the C API version 6.3.8-Q8.

For some reason I manage to save an image as png which is corrupt. identify tells me only corrupt image.

I did some debugging and found that I could read the info struct and IHDR. It will halt when reading the image data.

Here is the corrup png
http://www.poes-weather.com/~patrik/tmp/corrupt.png

I suspect that I have somehow managed to breake the ImageInfo or pull pixels from the stack when I manipulate the image. My system runs 24/7 and I can successfully save about 100 images before it gets corrupt so it is tricky to debug.

Any help appreciated.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Occasionally corrupt png images

Post by magick »

Which C API are you using? MagickCore or MagickWand? With MagickCore you need to be careful assigning structure members to avoid memory corruption. MagickWand has no structures to protect the developer against memory corruption problems.

Experiment with setting the memory and map resource limits to a small value like 16mb and 32mb respectively. If you are dealing with large images its possible the PNG delegate library is running out of memory and not exiting gracefully. Also make sure you have plenty of disk because disk errors can cause corruption as well.

Otherwise without viewing your program, building, running, and reproducing the problem you report, we can be of not further help.
ptast

Re: Occasionally corrupt png images

Post by ptast »

Many thanks for the quick reply!

I'm using the MagickCore. And I have suspected that the ImageInfo I use when saving, WriteImage(the_imageinfo, the_image) could be corrupt, I'll try to hammer it some.

I'll check also if the PNG delegate is not exiting gracefully.

The code that updates the image is almost a mile long and will not help you.

The idea I had in mind since it is possible to read the header and see the image size can you see if the amount of read rowbytes match (in the PNG) the size in the png header with your debugging tools. If these do not match I bet the delegate will crach immediately.

I bet the crash will be found after line 2184 in coders\png.c function ReadOnePNGImage

I can thoug view the corrupt image in Windows Picture and Fax viewer (and it looks corrupt)

Again, this is not a ImageMagick error, it is mine.
Last edited by ptast on 2008-02-20T09:49:33-07:00, edited 1 time in total.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Occasionally corrupt png images

Post by magick »

If you are assigning string type members of the ImageInfo structure, keep in mind that it must be allocated from heap memory. For example, this is wrong
  • image_info->size = "120x120";
whereas this is the the right way to assign a string member:
  • image_info->size = ConstantString("120x120");
ptast

Re: Occasionally corrupt png images

Post by ptast »

Yep I have noted, so if I assign static text in IM
I assign it like this

draw_info->density = "96x96";

then use it

Before I destroy I make sure that IM wont try to delete it by assigning
draw_info->density = NULL;
DestroyDrawInfo(draw_info);

I know this is not nice....

When I allocate an image I assing the size to the image->rows and image->columns
like

image = AllocateImage(imageinfo);
image->rows = height;
image->columns = width;

then do what ever

for(uy=0; uy<image->rows; uy++) {
q = GetImagePixels(image, 0, uy, image->columns, 1);
pq = GetImagePixels(pimage, 0, uy, pimage->columns, 1);
if(q == NULL || pq == NULL)
break;
for(ux=0; ux<image->columns; ux++) {
q->red = pq->red;
q->green = pq->green;
q->blue = pq->blue;
q->opacity = pq->opacity;
q++;
pq++;
}

if(SyncImagePixels(image) == MagickFalse)
break;
}

...and so on...


I'll keep on debugging....
Last edited by ptast on 2008-02-20T10:09:33-07:00, edited 1 time in total.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Occasionally corrupt png images

Post by magick »

Bad idea. Always use ConstantString() when assigning string members. That is precisely why we developed MagickWand. It's C but its based with an object-oriented design to ease the development of ImageMagick applications.
ptast

Re: Occasionally corrupt png images

Post by ptast »

I'll change to ConstantString() and use it from now on
ptast

Re: Occasionally corrupt png images

Post by ptast »

4 your interest. I'm receiving weather satellite images and this is what I do with IM Core C API since 2002.

The (occasional) corrupt image is a background image projected from a rectangular (spanning from -180W to 180E and -90S to 90N) to a polarstereographic image. In my case the northern hemisphere. I create this background image (from scratch) once every day. If this background image exists it will add the satellite pass to it and save it as png to be used later today. After it is saved I start to add text, grid, chop, etc and finally I chop it and save it as lossy JPG and upload it to the web.

Sample background image that contains two NOAA images (7 mb)
http://www.poes-weather.com/~patrik/tmp/good.png
The sample image contains two NOAA image, ie updated two times today

The final chopped composite image can be viewed at
http://www.poes-weather.com/~patrik/apt/logs/daily/ if you scroll down to Composite Images

When I started IM I tried the Wanda but found that it was too high-level for me so I desided to use the Core.

As you can see there are so many things that can go wrong before I call WriteImage(...)

My post here was:
- can you see if the png header is OK?
- if so, is the image data OK?
- is the PNG end OK?

In the corrupt png (7 mb) http://www.poes-weather.com/~patrik/tmp/corrupt.png

When we/I find out what is not OK then I will know were the problem is (ie I rip something from the stack).

I should not bother you with self-inflicted errors like this but I find it most interesting...
Post Reply