[SOLVED] write RAS files in BGR order

[duboism]

Hello,

This is probably an obvious question but I didn't find an answer. I have asked the question http://stackoverflow.com/questions/7025788/imagemagick-write-pixels-in-bgr-order but didn't receive an answer.

I want to convert JPEG files to Sun RAS files from command-line to read them with my own software.
The problem is that this software only reads RAS files in the BGR order while ImageMagick saves them in the RGB order.

So the question is: how can I force ImageMagick to use BGR order (ie the Type field of the header must be 0000 or 0001 instead of 0003).

Thanks in advance

[duboism]

Hi,

I just wanted to add that nautilus thumbnailer (under GNOME desktop) seems to be unable to display RGB images converted with image magick... Maybe a good reason to fix that.

[anthony]

I just wanted to add that nautilus thumbnailer (under GNOME desktop) seems to be unable to display RGB images converted with image magick... Maybe a good reason to fix that.

RGB images is raw data. It also needs other information outside the image file to be readable. Specifically iage size, and depth (integer size). Gnome is not something I would expect to be able to read a raw image data.

[anthony]

So the question is: how can I force ImageMagick to use BGR order (ie the Type field of the header must be 0000 or 0001 instead of 0003).

I am not familiar with the RAS image file format. and it is not a straight forward problem.

So... Use the Source Luke

Looking at the "sun.c" coder source I can see no switches specifically for a BGR format.

However their is a switch to switch the "type" field between RT_FORMAT_RGB=3 and RT_STANDARD=1 which depends on an internal 'storage_class' image setting. This setting defines whether the image has a limited color table available (psuedoclass) or not (directclass)

As such to get a RT_STANDARD type SUN RAS image, reduce the number of colors (any number)

Code: Select all

   convert  image.jpg -colors 10000 image.ras

[fmw42]

From http://www.fileformat.info/format/sunraster/egff.htm it would appear that the type has nothing to do with BGR format and I see no reference to BGR format.

However, you can rearrange the channels in IM and write it out as .ras, but then you need to find some tool to allow you to edit the header to get the type you want.

In Unix or Mac:

convert \( image_RGB.bmp -channel B -separate \) \
\( image_RGB.bmp -channel G -separate \) \
\( image_RGB.bmp -channel R -separate \) -channel RGB -combine image_BGR.bmp

In windows:

convert ( image_RGB.bmp -channel B -separate ) ^
( image_RGB.bmp -channel G -separate ) ^
( image_RGB.bmp -channel R -separate ) -channel RGB -combine image_BGR.bmp


PS. Here is a way.

Do the RGB to BGR color swap and write your image to pnm format. Then use pnmtorast to convert back to raster in standard format. See http://linux.about.com/library/cmd/blcm ... torast.htm See also http://vasc.ri.cmu.edu/old_help/Macinto ... ormat.html

[duboism]

Hi,

Thank you both for your reply and sorry for the long delay.

Anthony: it's very interesting to dig in the source code. It would be nice to be able to use BGR order without assumption on the colormap... RAS file can have a colormap (see the fields ras_maplength and ras_maptype). By the way, OpenCV also seems to be unable to open RAS files converted by ImageMagick.

fmw42: I'm pretty sure that the type indicates RGB or BGR order. I usually use this site: http://www.fileformat.info/format/sunraster/egff.htm (it seems down by now). Under ubuntu, if you install the package xviewg-dev, you can have a look at the /usr/include/pixrect/rasterfile.h file.

Anyway I followed you advice and I have now a working (linux) script

Code: Select all

filename=`basename $1 .jpg`

# 1st conversion (RGB order)
convert $1 $filename.tmp.ras

# swap channels and write to pnm
convert \( $filename.tmp.ras -channel R -separate \) \
\( $filename.tmp.ras -channel G -separate \) \
\( $filename.tmp.ras -channel B -separate \) -channel BGR -combine $filename.tmp.pnm

# final step
pnmtorast -standard $filename.tmp.pnm > $filename.ras

rm $filename.tmp.ras $filename.tmp.pnm


Thank you again.
Mathieu

[anthony]

Anyway I followed you advice and I have now a working (linux) script

Code: Select all

filename=`basename $1 .jpg`

# 1st conversion (RGB order)
convert $1 $filename.tmp.ras

# swap channels and write to pnm
convert \( $filename.tmp.ras -channel R -separate \) \
\( $filename.tmp.ras -channel G -separate \) \
\( $filename.tmp.ras -channel B -separate \) -channel BGR -combine $filename.tmp.pnm

# final step
pnmtorast -standard $filename.tmp.pnm > $filename.ras

rm $filename.tmp.ras $filename.tmp.pnm


That 'channel swap' convert does nothing BUT convert the ras to pnm. The -channel setting order has no bearing on the result of the combine at all. It is simply a unordered list of channel flags. That is -channel BGR means exactly the same thing as -channel RGB

If you really want to swap channels in that convert you must extract the channels in the order wanted, or swap (reverse) the order of the separate channels. Also you only need to read the image once!

Code: Select all

# swap channels so RGB become BGR and write to pnm
convert $filename.tmp.ras -separate  -reverse -combine $filename.tmp.pnm

See -reverse
http://www.imagemagick.org/Usage/basics/#reverse
An alternative is to use -swap 0,2 to swap the red and blue channel images.
See the blue rose in the combine examples of IM Examples
http://www.imagemagick.org/Usage/color_basics/#combine
This also explains about the unordered nature of the -channel setting

If your script is working it will be because "pnmtorast" is doing the channel swap as part of its operations.

[duboism]

You're probably right.

The following seems to work:

Code: Select all

convert 00000001.jpg -compress none 00000001.pnm
pnmtorast -standard 00000001.pnm > 00000001.ras


I have added the '-compress none' option just to check that I have 256 colors in the pnm because pnmtorast complains:

Code: Select all

pnmtorast: computing colormap...
pnmtorast: Too many colors - proceeding to write a 24-bit non-mapped
pnmtorast: rasterfile.  If you want 8 bits, try doing a 'ppmquant 256'


Playing a bit with identify shows that the JPEG image and the RAS have the same statistics (average pixel value, etc.) so I don't think it's important.