not resolved
DeBing
Member
Is it possible to update the exif infos of the pictures? Because i have update my pictures with Copyright infos and load it up (by ftp and override the old files) and rebuild some pictures. but that action didn't bring the result i wanted. And yes i have activated the Copyright Exif Info in the PhotoQ Options.
Or does the exif is only written while first upload of the picture through PhotoQ?
DeBing
Member
Another question: is there a way to put the "freeform content" into the description of the post and not into the metadata fields?
Edit: the "Include Exif data in post content" does not copy the exif data into the post content. And i am using this option with the normal "Photo link". The exif data will be shown but they aren't in the post content.
Fix of Edit: Sorry it was a Theme bug, fixed it in the theme.
DeBing
Member
Yeah, it's me again with the half of the solution (i think):
about updateing the exif datas after publishing, i think it should be in the
"updateExif"-function in the \Classes\PhotoQPhoto.php file.
function _updateExif()
{
// now first everytime (maybe controlled by an option in the exif-section?)
//get new exif data
$this->exif = PhotoQExif::readExif($this->_path); //<-- the only problem
//update full exif in database
update_post_meta($this->id, $this->_exifFullFieldName, $this->exif);
// the normal updateprocess
update_post_meta($this->id, $this->_exifFieldName, $this->getNiceExif());
}The only problem i have, i am not sure, if "$this->_path" returns the string of the path of the original file, and i am afraid of testing it on my live-system (my test-system is still the database-photoq and i can't test it there because its very unstable xD). Maybe you can tell me how to find the original file.
Best regards
yes you are exactly right. exif info is only read out of a file when it is uploaded. so if you overwrite your files manually via ftp, it won't happen.
you are also right about what you need to do to force an update, i.e.,
$this->exif = PhotoQExif::readExif($this->_path); //<-- the only problem
//update full exif in database
update_post_meta($this->id, $this->_exifFullFieldName, $this->exif);$this->_path is a string with the full absolute path to the original file. it is the same that you can also find in the photoQPath custom field.
DeBing
Member
ok, so i was right, that $this->_path is going to the path of the original file *lucky*. After a little bit code research i got it, but i wasn't so sure to test it so i asked you here. Now i commented it in my local file, that this is the path to the original file. Maybe you could implement an option to the settings, if the exifs should be readen and rewritten in the rebuild or not (sometimes helpfull). Thanks a lot will try it immediatly.
EDIT:
Tested
$this->exif = PhotoQExif::readExif($this->_path);
//update full exif in database
update_post_meta($this->id, $this->_exifFullFieldName, $this->exif);
update_post_meta($this->id, $this->_exifFieldName, $this->getNiceExif());two times, first with exifFullFieldName, second time only the last update_post_meta. But i got a problem: It really updates the exifs, but some field content in every post was shown as "Unkown: someIntegers_and_not_this_text". So as if some of the exif-id's couldn't loop through the exif-switch methods for the "right" values. Got an idea how to fix that? (luckily i got a backup of the database before testing).
And while testing it, i got another question: Is it possible to add the original exif information into the images of the other sizes (i'm just using the default main and thumbnail size), because this would be great, if someone "downloads" an image and there is my Copyright (in the exif) in it.
1) unknown exif tags: possible that the exif library used doesn't know all the tags. can i have a sample image that has this problem so i can have a look and see whether i can do something. thanks.
2) writing exif info to photos: this is unfortunately not possible right now. the reason is that the exif library photoq currently uses doesn't allow for writing exif data.
DeBing
Member
the funny thing is, its always the same pictures and i am using the same exifs. In the initial load, the integers were found and parsed correctly. With my edited method the integers will not be parsed correctly after adding Copyright as Exif-Info. Will test it some more.
DeBing
Member
Sorry, i testet it again and wanted to edit the last post, but i was to slow :-( so here again:
The thing is, the pictures work fine on the first exif-readout (when first time published from photo queue) or when you replace an image.
So i changed the code of _updateExif to
//get new exif data
$this->exif = PhotoQExif::readExif($this->_path);
//update full exif in database
update_post_meta($this->id, $this->_exifFullFieldName, $this->exif);
// this is the "original line" of updateExif and you have to do this here,
//because you can't trigger a rebuild here like in the replaceImage function
//(otherwise you would get an infinity loop)
update_post_meta($this->id, $this->_exifFieldName, $this->getNiceExif());for updating all picture exifs everytime. The most exif-values where right, but some were "wrong", so instead of a "string" there is only the integer value of it which have to loop to the switch cases for the right "string". I think you could reproduce this in your programming enviroment by copying the code into your updateExif function. add or remove an exif information and save the settings so the pictures will be rebuild.
finally got the chance to have a look at this.
i did the following:
1. replaced the _updateExif method with your version
2. published the photo that you linked to earlier on flickr
3. chose several exif tags in the photoq settings
4. save settings
5. activated and deactivated some more tags, saved settings again to trigger rebuilds
however, i was not able to recreate the problem. am i missing something?
DeBing
Member
Hello,
got some time now again. Ehm, did you try the whitebalance or flashlight output? Because i get the weird integers everytime when there should be a string to be displayed.
Today i got another question xD i tried my logic but it failed: i wanted to change the fileextension of the thumbnail in the generator to jpeg. So i searched the code, where you generate the thumbnails (class/PhotoQImageSize.php) and added following lines into the createThumb()-function:
function createThumb($inFile, $outFile, $width = 0, $height = 0)
{
$outFile = substr($outFile, 0, -3);
$outFile += "jpeg";
...But when i rebuild, i got an error and i can't var_dump on that place. I thought the outfile is the string of the filename + extension + dirname of the new thumbnail or am i wrong? Or is there an easier way to change all the thumbnail fileextension from jpg to jpeg and which is automatically updateing the posts like when you go under settings and "rebuild all the publishd photos" (i really need this change xD).
1.) will have to try at these exif outputs one of these days
2.) concerning filename extensions. you cannot just change them as you did. the reason becomes apparent when you look at how this function is called
$this->createThumb($oldOriginalPath, $this->_path,...
in your case you change $outFile locally in the function, which will have the file that is generated have your desired extension. however one level higher up, the _path field does not get changed and this one is used to create the post data. so in your case i guess that after your modification the filename on the server no longer matches what is put into the posts.
i don't see an easy and simple way to change these extensions. it was simply not foreseen. why do you want to change them anyway?
however, i think if you upload your files with .jpeg in the first place, they will always have this extension.
DeBing
Member
Yeah, i got the error that he couldn't find the file (after the file extension modification). I thought the this->_path would include the whole path + filename + extension, but ok. It's difficult to debug in wp-php-code or i just don't know how (yeah i have seen the "Debug" functions but don't know where the output is) xD.
Because of my security reasons i have locked jpg-images and some other filetypes in a .htaccess file this works very good. But for a better linking of posts with the thumbnail in some forums (where the thumbnail should be shown), the thumbnail have to have an another extension then jpg so i thought of jpeg which is the same file type with just another file extension. Thats why i can't replace all jpg through jpeg images because the original and main have to be jpg and only the thumbnail (for security issues) jpeg.
DeBing
Member
Ok, after a teatime i got another idea for my security issue. A new .htaccess file for the thumbnail folder. It could be so easy, but i must really say.... didn't thought about it till i got the idea. So the file extension-problem is solved. $head->brickwall xD
Outstanding is the exif-information-update. But that doesn't have any priority.
You must log in to post.