Legacy ImageMagick Discussions Archive

Hi

I'm using ImageMagick-6.3.5.3-Q16-Windows-dll and the librairies Magick++ under Microsoft visual studio. When I call the function :

img.attribute("dpx:television.time.code");

The fallowing error happen :

"Windows has triggered a breakpoint in ...

This may due to a corruption of the heap, and indicates a bug in ... or any DLLs it has loaded. "


When I break it, the software debug point to free.c.


If I don't use "img.attribute("dpx:television.time.code");" no error happened

Thanks

-Jimmy

The problem you reported is fixed in ImageMagick 6.3.5-4 Beta available sometime tomorrow. A release version will be available in about a week.

Hi

I still have the same problem with the version 6.3.5.4 downloaded this morning.

Do you want to have print screen of the error ?

Thanks

-Jimmy

We wrote a short Magick++ demo that simply reads a DPX image and outputs image.attribute("dpx:television.time.code"). We ran the application on Windows XP with ImageMagick 6.3.5-3 and it ran without complaint (no heap corruption).

Did you use Microsoft visual studio with MFC project ?

I could send you a small project in "Microsoft visual studio 2005" if you can handle it ?

Thanks

Post a URL to your sample project. The code should be as short as possible designed simply to illustrate the memory corruption and nothing else. Be sure to include a sample image since the problem could be image specific.

Hi everyone,
I am having a similar problem where I am trying to add time.code to a dpx image sequence. Effectively I have scripted in python a time.code generator that then uses the command to add timecode to each frame in a folder.

The problem occurs in that the time.code is added perfectly however the resulting dpx images are corrupt... the file sizes drop from 8108KB to 2708KB and nothing is willing to open them except when running a: clearly the time.code is being added however the actual image data is being lost somewhere along the line. Has anyone else experienced this or found a solution?!

Chris

We tried your command with several of our reference DPX image file and the conversion worked properly without complaint. Post a URL to your DPX image so we can download it and reproduce the problem.

Sure, no probs

Original: Corrupt: Thanks

We can reproduce the problem you posted. We'll need a few days to investigate.

Any luck with those investigations?!
~C

We believe we patched the problem. Download the latest ImageMagick release, version 6.6.7-0. If it fails for you, let us know.

I am facing the same issues described above by bydersjoint with a timecode header adjustment corrupting a DPX file. This is using version 6.8.0-2_0+q16 in a Mac terminal. If I run the following I see differing results on different image types:
On an RGB file with actual colour in the image, the operation seems to work successfully.

On an RGB file with only grayscale colour (e.g. all pixels are grey, such as a countdown leader at the head of an image sequence) the timecode data in the header is edited correctly, but the image file itself seems to be adjusted to grayscale, with the filesize shrinking from 8.3 MB to 2.8 MB.

How can I make this single header definition change without the rest of the file being converted in the process?

Add -type truecolor to your command line to force a RGB image type.

magick wrote:Add -type truecolor to your command line to force a RGB image type.

Thanks! Tried it and it seems to work exactly as expected.

On a side note, is the conversion to Grayscale the default behaviour for ImageMagick (I guess it's attempting to limit file size whenever possible, and sees a grayscale image as an ideal scenario for this) or is this a bug of some kind?

Certainly I can understand the behaviour for many file-types, but in the case of DPX it would be INCREDIBLY strange to see anything but an RGB image, and multiple applications I've tried will not open a grayscale DPX generated by IM. Additionally, when processing a large image sequence (which would be very common for DPX) to have some images down-converted to grayscale (for instance a credit roller at the end of a film) while the majority of frames are kept Truecolor, would be problematic.

Is there a way for me to suggest an IM enhancement to the DPX module to, by default, preserve the type of the source file in a convert operation?