Devon; The original file numbers may already be an integral part of the file data .. this information is, depending on your camera and software system, probably stored as a part of the 'EXIF' image header along with the time, date and other important image information.
You may be better to let the original number remain and then control your images through a management program such as 'Picasa' or better still Digikam (both are free). I use each 'year' as a major folder break in my system, so rollover within that period is unlikely. Adding bulk, single or multiple, 'tags', 'captions' and 'stars' to images during the initial processing period, allows for fast sorting and retrieval even over multiple years. David On Sat, 2009-01-17 at 19:45 -0500, Devon McCormick wrote: > Members of the Forum - > > I have a small practical puzzle - I have a solution for it but am wondering > if there's a better one. > > When I work with .JPG files from my digital camera, I'll sometimes use the > sequence numbers embedded in the names, typically something like this: > > DSCF8950.JPG > DSCF8953.JPG > DSCF8957.JPG > > and so on. The problem with using this for sequencing is that sometimes the > numbers roll over, e.g. 9998, 9999 is followed by 0, 1, 2 etc. What's a > good way to detect this? The sequence of numbers will have gaps because I > delete pictures from the camera before downloading the files, so sequence > might be 9995, 9998, 3, 5, 12.... > > Currently, I have an expression, where "nn" is the vector of numbers > extracted from the file names, like this: > > if. (nn+./ . >5000)*.nn+./ . <999 do. NB. Numbers >9999 and restarted at > 0? > nn=. nn+10000*nn<:5000 end. > > but it's less than elegant, particularly because of the embedded, arbitrary > limits of 5000 and 999. I chose these based on the number of pictures I > might take in one batch versus the number I might have deleted. So, this > assumes I'll never hit the roll-over point, take more than 999 more > pictures, then discard those numbered 0 to 999. If I did, this check would > fail even though it shouldn't. I'm assuming this is unlikely, but it isn't > impossible. > > Any ideas? > > Regards, > > Devon > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
