Make stripping of EXIF/IPTC data optional

Randy L shared this idea 2 years ago
Under Consideration

I've been the victim of I.P. theft before and I am acutely aware of the issues involved. I go through a considerable amount of time and trouble to modify and add EXIF/IPTC/XMP data to every image file I create. It serves multiple purposes for me - including carrying legal data like copyright and licensing info, along with my contact data.

After going through the files I've uploaded onto a test site to verify them - I was amazed that they were stripped of the metadata I've spent so much effort embedding into the originals. There is a reason I use the software I do, and that includes the internal and stand-alone meta tools that are all a part of my post-processing routine.

Checking the help files here on the site, I've read several posts stating that Koken's code has been written to specifically remove metadata in an attempt to keep file sizes down. I'm mindful of file sizes just as I am with image quality and speedy and responsive web rendering... BUT it's just as important to me that the data remains embedded as-is.

If this is in fact the case - please make the removal process optional. Presentation software shouldn't be making these choices for me and I would prefer to make my own editorial decision on what gets included in every file.

I'm aware that this code routine may have been offered as something helpful. However, in my case it certainly isn't and I assume I'm not alone in that regard. I prefer my files to remain intact - just as they were intentionally created.

Comments (4)


Hi Randy.

This feature is already present in the Admin-> Settings->Image Publishing->Metadata



Regards, Bjarne

Koken Community Support -


Unfortunately, no... it's not that simple a fix in my case. I've previously updated to 0.22.9 and unlike the screen you posted I see no options for setting metadata manipulation anywhere from within the backend. I don't see the same choices for image processing either - presumably because I'm using GD (v.2.1.0, my bundled default) instead of ImageMagik.

Essentially this still means that Koken is set to strip out metadata by default with GD as the processor (and I'll assume with any image library used), with no warnings or explanations to alert anyone about the issue. That, in turn, means that I won't have a choice for how the data is handled and I'm still at the mercy of the code.

My local dev machine is currently setup on Windows and I've never had any need for anything otherwise for web testing, so ImageMagik has never been loaded. The Apache bundled GD (and all the enabled EXIF/XPM/XBM modules) has always been sufficient for most image tasks used by other web scripts I've used and occasionally coded for. According to the Koken docs, GD is acceptable to use [ ], and will be the most likely library to be found in use with any web hosting provider... so it seems my dev environment isn't an issue.



After seeing Bjarne's screenshot and making my comments on different graphics processors, I thought I'd dig into the code a bit to see if, in fact, metadata gets handled differently depending on which library package is used. A cursory look shows that it does. I didn't go wild to trace all the code routines, so I don't know how the conditionals are set as defaults or know how the entire read/write operations work.

Inside the folder '/app/koken/Darkroom/' there are 4 files that handle the basic image tasks for the 4 supported libraries.

For ImageMagik (an external library - DarkroomImageMagick.php) it's conditional, via "if":

  1. private function setupArgs()
  2. {
  3. $this->sourceArgs = array($this->pathToConvert);
  4. $this->destinationArgs = array_merge(
  5. $this->setupLimitArgs(),
  6. array('-density 72', "-quality {$this->quality}")
  7. );
  8. if ($this->stripMetadata) {
  9. $this->sourceArgs[] = '-strip';
  10. }
  11. ... etc....

For Imagick (PECL addin wrapper for ImageMagick - DarkroomImagick.php) it's conditional, via "if":

  1. private function init($hintWidth, $hintHeight)
  2. {
  3. $this->image = new Imagick();
  4. $this->setLimits($this->image);
  5. $this->image->setSize($hintWidth, $hintHeight);
  6. $this->image->readImage($this->sourcePath);
  7. if ($this->stripMetadata) {
  8. $this->image->stripImage();
  9. }
  10. ...etc...

For GraphicsMagick (a fork of ImageMagick - Darkroom.php) it's hard coded to strip data:

  1. public function strip()
  2. {
  3. $this->stripMetadata = true;
  4. }

And, for GD v.2 (bundled Apache module - DarkroomGD2.php) it's hard coded to ignore EXIF, via how the functions are used. The simple 'imagecreatefromjpeg' call only copies the basic image data in creating a new file:

  1. private function createSource($path = false)
  2. {
  3. if (!$path) {
  4. $path = $this->sourcePath;
  5. }
  6. list(,,$this->sourceType) = getimagesize($path);
  7. switch($this->sourceType) {
  9. $this->sourceImage = imagecreatefromjpeg($path);
  10. break;
  11. ...etc...

I'm assuming above that the 'Darkroom.php' file may be specific to GraphicsMagick since the library's name isn't part of the filename itself - but - it may instead be used as the default/fallback routine, or for non-JPG or Tiff file types... and 'DarkroomImageMagick.php' is what's actually used - since the function calls could be identical between the two forks.

In any event, it's obvious that GD doesn't get any conditional handling. Many hosting companies don't provide support for any of the optional processing libraries within their shared hosting options, and only have GD available as a default. Given the possibility that not every potential/current Koken user wants (or can afford) to use a dedicated server or VPS solution to ensure that the other libraries can be used, the default handling under any of the 4 available libraries should be to explicitly pass all metadata as-is, and offer a conditional toggle when it's functionally available. From everything I've seen so far, this isn't complicated from a coding standpoint for any of the 4 libraries... including GD.



You rely did a thorough dive in to the code here hehe

Since always hade ImageMagic installed on all hosts that I have used (and they are a couple through the years) I have never given GD any deeper thought since IM always performed better and always been what's recomended.

But reading through your post, I have to agree with you, there should be some work done to this part of Koken...

But I might feel as this is more a question that should be posted as an bug/issue to the Koken issue tracker then a "plain feature request".