Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 13 November 2005 01:36 am, Daniel J Sebald wrote:
> 
>>Attached is a patch for AVS format (*.avs *.x).  
> 
> 
> Very nice.  
> With some minor tweaking, I think this should go into cvs.
> 
> 
>>Here are some sample commands:
>>
>>set datafile binary filetype=auto
>>plot "mandrill.x" binary with rgbimage
> 
> 
> Or in my case
>   set datafile binary filetype=avs
>   plot "< convert ~/images/photo.jpeg avs:-" binary with rgbimage
> 
> That works.  But these variants don't:
>   set datafile binary filetype=avs
>   set style data rgbimage
>   plot "< convert ~/images/photo.jpeg avs:-" with rgbimage
>          warning: Skipping data file with no valid points
>          x range is invalid
>   plot "< convert ~/images/photo.jpeg avs:-" binary
>         Read grid of zero width
> 
> I don't think these failures have anything to do with the patch,
> however.  I think the binary and rgbimage modes are not correctly
> picked up from the default style in any case.

OK, these are the problems I was running into and concluded there is some bug floating around here.  Thanks.  I'll look into it.

> Unfortunately, AVS format does not guarantee any particular byte order.

Actually, according to this:

http://astronomy.swin.edu.au/~pbourke/dataformats/avs_x/

"the format assumes a byte ordering as per SGI/MACIINTOSH/Motorola processors"

> You normally get whatever byte order is native to the machine the image
> was created on.  Therefore any application that reads AVS images should
> check for sanity of the xwidth and ywidth values at the head of the file,
> and try a different byte ordering if they are absurd.

So, I think this is covered by the following two lines in the patch:

+    df_bin_file_endianess = DF_BIG_ENDIAN;
+    read_order = byte_read_order(df_bin_file_endianess);

The first line indicates that the file is big endian (Mac/SGI/Motorola) by definition and the next line determines what type of swapping (if any) is needed based upon the computer's endianess.  Then after reading in the xwidth/ywidth there is

+    df_swap_bytes_by_endianess((char *) &M, read_order, 4);
+    df_swap_bytes_by_endianess((char *) &N, read_order, 4);

which swaps according to little/big/middle endian if the format doesn't match that of the CPU.

Dan