flf_histotag Geotagging & histogram for Coppermine 1.5.x Plugin

[Αndré]

Committed version 1.2 in r7169.

[Joachim Müller]

However, now I have the problem of needing to transfer information to the new .php-file, the Picture-ID in particular. I don't seem to be able to pass it with a regular parameter, cause the index.php strips those away

I can not replicate: using http://yoursite.tld/your_coppermine_folder/?file=flf_histotag/histotag_histogram_display&foo=bar&bla=whatever should work no matter what, so you should be able to get the pid as well via URL parameter (as an example for a lot of parameters in the URL, take a look at http://coppermine.svn.sourceforge.net/viewvc/coppermine/branches/cpg1.5.x/plugins/fetchcontent/js.php?view=log)

solved it by using the $_SESSION-array until I find something better.

You should change that, as sessions don't work reliably.

the $CURRENT_PIC_DATA-array is empty inside my newly opened file (I did include it with GLOBAL).

It's empty because there is no current pic if the script isn't aware of a pid. If you have the pid, you can always use the function get_pic_data to fetch the details.

[Timos-Welt]

Well I tried to get any result out of the latest version, but failed.
The button 'Generate all histograms (DANGER!)' doesn't work for me at all because of server timeout limits (this should be changed IMO - there's no danger in doing this like on admin tools page).
I never saw a histogram button, no matter what setting I used.
The settings for viewing the buttons even if there's no histogram file or geo data don't work for me. I still have to see a button.
The config setting 'Show button even if no geo data was found' always switches back to 'show', no matter what I set it to. Same applies for 'Show button even if no histogram is found'.
The setting 'Show histogram with every image(will be generated on the fly if necessary)' doesn't do anything, either.

[Joachim Müller]

The plugin tries to create a folder named "histograms" in coppermine's root folder (which is of course a very bad place for such a folder, as indiciated earlier). If it doesn't have permission to do so, it will fail with an error message. Maybe that's what happened for you.

[loungelizard]

Hi Timo,
did you see histograms created in the "root/histograms" folder after selecting the corresponding function? As a matter of fact, do you see the root/histograms folder at all? The "Generate all histograms" function is not required if you you toggle the "on-demand"-generation - but from what I'm reading you don't seem to see the buttons at all, which is strange.

Regarding the config screen: I'll look into this... frankly I didn't put any more effort into it after Joachim said the config screen was based on a bad example. @Joachim: Did you put any effort into it? If you didn't so far, I'll generate a new ones based on one of the plugins you suggested. I just want to make sure, you didn't start something that I might override otherwise.

At any rate, I'm surprised it doesn't work for you at all. Can you select your settings from the Config table for me and post them here or send via email?
SELECT * from <databasename>.<coppermine_prefix>_config where name like "flf%"?
(I'll change the parameters to the <plugin_flf_%>-alternative in next version too.)

If you all agree it's wiser to generate the histograms in the same folder, the actual files reside in, I'll change that in the next version.

Cheers, Florian

[Timos-Welt]

Yes the folder exists, and yes there are histogram files in it! A shame that I never was able to get one displayed

You should listen to Joachim; IMO he does great config pages and knows a lot about coppermine. In the end, the folder solution will work fine for small galleries with up to 500 files, but it won't work as well for galleries with 10,000 files.

[Joachim Müller]

@Joachim: Did you put any effort into it? If you didn't so far, I'll generate a new ones based on one of the plugins you suggested. I just want to make sure, you didn't start something that I might override otherwise.

Please go ahead and start working on it if you have the time. I have some suggestions though:

• Having two config options "Show button in navbar if geo data found" and "Show button even if no geo data was found" is not a bright idea. Turn that into one config setting, using radio buttons. The label should read "Show geo data button in navbar?" and the possible options should imo be "Always", "Only if image contains geo data" and "Never". A similar thing applies for the histogram button
• The option "Size of lytebox window" exists twice. I suggest dropping both of them and using the greybox as it is.
• Plugin tablename (usually don not change this!) - drop that option completely: the table name should be PREFIX_plugin_flf_histotag, with the PREFIX of course being the actual representation of $CONFIG['TABLE_PREFIX']
• The option "Type of histogram (combined/split)" mustn't be a text input field, but of course a radio button
• None of your dropdown selects should be used that way. Most of them can be turned into checkboxes

[loungelizard]

Version 1.3 is released. I've taken all the suggestions I got from this forum and put it into the new version. Most effort went in the new configuration but also some features have been added.
As always, I'm glad to get feedback from you.

To see the plugin at work please visit http://www.lounge-lizard.org/cms

Cheers, Florian


Full changelog:
[A] complete rewrite of the configuration screen
[A] added function to delete all histograms in the system in case you don't want them anymore or need to regenerate      
[A] added parameter for image quality of histograms (1-100) in %; less quality makes smaller file size
[A] added options to change the Google map style (satellite, regular etc.)

• Histograms are no longer stored inside the histograms folder; instead they are stored in the samefolder the picture resides in.
  [C] changed all parameters names according to coding conventions
  [C] sanitized the passing of the pid-parameter to the display-histogram function; thanks to GauGau for the hint
  [C] removed setting for changing tablename
  [C] changed configuration options for geosupport so it is clearer, what they mean.
  [D] eliminated most of the language-specific texts[/tt]

[Joachim Müller]

I have comitted your changes to the SVN (rev 7216). Thanks!

[Timos-Welt]

The latest version works perfectly for me. What a great plugin!

I've centered the display of the histogram in histotag_histogram_display.php by old-schoolish putting <center> tags around the image. But that's a question of personal taste.

Thanks very much!

[Timos-Welt]

Another idea for the future: Currently the plugin uses the original image to create the histogram. If an intermediate pic exists, it should be much faster (and generate much less server load) to use the intermediate size pic if one exists. The resulting histogram shouldn't really differ much, but the CPU time needed to generate it shrinks dramatically. In the end it's just a small change in function checkandcreatehistogram().

[Joachim Müller]

I've centered the display of the histogram in histotag_histogram_display.php by old-schoolish putting <center> tags around the image.

The <center>-tag is deprecated. I suggest using <div style="text-align:center"> instead for validity reasons.

[loungelizard]

Another idea for the future: Currently the plugin uses the original image to create the histogram. If an intermediate pic exists, it should be much faster (and generate much less server load) to use the intermediate size pic if one exists. The resulting histogram shouldn't really differ much, but the CPU time needed to generate it shrinks dramatically. In the end it's just a small change in function checkandcreatehistogram().

That is a bright idea. Thanks for the input. I couldn't think of a way how to decrease the calculation time cause it does take quite some time to loop through every file... especially disturbing when debugging 
I'll look into it asap.
Cheers, Florian

[loungelizard]

Commited in Version 1.4 (see first post for download)
I played around with the intermediate images a bit and decided to even include an option to use the thumbnails as source for the histograms. Lightning fast but the differences in accuracy are really noticable. See the attached examples from a sample image.

Additional changes:

• fixed a bug that left some pictures without geobutton even though geodata exists
• fixed a bug regarding include files
• fixed the link to the farbtastic colorpicker images in the config screen
• centered the histogram during output
• Using intermediate or thumbnail size images for the histogram calculation in case they exist. This dramatically increases performance, the output quality is not really affected that much when using the intermediate image. It does however make a bigger difference when using the thumbnails.
• Decide for yourself: accuracy vs. speed
• added a setting in the configuration screen for the above option
• Changed the icons supplied with the plugins to "Silk icon set" by www.famfamfam.com
• Fixed a bug that plugin information did not show in plugin manager, when plugin not yet installed

Have fun, Florian

[Joachim Müller]

• Changed the icons supplied with the plugins to "Silk icon set" by www.famfamfam.com

Bundling with the silk icon set can be tricky (license-wise). I suggest using the crystal_clear set by Everaldo instead (see http://documentation.coppermine-gallery.net/en/credits.htm#codebase and http://forum.coppermine-gallery.net/index.php/topic,57075.0.html).

Commited in Version 1.4 (see first post for download)

The term "commit" usually means "checking in into the subversion repository" in this aspect. I have done that for you.

[loungelizard]

Please make note of the newest addition to my histotag plugin. Please see first post for download link.
Please visit http://www.lounge-lizard.org/cms/coppermine/index.php?file=flf_histotag/mapalbum&aid=9 for an example.

The following features have been added in Version 1.5.

[A] added a feature to include a map to BING instead of Google; Can be used without a bing api account.
    If available, it uses the pretty "bird's eye view". If bird view is not available, a regular satellite image is used.
[A] added a new feature: Shows all geotagged images from an album on a Google map.
    The new file "flf_histotag/mapalbum.php" can be called with parameter aid
    If the user is allowed to view the album, the entire album is searched for images that contain valid geotags
    For each image, a marker is located on a googlemap, that display a small popup-window from where you can
    link to the displayimage.php for the corresponding image
    Additionally, a sidebar is added to the map that shows all the images that markers were set for. You can
    click on these thumbnail images to open the info window for the marker as well.
    The map is centered and zoomed to fit all markers on the map. If you have a album with images from all
    over the world, you'll get a smaller zoom level as if you have the images together that are from a close
    perimeter.
    A link to the map is available on the thumbnails.php or displayimage.php page - right after the breadcrumb
    Note: This link is only available if a valid album number can be identified, thus it doesn't work yet for metaalbums,
    search results etc.
    Note: This function only works with Google maps, therefore you must have your own API key.
    The style of the album map is determined by the same parameter as the regular map. If you use the
    bing maps for the regular image view, the topographic view from Google is used in the
    album view.
[A] The size of the album map is set by two new parameters.

If anyone has a better idea on where to link to the page besides the breadcrumb-Function in thumbnails.php and displayimage.php please toss me the idea. I couldn't think of a better way than including the text link as shown in the screenshots, but I'm not completely convinced yet.

Here are some screenshots.

Regards, Florian

[Joe Carver]

Very nice and very impressive work!

Since you seem to be very prolific with your output I hope you could consider adding these 2 features. One should be relatively simple and straightforward, the second might not be possible or would require new plugin hooks and/or a lot of work.

1) Could you add these selections to the Plugin configuration for map types?
     - Terrain Map (usually presents a very "clean" appearance)
     - GMenuMapTypeControl - will present the visitor with a drop-down menu to select map type (has limits)


2) For those of use with older cameras and very much older photographs. Would it be possible to add a reverse geo-tagging feature? Perhaps within edit_one_pic.php or on a dedicated page?



Very cool plugin - nice work.

[Timos-Welt]

The histogram button shouldn't be visible for non-images. Currently it's even there for mp3 files.

[loungelizard]

Hi Joe and thanks for your feedback.

1) Could you add these selections to the Plugin configuration for map types?
     - Terrain Map (usually presents a very "clean" appearance)

This one is already included (I presume you mean the G_PHYSICAL_MAP type? I named it "physical map" in the config screen; change that in the new version.) I did not find any other map type suitable for the plugin. It may be cause I'm still using the V2 of the Google maps API, V3 may offer some aditional things. See http://code.google.com/intl/de-DE/apis/maps/documentation/reference.html#GMapType

     - GMenuMapTypeControl - will present the visitor with a drop-down menu to select map type (has limits).

I added that function on my local testbed, works fine. After tweaking it a little bit I'll release later today.

2) For those of us with older cameras and very much older photographs. Would it be possible to add a reverse geo-tagging feature? Perhaps within edit_one_pic.php or on a dedicated page?

Gee I don't know. I geotag all my images with "geosetter" (http://www.geosetter.de). This is a really fantastic tool that does the trick for me, even if I don't have GPS tracks to merge with my images. This of course would require you to re-upload the images after you add the geodata.

Geotagging the images inside coppermine would require a couple of steps
- Obtain the geo-coordinates for an image with a user-friendly interface
- Save these Coordinates in the original JPEG-Exif header ( I could of course  only dump it into my plugin table, but i'd consider that a waste of effort on the user side)
- Retrieve the coordinates from the new Exif header to be able to display them.
I don't know if it's really worth the effort, especially the user-friendly-tagging part. I'll give it some thought.

Cheers, Florian

[phill104]

How about adding a "add location button" to each image. This could bring up a map where you could add the location. Once correct press another button to write to the db. Should be quite simple.

Here is a little example I knocked up of how the geocode could work in the back end.

http://www.windsurf.me.uk/geocode.html

As you can see, clickling on any location brings up the co-ordinates, simply add a button to accept that location and write to the db.

Code Select Expand

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
    <title>Google Map Long/Lat finder</title>
   
   
<!-- Remember to change the keys for your own domain  -->   
<script src="http://maps.google.com/maps?file=api&v=2.x&key=ABQIAAAAXIIfOy9RqRn6Joxvjn0lIxR3sZnehZIYWrxGjIHvkcGdHqJv2BQnhafXU6ucIsJNlj4yLfWXwdSoTQ" type="text/javascript"></script>
   

<!-- Local Search scripts: AJAX Search (uds.js) and LocalSearch (gmlocalsearch.js) -->
<script src="http://www.google.com/uds/api?file=uds.js&v=1.0&key=ABQIAAAAXIIfOy9RqRn6Joxvjn0lIxR3sZnehZIYWrxGjIHvkcGdHqJv2BQnhafXU6ucIsJNlj4yLfWXwdSoTQ"
      type="text/javascript"></script>

<script src="http://www.google.com/uds/solutions/localsearch/gmlocalsearch.js?adsense=pub-1022738694169855" type="text/javascript"></script>


<!-- Local Search styles -->
<style type="text/css">
  @import url("http://www.google.com/uds/css/gsearch.css");
  @import url("http://www.google.com/uds/solutions/localsearch/gmlocalsearch.css");
</style>

    <script type="text/javascript">
    //<![CDATA[

    var map = null;
    var geocoder = null;

    function load() {
      if (GBrowserIsCompatible()) {
        map = new GMap2(document.getElementById("map"));
       
        // create a local search control and add it to your map
      var lsc = new google.maps.LocalSearch();
      map.addControl(new GSmallMapControl());
      map.addControl(new GMapTypeControl());

        GEvent.addListener(map, "moveend", function() {
  var center = map.getCenter();
  document.getElementById("message").innerHTML = center.toString();
});
       
        map.setCenter(new GLatLng(54.512161, -1.17523), 5);
        geocoder = new GClientGeocoder();
      }
    }

    function showAddress(address) {
      if (geocoder) {
        geocoder.getLatLng(
          address,
          function(point) {
            if (!point) {
              alert(address + " not found");
            } else {
              map.setCenter(point, 13);
              var marker = new GMarker(point);
              map.addOverlay(marker);
              marker.openInfoWindowHtml(address);
            }
          }
        );
      }
    }
    //]]>
    </script>
  </head>

  <body onload="load()" onunload="GUnload()">

    <form action="#" onsubmit="showAddress(this.address.value); return false">

      <p>
        <input type="text" size="60" name="address" value="10 Downing Street,Westminster,London,UK" />
        <input type="submit" value="Go!" />
      </p>
      <div id="map" style="width: 600px; height: 400px"></div>
    </form>

<div id="message">(51.516514, -0.1342822)</div>

  </body>
<li>
</html>