Пол года назад я этим тоже интересовался: linguistic-suffocation.org/lab/tile/
У моего алгоритма иногда бывают проблемы с последними несколькими строчками
У вас количество картинок в ряду разное, как и на G+, а у автора статьи, как я понял, это самое количество фиксировано. То есть ваш вариант как раз что надо, а у автора статьи задача изначально слишком упрощена.
Впрочем, так совпало, что я вчера вечером занимался тем же самым и накидал свой простенький алгоритм, который делает с разным количеством картинок в ряду при определенных границах по высоте. И уже щас чужие варианты брать не хочется :)
Еще одно: эстетически идеальное решение этой проблемы нам недоступно — это 2D bin packing problem (http://en.wikipedia.org/wiki/Bin_packing_problem). Хотя у нас проблема модифицированная — мы можем пропорционально менять размер, в отличии от задач загрузки контейнеров какой-нибудь баржи или кузова фуры.
Физически проблема другая, а математически, на мой взгляд, она упрощается дополнительной степенью свободы — параметром масштаба для каждого прямоугольника. Может статься, что она неплохо решаема.
Я как раз таки и имел ввиду, что эта дополнительная степень свободы слишком сильно меняет суть задачи, т.е. как мне кажется идеи из исходной задачи здесь будут не очень полезны.
Протестировал
Сервер долго думал (секунд 15)
Картинки показались, как и планировалось, выровненные
Еще вылезла ошибка — Warning: Division by zero in /home/squie198/public_html/imagemos.php on line 160
Лучше на javascript сделать это, пусть браузер сам думает, нечего сервер нагружать
что за мода выкладывать ошибку с полным путем? Неужели нельзя оставить только имя файла и строку с ошибкой. Вы для кого полный путь до файла показываете?
such as using the load_file() (within a SQL Injection) query to view the page source, require the attacker to have the full path to the file they wish to view
Да, прочёл, но к сути моего комментария это не относится. Как, впрочем, и все комментарии из данного дерева до 2го уровня включительно.
А суть такова: паранойя в ИТ это хорошо и замечательно, но когда предоставленных кем-либо данных явно недостаточно для осуществления взлома (скажем, если человек тестировал у себя на виртуалке) либо же они публично доступны (например, демо автора) — это уже перебор. В первом случае это не опасно, а во втором любой сможет получить нужные данные.
А об уязвимостях в работающих системах лучше репортить в личку, да.
А об уязвимостях в работающих системах лучше репортить в личку, да.
Вот-вот. Во-первых дадите время на закрытие (и любой уже, возможно, не сможет получить данные), а во-вторых не станете упрощать жизнь потенциальному взломщику (хоть и попахивает security through obscurity).
>> Лучше на javascript сделать это, пусть браузер сам думает, нечего сервер нагружать
Да ладно вам, человек просто набросал алгоритм на коленке на том, на чем ему удобнее. Никто не предлагает использовать это в том виде в котором оно есть.
Масонри, как по мне, не справляется с основной задачей: плотно заполнить пространство. Да и расчитан он на текстовую информацию, которая не поддается масштабировке по понятным причинам. Хотя штука достойная, я согласен
не совсем то, я его пытался подкрутить для вывода фоток как гугел+, выходило, что легче написать отдельный скрипт
начал писать, потом случайно наткнулся на тот, что указал выше
есть там правда баг с последней фоткой в ряду, у себя пофиксил, но корявенько, как доведу до разумного вида — обязательно закину пул реквест
1) Было интересно реализовать, как минимум.
2) Для простоты, не хотел усложнять код.
3) Вывел ключевой момент кода, в котором идет подсчет. По ссылке есть полное демо.
4) Не привык я к IDE, работаю в блокноте, по старинке.
> работаю в блокноте
Самое ужасное для меня при работе с блокнотом — было перебивание табуляции. Что-то поменял, и все: во имя красивого оформления перебивай n-строчный блок на один-два отступа вправо/влево. Не сильно замечал, но когда перешел на notepad++, как в раю оказался.
Я вот тоже стирал ручками, но самое ужасное для меня, это то, что стираются руки до крови. Теперь использую стиральную машину:
Руки не стираются, но всеравно приходится следить за временем стирки, вынимать белье со стекающей водой, отжимать руками его. В общем надо то-то оптимизировать.
Нужно апгрейдить до современной стиралки. Засыпал порошок, нажал на кнопочку. Все само стирается, отжимается. Но все равно приходится гладить рубашки:( Надо подключать компонент «wife».
1. О посетителях без анлимов некоторые программеры забывают, а жаль — таких очень много
2. Это тестовый код, зачем здесь что либо выносить?
3. Код оформлен в виде кода, который нормальный программер вполне чегко прочитает — что еще надо?
4. И что что не определены переменные? Это ПЫХ, можно не заморачиваться с мелочами
Удачи в дальнейшем развиитии программирования — статус нуба — это поправимо ;)
Вы почти правы — намного проще и почти тот же результат. Только вот в мелочах (в данном случае — неровный правый край) и прячется качество. Согласитесь — выдача поиска картинок от Гугла была бы менее симпатичной в таком варианте.
Автор наверняка проводил эксперимент с сообществом — интересовался, чего ему там закачают. Либо уже все знал, и просто хотел создать/пополнить свою коллекцию пор… Котят!
в общем — есть предложение!
В связи с наступлением НГ2012 — собрать медиа хабра коллекцию картинок.
Т.е. народ присылает картинки на некий ресурс символизируя позитив — остальные могут просматривать оную этот позитив приумножая. Коллекция не будет аналогом гугла так как выборка будет создаваться именно людьми а не поисковиком.
Насколько я помню, в проектах я с подобной подзадачей не сталкивался, а писать только для того чтобы на хабр запостить не очень хочется. Да и к тому же не такая уж и интересная проблема: идеи и так всем понятны, а реализация может зависеть от того, как и где это применяется.
И этот топик в «лучшее за 24 часа». Я сам пхп-быдлокодер и обычно плюсую топики в блоге PHP почти их не читая. Но не настолько же, чтобы эхать тег img и вычислять его width и height, да ещё в style без ресайза собственно картинки через imagemagik или gd…
В чём она может меняться при использовании в качестве галереи? Загрузили новый файл в альбом, пересчитали, отресайзили, и лежит до следующей загрузки или очистки кэша.
Рандомный вывод или вывод результатов поиска — согласен, но тут уж, имхо, вообще на клиенте ресайзить надо. Рандом и поиск и так тяжелые операции, чтоб их чем-то ещё нагружать.
Не понимаю, как вообще могла прийти в голову идея делать это на серверсайде. Ну и код конечно не ахти: лапшичка, да с зашитой логикой представления.
Автор хотел услышать идеи и доработки — я бы советовал хотя бы этот код переписать по-человечески, ну а в продакшене использовать клиент-сайд решения для этой задачи.
Я пользуюсь либой code.google.com/p/phpresizer/ тоже самописанная
Думаю автор сможет от туда много чего себе перенять или просто взять эту либу на вооружение.
1. Поддерживает кеширование откадрированных изображений,
2. работает с полупрозрачными GIF, PNG, JPG
2. Поддерживает движки:
GD (Graphics Draw) library
ImageMagick
GraphicsMagick
3. При кадрированиии можно управлять параметрами:
«width»=>170, // желаемая ширина аватарки
«height»=>210, // желаемая высота аватарки
«aspect»=>false, // сохранять ли пропорции исходного изображения
«crop»=>95, //часть центральной части которую следует увеличить (прозумировать центр)
«quality» => 75 // качество JPEG
«background» => «ff00ae» // цвет котором стоит залить свободные области при $aspect = true;
'zoomSmallImage'=>false, // стоит ли ресайзить маленикие изображния
'pngCompress' => 9 // степень компрессии для png
Есть одна тема для tumblr, там фиксированная ширина картинок, но разная высота, и все подгружается по мере прокрутки страницы. В результате, все очень просто реализовано и без обрезок (простое уменьшение до одинаковой ширины). Хотя, не позволяет избавится от «рваного» края, но делает его эстетически привлекательным просто используя низ, а не левую сторону.
Можно немножко усложнить вам задачу. Бывают фотки слишком растянутые в ширину или в высоту. На том же G+ такие фотки кропятся, чтобы фотка не выходила за определенные границы соотношений w/h и h/w. Представьте что кто-то загрузил фотку 1000x100, или наоборот 100x1000. Вот такие как раз предварительно кропятся до определенных границ (скажем, 400x100 и 100x400), а потом уже в дело входит тот самый алгоритм, про который статья.
php — это ж наше всё. Как то видел клас для прожига дисков. И напишут великие умы свою операционную систему на php, где вместо биоса будет подыматься апач, либо нгинкс. И придет недалекое светлое будущее, и все будут жить в мире и гармонии с окружающим миром. конец пророчества.
Красивый вывод изображений