kenb@clmqt.marquette.Mi.US (Ken Baynard) (09/17/90)
DumpToIff finally crashed after on me after several successful uses and apparently the reason had to do when I JOINed 2 raw files together. I had started a trace that had gotten to line 29 and 'someone' got to the keyboard and stopped it so I restared from line 29 using a different filename. After the trace was finished I joined the files and tried DumpToIff. It crashed with stacks of 300K and 500K and after that I figured it was'nt a stack problem. I went and converted both parts seperately and joined them with PhotonPaint and it looks great. If one could figure a way to eliminate the header of each joined file ($3f019001) then it may be able to go through unscathed.
a976@mindlink.UUCP (Ron Tarrant) (09/17/90)
> kenb@clmqt.marquette.Mi.US writes: > > Msg-ID: <1990Sep16.175637.16978@clmqt.marquette.Mi.US> > Posted: 16 Sep 90 17:56:37 GMT > > Person: Ken Baynard > > > DumpToIff finally crashed after on me after several successful > uses and apparently the reason had to do when I JOINed 2 raw files > together. I had started a trace that had gotten to line 29 and > 'someone' got to the keyboard and stopped it so I restared from > line 29 using a different filename. After the trace was finished I > joined the files and tried DumpToIff. It crashed with stacks of > 300K and 500K and after that I figured it was'nt a stack problem. > I went and converted both parts seperately and joined them with > PhotonPaint and it looks great. If one could figure a way to > eliminate the header of each joined file ($3f019001) then it > may be able to go through unscathed. If I remember correctly, the cods suggest an overlap of one scanline for joining two partial images together. This may be the source of your problem. -Ron Tarrant a976@Mindlink.UUCP
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/17/90)
In <3199@mindlink.UUCP>, a976@mindlink.UUCP (Ron Tarrant) writes: > >If I remember correctly, the cods suggest an overlap of one scanline for >joining two partial images together. This may be the source of your problem. Sure, but remember, cods are schooling fish, and they _would_ suggest an overlap. :-) -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jean@pogo.hasler (09/18/90)
In article <1990Sep16.175637.16978@clmqt.marquette.Mi.US> kenb@clmqt.marquette.Mi.US (Ken Baynard) writes: > >DumpToIff finally crashed after on me after several successful >.................. >............ It crashed with stacks of >300K and 500K and after that I figured it was'nt a stack problem. >........... I looked myself in the source code of DumpToIFF and there many printf("{error type}") followed by exit(). They often cause crashes probably because the Amiga functionalities are not cleaned properly before exiting (sometimes we are in display mode). The use of stderr could be a better idea. Another improvement (for 500 users especially) would be to have a mode without display. DumpToIFF seems now to work on my A500 1Mb but without workbench loaded and a stack of 20K. About DKBtrace I could now compiled it on a SUN. However it is still slow. Currently I am using an AT03 overnight. I will also try it on an IBM RT which is currently less loaded than our SUNs. I could manage to write a program to create a 'dis' file which is the output of DKB and the input of DumpToIFF. By reading the attached code you can understand the format of the file. Another way is to dump (od -b) the output file. I have started to play a little bit with the RGB colors. /* program to create a *.dis file */ #include <stdio.h> #include <malloc.h> int w, l; /* horizontal and vertical size */ char *mp; /* memory address of file */ main(argc,argv) int argc; char *argv[]; { long size, index; FILE *str; if (argc != 3) { printf("2 parameters required\n"); exit(-1); } w = atoi(argv[1]); l = atoi(argv[2]); if ( (w<1) || (l<1) ) { printf("'w' or 'l' alpha or smaller than 1 \n"); exit(-1); } size = 4 + 3*(w * l) + 2*l; printf("Size is %ld\n",size); if ((mp = malloc(size)) == NULL) { printf("Memory allocation problems\n"); exit(-1); } if ( (str = fopen("try.dis","w+")) == NULL) { printf("Open error\n"); exit(-1); } setgen(); /* set basic values in the file */ fwrite(mp, size, 1, str); } /* write colors at pixel x,y */ writec(x,y,colr,colg,colb) int x; /* horiz */ int y; /* verti */ unsigned colr; /* RGB Red */ unsigned colg; /* RGB Green */ unsigned colb; /* RGB Blue */ { char *addr; addr = mp + 4 + 2*y + 3*(w*(y-1) + x) - 3; *addr++ = colr; *addr++ = colg; *addr = colb; } setgen() /* set basic various para in dis file */ { char *addr; /* address */ unsigned char byt0; int byt1, i, j; addr = mp; /* set 4 fisrt bytes */ byt0 = w >> 8; /* 2nd byte w/256 */ *addr++ = w - (byt0 << 8); /* rest: w - (w/256)*256 */ *addr++ = byt0; byt0 = l >> 8; /* 2nd byte h/256 */ *addr++ = l - (byt0 << 8); /* rest: l - (h/256)*256 */ *addr++ = byt0; i = 3*w; /* 3 RGB bytes */ byt1 = 0; byt0 = 0; for (j=0; j<l; j++) { *addr++ = byt1++; *addr++ = byt0; if (byt1 == 256) { byt1 = 0; byt0++; } addr += i; } }
a976@mindlink.UUCP (Ron Tarrant) (09/19/90)
> a976@mindlink.UUCP writes: > > If I remember correctly, the cods suggest an overlap of one scanline for > joining two partial images together. This may be the source of your problem. > -Ron Tarrant > a976@Mindlink.UUCP Oops, the 'cods' had nothing to say to be truthful. It was the haddocks had the 'docs'.
dbuck@ccs.carleton.ca (Dave Buck) (09/19/90)
In article <1990Sep16.175637.16978@clmqt.marquette.Mi.US> kenb@clmqt.marquette.Mi.US (Ken Baynard) writes: > >DumpToIff finally crashed after on me after several successful >uses and apparently the reason had to do when I JOINed 2 raw files >together. Technically, the joining of two output files is not yet supported. > If one could figure a way to >eliminate the header of each joined file ($3f019001) then it >may be able to go through unscathed. This is true. In fact, all you have to do is delete the first four bytes from the second file and merge it onto the end of the first. DumpToIFF should read it fine. For all interested, here's the format of the DKBTrace output files: wwww hhhh - width and height 16 bits - LSB first llll - line number 16 bits LSB first rr rr rr rr rr ... - Red data for line. 8 bits each pixel gg gg gg gg gg ... - Green data for line. 8 bits each pixel bb bb bb bb bb ... - Blue data for line. 8 bits per pixel. ... - Next line. The color information for red, green and blue ranges from 0 (dark) to 255 (bright). Lines go from 0 to "height-1" from top to bottom and pixels go from left to right. David Buck dbuck@ccs.carleton.ca -- _____________________________________________________________________ | David Buck | My employer is not responsible for| | dbuck@ccs.carleton.ca | my opinions. I'm not even sure | | David_Buck@carleton.ca | I am. |
rusty@steelmill.cs.umd.edu (Rusty Haddock) (09/21/90)
In article <3228@mindlink.UUCP> a976@mindlink.UUCP (Ron Tarrant) writes: >> a976@mindlink.UUCP writes: >> >> If I remember correctly, the cods suggest an overlap of one scanline for >> joining two partial images together. This may be the source of your problem. > >Oops, the 'cods' had nothing to say to be truthful. It was the haddocks >had the 'docs'. WAS NOT! WAS NOT!!! It was probably them Crappies down the stream, er... street. -Rusty- -- Rusty Haddock DOMAIN: rusty@mimsy.cs.umd.edu Computer Science Department PATH: {uunet,rutgers}!mimsy!rusty University of Maryland "IBM sucks silicon!" College Park, Maryland 20742 -- PC Banana Jr,"Bloom County" -- Rusty Haddock DOMAIN: rusty@mimsy.cs.umd.edu Computer Science Department PATH: {uunet,rutgers}!mimsy!rusty University of Maryland "IBM sucks silicon!" College Park, Maryland 20742 -- PC Banana Jr,"Bloom County"