#338 UFRaw0.18 crashes with large raws + 16 Bit Output
UFRaw 0.18 with GIMP 2.6.12, Windows XP SP 3.
When I start the 16 Bit- TIFF- conversion of a directly before loaded CR2-file from my Canon 5D MkII, which has very large raw-files (5634 x 3753 pixel), UFRaw begins Interpolating, stops it at 98 percent or so and then crashes with the message "ufraw.exe has encountered a problem and needs to be closed" etc. or so. Then I saw, that UFRaw has created a TIFF-file with only 1 KB, but no ID-file (“Create ID-file”- option was set to “also”). This 1 KB- TIFF-file cannot be opened by any Image viewing- or Image manipulationg program. When “Create ID-file”- option is set to “only”, UFRaw creates an ID-file. When I then load this ID-file into UFRaw-batch, the result is the same as described above (crash, error-message, undecodable 1 KB- TIFF- file).
With JPG- or 8 Bit- TIFF- output, UFRaw works normal.
I made several attempts with cropping the raw-image at its left side by using the crop-and-rotate-tab, then started the 16 Bit-TIFF- conversion and saw, what happens.
Results:
1.) Image cropped at its left side so that image dimensions are now 5049 x 3753 pixel: UFRaw begins Interpolating, stops at 99 percent or so, then UFRaw disappears from the desktop without any message. UFRaw has created a TIFF-file with only 1 KB, but no ID-file (like described above).
2.) Image cropped at its left side so that image dimensions are now 4999 (or smaller) x 3753 pixel: UFRaw works normal.
In all these results, it makes no difference, which interpolation algorithm is chosen.
Best regards
Udo Appel
(My last posting was at 30 Oct. 2009, sorry for providing no contribution since that time)
Please test with UFRaw 0.19.1 found at http://ufraw.sourceforge.net/ufraw-0.19.1-setup.exe and report back.
Regards,
Niels Kristian
I can confirm the crash with UFRaw 0.19.1 (32-bit installer) on Windows 7 (64-bit), but UFRaw works as expected on both 32-bit and 64-bit Linux.
Regards,
Niels Kristian
New attempt with UFRaw 0.19.1 on Windows XP SP3: Same crash, identical behaviour as reported initially.
Best regards,
Udo Appel
It was actually a stack overflow. It seems that the win32 stack is too small. This is now fixed in CVS.
Udi