Error generating GIF when size is changed

[eduardo.melgar]

Hi,

I am trying to generate to GIFS with different sizes: 50x50 and 150x150 (source file at https://drive.google.com/folderview?id= ... sp=sharing).
When I run the below command for generating the GIF files I get a correct 50x50 image, but the other image (150x150) is "corrupted" (test results also attached at link above).

Code: Select all

$ convert -quiet rgb_screen.tif -flatten -alpha transparent -clip -alpha opaque -trim +repage -resize 50x50 -profile "/opt/profiles/icc/rgb/sRGB Color Space Profile.icm" -unsharp 0.5x0.5+3.0+0.05 -dither Riemersma -units PixelsPerInch -density 72 -strip -background "rgb(254,255,255)" -flatten -transparent "rgb(254,255,255)" -transparent-color "rgb(254,255,255)" mini.gif 
$ convert -quiet rgb_screen.tif -flatten -alpha transparent -clip -alpha opaque -trim +repage -resize 150x150 -profile "/opt/profiles/icc/rgb/sRGB Color Space Profile.icm" -unsharp 0.5x0.5+3.0+0.05 -dither Riemersma -units PixelsPerInch -density 72 -strip -background "rgb(254,255,255)" -flatten -transparent "rgb(254,255,255)" -transparent-color "rgb(254,255,255)" thumb.gif

I am running Ubuntu 13.10 and ImageMagick 6.6.9-7 (2014-03-06 Q16)

If I run the same test on the last IM available version (ImageMagick 6.8.9-0 Q16 x86_64 2014-04-17) the results are even worse: the GIF images only show a white strip instead of the original image.

[snibgo]

Both commands work fine for me, and I can't see anything in them that might cause a problem. You are trimming, and if the clip goes wrong, that would explain heights of 1 pixel.

Looking at "identify -verbose", the embedded clip path is bad. It contains "Y" commands, which are not part of the SVG 1.1 standard. See http://www.w3.org/TR/SVG/paths.html (I have seen "Y" before, from another user with a similar problem.)

I'm on IM V6.8.9-0, Windows 8.1, Inkscape 0.48.

What is your SVG delegate? If you replace "-quiet" with "-verbose", does it say it is using Inkscape? If not, I suggest you install Inkscape.

[snibgo]

I've found the other thread: viewtopic.php?f=1&t=25008&p=108085

Your path also has the same problem as groyk's, that you have "V" commands which should be followed by one or more y-coordinates but seems to be followed by (x,y) pairs.

I have discovered that reading your file with Gimp, converting path to selection, deleting the path, and converting selection to path, cleans it up. It doesn't leave bad SVG in the path. I did this interactively, but I expect it could be done in batch.

[snibgo]

This problem is apparently solved by converting all the SVG "Y" and "V" commands to "L". Windows BAT script:

Code: Select all

call fixSvg rgb_screen.tif

%IM%convert rgb_screen.tif ( clipGood.svg -negate ) -alpha off -compose copy_opacity -composite rgb_screen4.png

... where fixSvg.bat is:

Code: Select all

rem From image file %1,
rem extract SVG and convert "V" and "Y" commands into "L".

%IM%identify -format %%[8BIM:1999,2998:#1] %1 > clipBad.svg

del clipGood.svg

for /F "tokens=1,*" %%A in (clipBad.svg) do (
  set COMMAND=%%A
  if "!COMMAND!"=="Y" set COMMAND=L
  if "!COMMAND!"=="V" set COMMAND=L
  echo !COMMAND! %%B>>clipGood.svg
)