Scum dot in grayscale -> bitmap conversion

[CardConnection]

We have developed a web interface which allows users to upload files for use on business cards. Once uploaded, Imagemagick converts the image to a grayscale and then to a bitmap (depth 1). For some reason, we are picking up a scum dot (small dots) in areas which were pure white originally. Our arguments are:

-contrast-stretch 15% -trim -colorspace Gray -ordered-dither 6x6a -depth 1

To see for yourself what I'm talking about go to http://www.raisedconnection.com, click RAISED PRINT BUS CARD 001 and click "Upload a Custom Graphic". If you select an image which clearly has white areas in it you will see that after the conversion the areas have dots in them.

Does anybody have any suggestions on how to avoid this from happening?

[fmw42]

That is to be expected when you apply a dither and you don't have perfectly white areas (which will be especially the case with jpg imagery). see http://www.imagemagick.org/Usage/quantize/#threshold

Also your command is wrong or a typo. You have -ordered-dither 6x6a, but there is no such dither pattern. Do you mean h6x6a?

If you want to remove random black spots.

logo3.png


convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 logo3_tmp.png



A simple way to remove some isolated noise at the expense of some change in the image is using median filtering.

convert logo3_tmp.png -median 1 logo3_tmp_med1.png

[CardConnection]

You are correct, there was a typo in my post. The arguments we are using are indeed:
-contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1.
I have done a little more r&d since my initial post and am now more confused than ever.

First of all, our upload script doesn't support png files like the one you used in your examples. Nonetheless, I thought I would start off by doing the same conversion manually (png to png) from your original just to confirm that we are getting the same results. Sure enough, we are.

The next thing I did was to resave your original png in a format that our upload script does support, tif. I then manually converted that file to our required output format, tif and got the same exact results we get when uploaded through our web interface. This conversion is dramatically different than the first conversion from the png file to a png file. The scum dots that my original post described were much more dramatic than your example.

Ah ha I thought, the input file type has something to do with the output. The final test I did however, set my head spinning. This time I took your original png and converted it to a tiff. To my surprise I wound up with a completely different image from the previous 2 conversions. Apparently, not only does the input file type make a difference but so does the destination file type.

My question is, if we have to support half a dozen or so possible input file types (none of which are png) and always generate a tiff, is there any controlled way to process them?

[fmw42]

tif is NOT a good format to use as it has too many variants and parameters. See http://www.imagemagick.org/Usage/formats/#tiff.


When I do:

convert logo3.png logo3.tif

The two images are identical. IM 6.5.1-1 beta.

But if I do:

convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 logo3_png_tmp.tif

convert logo3.tif -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 logo3_tif_tmp.tif

These two images are identical and the negative of the original:

convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 logo3_tmp.png

So if I add -negate, I get:
convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 logo3_tmp.png
convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 -negate logo3_png_tmp.tif
convert logo3.tif -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -depth 1 -negate logo3_tif_tmp.tif

And all 3 output images are identical.

I am not sure why I get the negative when processing to tif. But there is a tif parameter,
toggle the photometric interpretation
-define quantum:polarity=min-is-black
-define quantum:polarity=min-is-white

That may be involved. However, I could not get it to work right. Not sure when it may be needed to be placed in the command line if it is relevant.

What version of IM are you using? Is it old? What version of libtif and have you compiled jpeg support in it? See http://www.imagemagick.org/Usage/formats/#tiff

If you have an option, I would switch to PNG as a common format (or perhaps one of the NetPBM formats). Why did you pick tif as it is not a commonly displayable format on the web. PNG is a better standard and web supported mostly.


Try this. It seems to work without the -negate. I replace -depth 1 with -monochrome

convert logo3.png -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -monochrome logo3_png_tmp.tif
convert logo3.tif -contrast-stretch 15% -trim -colorspace Gray -ordered-dither h6x6a -monochrome logo3_tif_tmp.tif

However, once you get to 1bit images, you might as well save as GIF and not TIF.

[CardConnection]

Wow, thanks for all the great info. To answer a few of your questions.

1) We are using vs 6.4.3-Q16. Not sure about libtif and we haven't done anything other than the standard install so I doubt we've compiled jpeg support.

2) As far as input files, because this is only a small part of a larger system, we are limited to those file types supported by the upload routine previously in place AND png is not one of them. The supported types include JPEG, GIF, TIFF, EPS and PDF. Furthermore, we don't want to limit our customers by saying they can only upload one file type so we're trying to support the above mentioned.

3) As far as output file, again we are limited to the processing script which immediately proceed the imagemagick execution which ONLY ACCEPTS bitmaped tifs.

Given these parameters what set of arguments do you think will give us the best results?

[CardConnection]

I just tried replacing -depth 1 with -monochrome and that seems to do the trick. Much to my surprise, our system can even accept uploaded png files. From my testing it looks like customers can now upload: PNG, JPG, GIF, TIF, EPS or PDF. See for yourself at www.raisedconnection.com, click on RAISED PRINT BUS CARD 001 then click "Upload A Custom Graphic".

Thanks!

[CardConnection]

More info on tiffs. Both .tif and .tiff file extensions work however, Photoshop tifs with layers produce an error. Apparently, Photoshop tifs need to be flattened.

[fmw42]

More info on tiffs. Both .tif and .tiff file extensions work however, Photoshop tifs with layers produce an error. Apparently, Photoshop tifs need to be flattened.

Yes, that is in the notes at http://www.imagemagick.org/Usage/formats/#tiff

Also P.S. tifs may have jpg compression, so that may also compound your problem. But glad to see the -monochrome solved it. Perhaps you should inquire at the Bugs forum why you get the negative when using -depth 1. Also see viewtopic.php?f=3&t=13468 which may somehow be connected to your problem

[CardConnection]

I just tested tif with LZW, Zip and JPEG compression and they all worked fine. Perhaps our pre-processing of the uploaded image is stripping away the compression?