Page 1 of 1

possible bug -separate or transparent IM 6.8.7.0 Q16 Mac OSX

Posted: 2013-10-01T17:17:41-07:00
by fmw42
I am not sure if this is a -separate bug or something else. Or a problem with the input image in some way.

I have an image that I am trying to convert to binary format using -floodfill etc. It works fine on the original image. But it fails in most tests when I use only the green channel in-line. It works if I save the green channel first to png.

Input:
Image

This works fine:
convert 3.jpg -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:

This works fine as two separate commands:
convert 3.jpg 3_green.png

convert 3_green.png -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:

This fails inline:
convert 3.jpg -channel g -separate +channel -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:

This fails using MIFF:
convert 3.jpg -channel g -separate +channel MIFF:- | convert - -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:

This fails using TIFF:
convert 3.jpg -channel g -separate +channel TIFF:- | convert - -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:

This works using PNG:
convert 3.jpg -channel g -separate +channel PNG:- | convert - -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:


NOTE: this may have to do with transparency. Perhaps I am doing something wrong.

This new command fails using transparency:
convert 3.jpg -channel g -separate +channel -fuzz 18% -fill none -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -fill black -opaque none \
-morphology open:2 diamond:1 show:

This new command works with non-transparent red
convert 3.jpg -channel g -separate +channel -fuzz 18% -fill red -draw "color 0,0 floodfill" \
-fill white +opaque red -fill black -opaque red \
-morphology open:2 diamond:1 show:

It also fails for me on 6.8.6.9

Can anyone duplicate these results (especially on a Mac)?

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-01T18:44:43-07:00
by snibgo
I think you want the output to be a white object on a black background.

Sorry, I don't use Mac. On Windows 7, IM v6.8.6-10 and v6.8.7-0, I get the correct result by placing "-set colorspace sRGB" at suitable points. I don't know why this is needed. Perhaps "-separate" is doing something wrong. Windows script, with additions in red:


set I=%IM%

rem possible bug -separate or transparent IM 6.8.7.0 Q16 Mac OSX

rem This works fine:
%I%convert 3.jpg -fuzz 18%% -fill none -draw "matte 0,0 floodfill" -write i1b.png ^
-channel rgba -fill white +opaque none -background black -alpha background -alpha off -write i1c.png ^
-morphology open:2 diamond:1 i1.png

rem This works fine as two separate commands:
%I%convert 3.jpg 3_green.png

%I%convert 3_green.png -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-fill white +opaque none -background black -alpha background -alpha off ^
-morphology open:2 diamond:1 i2.png

rem This fails inline:
%I%convert 3.jpg -channel g -separate -set colorspace sRGB +channel -fuzz 18%% -fill none -alpha set -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -background black -alpha background -alpha off ^
-morphology open:2 diamond:1 i3.png

rem This fails using MIFF:
%I%convert 3.jpg -channel g -separate +channel MIFF:- | %I%convert - -set colorspace sRGB -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -background black -alpha background -alpha off ^
-morphology open:2 diamond:1 i4.png

rem This fails using TIFF:
%I%convert 3.jpg -channel g -separate +channel TIFF:- | %I%convert - -set colorspace sRGB -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -background black -alpha background -alpha off ^
-morphology open:2 diamond:1 i5.png

rem This works using PNG:
%I%convert 3.jpg -channel g -separate +channel PNG:- | %I%convert - -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -background black -alpha background -alpha off ^
-morphology open:2 diamond:1 i6.png

rem NOTE: this may have to do with transparency. Perhaps I am doing something wrong.

rem This new command fails using transparency:
%I%convert 3.jpg -channel g -separate -set colorspace sRGB +channel -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -fill black -opaque none ^
-morphology open:2 diamond:1 i7.png

rem This new command works with non-transparent red
%I%convert 3.jpg -channel g -separate +channel -fuzz 18%% -fill red -draw "color 0,0 floodfill" ^
-fill white +opaque red -fill black -opaque red ^
-morphology open:2 diamond:1 i8.png
-set colorspace sRGB +channel -fuzz 18%% -fill none -draw "matte 0,0 floodfill" ^
-channel rgba -fill white +opaque none -fill black -opaque none ^
-morphology open:2 diamond:1 i7.png

rem This new command works with non-transparent red
%I%convert 3.jpg -channel g -separate +channel -fuzz 18%% -fill red -draw "color 0,0 floodfill" ^
-fill white +opaque red -fill black -opaque red ^
-morphology open:2 diamond:1 i8.png

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-01T19:06:03-07:00
by fmw42
Yes, using -set colorspace sRGB or -colorspace sRGB after the -separate works for me also.

convert 3.jpg -channel g -separate -colorspace sRGB +channel -fuzz 18%% -fill none -alpha set -draw "matte 0,0 floodfill" \
-channel rgba -fill white +opaque none -background black -alpha background -alpha off \
-morphology open:2 diamond:1 show:


This seems to be something relatively new.


Magick: Is this a bug or a new requirement/feature?

But then why did it work fine for PNG and not with any other format?

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-05T15:54:46-07:00
by dlemstra
Could you narrow it down to a shorter list of commands? This will make it easier to find what is causing the issue.

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-05T16:28:40-07:00
by snibgo
In v6.8.7 [EDIT: 6.8.7, not 6.8.6] on Windows 7:

convert rose: -separate -colorspace sRGB -combine r0.png <== works

convert rose: -separate -colorspace RGB -combine r1.png <== makes lighter image

convert rose: -separate -combine r2.png <== makes monochrome image

I think r1.png is correct.

I think r2.png should be identical to r0.png, which is identical to rose:

I suspect the bug would be cured in the code that does a "-separate", setting the three results to sRGB.

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-05T18:02:46-07:00
by fmw42
convert rose: -separate -combine r2.png
I believe that this is more of the bug related to -combine. see viewtopic.php?f=3&t=24173

For example

This seems to work fine:
convert rose: -separate rose_%d.png
convert rose_0.png rose_1.png rose_2.png -combine newrose.png
display newrose.png

But this comes out grayscale in jpg format:
convert rose: -separate rose_%d.jpg
convert rose_0.jpg rose_1.jpg rose_2.jpg -combine newrose.jpg
display newrose.jpg

But this comes out grayscale in miff format:
convert rose: -separate rose_%d.miff
convert rose_0.miff rose_1.miff rose_2.miff -combine newrose.miff
display newrose.miff


I will try to work out a better example for the -separate case.

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-05T18:38:04-07:00
by fmw42
This may not be a -separate issue, but more a -draw or -fuzz issue because of gamma being set to 1 with -fuzz -draw. Seems like something is getting messed up with miff (but not png).

It appears that -draw fails to floodfill transparency for grayscale input (even with gamma=0.4545). This appears to happen because it is converting the grayscale to linear and does not make the image transparent unless it is set to sRGB in order to make gamma=0.4545. Possibly -fuzz gets messed up or fails to find anything to work on if gamma=1.


convert 3.jpg -channel g -separate +channel 3tmp1.miff
convert 3tmp1.miff -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.miff
convert 3tmp1.miff -set colorspace sRGB -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp3.miff

3tmp1.miff is grayscale with gamma=0.4545
3tmp2.miff is grayscale with gamma=1 and does not show any transparency
3tmp3.miff is grayscale with gamma=0.4545 and shows transparency properly

If I use png rather than miff it works fine
convert 3.jpg -channel g -separate +channel 3tmp1.png
convert 3tmp1.png -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.png

If I use jpg rather than png, if fails again
convert 3.jpg -channel g -separate +channel 3tmp1.jpg
convert 3tmp1.jpg -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.jpg


Seems like something is getting messed up with gamma for formats other than PNG. This appears similar to what is going on with -combine at viewtopic.php?f=3&t=24173

Perhaps it is related to the gamma issues and code that Glenn discovered and changed with regard to viewtopic.php?f=3&t=24205#p103515

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-08T15:04:57-07:00
by fmw42
All these seem to work fine in the latest IM 6.8.7.1 beta. The results are all color and not grayscale as before.


imbh convert rose: -separate rose_%d.png
imbh convert rose_0.png rose_1.png rose_2.png -combine newrose.png
imbh display newrose.png

imbh convert rose: -separate rose_%d.jpg
imbh convert rose_0.png rose_1.png rose_2.png -combine newrose.jpg
imbh display newrose.jpg

imbh convert rose: -separate rose_%d.miff
imbh convert rose_0.png rose_1.png rose_2.png -combine newrose.miff
imbh display newrose.miff


But in the following miff and tiff fail to show transparency but png works.

# this fails
imbh convert 3.jpg -channel g -separate +channel 3tmp1.miff
imbh convert 3tmp1.miff -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.miff
imbh display 3tmp2.miff

# this fails
imbh convert 3.jpg -channel g -separate +channel 3tmp1.tiff
imbh convert 3tmp1.tiff -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.tiff
imbh display 3tmp2.tiff

# this works
imbh convert 3.jpg -channel g -separate +channel 3tmp1.png
imbh convert 3tmp1.png -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.png
imbh display 3tmp2.png

I think it has to do with either -fuzz or -draw when the input is grayscale (gamma=0.4545), since the ones that fail end up with gamma=1 and the png that works has output gamma=0.4545



ADDITIONAL INFO:

It would appear to be related to -draw (rather than -fuzz) because both of these work


imbh convert 3.jpg -channel g -separate +channel 3tmp1.miff
imbh convert 3tmp1.miff -fuzz 18% -fill red -opaque white 3tmp2.miff
imbh convert 3tmp2.miff show:


imbh convert 3.jpg -channel g -separate +channel 3tmp1.png
imbh convert 3tmp1.png -fuzz 18% -fill red -opaque white 3tmp2.png
imbh convert 3tmp2.png show:

Re: possible bug -separate or transparent IM 6.8.7.0 Q16 Mac

Posted: 2013-10-11T13:06:44-07:00
by dlemstra
I am getting some strange result with my checkout from svn:

# this fails:
convert 3.jpg -channel g -separate +channel 3tmp1.tiff

convert 3tmp1.tiff -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.tiff
display 3tmp2.tiff

convert 3tmp1.tiff -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.png
display 3tmp2.png

# this works
convert 3.jpg -channel g -separate +channel 3tmp1.png

convert 3tmp1.png -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.tiff
display 3tmp2.tiff

convert 3tmp1.png -fuzz 18% -fill none -draw "matte 0,0 floodfill" 3tmp2.png
display 3tmp2.png

But the image 3tmp1 image is grayscale in both situations.