Re: [Gimp-user] time saver?

[Jay Smith <jay JaySmith com>]

On 11/15/2012 10:13 PM, Jay Smith wrote:
> On 11/15/2012 09:48 PM, rmooney wrote:
> > I enjoy using GIMP, but I'm looking for some help to cut down on my time
> > watermarking my photos. Currently I am opening a photo, adding text,
> > rotating
> > text, duplicating the text layer, then moving each layer to the top
> > left and
> > bottom right corners. Surely there must be a way to make this process
> > quicker?
> > Any help will be appreciated.
>
>
> A few years ago I was using Imagemagick for similar watermarking in an
> automated batch process.  However, at that time there were some bugs (at
> least on our system) that prevented me from getting exactly what I
> wanted in terms of text appearance.  However, it was _supposed_ to work
> and seemed to for other people.  I suspect it does now (if not then
> also) and would work now on our more modern o/s.
>
> http://www.imagemagick.org/script/index.php
>
> When I was using it, it was part of a larger process I ran: making
> multiple scaled JPEGs from single TIFFs, and applying the watermark, all
> in the same process (without messing up the TIFFs).
>
> We still use Imagemagick for the sizing/scaling to process thousands of
> images.  We use a Perl script wrapper to manage the process of running
> through hundreds of source directories/folders containing tens of
> thousands of images, processing only those that are newer in the source
> than the target, and pushing the results to a matching output
> directory/folder structure.  (Thus any changed image will get
> reprocessed.)  We use a complicated algorithm in the Perl script to
> decided the min / max size for each output, with max limitations on
> width and/or height (but maintaining original scale), based on the four
> target uses and on the physical size of the input object TIFFs (the
> TIFFs are all scanned at 100% of size (said from a printing perspective)
> at 300 dpi.  The original source objects range from 1x1 inch to 20x20
> inches (flatbed scans).  The output sizes need to be "sane" to fit in a
> web page that is "sane" and yet takes advantage of whatever size is
> available without making the page too wide.  The logic and math of this
> hurts my head; among other things, the differences input and output dpi
> really warps the math, while you are scaling differently depending upon
> various rules.
>
> Anyway, it works great and runs like cat with a bell tied to its tail.
> (I'm a cat person, but that would be fun.)  The more RAM and the more
> processors the better and if you can control (increase) the number of
> simultaneous processes on your machine, you can make it scream.
>
> If we were to go back to watermarking, of course the watermark needs to
> be applied _after_ the sizing/scaling, but before saving the JPEG.
>
> You could also set up a "watched folder" type of system into which you
> could drop the source images and have a 'cron' job that checks and
> processes the folder however often you want.
>
> Jay

One added note: By maintaining separate source (input) and target 
(output) directory structures you ....

- Will never damage your source files.

- If you want to change the watermark on the existing target files for 
any reason, you simply change the script doing the watermarking, use 
'touch' (or similar) to change the dates of either the source or target 
files so that the process [a Perl wrapper script] will think the source 
files are newer, and run it again.  All your target files will be 
recreated with the new & improved watermark.

Suggestion: Never delete your target files as a way to tell the process 
to recreate them.  (Instead, move them aside.)  I say this because every 
year I find one or two source files (out of tens of thousands) that have 
mysteriously been corrupted (though not accessed according to the file 
internals), the favorite corruption is that the image turns negative. 
Stray neutrinos??  Anyway, as long as you have your target files, you 
can at least have something usable even if your source has become bad. 
[And another good reason for progressive, non-destructive backups stored 
off premises.]

Jay