On the other hand I'm at a loss to explain why the "record=(a,b)" variant even cares what a and b are. I'll apply your patch because it's obvious that the two adjacent code sections handling "record=(a,b)" and "array=(a,b)" disagree with each other about the interpretation of a and b. On Nov 3, 2016, at 12:40 AM, Ethan Merritt wrote: (For fully arbitrary image distortions with Gnuplot one currently has to go to a 3-D plot with the viewpoint looking down from above.) (I spent a long time implementing arbitrary resampling for PDL - it’s a bear to get right). That’s a useful hack, even though it means you can’t input an arbitrarily-distorted image: most of the time linear transformations are enough and truly arbitrary distortions are something like 1,000 times slower. Then the rest of the rendering code treats the record matrix as some kind of implicit array matrix: it ignores the ordinate values and calculates them using that linear transformation. The code looks at the coordinates of the origin, the lower-right point, and the upper-left point, and uses that to create a linear transformation converting between pixel location in the matrix and dataspace location to be rendered. What’s going on is that the image plotting code doesn’t just place pixels in random locations - for speed it assumes they’re supposed to be a uniform grid in data space. The image plotting methods are, I think, the only 2-D ones where the shape matters. But “with lines” in 3-D plots a grid connecting the data points, so getting the order wrong would give you a few stray lines here and there. In “with points” plots, it really doesn’t matter - the points get plotted in a different order if you get the matrix shape wrong, but they look the same in the end. The issue is that the relative locations of the points in the record array matter for some plot styles. To unsubscribe from further messages, please visit Sent from because you indicated interest in I attach sample output and a datafile that reproduce the problem, along with the script below. This occurs for many output terminals - I have tested with pngcairo, png, x11, wxt, and pdfcairo. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. The "record" treatment of binary image data yields incorrect plotting. Error in Image Rendering With Specified Axis ValuesĬreated: Tue 05:23 PM UTC by Craig DeForest On Nov 1, 2016, at 11:23 AM, Craig DeForest wrote: cart_dim įPRINTF((stderr,"datafile.c:%d record dimensions %d x %d\n", LINE,ĭf_xpixels = df_bin_record.cart_dim ĭf_ypixels = df_bin_record.cart_dim That yielded strange duplicates and skewed copies of the image. But "with image" uses a shortcut of calculating a single Jacobian matrix for the transform (assuming the image-coord -> pixel-coord transformation is linear). This would not be a problem if each pixel were being individually read and parsed by the "with image" code, since each pixel would then be individually placed. The problem was that the "record" specifier was causing (e.g.) a 200x400 array to be read as if it were a 400x200 array. Gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image Gnuplot> set title "X index is as expected" Gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image Gnuplot> set title "Record processing (explicit index) is bad" Gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image Gnuplot> set title "Array processing (implicit index) is OK" Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 ' Gnuplot> set terminal pngcairo size 800,800 Immediate help: type "help" (plot window: hit 'h') Thomas Williams, Colin Kelley and many others
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |