@Per Jessen Disk-space is cheap, especially if you don't need to be worried about backup etc. I'm not sure why you think applying watermarks in an off-line process would any less manageable than doing it on-line. Well, the processing will be "online" in the sense that it will be triggered via an admin interface. The pictures will then be batch-processed by a php script using GD and saved to the disk and later served statically, without the overhead of applying the watermark per-request, at runtime. Less manegeable becouse I would have to keep copies of the pictures on the disk. If I ever want to change these watermarks, I would have to somehow recreate them. It is more work to do than if I used the per-request runtime applying of watermark approach, since in this case, I would just apply the watermarks I wanted and then serve the stream directly from memory. Sounds like you are planning to do the processing off-line then. You > could even do a mix - if you've got a lot of photos (millions and > milloins), applying the watermarks could take a while in itself, so you > could leave that running slowly in the background, but combine it with > an on-line process that does on-demand watermarking (when the photo is > displayed). > Yes, applying the watermarks "offline" in a batch to lots of images could take a while, but the album wouldn't be published before this process is done. So, I don't really understand what you mean by mixing the two approaches. @Nathan for the code that will invoke the watermarking, put it behind another layer, > so that you can easily alter it in the future as the site grows. for > example, you might use strategy pattern, and your initial strategy will use > the current webserver directly. however, as the site begins to grow, you > can add additional webservers, dedicated to running gd on top of php. you > can then write a strategy which will pass the requests off to those boxe(s), > and it will be transparent to your existing code that knows only of the > strategy interface. > > also, as you grow, distributed filesystems are key. for example, your > front-end webserver can handle requests from users on the site, dispatch a > request (restful for instance) to another box, dedicated to gd. since both > boxes share a common filesystem via nfs (or other) the gd box can create the > watermark, which will then be immediately available to the front-end box, > which it could signal w/ another request to say 'hey, the watermark is > ready'. > You have come with some great insights, the strategy idea seems nice and could work. Adding dedicated "image processing" boxes is a good idea, even better if the software to apply it is written in C, but I don't think my use case justifies such an investment of time and money. Another thing that you mentioned that is of great interest to me is the use of a distributed filesystem, since I think I will just pre-process the images in batch to add the watermark, the use of HDD space will grow considerably as time goes by and the app grow. Is this approach transparent enough so that architectural changes to the app wouldn't be necessary? Thank you all for the replies! Marcelo. On Thu, Aug 7, 2008 at 3:52 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: > Bernhard Kohl wrote: > > > I think it also depends on the size of your images. If they are huge > > megapixel files processing them on the fly might cause severe lag. > > Still adding a watermark to an image with 100-200 thousand pixels is > > done within milliseconds on a modern machine. > > > > (You probably meant to send this to the list) > > The OP spoke about "a kind of online photo viewer", so I assumed e.g. > JPEGs at 1024x768 as a typical size, so about 700K pixels. > > > /Per Jessen, Zürich > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
