Using Windows XP SP3, GM 1.3.18-Q16 (Same behavior noted in 1.3.13, upgraded and problem persisted.)
JPEG files produced by my Nikon D3100 are handled correctly by mogrify. JPEG files produced by batch converting NEF (Nikon raw) files produced by the same camera, using IrfanView, cause mogrify to crash, even with simple options like -rotate.
Attached file 1188_FS_0182.jpg (converted from NEF by IrfanView) causes crash, file 1188_FS_0183.jpg (generated directly by camera) does not.
I cannot reproduce the problem with either 1.3.12 or 1.4-snapshot-20131008, running on Ubuntu 12.04
I am not able to cause a problem with just the file either (tested under Windows 7 and Linux with valgrind). Please provide the exact mogrify command that you used so we can try to reproduce the problem.
I retested this morning, using the following commands:
gm mogrify -rotate 180 <filename>
gm mogrify -geometry x2000 <filename>
on several files created using IrfanView to convert NEF to JPEG. This behavior does not occur with files converted using graphicsmagick, which allowed me to solve my immediate problem. I have submitted crash reports using Windows error reporting, but I am unable to select the data submitted to send directly to you, other than the following:</filename></filename>
AppName: gm.exe AppVer: 14.11.0.0 ModName: core_rl_magick_.dll
ModVer: 14.11.0.0 Offset: 00005b97
I tried again using your exact commands but could not reproduce the problem.
What JPEG library are you using?
"ldd gm | grep jpeg" tells me I'm using
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8
GM appears to be using the jpeg library bundled with the Windows installer: CORE_RL_jpeg_.dll, version 6.2.0.0 (Checked using Process Explorer.)
The Windows jpeg library version is mis-identified due to my failure to update jpeg.rc. The version of libjpeg in the 1.3.18 is IJG 8d from 2012 rather than 6b from 1998. There is an IJG 9 release which has not yet been incorporated in the Windows build. Guido Vollbeding said he is working on a release 10 which will support 8, 10, 12, and 16 bit JPEG in a single library build (we shall see).
Ubtuntu Linux may appear to be using IJG 8 but in fact it is usually using Turbo JPEG which is a version of 6b which is heavily hacked to use SIMD code (e.g. SSE2) for more performance.
I am unable to reproduce this issue.