Exif Data for a Canon Rebel Xti (2008) seems listed, doesnt work Exif Data for a Canon Rebel Xti (2008) seems listed, doesnt work
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

Exif Data for a Canon Rebel Xti (2008) seems listed, doesnt work

Started by cadude7, December 15, 2020, 07:12:38 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

cadude7

I have been banging my head here and looks like your canon.php script for the exif tags, doesn't work with a canon you have listed in your help.  I have a Canon E0S Rebel XTI from 2008 and thought if this works we have it made.  But is prob going to be a show stopper for me. 

My other site that used some generic way to get tag data worked.  My pictures taken with a canon A75 from 2003 works.  I can see those flawlessly.  This model i didnt see listed in your help.  Any photo data from the Rockies including my brothers wedding don't show up at all.  none of the fields in the database are populated.  just some a:0 value.  I have tried a few times to blow them away and try again and it doesn't work.  Even installed some plugins thinking it would help.  I will admit i did start with it not enabled but have been going back and redoing them after enabling ALL fields.  Found it weird as soon as 2008 photos come up to add i don't get any fields which is when we got this camera.

You guys do test and confirm what you preach right?  or you just take the developers word for it??





lurkalot

cadude7,  just a thought.  Are you resizing, or editing these files before uploading them to Coppermine?  And if so, are you sure the EXIF data isn't being stripped out by that process?
Running SMF 2.1.4  / Tinyportal 3.0.1, bridged with Coppermine 1.6.25, plus cpmfetch 2.0.0

ron4mac

I uploaded one of your images to my test site and got all the camera data. Check all your configuration options.

And you might want to make sure you are using ImageMagick and not GD (GD removes those data).

cadude7

I'm sure this is not the settings.  I wouldn't have any other data.  And in respect to GD removing data, yes it does but the programmer has to catch the data before processing which php has the ability and then write it back.  My last album did all this on its own and left my files alone.  I can try ImageMajic but I am using GD2 right now and its working with the other photos.  I thought the documentation said that it goes into a database because of the stripping before this stripping occurs PART REASON for the database.  🤔

When i resize my stuff before moving using SMB to my server; I use stuff that retains the data like photoshop.  I'm not a moron.  I use ffmpeg to resize and make thumbnails when screen-shoting isn't available.  I also know i have files that have no data which is from places like crapbook.

Seriously guys you cant assume everyone is an idiot.  I support shit more complex than this with my work....reason you all have lights on and clean water to drink!  They even use it to watch bandwidth....  and my developers are just as hot headed which is why they don't write help files.  I just don't want to go making my own tracking system so when you release an update I can go back in and apply my changes to your core.

Anyways i seriously get frustrated reading your help files as they are actually RUDE in there own right!

This one works which was a different canon:

https://elterfamily.ca/Elter/Albums/displayimage.php?pid=1422

I have scanned photos showing data with a newer canon.

https://elterfamily.ca/Elter/Albums/displayimage.php?album=12&pid=1427#top_display_media


(FYI this # breaks facebook.  works removed!)  Doesn't break the debugger!

I thought maybe it was the DB and i increased the field size.  still shows a:0.

Ill try the imagemagic.  Is there a recommended 'Current' version?

cadude7

Solved changing to imagemagic.  :-\   Had a balls time getting the extension to work so just went with the executable in the end; plus its better as i dont need this effecting other areas of the site.   Oddly that got the data into the database.  Must be GD and its exif handling.

GD should still be viable even if it is a resource pig and if you have the server to run it.  Just not sure why GD allowed the ones through and not these ones.  I'm actually wondering if some internal mechanism (not your fault) is crashing and its handled as an ignore in PHP and has to do with the size of pixelation.  Since this site is production i don't tend to use debug as i don't need things exposed(I have a sister with a crazy bf).  Looking at the EOS; it does take some rather large files widthxheight.  The last album was pure IPTC and EXIF so i understand why that is working now as GD isn't a call around there EXIF reads.

Just odd that some work and some dont....has to be something to do with pixels.

Example working:

https://elterfamily.ca/Elter/Albums/displayimage.php?album=15&pid=1643


Thanks a bunch!  :)  Now to see if the file replace plugin will fix the wedding.



phill104

Fist let me ask you to not be angry and rude to people who are trying to help you. All are just doing this as a hobby, in their own spare time. Nobody is getting paid to help you, not did anyone get paid to produce Coppermine. It is a free package produced by many people, again as a hobby, over many years. You will notice this site doesn't even have advertisements, meaning there is zero revenue for anyone in the team. Please try and be polite.

Which part of the docs do you find rude? Pleas remember, many parts of the docs are written by non native English speakers. So while you may see them in your head as rude, you need to understand how they were written and translated.

So back you your problem. I had to jump through hoops to test your images as your settings mean the full size images (the ones that should contain the EXIF) require a logon to see. So to get to see them I had to come off my iPad to a PC, manipulate the output image links so I can download and check them.

So the first image, from a Powershot A75 with 3mo sensor. So output images are 2048*1536

The full size image is at those dimensions, so has not been modified suggesting it has not been modified on the server. Any modifications using GD on the server remove EXIF data, a limitation of GD.

The second image, which you suggest is from a Rebel XTI or Canon 400D as it is known here in the UK has a 10mp sensor so the full-size resulting image it outputs should be 3888*2952 pixels.

However, the image you link to is obviously not that resolution. It had been manipulated either before you uploaded it and cropped to 1734*1322 (which is what I suspect given the aspect ration and low resolution image) or you have edited in Coppermine, or it was larger than the settings you have allowed   (File size or max width dimensions set in config) so the script on the server has modified the file to comply with your settings. So either EXIF has been removed by your pre upload edit, or by the server during upload as it had to resize.

Given your image, and the fact you have not provided an account on your setup to test, and an unedited image for us to test it is not easy for us to help. Provide those and it may be easier.

I did however dig out an old Canon 400D and tested on my test setup. Once I had setup my install to allow the full resolution and file size in config all the EXIF remains, as it should. I also tested with my Canon R5 with its silly big files, and the EXIF works.
It is a mistake to think you can solve any major problems just with potatoes.

cadude7

Yes but if help files are written by rude people, its only fair that its returned.  Ive read a lot of the posts on your forum and a lot of the feedback come from the so called "freelancers" all have attitude!  if its such a problem why do it on your free time???? 

From a developers perspective its never there code that's an issue; its the end user and usually they are right.  But when people who have backgrounds in this stuff and get feedback "i uploaded your file and works"; curious how did you get said file as that's not in a shared area on the server.  Anyways i can sniff out people who have nothing better to do that write suggestions that are not helpful.  Like that same person suggested to use his plugin for videos and its literately trash!  It shrunk the scope of the widescreen.  lmao!  ill stick with ffmpeg thank you!!  Least i know which developers to listen to now.

Anyways using Imagemagik works.  GD does not.  Enough said! 

ron4mac

It's fortunate that you're so good at figuring things out on your own. I doubt very much that you'll get any further help here. I suggest that you go back to what you were using before or find something else.

cadude7

It is what it is.   I cant get help that's fine.  Just shows your true nature!  Social media is great you know!  remember that!

Adjusted your code RON so at the end it ignored the java creation ugly pic and to use ffmpeg instead:

$easythumb = realpath('../../'.$CONFIG['fullpath'] . $row['filepath'] . $row['filename']);
$easytb=realpath($thumb);
//echo $easythumb;
MakeThumb($easythumb);
//if (!rename($fimgp, $thumb)) die('FAILED: could not place thumbnail');

function MakeThumb($file){

$thumb=pathinfo($file)['dirname'].'\\thumb_'.pathinfo($file)['filename'].'.jpg';

$video = '"'.$file.'"';

$thumbnail = '"'.$thumb.'"';
$ffmpeg='ffmpeg.exe';
$command=' -i '.$video.' -deinterlace -an -ss 5 -t 00:00:05 -r 1 -y -vcodec mjpeg -f mjpeg '.$thumbnail.' 2>&1';
echo ($ffmpeg.$command);

$abc=exec($ffmpeg.$command,$output);
//print '<br/>';
//echo '<br/>------ Thumb Creation for Video ------<br/>';
// '<br/>'.$abc.'<br/>';
}

Takes an asshole to know one Ron!

phill104

Banned.

Fortunately many people are appreciative of the efforts Ron and many others have put into this project. Shame you cannot see that and be polite.
It is a mistake to think you can solve any major problems just with potatoes.