The collected works of markwend

Hey - let me chime in and say that I think that the djv suite is really a really useful tool. I've worked for a long time in professional film graphics, and this is by far the most useful and professional playback tool I've found in the public domain.

Running the latest prerelease under gutsy gibbon kubuntu. Works great so far.

One request: I write a lot of imaging code and rerender to the same output file. I display an image in djv_view, and then hit 'reload' whenever I rewrite the image. It would be GREAT if you kept the previous image in a temporary buffer, and have a 'toggle previous/current' key so that you can see what the change was. Right now, 'reload image' just reloads, but you can't see what the previous image was any more. With the toggle, you can go back and forth to really study any subtle changes that happen to the image.

Thanks!

Looking forward to testing the new Frame Store feature, but since I run on a linux (Kubuntu 7.10 'gutsy'), I'll wait until you've got something that you think will work.

Mark

There's a Linux version also, but I don't think it will work until I update my build machine with newer versions of ALSA/OSS.

PS. @ markwend & kaos, I've also added a "Frame Store" feature for comparing two images. It's under the "Image" menu; you can press "Shift+E" to load the current frame into the frame store, and then "E" to toggle between the current frame and the frame store.

Okay - installed and working under kubuntu 7.10. To answer your question, I use jpg when I don't care about quality and lossless tiff when I do.

The new framestore is great... thanks! Pretty much what I had in mind. I'll have to get used to it being manual, but I can see the value of that. I've worked with image playback tools in the past that always automatically kept the previous image in a buffer, so that you could toggle when you hit reload. With the manual approach, you have to *remember* to load the buffer when you reload, but I think I prefer that anyway.

Another issue: I typically save my files in 4-digit padded format (filename.%04d.tif), and I notice that djv_ls thinks there's a break between frame 999 and frame 1000. Likewise, if I have 'Automatically open file sequences' set in preferences, it only loads a sub-framerange (e.g., f0000-0999 if I give a frame between those numbers, even if there are more frames above 999).

For example, say I have 1500 frames in a directory:
clipper.0100-0999.jpg 33.1MB root Seq rwx Sat Dec 22 17:28:55 2007
clipper.1000-1599.jpg 21.68MB root Seq rwx Sat Dec 22 17:29:06 2007


If I force djv_view to load the full range (djv_view clipper.0100-1599.jpg), then it plays them all.


cheers
Mark

Hah! You beat me to it with that preference!

Hey Darby -

Got the new version and it works fine on gutsy. The issue you fixed with sequences over 1000 frames works fine now too. Thanks for that. A few new things...

a) Every time I install a new version, I have to go back and set my preferences all over from scratch. Any way to save preferences when a new version is installed?

b) When I set Mark In and Out points for playback, the Forward and Backward Playback modes obey these points. However, the jog shuttle (as well as right-button jogging) *doesn't* obey the mark in/out points. Is there a specific reason for that? If not, I'd prefer the shuttling to obey the marked points.

c) Here's a funny one. I'm in the habit of feeding a series of images to my own programs using wildcards (e.g., "myprogram file.*.jpg"). Of course, when I do this with djv_view, I get in trouble... it launches separate windows for EACH file that the wildcard expands to. I quickly need to killall in the shell before my machine swaps to death. Unless there's a compelling reason to open separate djv_view sessions with wildcards, it would be really nice to just load up all the files that a wildcard expands to in a *single* djv_view window. If I really want separate djv_view sessions, I launch them with separate commands.

Thanks again for a great and useful program!

cheers and happy holidays,
Mark