Page 1 of 1

possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-16T15:07:25-07:00
by fmw42
IM 6.7.3.1 Q16 Mac OSX Tiger

I seem to have trouble getting a script to work if I use .mpc format, but it works fine with .miff format.

This is the remap core of my script. I have already extracted the mapping pair of colors. With mpc, the image at the end is no different from the image after the -colors 24, showing that the remapping is not working. But with miff, there is a difference showing that the remapping is working.

Input image:
Image


This does not work with .mpc format.

infile="1cropped.jpeg"
convert -quiet -regard-warnings "$infile" -alpha off -depth 8 +dither -colors 24 +repage "1tmpA.mpc"
pairlist="rgb(8,10,9):rgb(0,0,0) rgb(46,25,24):rgb(41,42,39) rgb(71,57,86):rgb(80,64,107) rgb(88,30,28):rgb(82,45,36) rgb(112,15,17):rgb(82,45,36) rgb(112,88,87):rgb(109,98,94) rgb(117,70,57):rgb(101,83,59) rgb(120,120,163):rgb(121,91,167) rgb(140,71,60):rgb(147,80,58) rgb(142,18,21):rgb(156,48,36) rgb(142,84,73):rgb(142,86,59) rgb(162,111,99):rgb(156,116,100) rgb(162,155,165):rgb(151,152,154) rgb(163,175,211):rgb(186,186,186) rgb(164,23,29):rgb(156,48,36) rgb(177,135,120):rgb(175,138,123) rgb(180,147,141):rgb(175,138,123) rgb(182,203,228):rgb(205,215,210) rgb(197,139,121):rgb(193,151,121) rgb(198,150,138):rgb(193,151,121) rgb(199,165,161):rgb(173,165,157) rgb(200,188,198):rgb(203,193,193) rgb(204,215,239):rgb(230,224,232) rgb(211,216,230):rgb(230,224,232)"
pairArr=($pairlist)
echo "${pairArr[*]}"
numpairs="${#pairArr[*]}"
echo "numpairs=$numpairs"
dim=`convert 1tmpA.mpc -format "%wx%h" info:`
convert -size $dim xc:none 1tmpO.mpc
i=0
for colorpair in ${pairArr[*]}; do
color1=`echo "$colorpair" | cut -d: -f1`
color2=`echo "$colorpair" | cut -d: -f2`
echo "$i: $color1 to $color2"
convert \( 1tmpA.mpc \
+transparent "$color1" \
-fill "$color2" -opaque "$color1" \) 1tmpO.mpc \
-composite 1tmpO.mpc
i=`expr $i + 1`
done
convert 1tmpA.mpc 1tmpO.mpc -composite 1cropped_test_mpc.png

Image



Whereas the same code using miff format works fine.

infile="1cropped.jpeg"
convert -quiet -regard-warnings "$infile" -alpha off -depth 8 +dither -colors 24 +repage "1tmpA.miff"
pairlist="rgb(8,10,9):rgb(0,0,0) rgb(46,25,24):rgb(41,42,39) rgb(71,57,86):rgb(80,64,107) rgb(88,30,28):rgb(82,45,36) rgb(112,15,17):rgb(82,45,36) rgb(112,88,87):rgb(109,98,94) rgb(117,70,57):rgb(101,83,59) rgb(120,120,163):rgb(121,91,167) rgb(140,71,60):rgb(147,80,58) rgb(142,18,21):rgb(156,48,36) rgb(142,84,73):rgb(142,86,59) rgb(162,111,99):rgb(156,116,100) rgb(162,155,165):rgb(151,152,154) rgb(163,175,211):rgb(186,186,186) rgb(164,23,29):rgb(156,48,36) rgb(177,135,120):rgb(175,138,123) rgb(180,147,141):rgb(175,138,123) rgb(182,203,228):rgb(205,215,210) rgb(197,139,121):rgb(193,151,121) rgb(198,150,138):rgb(193,151,121) rgb(199,165,161):rgb(173,165,157) rgb(200,188,198):rgb(203,193,193) rgb(204,215,239):rgb(230,224,232) rgb(211,216,230):rgb(230,224,232)"
pairArr=($pairlist)
echo "${pairArr[*]}"
numpairs="${#pairArr[*]}"
echo "numpairs=$numpairs"
dim=`convert 1tmpA.miff -format "%wx%h" info:`
convert -size $dim xc:none 1tmpO.miff
i=0
for colorpair in ${pairArr[*]}; do
color1=`echo "$colorpair" | cut -d: -f1`
color2=`echo "$colorpair" | cut -d: -f2`
echo "$i: $color1 to $color2"
convert \( 1tmpA.miff \
+transparent "$color1" \
-fill "$color2" -opaque "$color1" \) 1tmpO.miff \
-composite 1tmpO.miff
i=`expr $i + 1`
done
convert 1tmpA.miff 1tmpO.miff -composite 1cropped_test_miff.png


Image


What am I missing here? Is this a bug?

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-16T17:35:38-07:00
by magick
Miff is saved @ a depth of 8, MPC @ 16. Try:
  • convert "$infile" -alpha off -depth 8 +dither -colors 24 +repage -depth 8 "1tmpA.mpc"

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-16T18:10:30-07:00
by fmw42
magick wrote:Miff is saved @ a depth of 8, MPC @ 16. Try:
  • convert "$infile" -alpha off -depth 8 +dither -colors 24 +repage -depth 8 "1tmpA.mpc"

Yes, that works. Thanks very much. I had been struggling with this for several days.


Perhaps this should be pointed out somewhere in the documentation (regarding the mpc and miff difference) as well as the fact that two -depth 8 are needed. This is all very important information when doing color reduction and color remapping together.

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T18:17:24-07:00
by anthony
I have added the following note to MIFF in IM examples..
I recommend when writing "miff:" that you include a "+depth" option. This will reset the 'input depth' of the image to the IM memory quality so as to use the best posible quality for the intermediate image save. Of course you can 'clip' the save image depth using "-depth 8" so as to reduce the image size on disk, however that will also force Quantum Rounding effects as well (unless HDRI floating-point save is also enabled).
Of course if you want to 'clip' the image depth in the saved image (making it smaller), that is a different matter!

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T18:38:44-07:00
by fmw42
anthony wrote:I have added the following note to MIFF in IM examples..
I recommend when writing "miff:" that you include a "+depth" option. This will reset the 'input depth' of the image to the IM memory quality so as to use the best posible quality for the intermediate image save. Of course you can 'clip' the save image depth using "-depth 8" so as to reduce the image size on disk, however that will also force Quantum Rounding effects as well (unless HDRI floating-point save is also enabled).
Of course if you want to 'clip' the image depth in the saved image (making it smaller), that is a different matter!

The issue was that mpc was at 16-bits and needed to have -depth 8 assigned after doing +dither -colors X. That cause problems later when I went to replace colors, because the colors I thought were raw 8-bits were actually raw 16-bits. Those are the two issues I thought might be mentioned somewhere (MPC vs MFF and regarding +dither -colors X -depth 8)

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T19:03:02-07:00
by anthony
MPC is basically a direct mapping of memory to disk. You can not use -depth or any other normal image save options with it as it is exactly what the image is, in-memory!

If -depth is doing something with MPC, then it is only a side effect of repording the 'prefered depth' of the image for later save, and not a change in the image data itself.

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T20:11:33-07:00
by fmw42
anthony wrote:MPC is basically a direct mapping of memory to disk. You can not use -depth or any other normal image save options with it as it is exactly what the image is, in-memory!

If -depth is doing something with MPC, then it is only a side effect of repording the 'prefered depth' of the image for later save, and not a change in the image data itself.

This comes directly from Magick (above)
Miff is saved @ a depth of 8, MPC @ 16. Try:

convert "$infile" -alpha off -depth 8 +dither -colors 24 +repage -depth 8 "1tmpA.mpc"

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T20:26:42-07:00
by anthony
Lets see what magick has to say then. Something about that does not make sense.

Re: possible bug mpc vs miff IM 6.7.3.1 Q16

Posted: 2011-10-18T20:30:10-07:00
by fmw42
anthony wrote:Lets see what magick has to say then. Something about that does not make sense.

That is fine with me. I would certainly like to understand this better. But it did solve my problem.