Testing Range - Gibson Family Pictures

My /pix directory is shared by all the sites on my server.  testingrange.com/pix, chilidog.com/pix, journalsonline.com/pix.  But Google Maps needs unique developer keys..well see <a href="/pix/map_api.html">/pix/map_api.html</a> for my experiments on getting that to work.


Dec 8, 2004 - I'm experimenting with ways to access the pictures...part of my old rant on 'Access Paths.'  So here are some Access Paths
<a href="/">Or return to TestingRange.com</a>
<hr>
<li>This is the original <a href="/pix/contact.cgi">list of image contact sheets</a>
<li><a href="/pix/contact.cgi?limit=50&image_only=1">A screen of thumbnails with links to the galleries</a>
<li><a href="/pix/gallery.cgi">Text only list of all image directories</a>
<li><a href="/pix/calendar.cgi">Calendar View</a>
<li><a href="/pix/random.cgi">Show random images</a>
<li><a href="/pix/tags.cgi">Show tags for directories</a>
<li><a href="/pix/gallery.cgi?todo=1">My images todo list</a> Shows directories that need thumbnails or galleries.
<h2>Source for Tools</h2>
<a href="README">README with additional tool notes-especially on Nikon D70 Raw mode NEF files</a>

These are links to my production tools.  They are hinky ugly scripts...but release early and often, right?  You really really should make sure you understand the code or talk to me before using these on your own images.  Some of these tools do rather unreasonable things (like overwriting your source images with low resolution copies if they are called wrong)...you have been warned.  These are all released under the Perl artistic license or the GNU-you're pick.  Though if you actually find these have commercial applications I'd love to talk with you in order to have a hand in things.  The best way to predict the future is to create it...
<hr>
<li><a href="/pix/work">work - my (dangerous) script</a> Copies images to source directory, creates web viewable images and thumbnails, and the html files.
<li><a href="/pix/exiforient.txt">Automatically rotate images</a> - you should only use this on copies of originals, as it uses a lossy rotation.
<li><a href="/pix/exifdump.txt">Dump exif headers</a>
<li><a href="/pix/calendar.txt">Calendar view</a>
<li><a href="/pix/contact.txt">Contact sheet code</a>
<li><a href="/pix/gallery.txt">Gallery code</a>
<li><a href="/pix/random.txt">Random Image viewer code</a>
<h2>Thoughts</h2>
<b>Dork sort ranking</b>
What is the quickest way to apply some order to an unordered set of images?  How abouta (modified?) dork sort.  Enter the program...it will then select a folder based on some basis, and then pull 2 images out of the gallery (take advantage of whatever ordering currently exists in the galleries).  The question is then 'which one is better?'

<p>
But...are galleries 'the best' pictures, or are they intended to present a sequential narrative?  Ack!
<p>
Assume we want to extract the 'best' images.  Maybe: create a different idea of 'quality' or 'rank' as opposed to sequence.
<p>
The question is my normal question: what is the outcome.  The archivist and the storyteller are in conflict.
<p>
Basic idea...which of these things is better?  It turns out that a dork sort is a good choice at applying some order quickly.  So present to images at random, ask for some relative ranking, 'reward' the winner and 'punish' the loser.
<p>
<a href="/pix/dorksortmock.html">Dork sort ui mock up</a>

<p>
Thought: 
__SUMMARY__
to contain the 'best' images...if it doesn't exist, take the first image from the gallery?

<p>
1/31/2005 Things in picture land are officially absurd.  I've said this before, but it is 
really true.  The ads say 'buy a Mac Mini, use it for pictures and mp3's'  I was _almost_ 
convinced, except that right now I have 43 gb in my /pix directory, and 164,385 individual
files.  Now...for each real picture I have the full size source, the normal image, the thumbnail,
and the html preview file, so at least four files per image (well, aside from some of the 
'special collections,' like my grandfather's letters, which may not have the thumbnail)...
<p>
And the psychic cost of not having something that I later want is pretty high...but is it 
higher then massive image size growth?
<p>
Jul 2004: 6.2 gb<br>
Aug 2004: .5 gb<br>
Sep 2004: 1.1 gb<br>
Oct 2004: 1.1 gb<br>
Nov 2004: 5.8 gb (5.2 of that in Italy)<br>
Dec 2004: 3.8 gb<br>
Jan 2005: 1.9 gb<br>

All of 2001: 4.8 gb<br>
All of 2002: 7.7 gb<br>
All of 2003: 5.3 gb<br>
All of 2004: 21 gb<br>

<p>
40.7 gb in normal phots, and 2+ gb in 'odd' things...ie, things that are not CP_mmddyyyy* 
or D7_mmddyyyy*.
<p>
for white balance setting
Red 9.1/23.3
Green 11.1/15.6
Blue 15.4/7.4
Red_mul G/R 1.22/.67
blue_mul G/B .72/2.1