[Help] Problem with ximage in 7.3.2

Hello all,

Very long time ago I'd compiled Radiance 3.1.11 on my SGI Indigo2 [IRIX
6.5.22, MipsPro 7.3.2] and it did run fine - but then I forgot about it.

Just recently, however, I recompiled 3.1.11 on my new SGI Fuel [IRIX
6.5.28,
MipsPro 7.4.4, V12] and everything worked as before.

So, I decided to upgrade to Radiance 3.7.2 on my Fuel [same OS & same
compiler
as above]. It compiled ok, but <ximage> seems now somehow to be broken -
all
my pictures (ok under 3.1.11 on my Fuel) are completly wrong color-wise
and
look almost like as if produced via fractint :-).

I feel something with the colortable routines is amiss, but I've no
idea what it could be [I tried different values for DSPEED - but no
success;
also changing the value of <set special> in <makeall> from "ogl" to
"tiff" to
"sgi" didn't help any].

BTW, if I convert the pics with ra_tiff and view them [on my Fuel with
vstiff],
they are ok.

Your hints are certainly appreciated.

Thanks in advance.
/oskar

DISCLAIMER

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to which they are addressed and may be legally privileged and/or confidential. Any unauthorized use, disclosure or copying of this e-mail or any of its attachment(s) by unintended recipient may be unlawful and is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail and permanently delete the original e-mail and attachment(s) from your computer system.

Any opinions contained in this message are those of the author and are not given or endorsed by OPEC, unless otherwise clearly indicated in the message, and the authority of the author to so bind OPEC is duly verified. OPEC does not warrant or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained in the e-mail content transmitted over the Internet.

Thank you for your cooperation.

Hi Oskar,

I have not had any other reports of any problems with the latest version of ximage in 8-bit mode, but it's difficult to find hardware these days that even supports 8-bit color lookups. There may well be a bug, but I can't find it if I can't find hardware on which to reproduce the problem.

Maybe you can just continue to use the old binary for ximage, if that's working. I can see no reason why not to -- it isn't as if the Radiance picture format has changed in any incompatible way.

-Greg

···

From: "Itzinger, Oskar" <[email protected]>
Date: May 15, 2006 12:30:03 AM PDT

Hello all,

Very long time ago I'd compiled Radiance 3.1.11 on my SGI Indigo2 [IRIX
6.5.22, MipsPro 7.3.2] and it did run fine - but then I forgot about it.

Just recently, however, I recompiled 3.1.11 on my new SGI Fuel [IRIX 6.5.28,
MipsPro 7.4.4, V12] and everything worked as before.

So, I decided to upgrade to Radiance 3.7.2 on my Fuel [same OS & same compiler
as above]. It compiled ok, but <ximage> seems now somehow to be broken - all
my pictures (ok under 3.1.11 on my Fuel) are completly wrong color-wise and
look almost like as if produced via fractint :-).

I feel something with the colortable routines is amiss, but I've no
idea what it could be [I tried different values for DSPEED - but no success;
also changing the value of <set special> in <makeall> from "ogl" to "tiff" to
"sgi" didn't help any].

BTW, if I convert the pics with ra_tiff and view them [on my Fuel with vstiff],
they are ok.

Your hints are certainly appreciated.

Thanks in advance.
/oskar

regarding Re: [Radiance-general] [Help] Problem with ximage in 7.3.2:

I have not had any other reports of any problems with the latest
version of ximage in 8-bit mode, but it's difficult to find hardware
these days that even supports 8-bit color lookups. There may well be
a bug, but I can't find it if I can't find hardware on which to
reproduce the problem.

ximage works on 8-bit displays with no problems.

The OpenGL programs don't, eg:

$ glrad asd.rif
fatal - no suitable visuals available
...

James.

···

On 15/05/06, 17:07:52, Gregory "J." Ward <[email protected]> wrote

James,

hmm, while I apparently don't have "asd.rif" [can't find it in 3.7.2],
the
following works quite ok on my SGI Fuel [Irix 6.5.28/MipsPro 7.4.4/V12]:

IRIS 9 $ cd /disk03/mephisto/source/radiance_3.7.2/obj/misc
IRIS 10 $ /disk03/mephisto/source/radiance_3.7.2/bin/glrad daf.rif
        oconv daf.rad > daf.oct
X connection to :0.0 broken (explicit kill or server shutdown).

...and I indeed get a daffodil rendered!

/oskar

Message: 1
Date: Wed, 17 May 2006 10:39:57 GMT
From: James Lee <[email protected]>
Subject: Re: [Radiance-general] [Help] Problem with ximage in 7.3.2
To: Radiance general discussion <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

regarding Re: [Radiance-general] [Help] Problem with ximage in 7.3.2:

> I have not had any other reports of any problems with the latest
> version of ximage in 8-bit mode, but it's difficult to find hardware
> these days that even supports 8-bit color lookups. There
may well be
> a bug, but I can't find it if I can't find hardware on which to
> reproduce the problem.

ximage works on 8-bit displays with no problems.

The OpenGL programs don't, eg:

$ glrad asd.rif
fatal - no suitable visuals available
...

James.

DISCLAIMER

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to which they are addressed and may be legally privileged and/or confidential. Any unauthorized use, disclosure or copying of this e-mail or any of its attachment(s) by unintended recipient may be unlawful and is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail and permanently delete the original e-mail and attachment(s) from your computer system.

Any opinions contained in this message are those of the author and are not given or endorsed by OPEC, unless otherwise clearly indicated in the message, and the authority of the author to so bind OPEC is duly verified. OPEC does not warrant or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained in the e-mail content transmitted over the Internet.

Thank you for your cooperation.

···

On 15/05/06, 17:07:52, Gregory "J." Ward > <[email protected]> wrote

Greg,

thanks for your reply - as I have no reservations using the 3.1.11
ximage on
pics created with 3.7.2, that's fine for me.

However, although in my original post I'd reported that compilaton of
3.7.2
on my SGI FUEL under IRIX 6.5.28/MipsPro 7.4.4/V12 works "ok" [since I'd
only
looked at the tail of the file into which I'd re-directed the output
from
<makeall install> and I'd read 'Done.' there, I'd not bothered further
to wade
thru all messages], upon closer inspection I did indeed find a few
entries
worth of comments - please bear with me for the nonce. First, here is my

rmake command:

#!/bin/sh
exec make "SPECIAL=ogl" \
  "OPT=-O2 -DSPEED=200" \
  "MACH=-w" \
  ARCH=sgi "COMPAT=strcmp.o" \
  INSTDIR=/disk03/mephisto/source/radiance_3.7.2/bin \
  LIBDIR=/disk03/mephisto/source/radiance_3.7.2/lib \
  ESUFFIX= \
   "$@" -f Rmakefile

Since 'New rmake command -- running "makeall clean"...', that's what is
executed initially. Then:

1. In directory px...
  rm -f [...]
  cd tiff; make distclean
don't know how to make distclean (bu42).
*** Error code 1 (bu21)

Right now it escapes me why this doesn't work, as <Makefile> in tiff
"does"
have a target "distclean" indeed.

2. There are a number of

sh: ranlib: not found
*** Error code 127 (bu21) (ignored)

as IRIX doesn't have/need ranlib at all.

3. More seriously, however,

In directory hd...
cc-1020 cc: ERROR File = rhd_ogl.c, Line = 367
  The identifier "d" is undefined.

    d = eyesepdist / sqrt(nv->hn2);
    ^

1 error detected in the compilation of "rhd_ogl.c".
*** Error code 2 (bu21)

So I wonder why compilaton hasn't just stopped there in the first
place???

4. Although I've quite rarely seen a package which produces almost no
warnings
[Radiance is a very satisfactory exception - applause to you!!!], I do
get a
whole bunch of them when

In directory px...
  cd ../libtiff ; make install

While you seem to use tiff-3.7.3 in Radiance 3.7.2, I've gotten most of
these
warnings also when I compiled the stand-alone tiff-3.8.2 before - so, I
can
live with them [and I don't blame you at all there :-)]. On the other
hand,
though, I see

Libtiff is now configured for mips-sgi-irix6.5

  Installation directory: /usr/local

although libtiff is indeed later installed in src/lib as wanted...

5. BTW, upon installation of Radiance 3.7.2, I get a directory

<...>/test/test data/

[note the blank in the dir name], and I can't access files in there at
all:

IRIS 121 $ cd /disk03/mephisto/source/radiance_3.7.2/test/test data
ksh: /disk03/mephisto/source/radiance_3.7.2/test/test: not found

OK, I'd run <makeall clean> - this time I got no error (!) with

In directory px...
  rm -f [...]
  cd tiff; make distclean

[although .o/.lo are not cleaned out in tiff/libtiff at all - I deleted
them
manually], but I got a new error:

Making distclean in man
make: file `Makefile' line 292: Syntax error
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)

which I didn't have when compiling the stand-alone tiff-3.8.2.

Anyway, prompted by 3) above, in <...>/src//hd/rhd_ogl.c, I added

326a327

        double d;

[guessed from similiar usages of d in the same .c], and this error went
upon
a fresh <makeall install>.

However, as my original ximage problem was still there, I installed
3.7.2 also
on my SGI INDIGO2 [IRIX 6.5.22/MipsPro 7.4.2/GR2] and afterwards the
3.7.2
ximage worked on it fine! So, I copied the 3.7.2 ximage as generated on
the
INDIGO2 to the FUEL - but I got only the original problem again. Then I
copied the 3.7.2 image as generated on the FUEL to the INDIGO2 but
understandibly it didn't run there at all:

ksh: ximage: Program not supported by architecture

So, my conclusions are:

1. There is something wrong on my FUEL, or

2. Radiance 3.7.2 doesn't work properly anymore on the FUEL [to repeat:
   ximage after recompilation of 3.1.11 on the FUEL works quite well
there]...

Presently, I'm just stuck...

Anyhow, thanks for wading thru this long post...

/oskar

Date: Mon, 15 May 2006 09:07:52 -0700
From: "Gregory J. Ward" <[email protected]>
Subject: Re: [Radiance-general] [Help] Problem with ximage in 7.3.2
To: Radiance general discussion <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi Oskar,

I have not had any other reports of any problems with the latest
version of ximage in 8-bit mode, but it's difficult to find hardware
these days that even supports 8-bit color lookups. There may
well be
a bug, but I can't find it if I can't find hardware on which to
reproduce the problem.

Maybe you can just continue to use the old binary for ximage, if
that's working. I can see no reason why not to -- it isn't
as if the
Radiance picture format has changed in any incompatible way.

-Greg

> From: "Itzinger, Oskar" <[email protected]>
> Date: May 15, 2006 12:30:03 AM PDT
>
> Hello all,
>
> Very long time ago I'd compiled Radiance 3.1.11 on my SGI Indigo2
> [IRIX
> 6.5.22, MipsPro 7.3.2] and it did run fine - but then I forgot
> about it.
>
> Just recently, however, I recompiled 3.1.11 on my new SGI Fuel
> [IRIX 6.5.28,
> MipsPro 7.4.4, V12] and everything worked as before.
>
> So, I decided to upgrade to Radiance 3.7.2 on my Fuel [same OS &
> same compiler
> as above]. It compiled ok, but <ximage> seems now somehow to be
> broken - all
> my pictures (ok under 3.1.11 on my Fuel) are completly wrong color-
> wise and
> look almost like as if produced via fractint :-).
>
> I feel something with the colortable routines is amiss, but I've no
> idea what it could be [I tried different values for DSPEED
- but no
> success;
> also changing the value of <set special> in <makeall> from
"ogl" to
> "tiff" to
> "sgi" didn't help any].
>
> BTW, if I convert the pics with ra_tiff and view them [on my Fuel
> with vstiff],
> they are ok.
>
> Your hints are certainly appreciated.
>
> Thanks in advance.
> /oskar
>

DISCLAIMER

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to which they are addressed and may be legally privileged and/or confidential. Any unauthorized use, disclosure or copying of this e-mail or any of its attachment(s) by unintended recipient may be unlawful and is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail and permanently delete the original e-mail and attachment(s) from your computer system.

Any opinions contained in this message are those of the author and are not given or endorsed by OPEC, unless otherwise clearly indicated in the message, and the authority of the author to so bind OPEC is duly verified. OPEC does not warrant or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained in the e-mail content transmitted over the Internet.

Thank you for your cooperation.

Hi Oskar,

The formatting of your post is rather messed up, but I'll try to reply in-line:

thanks for your reply - as I have no reservations using the 3.1.11
ximage on pics created with 3.7.2, that's fine for me.

However, although in my original post I'd reported that compilaton
of 3.7.2 on my SGI FUEL under IRIX 6.5.28/MipsPro 7.4.4/V12 works
"ok" [since I'd only looked at the tail of the file into which I'd
re-directed the output from <makeall install> and I'd read 'Done.'

Radiance compiles with the rmake -k option, which means that compilation continues even when errors are encountered. You can take this off in the makeall script if you like.

there, I'd not bothered further to wade thru all messages], upon
closer inspection I did indeed find a few entries worth of comments
- please bear with me for the nonce. First, here is my rmake command:

...

1. In directory px...
  rm -f [...]
  cd tiff; make distclean
don't know how to make distclean (bu42).
*** Error code 1 (bu21)

Right now it escapes me why this doesn't work, as <Makefile> in tiff
"does" have a target "distclean" indeed.

I've seen this problem before, but I don't know where it comes from. I suspect that the latest TIFF library is using some non-standard features of make that aren't supported on your system. Not much I can do to fix it because I don't understand the build on libtiff at all.

2. There are a number of

sh: ranlib: not found
*** Error code 127 (bu21) (ignored)

as IRIX doesn't have/need ranlib at all.

This should be no cause for concern.

3. More seriously, however,

In directory hd...
cc-1020 cc: ERROR File = rhd_ogl.c, Line = 367
  The identifier "d" is undefined.

    d = eyesepdist / sqrt(nv->hn2);
    ^

1 error detected in the compilation of "rhd_ogl.c".
*** Error code 2 (bu21)

So I wonder why compilaton hasn't just stopped there in the first
place???

The compilation continued because of the -k option, as mentioned above. This is a bug introduced some years ago no doubt in one of Georg Mischler's code clean-ups. Almost no one uses -DSTEREO, which is why it wasn't noticed before. Just add a "double d;" declaration at the top of the routine and it should be OK. Let me know if you run across anything else -- I've checked in a fix for the next release.

4. Although I've quite rarely seen a package which produces almost
no warnings [Radiance is a very satisfactory exception - applause
to you!!!],

Actually, you have Georg to thank for that. I used to just ignore warnings, which accumulated over the years as C compilers got more and more finicky. Schorsch went in and fixed most of them.

I do get a whole bunch of them when

In directory px...
        cd ../libtiff ; make install

While you seem to use tiff-3.7.3 in Radiance 3.7.2, I've gotten
most of these warnings also when I compiled the stand-alone tiff-3.8.2
before - so, I can live with them [and I don't blame you at all
there :-)]. On the other hand, though, I see

Libtiff is now configured for mips-sgi-irix6.5

  Installation directory: /usr/local

although libtiff is indeed later installed in src/lib as wanted...

Like I said, I don't understand libtiff compilation, and I just struggle to get it to do anything reasonable at all.

5. BTW, upon installation of Radiance 3.7.2, I get a directory

<...>/test/test data/

[note the blank in the dir name], and I can't access files in there at all:

IRIS 121 $ cd /disk03/mephisto/source/radiance_3.7.2/test/test data
ksh: /disk03/mephisto/source/radiance_3.7.2/test/test: not found

This is part of Georg's test suite, which is another thing I don't understand. I think he has the spaces in there for a reason, but I don't recall what it was.

OK, I'd run <makeall clean> - this time I got no error (!) with

In directory px...
  rm -f [...]
  cd tiff; make distclean

[although .o/.lo are not cleaned out in tiff/libtiff at all - I deleted
them
manually], but I got a new error:

Making distclean in man
make: file `Makefile' line 292: Syntax error
*** Error code 1 (bu21)

which I didn't have when compiling the stand-alone tiff-3.8.2.

Libtiff again. Dunno. Dunno. Dunno.

Anyway, prompted by 3) above, in <...>/src//hd/rhd_ogl.c, I added

326a327

        double d;

[guessed from similiar usages of d in the same .c], and this error went
upon a fresh <makeall install>.

Yeah, that's the right thing to do -- didn't read this far before my response.

However, as my original ximage problem was still there, I installed
3.7.2 also on my SGI INDIGO2 [IRIX 6.5.22/MipsPro 7.4.2/GR2] and
afterwards the 3.7.2 ximage worked on it fine! So, I copied the
3.7.2 ximage as generated on the INDIGO2 to the FUEL - but I got
only the original problem again. Then I copied the 3.7.2 image as
generated on the FUEL to the INDIGO2 but understandibly it didn't
run there at all:

ksh: ximage: Program not supported by architecture

So, my conclusions are:

1. There is something wrong on my FUEL, or

2. Radiance 3.7.2 doesn't work properly anymore on the FUEL [to repeat:
   ximage after recompilation of 3.1.11 on the FUEL works quite well there]...

I wish I could follow what you just said. What do you get if you cd to ray/src/px and just run "rmake ximage" there?

-Greg

Greg,

sorry if I sounded too complicated. What I meant is simply:

I have two machines,

A. SGI INDIGO2, IRIX 6.5.22, MipsPro 7.4.2 compiler, "Extreme"
   graphics

B. SGI FUEL, IRIX 6.5.28, MipsPro 7.4.4 compiler, "VPro12"
   graphics

Now, after re-compilation on A and B respectively, I have on

A. Radiance 3.1.11: ximage displays pics *ok" color-wise
   Radiance 3.7.2: ximage displays pics *ok* color-wise

B: Radiance 3.1.11: ximage displays pics *ok* color-wise
   Radiance 3.7.2: ximage displays pics *wrongly* color-wise

Perhaps something in the way X visuals are selected changed from
3.1 to 3.7 [my default on B is an 8-bit PseudoColor visual - but
I could alter that to something else if necessary].

Maybe it helps if I recompile 3.7.2 on B with -DDEBUG to see
which visuals are recognized and which one is finally selected in
x11image.c?

BTW, running "rmake ximage" in ray/sr/px didn't change any...

Thanks.
/oskar

Date: Tue, 23 May 2006 06:20:20 -0700
From: "Gregory J. Ward" <[email protected]>
Subject: Re: [Radiance-general] [Help] Problem with ximage in 7.3.2
To: Radiance general discussion <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

> However, as my original ximage problem was still there
> [skip]

I wish I could follow what you just said. What do you get if you cd
to ray/src/px and just run "rmake ximage" there?

DISCLAIMER

This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to which they are addressed and may be legally privileged and/or confidential. Any unauthorized use, disclosure or copying of this e-mail or any of its attachment(s) by unintended recipient may be unlawful and is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail and permanently delete the original e-mail and attachment(s) from your computer system.

Any opinions contained in this message are those of the author and are not given or endorsed by OPEC, unless otherwise clearly indicated in the message, and the authority of the author to so bind OPEC is duly verified. OPEC does not warrant or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained in the e-mail content transmitted over the Internet.

Thank you for your cooperation.

Hi Oskar,

I'm moving this to the Radiance development list, since it is a code issue that's of limited use to others. Please respond there rather than replying to this. (You will need to subscribe first if you aren't already on that list at <http://www.radiance-online.org/mailman/listinfo/radiance-dev>.)

Definitely run both versions of ximage on both machines after compiling with -DDEBUG, because the visual selection code changed considerably between 3.1.11 and 3.7.2. It seems the color table code also changed, though, and the problem might be there.

-Greg

···

From: "Itzinger, Oskar" <[email protected]>
Date: May 24, 2006 3:12:55 AM PDT

Greg,

sorry if I sounded too complicated. What I meant is simply:

I have two machines,

A. SGI INDIGO2, IRIX 6.5.22, MipsPro 7.4.2 compiler, "Extreme"
   graphics

B. SGI FUEL, IRIX 6.5.28, MipsPro 7.4.4 compiler, "VPro12"
   graphics

Now, after re-compilation on A and B respectively, I have on

A. Radiance 3.1.11: ximage displays pics *ok" color-wise
   Radiance 3.7.2: ximage displays pics *ok* color-wise

B: Radiance 3.1.11: ximage displays pics *ok* color-wise
   Radiance 3.7.2: ximage displays pics *wrongly* color-wise

Perhaps something in the way X visuals are selected changed from
3.1 to 3.7 [my default on B is an 8-bit PseudoColor visual - but
I could alter that to something else if necessary].

Maybe it helps if I recompile 3.7.2 on B with -DDEBUG to see
which visuals are recognized and which one is finally selected in
x11image.c?

BTW, running "rmake ximage" in ray/sr/px didn't change any...

Thanks.
/oskar