Format hint in image_info->magick doesn't work when loading from file

[kleisauke]

ImageMagick version

7.1.1-6

Operating system

Linux

Operating system, version and so on

Fedora 37

Description

Hinting the format in image_info->magick doesn't work when loading from a file. For example, when loading a NEF image and initializing image_info->magick to "NEF" the image appears to load via the TIFF loader (see reproducer below).

Reverting commit 6f7cebf seems to fix this.

--- a/MagickCore/image.c
+++ b/MagickCore/image.c
@@ -2855,8 +2855,7 @@ MagickExport MagickBooleanType SetImageInfo(ImageInfo *image_info,
         }
     }
   *component='\0';
-  if (*image_info->magick == '\0')
-    GetPathComponent(image_info->filename,ExtensionPath,component);
+  GetPathComponent(image_info->filename,ExtensionPath,component);
   if (*component != '\0')
     {
       /*

(This corresponds to commit ImageMagick/ImageMagick6@2cf7bfe in ImageMagick 6.x)

Steps to Reproduce

/* Compile with:
 * gcc -g -Wall test-nef.c `pkg-config MagickCore --cflags --libs` -o test-nef
 *
 * Run with:
 * ./test-nef _DSC4175.NEF
 *
 * Expected output: 4284x2844
 * Actual output: 160x120
 */
#include <stdio.h>
#include <assert.h>

#include <MagickCore/MagickCore.h>

int
main(int argc, char **argv)
{
	ExceptionInfo
		*exception;

	Image
		*image;

	ImageInfo
		*image_info;

	if (argc != 2) {
		printf("Usage: %s image\n", argv[0]);
		return 1;
	}

	MagickCoreGenesis(*argv, MagickTrue);
	image_info = AcquireImageInfo();
	(void) CopyMagickString(image_info->filename, argv[1], MaxTextExtent);
	(void) CopyMagickString(image_info->magick, "NEF", MaxTextExtent);
	exception = AcquireExceptionInfo();
	image = ReadImage(image_info, exception);

	assert(image);
	printf("%ldx%ld\n", image->columns, image->rows);

	image = DestroyImage(image);
	exception = DestroyExceptionInfo(exception);
	image_info = DestroyImageInfo(image_info);
	MagickCoreTerminus();

	return 0;
}

Images

_DSC4175.zip

[kleisauke]

Thanks! I'm not sure if this is on purpose, but I noticed that image_info->filename has a higher priority than image_info->magick, i.e. on the above reproducer:

$ cp _DSC4175.NEF x.tiff
$ ./test-nef x.tiff
160x120
$ ./test-nef _DSC4175.NEF
4284x2844

I would expect both commands to return 4284x2844.

[kleisauke]

Ah, it looks like image_info->magick is still being ignored somehow.

$ cp _DSC4175.NEF x
$ ./test-nef x
160x120

[urban-warrior]

The type of an image can be implied by its file extension, such as NEF in this case. However, the internal "magic" numbers of the image can override this implicit format. In the case where an image has a TIFF signature, it will be read by the TIFF coder instead. If you want to explicitly set the image type, you can do so by prefixing the image filename. This explicit file type will take precedence over any magic number or implicit file extension.

It's possible that your unit test used to work in the past, but we likely discovered and fixed a bug that caused a side effect, leading to your unit test failure. To achieve the desired outcome, it's best to use an explicit filename.

$ ./test-nef nef:_DSC4175.NEF
4284x2844

[kleisauke]

I see, but NEF images are registered as ExplicitFormatType.

ImageMagick/coders/dng.c

Line 805 in e590343

entry->format_type=ExplicitFormatType;

So, I would assume that setting image_info->magick to "NEF" would not determine the image format from the first few bytes of the file, thus preventing it from being loaded by the TIFF coder.

How about this patch?:

--- a/magick/image.c
+++ b/magick/image.c
@@ -2914,6 +2914,9 @@ MagickExport MagickBooleanType SetImageInfo(ImageInfo *image_info,
     {
       (void) CopyMagickString(magic,image_info->magick,MaxTextExtent);
       magick_info=GetMagickInfo(magic,sans_exception);
+      if ((magick_info != (const MagickInfo *) NULL) &&
+          (magick_info->format_type == ExplicitFormatType))
+          image_info->affirm=MagickTrue;
       if (frames == 0)
         GetPathComponent(image_info->filename,CanonicalPath,filename);
       else

This would fix all the test cases mentioned earlier.

[urban-warrior]

We'll apply the patch. We'll need to run all our units tests (multi-thousands) before we can release the patch. If we run into any issues, we'll let you know.

[kleisauke]

Thanks! I'll close, feel free to re-open if this causes any issues.

For reference, this fix was released in version 7.1.1-7 and 6.9.12-85.