#614 ping(blob) reports JPG and JNX files as monochrome BilevelType

[xm]

read(blob) works fine at the same place, relevant code-part tested:

Magick::Blob blob(pRawImgBuf, dwRawImgBufSize);
Magick::Image image;
image.magick(szFileExtA);

image.ping(blob); // problems with ImageType later!
//image.read(blob); // works fine

if ((0 == image.columns()) || (0 == image.rows()))
return 0; // error

switch (image.type())
{
case MagickLib::BilevelType:
// JPG and JNX files go in here with ping()!

[Bob Friesenhahn]

What does command-line

gm identify file.jpg

report for your file? Does the report differ from what

gm identify +ping file.jpg

reports?

In theory, the default ping mode is supposed to try not to read image
data or do other expensive processing. There was a release or two
where the JPEG reader was not fully parsing the JPEG header. The
current release should be fully parsing the JPEG header.

The ImageInfo structure has a 'ping' option (not exposed in Magick++
as far as I can see) which requests that the reader proceed and do a
full read of the image in order to assure a correct result.

Lastly, the report is actually for the way the image is stored after
it has been read. If a JPEG file was truely back/white it could be
reported as Bilevel, even though the JPEG format does not support
Bilevel.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[xm]

gm identify anteater.jpg
anteater.jpg JPEG 373x500+0+0 DirectClass 8-bit 37.5Ki 0.000u 0m:0.000009s

gm identify +ping anteater.jpg
anteater.jpg JPEG 373x500+0+0 DirectClass 8-bit 37.5Ki 0.000u 0m:0.009481s

[Bob Friesenhahn]

Now that I look at the related code in Magick++/lib/Options.cpp I see that it does this:

Magick::ImageType Magick::Options::type ( void ) const
{
return _imageInfo->type;
}

The ImageInfo structure is used for input options rather than for output.

The related code in Magick++/lib/Image.cpp forwards the request like:

// Image representation type
Magick::ImageType Magick::Image::type ( void ) const
{

ExceptionInfo exceptionInfo;
GetExceptionInfo( &exceptionInfo );
ImageType image_type = constOptions()->type();
if ( image_type == UndefinedType )
image_type= GetImageType(constImage(), &exceptionInfo);
throwImageException( exceptionInfo );
return image_type;
}

The core library function which returns the desired value is GetImageType() in magick/analyze.c. We can see that this function
is called if the value returned by constOptions()->type() is UndefinedType. I assume that it is not returning UndefinedType.

The default value for ImageInfo->type is UndefinedType (0). What I am wondering is why the value is apparently not
UndefinedType in your program?

Bob

[xm]

So I tried again (now using your convert.c simple example with some modifications), but with the same result (imagetype_ping will become BilevelType and imagetype_read TrueColorType), relevant code:

 MagickLib::Image* image_ping = MagickLib::PingImage(imageInfo, &exception);
if (!image_ping)
{
    CatchException(&exception);
    exit_status = 1;
    goto program_exit;
}
MagickLib::ImageType imagetype_ping = MagickLib::GetImageType(image_ping, &exception);

MagickLib::Image* image_read = MagickLib::ReadImage(imageInfo, &exception);
if (!image_read)
{
    CatchException(&exception);
    exit_status = 1;
    goto program_exit;
}
MagickLib::ImageType imagetype_read = MagickLib::GetImageType(image_read, &exception);

[Bob Friesenhahn]

I see that the GetImageType() implementation is based on GetImageCharacteristics() and if that function does not have an actual read image to rummage through, it only has the boolean properties: colorspace, is_grayscale, is_monochrome, matte, storage_class to use as input. Out of these, I expect that storage_class should be reliably set by 'ping', and the others may or may not get set.

It may be that JPEG (and JNX which is based on JPEG) may be implemented differently than most.

[Bob Friesenhahn]

This issue is solved by Mercurial changeset 17905:6e5569db2deb. Thank you for your extreme patience!