error opening dpx when creation time not set

[jo b]

hi, when I try to open a DPX file with wrong creation time, IMDisplay.exe crash.
a tried the same with a call to image.read() in magick++ library in debug mode and my program crash also now with the message:

debug assertion Failed!
program: ...
file: dtoxtm64.c
line: 67

Expression: (((long)(yr - 1900) >= _BASE_YEAR)&&((long)(yr - 1900) <= _MAX_YEAR64))

For information on how your program can cause an assertion
failure, see the visual C++ documentation on asserts.

is there a way to catch/bypass/correct the error ?
because my DPX file can be open with xnview without problem.

[magick]

It looks like we'll need to sanitize bad dates. Linux / Mac does not crash with bad dates. Can you post a URL to an image that causes the crash so we can reproduce the problem and fix it. Thanks.

[jo b]

It would be difficult to send you an image that will cause the crash because copying of the file will set a good creation time in the copied file.
I have managed to get the creation filetime of my DPX that has a wrong creation time and here is some code sample lines that will help to modify any dpx file so it has the same creation date than mine.

Code: Select all

//the creation filetime of the bad DPX file is {dwLowDateTime=3577643008 dwHighDateTime=27111902 }
FILETIME ftCreate; 
ftCreate.dwLowDateTime = 3577643008;
ftCreate.dwHighDateTime = 27111902;
HANDLE hFile = CreateFile( "c:\\01.dpx", GENERIC_ALL, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
SetFileTime(hFile, &ftCreate, NULL, NULL);
CloseHandle(hFile);

I hope this is helpfull...

[magick]

Rather than a bug in ImageMagick, this appears to be a problem with Visual C++ and only affect certain releases. Microsoft reports, for example:

You’re passing a year earlier than 1900 to one of our time classes. We have never correctly supported this (for example, strftime outputs incorrect values). During Whidbey we made a decision to explicitly report when these bad values were used. The "crash" you're seeing is us reporting an invalid parameter to the operating system which invokes our crashdump debugger, captures a dump and aborts. In debug builds we assert.

This validation of the year has caused a lot of customer pain since we shipped, so we’ve recently issued a patch to change our behaviour back to that of VC7 and earlier. The patch doesn’t make our code work right for negative years, but we no longer report the error. This is enough to make some simple cases work again.

The patch number is KB911884 and you can get it if you call product support.

Martyn Lovell
Development Lead
Visual C++ Libraries

[jo b]

ok, but since in IMdisplay.exe the crash happens also, is it possible to bypass this check or find an alternative ?
Or is there a true meaning to check this time values ?

[magick]

We tried your code under Windows XP but all it did was create a file date of 2020 and ImageMagick processed it without complaint. We could put a check in ImageMagick for a proper date but we need a reference image file that we can use to reproduce the problem to verify our patch works.

[jo b]

hello,
sorry for the delay. the problem is if I post only a DPX file the action of downloading it will overwrite the filetimes in the downloaded file.

the solution I found is to generate yourself the DPX file.
here the source code and an exe in a zip: http://www.datafilehost.com/download-88099d61.html
by running the exe, 27 small dpx files will be generated in the folder DPX.

the test is to open the files with imdisplay.exe on windows xp.

If your computer is in the timezone -05:00 (it was my case) :
- the files [01.ps.-13.dpx] to [09.ps.-05.dpx] wil work fine
(filetimes: 1970\01\01 06:00:00 to 1970\01\01 00:00:00).

- the files [10.ps.-04.dpx] to [14.ps.+00.dpx] will make imdisplay.exe crash!
(filetimes: 1969\12\31 23:00:00 to 1969\12\31 19:00:00).

- the files [15.ps.+01.dpx] to [27.ps.+13.dpx] will make imdisplay.exe display a messagebox "parameter is incorrect".
(filetimes: 1969\12\31 18:00:00 to 1970\01\01 06:00:00).

if you are in another timezone the file grouping chift.

[magick]

What OS are you using? We ran your script and it created DPX images with dates at 1969 and 1970. We're using ImageMagick 6.5.9-0 under Windows XP and Windows 2003 Server with all the latest patches. All the image files converted without a crash or complaint.

[jo b]

yes the script does not do a conversion.
it create new DPX files with filetimes set at 1969 and 1970.

you have to try to open the files with imdisplay.exe
i'm using ImageMagick-6.4.7-Q16 on a windows Xp sp3 OS.

what is your computer timezone?

[magick]

We suspect the problem is that you are using an older version of ImageMagick. Try the latest release, 6.5.9. The imdisplay program works for us. We're EST.

[jo b]

ok, I've tested the 6.5.9 release.
now,
- imdisplay opens nicely the files [01.ps.-13.dpx] to [14.ps.+00.dpx]
(filetimes: 1970\01\01 06:00:00 to 1969\12\31 19:00:00).

- imdisplay.exe display a messagebox "parameter is incorrect" for the files [15.ps.+01.dpx] to [27.ps.+13.dpx]
(filetimes: 1969\12\31 18:00:00 to 1970\01\01 06:00:00).

since we are in the same timezone EST (+05:00), you should have the same comportement, is it the case ?

[magick]

It looks like ImageMagick can read the DPX images with the bad timestamps. Its only imdisplay that has a problem with them. imdisplay is a contributed program which we do not support. The user community is welcome to try to fix imdisplay to handle images with bad timestamps and post any patches here. We'll get them into the next release of ImageMagick.