After some interesting discussion inside the topic "Which IDE and Debugger to run zenphoto?" I created this topic because it will focused on Exif.
@Trisweb
@Thinkdreams
@all
Design architecture advice, sure...
This is basically going to be a function that class-image.php uses to get EXIF information. So we need a couple things...
Re: Additional fields/redundant information: These are NOT tags, I'm talking about duplicating (caching) the EXIF data in the database. Parsing a file for its EXIF data is an intensive process. We can do benchmarks to find out just how intensive it is, but I know it's not simple. Reading data from a database, on the other hand, is very fast, [i]plus we already do a query for each image[/i] so adding an additional 10, 20 or even 30 fields won't slow anything down beyond the already existing query overhead. The EXIF will only need to be read from the image [i]once per image update[/i], which is good.
If you mean that some data will always be the same, like camera model, then I agree completely, we could use an ID instead into an exif data table. But for most of the exif data, it varies a lot, so it won't be very necessary. We'll look at the data and decide later if we need to alter the schema.
So let's get that EXIF library reading image data first, make a new method in the Image class to read it, process it, and store it by using $this->set('variablename')*, and don't worry about the database caching just yet. I'll take care of that.
@thinkdream
More in the evening...
@stef-
Tris in a previous post suggested storing one EXIF field per column, so I think dedicated fields would probably be the best thing.
@thinkdreams
Gotta figure out what it all means, but here's a start:
http://www.thinkdreams.com/devzen/index.php?album=vermont&image=hi_bunnies.jpg
(Aren't the bunnies cute?)
Oh, sorry. Try looking at the raw EXIF data below.
Another example is:
http://www.thinkdreams.com/devzen/index.php?album=njsummer&image=IMG_2129.JPG
which has better camera info.
Looks like everything is already in an array.
Implemented by:
In the image.php
`
`
And in the zen directory I placed the makers dir and the exif.php from the Exifixer library.
The code above is basically taken from the index.php file supplied with the distribution.
Really rough, but a start.
The cool thing is that the maker information is abstracted (or separated) from the core exif library, so technically you could write camera support "makers" for new cameras with errant tags thereby effectively supporting many different types of cameras.
From here, we need to decide what to get by default. I'm guessing like Stef said the biggies:
date and time,
camera make and model (looks like two fields)
fstops,
exposure time,
aperture?,
flash (yes or no),
focal length,
orientation (important for rotation)
Looks like the raw data returned pretty much takes care of these, and these should be common among most, if not all maker data with a few exceptions.
I'm not fantastic on arrays and data processing. To be really honest, I stink. How are you at arrays Stef? Since there potentially is a large amount of data, we need to find the commonly used data, and maybe just grab those rather than the whole raw set of data?
Am I even making sense? It's been a looooong week.
Yep, making some sense there
I guess you'd just want to find where the data resides in the array, and just reference it and assign it to some variables... something like...
`$result = read_exif_data_raw($path,$verbose);
if ($result['ValidEXIFData'] == 1) {
$aperture = $result['SubIFD']['ApertureValue'];
$exptime = $result['SubIFD']['ExposureTime'];
...
}`
Then you have your EXIF data :-)
@thinkdreams, trisweb
@thinkdreams
Question:
Stef, LAMPP on a Linux sys? I'm not sure if it comes prepackaged or what...
If you're using Debian/Ubuntu, just use apt-get, it integrates everything correctly and works great. On gentoo obviously use emerge. Not sure what distro you're using.
No worries about delays
@stef-
I know that this statement will sound pretty opinionated (I apologize), but
speaking from experience (as a network admin with lots of years of tech support experience), never, never, never buy maxtor again. they have the worst industry record for failures and errors. stick with seagate or western digital, generally speaking they have decent track records. all hard drives fail, but maxtor seems to suck more than all the others.
We had a mission critical NAS appliance at work by maxtor and it was awful. it crashed all the time, and for a business file server system, that isn't good. we ended up going back to an HP Proliant rack server after 1.5 years using it, and we replaced the unit's drives at least 3 times during that time.
(Maxtor no longer makes NAS appliances BTW)
And what the heck do rapids have to do with cute little bunnies?
Craig, that's good info. I've got a Maxtor 250GB drive in my comp and it's worked great for over a year now, so I guess some aren't as bad as others, but I've always like WD/Seagate as well (Bought a laptop drive from Seagate that's blazing and super stable, quite nice).
I am also curious as to what the heck rapids have to do with bunnies. :-)
I´m looked for the Exif-function too (I found a ToDo at the ZP exif function - and i wanted to code a new function).
I recognized, that the PHP-Function exif_read_data() [http://de2.php.net/manual/de/function.exif-read-data.php] not always do, what they have 2 do (PHP Package must be Compiled with --enable-exif to work). And now i have found your thread that you still work on the exif function for ZP. Nice =) ^^
Thread Merged
sry 4 my shitty ^^ english
Tom
@all
I'm back...or should I say my LINIX PC is back.
VMWare:
Exif:
We already, within the Exifixer library, have a function that returns the raw tags. So a function to return the tags is already there for us to use (see my examples). What we need now is a way to take those tags that the raw function returns, and assigns them to variables, based on what tags we decide to start using. We probably don't want to assign every tag possible to variables, just the common ones. Then Tristan I believe will take those variables, and cache the stored data in the DB, right Tristan?
So, we can either rewrite the raw tag function, or write a new one that does the same thing (I'm thinking a new function that stores into variables rather than displays would probably be best)
Nope. I haven't. I'm still bringing my company back up to 100% from a large virus outbreak (Spybot/Rinbot worm) which hit our slightly out of date Symantec scanning engine. The funny thing was, our virus defs were good, it targeted a security hole in the slightly older version we were running. So word of advice, make sure you run the latest virus defs AND the latest engine if you run windows boxes. The virus writers are hitting Symantec products pretty hard right now.
All I really need to do is write the function that grabs the tags from the image and drops them into variables as you outlined above. Then I can hand it off to you to look over. Hopefully within the next week or so, earlier if I can free up some time.