What am I not understanding in the following. Is there some issue with writing information at various stages of a command using %{pixel:...]
convert rose: -format "%[pixel:s.p{10,10}]\n" -write info: \
-separate +channel -evaluate-sequence mean -format "%[pixel:s.p{10,10}]\n" -write info: rose_comb.png
srgb(72,64,57)
srgb(72,64,57)
Why are these two the same? Should not the average of all 3 channels be grayscale and thus r,g,b be the same in the second value?
convert rose_comb.png -format "%r\n" info:
PseudoClass Gray
convert rose_comb.png -format "%[colorspace]\n" info:
sRGB
convert rose_comb.png -format "%[type]\n" info:
Grayscale
convert rose_comb.png -format "%[pixel:s.p{10,10}]\n" info:
srgb(72,64,57)
And again if the resulting image is grayscale, then why are r,g,b not all the same?
possible bug %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
It does seem to be wrong. You should see at least some changes.
First thought, the first result is just being repeated... no.. adding some other text to the format shows it is using the given string. The second string should be grayscale!
FYI... this is the simpler way to do it... assuming you are not piping an image result.
However IMv7 is getting a grayscale value...
First thought, the first result is just being repeated... no.. adding some other text to the format shows it is using the given string. The second string should be grayscale!
FYI... this is the simpler way to do it... assuming you are not piping an image result.
Code: Select all
convert rose: -print "A=%[pixel:s.p{10,10}]\n" \
-separate +channel -evaluate-sequence mean \
-print "B=%[pixel:s.p{10,10}]\n" \
rose_comb.png
A=srgb(72,64,57)
B=srgb(72,64,57)
However IMv7 is getting a grayscale value...
Code: Select all
magick rose: -print "A=%[pixel:s.p{10,10}]\n" \
-separate +channel -evaluate-sequence mean \
-print "B=%[pixel:s.p{10,10}]\n" \
rose_comb.png
PS: alternative to get average of the three channels.... use -grayscale averageA=srgb(72,64,57)
B=gray(64)
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 %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
So is there a bug in IM 6?
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
1. I don't know what "s." does here. I don't think it should be needed, but it does (sometimes) make a difference.
2. There seems to be a bug that "-format ... -write info:" makes a difference to the final result.
2. There seems to be a bug that "-format ... -write info:" makes a difference to the final result.
Code: Select all
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose: -format "%[pixel:s.p{10,10}]\n" -write info: -separate +channel -evaluate-sequence mean -format "%[pixel:s.p{10,10}]\n" -write info: rose_comb.png
srgb(72,64,57)
srgb(72,64,57)
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose: -separate +channel -evaluate-sequence mean rose_comb2.png
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose_comb.png -format "%[pixel:s.p{10,10}]\n" info:
srgb(72,64,57)
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose_comb.png -format "%[pixel:p{10,10}]\n" info:
grey25
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose_comb2.png -format "%[pixel:s.p{10,10}]\n" info:
grey25
D:\web\im>c:\im\ImageMagick-6.8.6-9-Q16\convert rose_comb2.png -format "%[pixel:p{10,10}]\n" info:
grey25
snibgo's IM pages: im.snibgo.com
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
s = current image in list (for %[fx:] otherwise = u)
see
http://www.imagemagick.org/script/fx.php
http://www.imagemagick.org/Usage/transform/#fx_escapes
I presume that means the current image as modified by any processing. But perhaps that only works for pixel: and not fx:
see
http://www.imagemagick.org/script/fx.php
http://www.imagemagick.org/Usage/transform/#fx_escapes
I presume that means the current image as modified by any processing. But perhaps that only works for pixel: and not fx:
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: possible bug %[pixel:...] IM 6.8.6.9 Q16 Mac OSX
Often the percent methods are applied to every image (-format -identify for example) in that can 's' means the image while 'u' retains it normal meaning of the first or zeroth image in the list. 'v' means second or 'index 1' image
Then using -fx (which iterated over each pixel data value in 'u', and just 'u') s is fixed to be the same as 'u' first image and correspondingly 't' has the value zero.
Note that when using a 'index suffix' such as: u[2], s[2] and v[2]; all result in the same image, the image with index '2' (or the thrid image in the list)
... RAMBLING ignore if you want...
I do have a 'future todo' to make a -fx_list operation that not only iterates over pixel data in 'u' but does it for every image in the list, with 's' and 't' being set accordingly. The resulting image replacing the 's' image. Whether it does that replacment after each image iteration (so previous image data is available to the next image), or only after all images have been processed (thus needing a higher memory overhead) is undecided.
But when I do it (if at all) is -- well who knows! Life has moved on for me.
Though I do still want to complete the IMv7 scripting interface. My current todo is to allow %[fx:...] and %[pixel:..] expressions when no images are available. For mathematics assignments.
For example things like... or even some color math assignments like...
In IM v6 these sort of things need two commands, and thus no good in a single 'magick' script that is part of IMv7
I am thinking the easiest way would be simply passing a 'null' image, when no images are available, rather than having to add a test for image existence on every image lookup reference. But it means a image creation and destrutcion for even assignment until images have been read in or created.
Then using -fx (which iterated over each pixel data value in 'u', and just 'u') s is fixed to be the same as 'u' first image and correspondingly 't' has the value zero.
Note that when using a 'index suffix' such as: u[2], s[2] and v[2]; all result in the same image, the image with index '2' (or the thrid image in the list)
... RAMBLING ignore if you want...
I do have a 'future todo' to make a -fx_list operation that not only iterates over pixel data in 'u' but does it for every image in the list, with 's' and 't' being set accordingly. The resulting image replacing the 's' image. Whether it does that replacment after each image iteration (so previous image data is available to the next image), or only after all images have been processed (thus needing a higher memory overhead) is undecided.
But when I do it (if at all) is -- well who knows! Life has moved on for me.
Though I do still want to complete the IMv7 scripting interface. My current todo is to allow %[fx:...] and %[pixel:..] expressions when no images are available. For mathematics assignments.
For example things like...
Code: Select all
-set my:sin45 '%[fx:sin(45)]'
Code: Select all
-fill '%[pixel:(yellow+orange)/2]'
Code: Select all
average=`identify -format '%[pixel:(yellow+orange)/2]' null:`
convert -size 100x100 xc:yellow xc:"$average" xc:orange +append show:
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/