nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

448873_en-US

liliconcom

Double Precision and a Canny Filter

Follow-up to Multiple precision arithmetic with Python -- I decided not to go down that path; instead I'm using the fast double precision numbers and not going past 1e-13 or so. It is still slow, and gets very slow near the end, because the number of iterations goes up.

Time required for successive pictures goes up, slowly at first. Then it gets weird.Time required for successive pictures goes up, slowly at first. Then it gets weird.Time required for successive pictures goes up, slowly at first. Then it gets weird.Time required for successive pictures goes up, slowly at first. Then it gets weird.Time required for successive pictures goes up, slowly at first. Then it gets weird.

After a bit of studying, I realized the spikes in the time required were unrelated to the particular image, and directly a result of the machine doing another rendering process at the same time. Both images look very similar, the large black areas require the maximum number of iterations on each pixel.

~58K iterations for each pixel in the large black patch.~58K iterations for each pixel in the large black patch.~58K iterations for each pixel in the large black patch.~58K iterations for each pixel in the large black patch.~58K iterations for each pixel in the large black patch.

During those spikes, Blender was converting frames made by this JSL

nr = 384 / 2; nc = 384 / 2; bitmap = J( nr, nc, -Random Integer( 0, 255 * 255 * 255 ) ); New Window( "x", bb = Border Box( Text Box( "x" ) ) ); nn = 1e6; //pngdir = "F:/raindrops/png1/"; //Create Directory( pngdir ); While( nn-- > 0, For( i = 1, i <= 1, i += 1, img = New Image( bitmap ); img << setsize( {nc - 2, nr - 2} ); // use JMP's image processing to shrink array to the center x = (img << getpixels)[0, 0]; // then put the shrunken image back bitmap[2 :: nr - 1, 2 :: nc - 1] = x[1 :: nr - 2, 1 :: nc - 2]; // the add fresh noise around the edge bitmap[1, 0] = J( 1, nc, -Random Integer( 0, 255 * 255 * 255 ) ); bitmap[nr, 0] = J( 1, nc, -Random Integer( 0, 255 * 255 * 255 ) ); bitmap[0, 1] = J( nr, 1, -Random Integer( 0, 255 * 255 * 255 ) ); bitmap[0, nc] = J( nr, 1, -Random Integer( 0, 255 * 255 * 255 ) ); ); img << setsize( {1920 * 1, 1920 * 1} ); // stretch, a lot img << filter( "canny", // use the canny edge detector largeThreshold( .001 )/*tracing begins when a large-value edge is found*/, smallThreshold( .00001 )/*tracing stops when the edge value gets too small*/, radius( 3 )/*a blur-filter, use 0 for no blurring*/, Repeat( 3 )/* number of repeats of a box-blur; 3 approximates a gaussian-blur filter */ ); // img << saveimage( pngdir || Char( nn ) || ".png" ); If( Mod( nn, 1 ) == 0, imgS = New Image( img ); imgS << scale( .9 ); // keep it on screen by shrinking a bit (bb << child) << delete; // remove old content bb << append( imgS ); // add new content ); Wait( .1 ); );

into this video (which is...interesting...? Not nearly enough bandwidth for that much action.) I'm just using Blender's video sequence editor, not the 3D bits it is most famous for.

https://www.youtube.com/watch?v=RzlMcQiOXHA The Canny edge detector is pretty cool, but not what I want either. It looks like I might get to 9000; 175 to go. 6 more hours for the last 6 seconds?

Giving up, for now, on multiple precision numbers. What does this Canny filter have to do with spikes in a performance curve?

Comments

Quick Links