IM Core Enhancements

[tc33]

Hi,

Here are a few proposed tweaks to IM core based on my own internal modifications:

- CORE_png / pngvalid.c: interferes with the running of Boost test since it defines an int main(). Recommend removing 'pngvalid.c' from the default build. OpenCV has already removed the file from their build. Reference: http://stackoverflow.com/q/12165121/882436

- CORE_zlib / deflate.c: modify TOO_FAR macro based on logic in accordance with this: http://optipng.sourceforge.net/pngtech/too_far.html Since IM is an image library rather than a text library, the modification is a no-brainer IMO.

- CORE_magick / threshold.c, OrderedPosterizeImageChannel
The logic within this function requires an external XML file, which results in lower performance, conflicts with my static build and complicates my deployment. Recommend hard-coding the default threshold maps, while still allowing the use of the external XML file for custom-defined threshold maps. Here is the code I'm using starting at line 1459:

Code: Select all

//map = GetThresholdMap(token, exception);

	// TC
	//	hard code threshold map so we don't have to parse xml
	map = (ThresholdMap *)AcquireMagickMemory(sizeof(ThresholdMap));
	  if ( map == (ThresholdMap *)NULL )
		ThrowFatalException(ResourceLimitFatalError,"UnableToAcquireThresholdMap");
	  map->map_id = ConstantString("threshold");
	  map->description = ConstantString("");
	  map->width = 1;
	  map->height = 1;
	  map->divisor = 2;
	  map->levels=(ssize_t *) AcquireQuantumMemory((size_t) map->width,map->height * sizeof(*map->levels));
	  if ( map->levels == (ssize_t *)NULL )
		ThrowFatalException(ResourceLimitFatalError,"UnableToAcquireThresholdMap");
	  map->levels[0] = 1;
	// end tc

    if ( map == (ThresholdMap *)NULL ) {
      (void) ThrowMagickException(exception,GetMagickModule(),OptionError,
        "InvalidArgument","%s : '%s'","ordered-dither",threshold_map);
      return(MagickFalse);

I'd imagine a simple "if token == hard_coded_map_1 then [x] else if token==hard_coded_map_2 then.....else parse_xml_file()" type operation would be appropriate. If you want to pursue this idea further and want me to submit some code, I'd be happy to do so.

Thanks in advance!

[magick]

We'll get your patches into the ImageMagick distribution within a few days. Thanks.

Regarding OrderedPosterizeImageChannel(), we can define one or two threshold maps in memory, the ones what might be used most often. Do you have a partricular map that you use often?

[tc33]

Regarding OrderedPosterizeImageChannel(), we can define one or two threshold maps in memory, the ones what might be used most often. Do you have a partricular map that you use often?

Yes, I'm exclusively using the 1x1 threshold map. The code equivalent is above, here is the relevant xml fragment from thresholds.xml:

Code: Select all

<threshold alias="1x1" map="threshold"> <description>Threshold 1x1 (non-dither)</description> <levels divisor="2" height="1" width="1"> 1 </levels> </threshold>

Thank you!

[glennrp]

To change TOO_FAR we'd need to bundle zlib with ImageMagick and not use the zlib that's on the host. I'm not sure that's adviseable.

How did pngvalid.c get into the core? It's in the "contrib/libtests" subdirectory of libpng.

[magick]

Glenn, this is the Window distribution which include Zlib and PNG. We've corrected these problems in the latest Beta release.

[glennrp]

Glenn, this is the Window distribution which include Zlib and PNG. We've corrected these problems in the latest Beta release.

In that case we should #undef PNG_PROGRESSIVE_READ_SUPPORTED in png/pnglibconf.h (simply change #define to #undef). We don't use that, and the #undef will remove
a significant amount of code.

[magick]

Done. Thanks.

[glennrp]

Done. Thanks.

There are other things that can be defined out to save a little more filesize, but those are just a drop in the bucket, considering the whole static exe is around 40Mb. If you are interested I can recommend a few more undefs.

[magick]

Ok, but keep in mind that you can make the changes yourself directly in the Subversion trunk.