Legacy ImageMagick Discussions Archive

Hi,
Just for fun (and thinking about a pixel-test program in the long run) I wanted to generate a series of 1920x1080 images that are each one color, 16 million + images, the colors ranging from #000000 to #FFFFFF. So of course I'm not going to do this by hand, it's a perfect job for a script. I'm starting with an image called base.jpg that is 1920x1080 and a uniform background of #000000. Here's the script (doing just #000000 to #00000F for testing purposes):

#!/bin/bash
for((i=0;i<16;i++))
do
f=$(printf "#%.6X" $i)
g=$(printf "%.6X" $i)
convert base.jpg -background $f -compose Dst -flatten $g.jpg
done

When I run this, I get the images 000000.jpg - 00000F.jpg, but the don't have the correct background values.
000000.jpg and 000001.jpg both have pure black backgrounds (#000000)
000002.jpg and 000003.jpg both have backgrounds of #000002
000004.jpg has background #000004
000005.jpg has background #010005
000006.jpg has background #010006
000007.jpg has background #000106
000008.jpg and 000009.jpg have background #000008
00000A.jpg and 00000B.jpg have background #00000A
00000C.jpg and 00000D.jpg have background #00000C
00000E.jpg and 00000F.jpg have background #01000E

Based on what I was reading on the Usage pages (http://www.imagemagick.org/Usage/canvas/#specific), I also tried using the convert line
convert base.jpg -fill $f -draw 'color 0,0 reset' $g.jpg
but the results were the same (exactly the same).

Since the file names are correct, the value being put into -background should be correct (and the same as the file name just with the # in front of it).
Does anyone have an idea why this isn't working the way I expect it to?

$ convert -version
Version: ImageMagick 6.4.0 01/19/10 Q16 http://www.imagemagick.org

Thank you so much,
J.F.H.

hex color values need to be in quotes (as do rgb(...) values). Also DST is a no-op. Try DstIn

so try

convert base.jpg -background "$f" -compose DstIn -flatten $g.jpg

as a test, echo your $f in your loop to see what you are getting and if it is what you want and includes the #. You can do a limited test with just a few interations to see.

Also just try your command as a one line test.

convert base.jpg -background "#ffaacc" -compose DstIn -flatten test.jpg

This makes a solid color. But you could just as easily done

convert base.jpg -fill "#ffaacc" -colorize 100 test.jpg

or

convert base.jpg -fill "#ffaacc" -opaque black test.jpg



However a better and more direct way is

convert -size 1920x1080 xc:"#ffaacc" test.jpg
or
convert -size 1920x1080 canvas:"#ffaacc" test.jpg

see http://www.imagemagick.org/Usage/canvas/#solid or http://www.imagemagick.org/Usage/color_mods/#colorize

fmw42 wrote:hex color values need to be in quotes (as do rgb(...) values). Also DST is a no-op. Try DstIn

Okay, I was just basing things on what I read on that page I referenced (hence the -Dst with nothing else).

fmw42 wrote:so try

convert base.jpg -background "$f" -compose DstIn -flatten $g.jpg

Same results.

fmw42 wrote:as a test, echo your $f in your loop to see what you are getting and if it is what you want and includes the #. You can do a limited test with just a few interations to see.

Of course this was the first thing I did when I got the unexpected results.
echo $f $g returns:
#000000 000000
#000001 000001
... ...
and of course the file names are correct...and since they are generated by an identical printf command except for the # symbol, the output $f has to be correct.

fmw42 wrote:Also just try your command as a one line test.

convert base.jpg -background "#ffaacc" -compose DstIn -flatten test.jpg

This makes a solid color. But you could just as easily done

convert base.jpg -fill "#ffaacc" -colorize 100 test.jpg

or

convert base.jpg -fill "#ffaacc" -opaque black test.jpg

Okay, this I didn't check until now because I assumed it was something I was doing wrong.
Entering the first of the commands individually on the command line (and also testing your suggestion) gives identical results to those in the original post. i.e.,
convert base.jpg -fill "#000005" -colorize 100 000005.jpg
produces a uniform image where every pixel has value #010005. That's not what I was expecting.

The second command doesn't seem to do anything, all of the resulting images are identical to base.jpg.

fmw42 wrote: However a better and more direct way is

convert -size 1920x1080 xc:"#ffaacc" test.jpg
or
convert -size 1920x1080 canvas:"#ffaacc" test.jpg

see http://www.imagemagick.org/Usage/canvas/#solid or http://www.imagemagick.org/Usage/color_mods/#colorize

The one with xc: entered from the command line gives identical results to those in the original post.
The one with canvas: in the command line gives the following errors:
$ convert -size 1920x1080 canvas:"#00000F" 00000F.jpg
convert: unable to open image `canvas:#00000F': No such file or directory.
convert: missing an image filename `00000F.jpg'.

So, it seems my script is doing what I expect, but for some reason ImageMagick isn't.

Tested on Windows 7/cygwin, ImageMagick 6.4.0
and
Kubuntu 11.04, ImageMagick 6.6.2-6
All tests of scripts and command-line are identical on both boxes, image valued found identical with ifranview, Paint Shop Pro, and GIMP.

Your IM version is too old for canvas: It was a relatively newe addition meant to be an alias for xc:, but a bit more descriptive. I believe xc means x-color.

This works just fine for me on IM 6.7.2.2 Q16 Mac OSX Tiger.

convert -size 100x100 canvas:"#0000FF" blue.png

Okay, we're narrowing it down, at least.
I just tried the following from the command line:
convert -size 1920x1080 xc:"#000005" 000005.jpg
and got a 1920x1080 with constant color #010005

Then I tried
convert -size -1920x1080 xc:"#000005" 000005.png
and got a 1920x1080 with constant color #000005


So it looks like there's something going on in making the jpg. Does ImageMagick start with a default output then run a conversion (Lanczos filter or something like that) to produce the jpg? If so, it looks like that's where the issue is happening.

QPhysics wrote:Okay, we're narrowing it down, at least.
I just tried the following from the command line:
convert -size 1920x1080 xc:"#000005" 000005.jpg
and got a 1920x1080 with constant color #010005

Then I tried
convert -size -1920x1080 xc:"#000005" 000005.png
and got a 1920x1080 with constant color #000005


So it looks like there's something going on in making the jpg. Does ImageMagick start with a default output then run a conversion (Lanczos filter or something like that) to produce the jpg? If so, it looks like that's where the issue is happening.

Note: you have an extra minus sign in the last one. Sizes cannot be negative

IM creates the file in its internal format, as I understand it, then converts to jpg or png or whatever you want using delegate libraries such as libjpeg, libpng, etc.

JPG is a lossy compression method and can change values due to the compression. So that could explain your resulting values of #010005 when using jpg output rather than #000005 when using png.

I would recommend for such images you just use gif format with limited colors. That will give you very small file sizes.


You might want to post this on the bugs forum and see what the IM developers say.

convert -size 1920x1080 xc:"#000005" 000005.jpg
convert 000005.jpg[1x1+0+0] txt:
# ImageMagick pixel enumeration: 1,1,255,rgb
0,0: ( 1, 0, 5) #010005 rgb(1,0,5)
Note: Filesize: 12.5KBB


convert -size 1920x1080 xc:"#000005" 000005.png
convert 000005.png[1x1+0+0] txt:
# ImageMagick pixel enumeration: 1,1,255,rgb
0,0: ( 0, 0, 5) #000005 rgb(0,0,5)


convert -size 1920x1080 xc:"#000005" -depth 8 000005.miff
convert 000005.miff[1x1+0+0] txt:
# ImageMagick pixel enumeration: 1,1,255,rgb
0,0: ( 0, 0, 5) #000005 rgb(0,0,5)

convert -size 1920x1080 xc:"#000005" 000005.gif
convert 000005.gif[1x1+0+0] txt:
# ImageMagick pixel enumeration: 1,1,255,rgb
0,0: ( 0, 0, 5) #000005 rgb(0,0,5)
Note: Filesize: 2.6KBB

Lets back off a little.
1920x1080 pixel images, each containing every posible 8bit color.
That is 256x256x256 different colors!

Now each image will probbaly compress real well being one color...
Ok each file is 4Kbytes of disk block space, but that is still 16777216 files!
which is 67108864 Kbytes ,or 65536 Mbytes, or 64 Terrabytes of disk space!!!
(yes the numbers really do round off nicely)
and that does not count directory, and file meta data needed!

Now I know they make 2 and possibly expensive 4 Tb disk drives today!, but 64 Terrabytes!

Do you really want to use 64TB of disk space for something that can be essentially created faster in memory, as you need it, than it can be read from a disk?

Think about it!