Globs site - Forum - Web iPhoto Access

Thunderbird Extensions

External Editor

Yamb

Apple - mac

Web iPhoto Access

Donation

Preferences

29 members

Users online

( nobody )

Visits

147764 visitors

Fresh News

Extension updates

WiPhA photocast demo

Private

Slideshow test

Forum - Web iPhoto Access - Topic #64

Topic #64	Install on Linux by rpaskowitz - visitor 22/02/2006 @ 21:48
This looks like just the thing I want for my photos, but I don't have a mac server. I'm willing to put some work in to make it work on linux, but am hitting a couple walls. 1) `changeperm` the mach-o executable. Is the source available? I'll need to get that compiled 2) I get the following on first login: Warning: Unexpected character in input: '' (ASCII=15) state=1 in /usr/local/dh/cgi-system/php.cgi on line 1247 Parse error: syntax error, unexpected T_STRING in /usr/local/dh/cgi-system/php.cgi on line 1247

Answer #1	by Globs - ( 138 messages ) 22/02/2006 @ 22:02
Hi, 1) yes the changeperm source is available, but you don't need it: if you run on a Linux server, you will copy your iphoto library on this server. Then, you will perform all chmod by yourself for the apache user to have read access on them. changeperm is necessary on the mac, when the iPhoto Library is updated by iPhoto which modifies the permissions in such a way that apache can't access them anymore. 2) I don't know what this means. The error occurs in the php core. I find strange that this could be triggered by wipha. 3) your main problem: I use a mac command-line utility to resize the pictures and compress them (search for 'sips'). You either need to find a linux utility with similar functionalities, or use the php GD module, but this would imply more dev. if you have questions, don't hesitate. Good luck.

Answer #2	by Rpaskowitz - visitor 22/02/2006 @ 22:08
Ok, fine with not needing the changeperm because I can set perms on the library just fine. A popular utility for resizing images is ImageMagick, it's open source, has command line access and is very portable. Plenty of binaries available for mac. I highly recommend its use, or php's GD module as portability is a great thing. wipha is in my mind a great alternative to ugly things the Gallery or Coppermine exporters. I'll look into that second error myself, hopefully I can get that resolved.

Answer #3	by Globs - ( 140 messages ) 22/02/2006 @ 22:16
Yep, What I could do is test the OS, and call the changeperm only on OSX. Then, I would require image magick on Linux and keep using sips on macs (because it's installed by default). When you have ported it to image magick, would you please send me the command you used for resizing and compressing ? Thank's

Answer #4	by rpaskowitz - visitor 22/02/2006 @ 22:59
Switching to php5 seems to have fixed that other error. The problem seems to come from within wipha as a lot of links were incorrect going to cgi-system/ instead of wipha/. I'm working on imagemagick support right now, it's quite easy, I'm just testing it. In the relevant code there is $ratio = $transfoParams['ratio'];, is that width/height, or height/width?

Answer #5	by Poochie - visitor 22/02/2006 @ 23:01
If there is a Mac compiled version of image magick it could be better to use that in OSX too, sips gives quite a slow performance on my 1.33 Ghz G4.

Answer #6	by Poochie - visitor 22/02/2006 @ 23:12
Speed hint: I noticed that iPhotoWebShare is quite faster as it reads thumbnail pictures from iPhoto Library/Data/<YEAR>/<ROLL_NAME>/<PHOTO_NAME> this would accelerate the performance a lot and would also make it linux-compatible!!

Answer #7	by Globs - ( 141 messages ) 22/02/2006 @ 23:27
Dixit... In the relevant code there is $ratio = $transfoParams['ratio'];, is that width/height, or height/width? it's width/height, from the AlbumData.xml file. Dixit... If there is a Mac compiled version of image magick it could be better to use that in OSX too, sips gives quite a slow performance on my 1.33 Ghz G4. Maybe, but the advantage of sips is that is it installed by default on OSX. The less dependencies, the better. Anyway, the image is only computed one time, and is then cached (in wipha/data/cache) for future reuse. Dixit... I noticed that iPhotoWebShare is quite faster as it reads thumbnail pictures from iPhoto Library/Data/<YEAR>/<ROLL_NAME>/<PHOTO_NAME> Do you mean it accesses to thumbnails through direct url ? I try to have as little code as possible on the way to the images, but I set up an authentification system which is supposed to enforce your pictures privacy, so this must be checked for each requested picture. This is probably what makes it slower. Here again, I managed to handle the cache properly, and a thumbnail should only be requested one time by your browser (unless you ask for refresh). The general system is: - compute an image only one time and store it in the cache folder. - manage the browser cache to prevent it to ask the image again when not needed.

Answer #8	by rpaskowitz - visitor 22/02/2006 @ 23:37
I have what I believe is working code but am having a bit of trouble following something. Thumbnails are retrieved by calling main.php?th=<id> This sets action = 'thumb' which in turn calls $wipha->sendThumb(). sendThumb() does the auth check and calls sendImage(). This is where I get lost. sendImage() is called without a ratio, maxHeight, maxWidth or quality. This should have it skip the resized image generation and output the full image. Strangely enough, I do get a thumbnail, but nothing in the cache.

Answer #9	by Globs - ( 142 messages ) 22/02/2006 @ 23:46
Yes, that's because, as much as possible, I use the existing iPhoto images. Here, I just send the original iPhoto thumbnail. I transform images for - the slideshow (max dims to 640 and reduced (a little) quality; main.php?ph=<id>) - photocast imagess (original size, compressed).

Answer #10	by rpaskowitz - visitor 22/02/2006 @ 23:56
From where are the iPhoto thumbnails retrieved? I have wipha grabbing the library from an rsync'd backup, and I purposefully leave out Thumb[32\|64\|JPG].data because they were large and change rapidly. I can have those transfered if need be, but it seems to be working without them, so now it's just curiosity. Resizing code seems to be working great on slideshow, looks good and files land in the cache. Patch is here: http://dev.gentoo.org/~r2d2/utils.diff Wrapping it in OS or tool checking code is probably the best idea.

Answer #11	by Globs - ( 143 messages ) 23/02/2006 @ 00:02
The .data files are useless. I just need AlbumData.xml and images files. Have a look in AlbumData.xml: for each image, it specifies the image path, the original image path (if you modified it), and the thumbnail path. (search for ImagePath and ThumbPath). Thank's for the patch, I'll try to add it in the next release.

Answer #12	by Poochie - visitor 23/02/2006 @ 00:09
Answer to part 3: I still believe that accessing those stored thumbnails is preferrable. Performance is optimum for every user, the page load instantly and the cpu load on the server is very low, null due to computing the image. Using wipha I noticed very big delays and 100% cpu time with up to 4 httpd instances. thumbnail mode: - sudo fs_usage \| grep iphotod \| grep open gave me 24 thumbnails in less than two seconds - sudo fs_usage \| grep httpd \| grep open gave me 15 thumbnails (uncached) in 31 seconds (tested twice) generating a massive flow of messages Please seriously take in consideration the chance of using the already present thumbnails, it requires even less computation and resolves any OS dependancy.

Answer #13	by Poochie - visitor 23/02/2006 @ 00:14
Dixit... Do you mean it accesses to thumbnails through direct url ? It uses them, as I can see from fs_usage, but in the browser they are mapped to a php interpreted string.

Answer #14	by Globs - ( 144 messages ) 23/02/2006 @ 00:15
Ok, I'll try to play with fs_usage and see what's reported, but your last sentence seems irrelevant, since, as I wrote before, thumbnails are not computed at all, but retrieved from the iPhoto data.

Answer #15	by Poochie - visitor 23/02/2006 @ 00:21
Oh, when you told about sips I thoung it was used to make the thumbnails! Then there must be too many things calculated when requesting the page. As fs_usage stats there are lots of calls, plus I always get only one thumbnail at once and the cpu at 100% if you're using a mini it should happen to you too!

Answer #16	by Globs - ( 145 messages ) 23/02/2006 @ 00:42
All these files opened seems to be mostly smarty files. But they are quick to be parsed. When thumbnails are already in the browser cache, I need about 1 sec to display a 15 thumbnails page. But yes, the first time, the entire system is loaded for each image, because I refuse to put direct URL in the page (and I could not do it even if I wanted, the Pictures folder is not in the Sites folder, so not web visible. I would have to play with symlinks as I did in the 0.7 version). Anyway, the authentification requirement also forbids this. And regarding the mini, I agree it's a little underpowered. Mine has 512Mo and swaps sooo often. Oh, one point though: it may seem a little slow to retrieve thumbnails when running locally, but as soon as it's accessed remotely, the network bandwidth is the main issue and I'm not sure you may feel a difference. I'm a right ?

Answer #17	by rpaskowitz - visitor 23/02/2006 @ 00:56
It's holding strong on my webserver and will be making my life much much easier. Tough to judge performance, server is nowhere near me. I think the UI has room for improvement, but as far as I'm concerned, there's only 2 things that are important to me. 1) A bit of a nicer view of the library. For instance, show the albums within folder. I've got 100+ albums/forlders right now, so it could use some organization online. 2) Groups. Would be nice to be able to add people to a group and give them all access to albums with just a few clicks.

Answer #18	by Poochie - visitor 23/02/2006 @ 01:05
1.5 GB here, but it's no good anyways... Using it remotely will result in average bandwidth usage (10kBps average 40 peak), the same 100% cpu usage and one thumbnail at a time loading... maybe a little faster, but not much. I think the problem is the same, difference made from saving Safari from working on the page (which was a bit of weight). I don't see the security issue. Can't you map a php request to the direct thumbnail instead of the temp file? The URL would be the same...

Answer #19	by rpaskowitz - visitor 23/02/2006 @ 01:08
If the thumbnail is grabbed directly over http (http://domain/wipha/data/cache/.....jpg) then someone that is unauthorized would be able to access it directly, which is the security(privacy) issue.

Answer #20	by Poochie - visitor 23/02/2006 @ 01:18
Dixit... If the thumbnail is grabbed directly over http (http://domain/wipha/data/cache/.....jpg) then someone that is unauthorized would be able to access it directly, which is the security(privacy) issue. I'm missing the difference. Without SSL the listener would surely be able to view the image. What I'm saying is that the server should change the read source, but the result to the web client would be the same URL string and Photo, so I wouldn't see any difference for the listener... If I sniff the data my client trans-receives I don't think I'll be able to get the remote path to the file, wouldn't I?

[ 1 2 ]

Top

Document generated in 0.52 second