BUG!? border + trim = 2 line remaining only at top

[kkoeberlein]

Hi,

I'm using imagemagick very often for all kinds of converting and modifiing images and I'm very glad to have this wonderful software!!
Now I have a picture which I wanna trim and I don't know where is my bug or if IM has a bug!?
Don't wonder - normally the pictures have additional white areas which should be trimmed. But this example is problematic...

1)

Code: Select all

convert B156074.png +matte -bordercolor white -border 8x8 B156074_border.gif

2)

Code: Select all

convert B156074_border.gif -bordercolor white -trim +repage B156074_result.gif

After that two conversions the resulting picture should be (in this case) the same like the original. Why are three borders trimmed correct and only top border isn't?

Here the link to a sample page with the above pictures: http://www.thieme-chemistry.com/fileadm ... -test.html

Any comment to this bug is welcome!

Klaus

[fmw42]

I get your same results on IM 6.6.1-6 Q16 Mac OSX Tiger. I don't know why this is happening, but you can fix it by using -fuzz

convert B156074_border.gif -fuzz 1% -trim +repage B156074_result2.gif

[anthony]

I do.

Look closely at the trimmed file....

Code: Select all

  convert B156074_border.gif -trim +repage -crop 0x3+0+0 txt:

this shows three off-white pixels in the two lines that was not trimmed.
pixels 62,0 62,1 63,1
the first is the pixel that stopped the trim.

Why are these pixels present? because you converted a very colorful PNG image
to a GIF image and as a result it was color reduced (quantized) and dithered.
That produces 'dither noise' or 'dither speckle' as it tries to correct the accumulated color 'errors' as part of the dither process.. See
How an E-Dither Works
http://www.imagemagick.org/Usage/quantize/#dither_how
E-Dither Pixel Speckling
http://www.imagemagick.org/Usage/quanti ... er_speckle

The solution. DO NOT use a limited image file format like GIF, or JPEG except as the last step in any image processing.

[fmw42]

thanks Anthony. I missed that and should have know. I did not look closely enough to see his input was PNG and output was GIF.

Good Reminder!

[Drarakel]

I wouldn't recommend GIF as intermediate format either...
But: Does it really has to be color reduced here? The starting file already has less than 256 colors (palette).

I can make this:
convert B156074.png -bordercolor white -border 8 PNG8:B156074_b.png
convert B156074_b.png -trim +repage B156074_t.gif
The final image is identical to the input and the 248 colors are retained.

With GIF instead of the max. 256 colors PNG as intermediate:
convert B156074.png -bordercolor white -border 8 B156074_b.gif
convert B156074_b.gif -trim +repage B156074_t2.gif
Now the colors are reduced to 246 (and due to the changes the trim doesn't work that way).
Strange..?

[anthony]

I report GIF color reduction failures, whenever I see them. In the latest SVN beta I am using (IM v6.6.1-6) there are no GIF color reduction failures.

The test (shell script) is part of IM Usage examples, and is as follows...

Code: Select all

  [ `convert -size 1x256 gradient: gif:- |\
       identify -format %k - ` -eq 256 ] || echo >&2 \
    "ASSERTION FAILURE: GIF did not save a 256 color gradient"

  [ `convert -size 1x256 gradient: -transparent Gray30 gif:- |\
       identify -format %k - ` -eq 256 ] || echo >&2 \
    "ASSERTION FAILURE: GIF did not save a 256 color gradient (with trans)"

The first tries to save (pipeline) a GIF image with exactly 256 greyscale colors
The second is the same but replaces one of those greyscale colors with transparency.

Typically whe the above fails, the first will secede and the second will fail (color reduced to around 64 colors.) They are currently working - producing no error output.

Normal (non-palette) PNG images however has no color restrictions, so I am not suprised their are too many colors in the GIF version. This is even worse for JPEG whcih generates extra colors due to its lossy compression technique

[Drarakel]

All of the above-mentioned PNGs are written as palette!

Perhaps that makes my 'problem' clearer:

convert B156074.png PNG:- | identify -format %k -
248
convert B156074.png GIF:- | identify -format %k -
248
convert B156074.png -bordercolor white -border 8 PNG:- | identify -format %k -
248
convert B156074.png -bordercolor white -border 8 GIF:- | identify -format %k -
246

Thanks for the info about that GIF color reduction test.
Here (IM v.6.6.1-5 Q16, Windows XP), the first test is successful. But the second test gives me only 65 colors.

[Drarakel]

After updating ImageMagick, I now get 256 colors for the second GIF test, too. So that works.
But I'm still getting reduced colors for the 'B156074' GIF. I'll have to do some more tests for that...

[kkoeberlein]

After updating ImageMagick, I now get ...

Updating to what version?

[Drarakel]

I think Anthony's GIF test is successful with version 6.6.1-6 (or newer). But this won't change the result of your commands. I believe there is a problem with the GIF format. In the meantime you could use e.g. PNG8 (if you have pictures with max. 256 colors) and convert to GIF only as a last step.

[anthony]

PNG8 Image file format and GIF are handled and treated in exactly the same way!!!!

Both have a 256 color limit and both have boolean transparency.

It is normal non-palette PNG that does not have these color restrictions.

[Drarakel]

PNG8 Image file format and GIF are handled and treated in exactly the same way!!!!

Not in the above examples.

[anthony]

PNG8 Image file format and GIF are handled and treated in exactly the same way!!!!

Not in the above examples.

The above examples use PNG and not PNG8!
This is also just the way IM outputs PNG8, reading is handles fine regardless.

[Drarakel]

I don't want to start an argument here , but the only exception in this thread where the files would be stored as 'normal' PNG (3x8bit) is my last test:

convert B156074.png PNG:- | identify -format %k -
248
convert B156074.png GIF:- | identify -format %k -
248
convert B156074.png -bordercolor white -border 8 PNG:- | identify -format %k -
248
convert B156074.png -bordercolor white -border 8 GIF:- | identify -format %k -
246

But I could replace 'PNG:' with 'PNG8:' and for the colors it wouldn't make a difference. Only the PNG/PNG8 output stores the correct colors here, not GIF.

@kkoeberlein:
Instead of your first command, you could use this:
convert B156074.png +matte -bordercolor white -border 8x8 +dither -colors 256 B156074_border.gif
For this example, it works (no change in colors and the 'trim' afterwards wil be successful). But the better solution of course is not to use GIF as intermediate - as the others said.