Форум PHP

я со своего компа гружу его фотки и знак ставится. он грузит со своего - знак не ставится. это ведь на сервере делается, при чем тут комп?

говорит, что иногда пишется. но чаще не пишется. не может понять, при каких условиях это происходит. прошу его прислать мне те фотки,к оторые он грузит, т.к. я гружу те, которые уже на сайте, т.е. уже уменьшенные, - молчит. не шлет. как с такими людьми работать? :(

гружу сама большие (до 1Мб) фотки, знак пишется...

еще вопрос - лучше этот знак писать на фотку при загрузке или "на лету" в тот момент, когда ее запросит браузер?

Я бы в первую очередь предположил, что напутано с координатами простановки водяного знака, либо по цвету просто скрывается (клиент же всегда прав).
А по поводу того, когда знак наводить, оба способа чем-то хороши: если накладывать при загрузке, то вроде как снижается нагрузка на сервер при последующих обращениях к картинке, а если вешать знак при отдаче, то проще будет, скажем, перейти на новый логотип, то есть сменить водяной знак без перезаливки картинок, но так как трудно защитить картинку от прямого скачивания, то есть опасность утечки непомеченных файлов.
А как, кстати, Вы предполагаете вешать знак на картинку "на лету"?

понятия не имею. когда-то давно прочитала, что способ "на лету" жрет много ресурсов и отказалась от него. мне еще предлагают сделать псевдокэш - хранить отдельно фотки, которые уже смотрел кто-то и на которых уже стоит знак... это, по-моему, вообще зверство - плодить дубликаты!

У вас есть выбор: пожертвовать ресурсами и накладывать знак каждый раз или наложить знак один раз и сохранять эти "зверские дубликаты".
Рекомендую второй способ.

возможно-ли такое что из-за time_limit, фотография успевает сохраняться но на ней не успевается ставить водяной знак ?
Или возможно-ли что он вообще подсовывает файлы не того формата который способен правильно обработать скрипт ?

время работы скрипта я увеличила, хотя и не уверена, что сервер эту команду проглотил.
тип фоток правильный, иначе они бы вообще не грузились и не уменьшались.
я сама грузила большие и все работало. положение знака вычисляется уже с новыми размерами фотки.

Лично я вижу только один способ накладывания "он флай" - <img src='get_photo_and_put_watermark.php?item=photo99.jpg'>, в котором photo99 хранится в недоступной через веб директории. Но дисковое пространство нынче сильно дешево, гораздо дешевле, чем убыток, вызванный отбоем посетителей при перегрузке сервера. Саня дело говорит.

только что загрузила фотку весом 6.7 Мб, знак прилип :)

клиент - молчит в тряпочку. у него сейчас в базе около 4 тыс. объяв, у каждой м.б. до 10, а то и больше фоток. мне не жалко места, пусть платит. но ведь у него сам знак не клеится! он будет сам смотреть фотки, они будут записываться в псевдокэш, а где гарантия, что на них будет знак?

даже не может, как я прошу, слить себе одну любую фотку с сайта и снова ее же загрузить... надо же узнать, что он такое с ними делает, что они его не слушаются!

Ну, а еще можно расслабиться и не решать невозникших проблем: будет новый логотип, будут новые фотки с новым водяным знаком, а старые – со старым.
А Вы сама видите на сайте фотографии без водяных знаков, залитые клиентом?

вижу. проблема есть - клиент хочет знак, а его нет. я как раз и не хочу делать то, что, возможно, тоже работать не будет (кэш). сначала надо сделать, чтоб у него всегда клеился знак при загрузке, а потом можно будет подумать и о кэше и о "полете"...

Согласитесь, для решения данной проблемы у нас маловато информации. Ни кода обработчика, ни примеров работы.

обработчик работает. поменяла шрифт, работает (у меня). меня интересует сейчас только исходная фотка. жду ответа от заказчика. он не первый, кому я этот скрипт ставлю, ни у кого таких проблем не было...

прогресс. углядела, что на фотке, которая говорит, что нету фото, есть знак! а эту фотку точно только заказчик грузит, я ее большой и не видела никогда. скачала ее по FTP.

Может, проблема носит чисто инженерный характер, и заказчику надо протереть монитор? ))
Или поработать над контрастностью водяного знака...

вставила в код одну строчку, чтобы тихой сапой скрасть у заказчика исходную фотку, ничего с ней не делая скриптом. закинула ("удочку"). сижу в засаде, жду. а то вижу, что он фотки грузит, а мои письма не отвечает...

:) удачно Вам сцапать заказчика.
но он-же сам говорил, что иногда всё получается а иногда нет. Поэтому всётаки я-бы не расчитывал сильно что-то выяснить таким образом. Тем-более что возможно сам заказчик просто перепутал когда высказал что-то, и молчит потомучто ему теперь стыдно за своё невежество :) И у Вас есть повод вообще ничего не делать пока он не объяснится.

мммдяяя, это у него "маленькие" фотки. всего 3500рх в ширину... 3.5 Мб ...
но собака порылась совсем в другом месте. :)

он, гад, даже не удосужился мне сказать, откуда, с какой страницы он грузит. раньше у меня был ввод фоток в той же форме, что и само объявление. а потом я поменяла, сделала отдельную страницу. у всех. кроме этого. этот продолжал грузить фотки пачками. я и удивилась, как это он так быстро, за 30 сек, 6 фоток закинул. потом вспомнила, что была форма для массового аплоада. он в ней и сидит, гад. а я скрипт кинула в ту, которая по одной грузит (так удобнее оказалось)...

всем спасибо. мне - срочно в отпуск :)

способ формирования целевого изображения "на лету" жрет ресурсов не больше чем тот же способ "при загрузке" .
Просто если одна фотка, будучи загруженной единожды, подвергается тысяче просмотров, то операция формирования целевого изображения будет выполняться тысячу раз. Вместо того, чтоб оказаться выполненной единожды.
Безусловно реактивность отклика окажется ниже всякого разумения, т.к. кеширования нет, и при каждом чихе фотка будет перезапрошена.
Если, допустим, запомненная фотка, оказавшись в кеше, запрашивается 1 раз из сотни, получается такая картина:

отрисовок запросов формирований способом    1000      10       1         при загрузке    1000    1000    1000         на лету