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:
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
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
What am I missing here? Is this a bug?
possible bug mpc vs miff IM 6.7.3.1 Q16
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
Miff is saved @ a depth of 8, MPC @ 16. Try:
- convert "$infile" -alpha off -depth 8 +dither -colors 24 +repage -depth 8 "1tmpA.mpc"
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
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.
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
I have added the following note to MIFF in IM examples..
Of course if you want to 'clip' the image depth in the saved image (making it smaller), that is a different matter!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).
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
anthony wrote:I have added the following note to MIFF in IM examples..
Of course if you want to 'clip' the image depth in the saved image (making it smaller), that is a different matter!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).
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
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
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.
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.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
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"
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
Lets see what magick has to say then. Something about that does not make sense.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug mpc vs miff IM 6.7.3.1 Q16
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.