Horizontal artifacts in large image

Fellow Radiance users,

I recently completed a large image (1.4 GB .pic file, 16k
by 24k pixels), and it appears like there are two obvious
horizontal bands of incorrect values (one 30% from the top,
the other ~80% from the top). I pfilt'd the image down to
5% of it's original size to make the image below:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_1_tw.jpg

The commands that I ran were:

rpict -x 16000 -y 24000 -vta -vp 0.2 0.2 -0.01 -vd 0.454 0.891 -0.08
-vu 0 0 1 -vh 58.66667 -vv 88 -ab 1 -aa 0 -ad 16 -as 0 -dv -ds 0.1
-dj 1.0 -t 600 -o img10_1.pic real.oct

pfilt -1 -x /10 -y /10 -r 0.4 img10_1.pic > timg10_1_t.pic
pfilt -1 -e +3 -x /2 -y /2 timg10_1_t.pic | ra_ppm | cjpeg -q 95 > timg10_1_tw.jpg

Does anyone know where these artifacts originate, or how to
prevent them from appearing? I'm running the same image at
reduced resolution right now, but final print quality is
not going to be as I'd hoped.

Mark

Mark Stock wrote:

Fellow Radiance users,

I recently completed a large image (1.4 GB .pic file, 16k
by 24k pixels), and it appears like there are two obvious
horizontal bands of incorrect values (one 30% from the top,
the other ~80% from the top). I pfilt'd the image down to
5% of it's original size to make the image below:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_1_tw.jpg

Scary...

The commands that I ran were:

rpict -x 16000 -y 24000 -vta -vp 0.2 0.2 -0.01 -vd 0.454 0.891 -0.08
-vu 0 0 1 -vh 58.66667 -vv 88 -ab 1 -aa 0 -ad 16 -as 0 -dv -ds 0.1
-dj 1.0 -t 600 -o img10_1.pic real.oct

Looks like the simulation got killed and restarted at those points.
And since you're not using an ambient file, that will necessarily
produce discontinuities in the diffuse lighting before and after.

You appear to have plenty of disk space, so I'd recommend to
use an ambient file. You may want to play with the ambient
resolution as well if you do this, to keep the size of that
file under control.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Hi Mark,

Did you have to restart this rendering process? The artifacts don't _quite_ look like an ambient calculation restart. I have a competing theory, which is that a long integer is getting wrapped in the source testing code. This is really a bug, but I guess it hasn't shown up before because no one has testing a light source 2^31 times in a single run. Actually, maybe they have, but just never noticed the problem.

I'll work on a fix for this today, but obviously you're going to have to find another way to repair your image to meet your deadline. Sorry about that. I recommend using the -vl option to rpict and rerendering a portion of your image to cover up the problem areas using pcompos. Let me know if you need help on figuring these options out.

-Greg

···

From: Mark Stock <[email protected]>

Fellow Radiance users,

I recently completed a large image (1.4 GB .pic file, 16k
by 24k pixels), and it appears like there are two obvious
horizontal bands of incorrect values (one 30% from the top,
the other ~80% from the top). I pfilt'd the image down to
5% of it's original size to make the image below:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_1_tw.jpg

The commands that I ran were:

rpict -x 16000 -y 24000 -vta -vp 0.2 0.2 -0.01 -vd 0.454 0.891 -0.08
-vu 0 0 1 -vh 58.66667 -vv 88 -ab 1 -aa 0 -ad 16 -as 0 -dv -ds 0.1
-dj 1.0 -t 600 -o img10_1.pic real.oct

pfilt -1 -x /10 -y /10 -r 0.4 img10_1.pic > timg10_1_t.pic
pfilt -1 -e +3 -x /2 -y /2 timg10_1_t.pic | ra_ppm | cjpeg -q 95 > timg10_1_tw.jpg

Does anyone know where these artifacts originate, or how to
prevent them from appearing? I'm running the same image at
reduced resolution right now, but final print quality is
not going to be as I'd hoped.

Mark

The process ran straight through, with no pauses or restarts.

Another process (another third of the final image), which did
require a few restarts, is here:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_2_tw.jpg

This one contains the same horizontal bands, one at ~35% of the way
down, but a pair at about 85%.

But there's also a weird slightly-darker band 20% of the way down,
and on the center vertical tube.

I'm also noticing thin dark lines on some of the tubes. I marked
them in the following image:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_2_twm.jpg

Sorry about the long URLs. I'd move it to a more root-ward directory,
but stuff has been rendering constantly for 2+ weeks.

···

----
Georg writes:
You appear to have plenty of disk space, so I'd recommend to
use an ambient file. You may want to play with the ambient
resolution as well if you do this, to keep the size of that
file under control.
----

That's the way I would have done it in the first place, but
once the scene and the ambient file got up to 1.3 GB in RAM
(where I have only 1 GB), it started to thrash, and I'd only
made it to the 4k x 2k version by then. Plus, there were
still splotches from the not-completely-resolved ambient
distribution. Ultimately, with -aa 0, I get a smoother final
rendering, at the cost of a more speckled pre-filtered
rendering.

I'm trying a lower-resolution run right now. Thanks for
the input.

Mark

On Tue, 24 Jun 2003, Greg Ward wrote:

Did you have to restart this rendering process? The artifacts don't
_quite_ look like an ambient calculation restart. I have a competing
theory, which is that a long integer is getting wrapped in the source
testing code. This is really a bug, but I guess it hasn't shown up
before because no one has testing a light source 2^31 times in a single
run. Actually, maybe they have, but just never noticed the problem.

I'll work on a fix for this today, but obviously you're going to have
to find another way to repair your image to meet your deadline. Sorry
about that. I recommend using the -vl option to rpict and rerendering
a portion of your image to cover up the problem areas using pcompos.
Let me know if you need help on figuring these options out.

-Greg

> From: Mark Stock <[email protected]>
>
> Fellow Radiance users,
>
> I recently completed a large image (1.4 GB .pic file, 16k
> by 24k pixels), and it appears like there are two obvious
> horizontal bands of incorrect values (one 30% from the top,
> the other ~80% from the top). I pfilt'd the image down to
> 5% of it's original size to make the image below:
>
> http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/
> timg10_1_tw.jpg
>
> The commands that I ran were:
>
> rpict -x 16000 -y 24000 -vta -vp 0.2 0.2 -0.01 -vd 0.454 0.891 -0.08
> -vu 0 0 1 -vh 58.66667 -vv 88 -ab 1 -aa 0 -ad 16 -as 0 -dv -ds 0.1
> -dj 1.0 -t 600 -o img10_1.pic real.oct
>
> pfilt -1 -x /10 -y /10 -r 0.4 img10_1.pic > timg10_1_t.pic
> pfilt -1 -e +3 -x /2 -y /2 timg10_1_t.pic | ra_ppm | cjpeg -q 95 >
> timg10_1_tw.jpg
>
> Does anyone know where these artifacts originate, or how to
> prevent them from appearing? I'm running the same image at
> reduced resolution right now, but final print quality is
> not going to be as I'd hoped.
>
> Mark

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Mark,

Assuming it's the long integer wrapping as I suspect, you should download top-of-trunk and recompile to see if this is fixed. Go to www.radiance-online.org and click on the "download Radiance" link under software. Then, grab the "current experimental/bug-fixed version" called radiance-HEAD.tgz. Rerun "rmake install" in src/common and src/rt and that should update rpict, rtrace, and rview.

-Greg

···

From: Mark Stock <[email protected]>

The process ran straight through, with no pauses or restarts.

Another process (another third of the final image), which did
require a few restarts, is here:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_2_tw.jpg

This one contains the same horizontal bands, one at ~35% of the way
down, but a pair at about 85%.

But there's also a weird slightly-darker band 20% of the way down,
and on the center vertical tube.

I'm also noticing thin dark lines on some of the tubes. I marked
them in the following image:

http://mark.technolope.org/image/p21c_fish_take_3/redo_smooth_6/timg10_2_twm.jpg

Sorry about the long URLs. I'd move it to a more root-ward directory,
but stuff has been rendering constantly for 2+ weeks.

Just got around to this today. in src/common I get:

gcc -Dlinux -L/usr/X11R6/lib -I/usr/include/X11 -DNOSTEREO -DBIGMEM -DMC
-O2 -DSPEED=200 -O3 -march=i686 -malign-double -mno-ieee-fp -ffast-math
-fomit-frame-pointer -fstrict-aliasing -c -o header.o header.c
In file included from header.c:28:
resolu.h:64: parse error before `*'
resolu.h:66: parse error before `t'
make: *** [header.o] Error 1

Those lines are:
extern int dateval(time_t *t, char *s);
and
extern void fputdate(time_t t, FILE *fp);

And in src/rt:

gcc -I../common -L../lib -O2 -DSPEED=200 -O3 -march=i686 -malign-double
-mno-ieee-fp -ffast-math -fomit-frame-pointer -fstrict-aliasing -Dlinux
-L/usr/X11R6/lib -I/usr/include/X11 -DNOSTEREO -DBIGMEM -DMC -DNICE=4 -c
rtmain.c
In file included from rtmain.c:17:
../common/random.h:70: parse error before `int'
make: *** [rtmain.o] Error 1

This also reminds me: does anyone regularly use true random Monte-
Carlo sampling with the -DMC compile flag? I have traditionally had
to make changes in the common/random.h file to get that to build
under current gcc versions---as I did when 3R5 came out.

Mark

···

On Wed, 25 Jun 2003, Greg Ward wrote:

Assuming it's the long integer wrapping as I suspect, you should
download top-of-trunk and recompile to see if this is fixed. Go to
www.radiance-online.org and click on the "download Radiance" link under
software. Then, grab the "current experimental/bug-fixed version"
called radiance-HEAD.tgz. Rerun "rmake install" in src/common and
src/rt and that should update rpict, rtrace, and rview.

Mark Stock wrote:

Just got around to this today. in src/common I get:

gcc -Dlinux -L/usr/X11R6/lib -I/usr/include/X11 -DNOSTEREO -DBIGMEM -DMC
-O2 -DSPEED=200 -O3 -march=i686 -malign-double -mno-ieee-fp -ffast-math
-fomit-frame-pointer -fstrict-aliasing -c -o header.o header.c
In file included from header.c:28:
resolu.h:64: parse error before `*'
resolu.h:66: parse error before `t'
make: *** [header.o] Error 1

Those lines are:
extern int dateval(time_t *t, char *s);
and
extern void fputdate(time_t t, FILE *fp);

Two alternative solutions:

- Change header.c so that the system headers get included before
  resolu.h.

- #include <time.h> at the top of resolu.h (and <string.h> as
  well, while you're at it).

Can't say anything about the random stuff.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Hi Mark,

From: Mark Stock <[email protected]>

Just got around to this today. in src/common I get:

gcc -Dlinux -L/usr/X11R6/lib -I/usr/include/X11 -DNOSTEREO -DBIGMEM -DMC
-O2 -DSPEED=200 -O3 -march=i686 -malign-double -mno-ieee-fp -ffast-math
-fomit-frame-pointer -fstrict-aliasing -c -o header.o header.c
In file included from header.c:28:
resolu.h:64: parse error before `*'
resolu.h:66: parse error before `t'
make: *** [header.o] Error 1

Those lines are:
extern int dateval(time_t *t, char *s);
and
extern void fputdate(time_t t, FILE *fp);

I decided against including resolu.h in header.c, and the latest source check-ins reflect this already. Download it again.

And in src/rt:

gcc -I../common -L../lib -O2 -DSPEED=200 -O3 -march=i686 -malign-double
-mno-ieee-fp -ffast-math -fomit-frame-pointer -fstrict-aliasing -Dlinux
-L/usr/X11R6/lib -I/usr/include/X11 -DNOSTEREO -DBIGMEM -DMC -DNICE=4 -c
rtmain.c
In file included from rtmain.c:17:
../common/random.h:70: parse error before `int'
make: *** [rtmain.o] Error 1

This also reminds me: does anyone regularly use true random Monte-
Carlo sampling with the -DMC compile flag? I have traditionally had
to make changes in the common/random.h file to get that to build
under current gcc versions---as I did when 3R5 came out.

Thanks for pointing this out -- it should be fixed, now.

-Greg

P.S. Radiance-dev is probably a better place for this discussion, if you wish to share it any further. I doubt there are many on this list compiling from top-of-trunk.