Legacy ImageMagick Discussions Archive

Hello Anthony,

You have helped me greatly in the past, hence I am returning to you with a pressing question:

I am running the following command on an image circle:

exec('convert -strip -density 300x300 -units PixelsPerInch ' .
"../..".$_GET['dir'] . ' -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -fill "#FFFFFF" -opaque none ' .
"../..".$_GET['dir']);

This all works great but what we are noticing is that in some applications (such as our wasatch printing software), the circle image renders with part of the edges of the circle being clipped. When we take this png image and save as jpg, then the image shows perfect. The image also show perfect in the photoshop but it is as if some application have hard time rendering transparent image and as if the size of the transparency is smaller than the image itself, hence it cuts it off. Can you please shed some light on this? Is anything of the command above can cause this. Here is the resulting image that has this issue:
http://209.20.87.13/10490peek.png

Your help on this is greatly appreciated in advance.

With Regards,

Robert

I don't know if this is relevant or not, but perhaps your png image has a virtual canvas and so it needs to be removed using +repage. See if that helps?

Hmmm.... I tried but it did not seem to help. Is there any way to check the info of the png file to see what virtual canvas if any there is? Also, perhaps the info of the file would reveal the possible culprit here the same as you can run info and grep the histogram to see the transparency information.

rs13 wrote:Hmmm.... I tried but it did not seem to help. Is there any way to check the info of the png file to see what virtual canvas if any there is? Also, perhaps the info of the file would reveal the possible culprit here the same as you can run info and grep the histogram to see the transparency information.

identify -verbose filename

I am lost. Here is the output of the info after running that identify command. Can you please review:
###

• Image: 10490peek.png
  Format: PNG (Portable Network Graphics)
  Class: DirectClass
  Geometry: 720x720+0+0
  Resolution: 118.11x118.11
  Print size: 6.09601x6.09601
  Units: PixelsPerCentimeter
  Type: TrueColorMatte
  Endianess: Undefined
  Colorspace: RGB
  Depth: 8-bit
  Channel depth:
  red: 8-bit
  green: 8-bit
  blue: 8-bit
  alpha: 8-bit
  Channel statistics:
  red:
  min: 0 (0)
  max: 255 (1)
  mean: 245.452 (0.962556)
  standard deviation: 22.8028 (0.0894227)
  kurtosis: 0.229865 (0.00090143)
  skewness: -0.0286181 (-0.000112228)
  green:
  min: 0 (0)
  max: 255 (1)
  mean: 233.321 (0.914985)
  standard deviation: 28.6286 (0.112269)
  kurtosis: 0.114146 (0.000447633)
  skewness: -0.019083 (-7.48355e-05)
  blue:
  min: 0 (0)
  max: 255 (1)
  mean: 232.054 (0.910016)
  standard deviation: 26.362 (0.103381)
  kurtosis: 0.111367 (0.000436732)
  skewness: -0.0177303 (-6.95305e-05)
  alpha:
  min: 0 (0)
  max: 255 (1)
  mean: 200.525 (0.786374)
  standard deviation: 103.36 (0.405335)
  kurtosis: -2.23774e-05 (-8.77544e-08)
  skewness: 0.00547077 (2.1454e-05)
  Alpha: rgba(255,255,255,0) #FFFFFF00
  Rendering intent: Undefined
  Interlace: None
  Background color: rgba(1,1,1,1)
  Border color: rgba(223,223,223,1)
  Matte color: grey74
  Transparent color: none
  Page geometry: 720x720+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Zip
  Orientation: Undefined
  Properties:
  create-date: 2009-06-23T15:43:47+00:00
  modify-date: 2009-06-22T22:55:01+00:00
  signature: 6996dea3c0621f418fbf250cebf520540530b13bc4707821e1e41c04c783b2ee
  Artifacts:
  verbose: true
  Tainted: False
  Filesize: 278kb
  Number pixels: 506kb
  Version: ImageMagick 6.4.8-5 2009-01-15 Q16 OpenMP http://www.imagemagick.org

Basically it says you have a png image of size 720x720 (no other virtual canvas of different size see page geometry for virtual canvas) which is 8-bit rgba of type truecolormatte (the matte means alpha channel) and is zip compressed (I think). The image has density/resolution of 118.11 pixels per centimeter. Each of the rgba channels varies from full black (0) to full white (255).

I guess I don't really understand your processing steps --- what are you trying to accomplish?

-alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -fill "#FFFFFF" -opaque none

you turn alpha off, then convert near white to full white, then turn alpha on, then turn white to transparent. seems like you may have some kind of conflict between the original alpha channel and alpha channel you seem to be trying to make by turning white to transparent (color=none). Note that -fill "#ffffff" -opaque none is the same as -transparent "#ffffff". What bothers me is that you turn alpha off, then on, then try to make white into transparent. If you want to remove the original alpha channel and then turn white to transparent, you should perhaps not turn back on the original transparency. Also you are making near white into white (which you presumably have also) and then both to transparent. But you can do that with -fuzz and get all near white values turned to transparent, not just #fffffe and #ffffff (although nothing wrong with doing that, if that is all you want to be transparent)

-alpha off -fuzz XX% -transparent white

Again, I am not sure of your objective here?

I see, but does that shed some light as to why certain application clip the sides of the image. If I take that image and save as jpg, it renders correctly. Does it have to do with the background and transparent color setting whereby under these conditions certain application with transparency rendering problem cut off the edge of the image itself. This sample image is at https://209.20.87.13/10490peek.png. The round circle gets cut off by 3-5px on each side.

I also do not understand what you are attempting to do.

It may be their are better ways to do what you are wanting!

PNG -alpha off should produce the same result at JPEG which (generally) has no alpha channel). WARNING; The JPEG is a lossy format. colors are generally not exact, so the exact color changes you are performing will probably do not work as you would expect with JPEG.

However just turning alpha off then turning it on again does not clear the alpha channel!!!! It preserves it (just flips a switch, that is all). That is turning alpha off simply removes the alpha channel from normal image processing, and even from being copied (no all operations copy the image). The data in the alpha will remain as is and unchanged until it is turned, on and/or cleared. Of course saving with alpha off will not save the alpha channel data either.

If you want to turn the alpha on, and make it opaque, use -alpha set or -alpha opaque.
'set' turns it on AND makes it opaque, BUT ONLY if alpha was 'off' .
'opaque' however will do that regardless of its former state.

Final point -strip is a operator (remove all meta-data from image), it should be applied AFTER reading the image.

your alpha channel is not binary b/w but has gray values near the edge of the circle to antialias the image against the background. So if some application or your processing converts the alpha channel to binary (or you turn it off and recreate the alpha by your processing), then you may lose those gray values as they may be converted to black rather than white. Other applications or your conversion to jpg may convert the gray values to white and so you won't lose parts of the circle, but it will be stairstepped and have no antialiasing.


Perhaps if you explained what your goal/objective is with all the white and transparency processing, one might be able to provide further insight and perhaps some simpler solution to your processing.

Thank you guys both for trying to help me. Basically we collect the image from the user from the website. Usually these final images are circles. We then take those circles and print them on the tin containers using proprietary software called Wasatch. This Wasatch software talks to our printer which prints on rounded tin containers.

We determined that we need a final image in png format as we want to have transparency and know at all time what the user made transparent and what they did not. We also render that image to the user in preview and we want to preview user image with transparency.

Because Wasatch software has lots of strange behaviors rendering png and transparency similar to the old days of IE 5+, we do:

exec('convert -strip -density 300x300 -units PixelsPerInch ' .
"../..".$_GET['dir'] . ' -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -fill "#FFFFFF" -opaque none ' . "../..".$_GET['dir']);

We got help from Anthony in January helping us to convert every #FFFFFF pixel to #FFFFFE. This is needed as our printer ignores pure white and prints nothing (Anthony helped us by suggesting that in order to convert all white, we turn alpha off and then back on again -- this worked and works today). Hence switching it to #FFFFFE allows us to trick the printer to print white while the user does not notice such subtle color difference.

Secondly, because Wasatch has the same issue as the old IE 5+, whereby it renders transparency as black and prints black, we believe the above command also takes care of this problem as after running each image through the above command Wasatch shows transparency as transparency instead of black.

Now to our problem:

We thought the above solves our issues but we very recently noticed that when we have circle images (these could be photos or anything else) and they bleed to the edge, the Wasatch software renders it by clipping 3 to 5px off of each side of the circle. We do not know what causes this but we believe it has to do something with Wasatch's ill rendering of transparency/png. What we are looking for is to make sure that the circle does show up the same way as it shows up when viewed in Firefox for example (http://http://209.20.87.13/10490peek.png) with anti-aliasing if possible. This is our final image ready to print that was created using the above 'convert' command. It looks fine in Firefox but as soon as we load it into the Wasatch software its sides are clipped. Any help on this is greatly appreciated.

I might just also add that as soon as we take 10490peek.png and save it as png without transparency in photoshop, Wasatch renders the image correctly without clipping its sides.

exec('convert -strip -density 300x300 -units PixelsPerInch ' .
"../..".$_GET['dir'] . ' -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -fill "#FFFFFF" -opaque none ' . "../..".$_GET['dir']);

OK, so you want to change pure white #ffffff to near white #fffffe. That is fine. You turn off transparency and change the color. Fine. Then turn on the original transparency. Fine. But why the -fill #ffffff -opaque none?

First, this will have no effect as you have no pure white any longer. Second, you are trying to make white into transparent and you already have the transparency from the original image. So I may be wrong about this, but I don't know which one will "win" -- your old transparent layer or the new one you are trying to make, which should not contain anything.

What happens if you remove the -fill "#FFFFFF" -opaque none from your command line?



Next, your image has a white background, which has already been antialiased. When you turn off the transparency either as a png or turning it to jpg, then you see the underlying image with the antialiased circle and white background which will look exactly or nearly exactly the same as viewing the original png with transparency on a white background such as your browser default white background.

In my opinion, lacking further understanding of your images and their variations, your problem appears to be with your Wasatch program and how it handles grayscale transparency overlays.

Why do you need to keep the transparency layer. So why not flatten any image with transparency onto a near white background, thus making the image look antialiased as if it had transparency, but actually removing the transparent layer by the flattening process.

Assuming you always want a near white background outside the circle, then

convert image -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -background "#FFFFFE" -flatten result

You can also add your other steps to strip the profiles and change the density.

Anthony may have more information to add or further suggestions or understanding of this issue as apparently he helped you originally

Thanks, I see you point. I have adjusted the command and now run the following:

exec('convert -density 300x300 -units PixelsPerInch ' . "../..".$_GET['dir'] .
' -strip -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -background "#FFFFFF" -flatten ' .
"../..".$_GET['dir']);

However, the issue is still persisting. I uploaded the resulting file to http://209.20.87.13/rob1peek.png.
The background is now white (we need it to be as the printer ignores pure white), however, the wasatch software still chops the edges of the image (about 3-5px on each side). If I go and look at the file's info, I see:

Background color: black
Border color: rgba(223,223,223,1)
Matte color: grey74

I also see:

Units: PixelsPerCentimeter
Type: TrueColorMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 8-bit
Channel statistics:
.....
alpha:
min: 0 (0)
max: 255 (1)
mean: 200.525 (0.786374)
standard deviation: 103.36 (0.405335)
kurtosis: -2.23774e-05 (-8.77544e-08)
skewness: 0.00547077 (2.1454e-05)
Alpha: rgba(255,255,255,0) #FFFFFF00
Rendering intent: Undefined

Can any of this still causing this? Btw, the units are still pixelsPerCentimeter instead of pixelsPerInches as I specified using the command. Not sure if that could be throwing the wasatch off but just wanted to mention it.

try applying the -density and -units after reading the image. in fact, try reading the image first and then apply all the IM options

also you misread or mistyped my suggestion -- at the end it should be -background "#ffffe" etc as you want your background to be the same off-white so your printer will print it.


convert image -strip -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on -background "#FFFFFE" -density 300x300 -units pixelsperinch -flatten result

Other than this, I have no idea why your app will cut off the image?


To what image format are you saving the results (PNG)? If you flatten it you don't need a format that allows transparency. So you can also set the -type to palette to make the image smaller or convert to 8-bits per channel color via -depth 8 to make the image smaller or both. Or you can use JPG and compression to make it smaller. In any event, perhaps you app does not like PNG and some other image type would be better for it.

Your image info above --- was that for the input or output image? If that was for the output, then something is wrong as it still has the overlay enabled and -flatten should get rid of it (I thought?)

When I download your image and get its information, I see an alpha channel still on, but totally opaque (equivalent to not there):

identify -verbose rob1peek.png
Image: rob1peek.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 720x720+0+0
Resolution: 118.11x118.11
Print size: 6.09601x6.09601
Units: PixelsPerCentimeter
Type: TrueColorMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
Channel statistics:
red:
min: 233 (0.913725)
max: 255 (1)
mean: 242.202 (0.94981)
standard deviation: 9.99294 (0.039188)
kurtosis: -1.75586
skewness: 0.446375
green:
min: 131 (0.513725)
max: 255 (1)
mean: 179.293 (0.70311)
standard deviation: 58.9522 (0.231185)
kurtosis: -1.75016
skewness: 0.451797
blue:
min: 182 (0.713725)
max: 255 (1)
mean: 210.327 (0.824813)
standard deviation: 34.5296 (0.13541)
kurtosis: -1.75497
skewness: 0.447159
alpha:
min: 255 (1)
max: 255 (1)
mean: 255 (1)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0


OK. I have taken your original image and processed it and added -alpha off at the end after flatten. I am not sure why one needs to do that. Anyway, now you don't get the alpha channel. But the units are still wrong as is the Resolution/density (118 rather than your requested 300). I would suggest you submit a bug report. Unless PNG does not support density changes and units.

convert 10490peek.png -strip -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on \
-background "#FFFFFE" -density 300x300 -units pixelsperinch -flatten -alpha off \
10490peek_result2.png

identify -verbose 10490peek_result2.png
Image: 10490peek_result2.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 720x720+0+0
Resolution: 118.11x118.11
Print size: 6.09601x6.09601
Units: PixelsPerCentimeter
Type: TrueColor
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
...
Filesize: 179kb

If I do the same and make the output JPG, then all works fine:

convert 10490peek.png -strip -alpha off -fill "#FFFFFE" -opaque "#FFFFFF" -alpha on \
-background "#FFFFFE" -density 300x300 -units pixelsperinch -flatten -alpha off \
10490peek_result2.jpg

identify -verbose 10490peek_result2.jpg
Image: 10490peek_result2.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Class: DirectClass
Geometry: 720x720+0+0
Resolution: 300x300
Print size: 2.4x2.4
Units: PixelsPerInch
Type: TrueColor
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
...
Filesize: 34.4kb


If you save as JPG, then you can also use -quality to set the compression at the very end.

Thank you very much for your analysis. We will try to play around with saving as jpg as per your recommendation and see if that helps. I will let you know how it went.

Please let me know if you are going to submit a bug report. Otherwise I will do so.