Legacy ImageMagick Discussions Archive

i observe a change in behaviour from version 6.6.9-7 to 6.7.7-10 :

i am generating a panorama from a sky image with lookup tables, lutX.png and lutY.png
In the older version the result is in color on the newer i get a grayscale image.
The call in bash is as follows $wraw, $hraw are width and height of the raw image.

example images can be found here
http://gop.meteo.uni-koeln.de/~hatpro/j ... ge_magick/

the full code with variables and lookup tabels is:
am i doing wrong or is it convert ?

It is taking the type (and other metadata) from the first image in the list. Insert "-type TrueColor" before the output filename.

-type TrueColor does not help:

metadata of pan without -type TrueColor
$identify pan.jpg
pan.jpg JPEG 288x45 288x45+0+0 8-bit PseudoClass 256c 3.81KB 0.000u 0:00.000

generate pan with -type TrueColor :
$convert lutX.png lutY.png raw.jpg -fx "u[2].p{ u*$wraw , v*$hraw }" -type TrueColor pan_tc.jpg
metadata of this
$identify pan_tc.jpg
pan_tc.jpg JPEG 288x45 288x45+0+0 8-bit PseudoClass 256c 3.81KB 0.000u 0:00.010

so there is no change ... ant the image is still grayscale.


metadata of the lookup table i.e. the first image:
$identify lutX.png
lutX.png PNG 288x45 288x45+0+0 16-bit PseudoClass 65536c 24.4KB 0.000u 0:00.000

if I add -type TrueColor to the command generating lutX i get:
$convert -size $wpan'x'$hpan xc: -channel G -fx "($cx-$rad*j/$hpan*sin(2*pi*i/$wpan))/$wraw" -separate -type truecolor lutX_tc.png
$identify lutX_tc.png
lutX_tc.png PNG 288x45 288x45+0+0 16-bit DirectClass 28KB 0.000u 0:00.000

i.e. DirectClass instead of Pseudoclass which is not a 3*8bit but (if i understand correct) 3*5bit 'truecolor'

if i use this for the generation of pan.jpg without -type = truecolor I get:
$convert lutX_tc.png lutY.png raw.jpg -fx "u[2].p{ u*$wraw , v*$hraw }" pan_tc1.jpg
$identify pan_tc1.jpg
pan_tc1.jpg JPEG 288x45 288x45+0+0 8-bit DirectClass 4.46KB 0.000u 0:00.000

8-bit DirectClass means 3*8bit RGB truecolor ?
it is not the same type as lutX_tc.png !
but pan_tc1 it is now in color - great - problem solved.

But it remains somehow puzzling ...

...
could do it also with lookup tables in the red and green channels of lut_RG.png this way the color problem does not occur (lut_RG.png is now a 16bit directclass).

Additonally this way might be slightly faster as only one lut has to be loaded.
(i am using lookup tables because they need to be changed only very rarely whereas the panorama is generated every 20seconds - see http://gop.meteo.uni-koeln.de/~hatpro/jue/tsi/current/)
... and think about using miff instead of png for the lut ...

IM did some weird things with greyscale around your versions. See http://www.imagemagick.org/script/color-management.php . It may be a good idea to upgrade to the current version.

The oldest version on my laptop is 6.8.0-0. On that version, with or without "-type TrueColor", I get a colour image.

On 6.9.0-0 (which is now quite old, but it is what I use), I need "-type TrueColor" to get colour.

"Pseudoclass" means palette; "Directclass" means non-palette. Both of those can be grayscale or colour.


Yes, loading only one file will probably be quicker, and miff will be quicker than png. However, miff file formats can change between versions. You might regenerate them when you upgrade, or at the start of each batch.