From: Daniel J S. <dan...@ie...> - 2005-12-30 02:31:35
Attachments:
test001jpeg.png
|
Ethan A Merritt wrote: > On Thursday 29 December 2005 12:30 pm, you wrote: > >>No doubt. However, cropping of images is such a useful thing that it >>could have it's special case in the gnuplot core. > > > It cannot be implemented in the core, because it is a terminal-specific > operation. E.g., how on earth would the core code know anything about > a particular pixel in an output png image? The core knows the overall dimension of the image, and I think that is all it would need to know. > Even more impossible is to > know about the "pixels" in an output PostScript file whose font > characteristics will only be determined by the eventual print device. Well, that is what I'm saying. Only if there is absolutely nothing except an image in the plot could one assume the cropped output resolution should match 1 to 1 the size of the image. Once there is anything else like a font, tic mark, axis, etc., this should no longer be assumed possible. PostScript does not have an output resolution like other formats such as PNG, JPEG and GIF. > > >>Well, JPEG is out. > > > Are you talking about mencoder here? No. I'm not that far yet. I'm just looking at the images created by gnuplot right now. See attached example JPEG converted to PNG. You should be able to see how the JPEG library creates images where individual pixels are spatially interpolated. In the particular application of interest, it must be one matrix element creates one image pixel. No spatial interpolation because that will confuse the interpretation of the data. You can see the issue here, unless the output is 20 x 20 exactly matching the image, there will be half pixels and so on so that not until 100 x 100 does the actual result start looking like a nice arrangement. It's fine if we are looking at one or two images, but I'm interested in 20 images per second on the order of minutes. Hence, efficient images are of interest to me. > > JPEG supports a loss-less mode. But yes, normally if you want > loss-less images you would pick a different format. > > Animation normally involves interpolation between frames, and saves > space by sending full "index" frames every Nth frame but intervening > update frames with only incremental or interpolated contents. > The ratio of full to partial/interpolated frames can be set at the > time you encode the animation. > Sounds like you want index frames only. That is definitely possible. Probably, but that is for the movie making software to deal with, as I understand. > A whole lot more people can easily view an embedded gif on a web > page than will take the time to install some fancy movie-player > just so they can afterwards download and look at your plot. Sure, but I'm thinking there are as many people who would like to generate a movie (not for a web page), angiography images, space images, etc. Then play it back in some viewer. > > >>Alright, let me look at generating movies with ImageMagick... > > > Wrong tool. > You really do want mencoder. Believe me. OK. I'm interested. Will investigate. > But you may have to build it from source to get a full range of > supported formats. Oh, it seems everything I need requires the source. The only thing up to date in Fedora, et al. is the compiler, whereas apps are months, if not years, old. Dan |
From: Daniel J S. <dan...@ie...> - 2006-01-01 13:13:25
|
(Ethan, please have a look at this as soon as you can. As I said, I'm a bit pressed for time. Also, there are two patches here: your original file updated to account for the changes you already added to CVS repository, and then my update... see the ChangeLog. It's hard enough keeping track of one patch.) Here's a resulting patch for the GIF animation modifications. Actually there are two patches; first animation_eam_1jan2006.patch must be applied. Then animation_djs_1jan2006.patch must be applied. I've added a demo. A new animation that spins the globe around. So there is an "animate2.dem" combining the concepts of animate.dem and world2.dem. I've also rewritten "animate.dem" and "gnuplot.rot" slightly, so that I could reuse gnuplot.rot. I've made it generic as follows: iteration_count=iteration_count+1 if ((!limit_iterations) || (iteration_count<=limit_iterations)) \ set view xview(xrot),zview(zrot); \ replot; \ zrot=(zrot+zrot_delta)%360; \ xrot=(xrot+xrot_delta)%360; \ reread You can imagine how this works. Just define all the variables and away we go. animate2.dem is essentially the same. (Very first figure might be different.) Anyway, I think you'll really like this new feature and demos. (I think they are great. Try "gthumb" on the GIF files.) Actually, it really isn't so much a new feature, just realizing how to utilize what we already have. Dan PS: Some comments: 1) The looping file mechanism in gnuplot.rot was actually one greater than the number of iterations specified because even the pass in which the test fails (and doesn't do a reread) does a plot. I fixed this. 2) [Ethan already replied to this with an alternative.] It would be nice if looping could be done without requiring two files. What might enable that is a special test or function saying how deep the "reread" is. For example, say I wanted to have the above example in a single file, it might be if (!load_depth()) \ <all the initial definitions> \ else \ iteration_count=iteration_count + 1 if () \ set view \ replot \ zrot= \ xrot= \ if () reread where load_depth() is just some pseudo function or variable that gnuplot makes available. 3) [Ethan replied to this too. See previous email.] Modulo (%) doesn't seem to work with negative numbers. Shouldn't it? 4) We've got to combine the layout and border behavior for 2D and 3D plots. In the demo I created, I had to make the GIF output resolution very large simply because otherwise all the image is used up by the borders and only a few pixels are left for the plot. I tried to kludge this by making the view scaling large, but then got: gnuplot: hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed. A more graceful failure would be nice in any case. 5) libgd is pretty smart. Check out this animation file where the internal image is shrunk after the first one because the outer pixels are the same: [root@local demo]# gifsicle ground_hog_day.gif -I * ground_hog_day.gif 72 images logical screen 200x200 global color table [128] background 0 loop forever + image #0 200x200 local color table [128] disposal asis delay 0.10s + image #1 191x165 at 5,11 local color table [128] disposal asis delay 0.10s ... |