мне кажется вы слишком глубоко задумываетесь о том, о чем не нужно — особенно об авторских правах в разрезе демосцены и некоммерческих релизов.
Если есть не поддерживаемые больше ресурсы или ресурсы со слабым функционалом, но при этом есть новые силы у новых людей — надо брать и делать. Просто брать и делать. Личные мнения пусть высказывают сами авторы, уже на новом ресурсе. Должна быть эволюция, должны быть изменения на волне новых технологий.
Отлично. Я в тебе не сомневался :)
Не хотел обобщать, просто как ни заикнусь о копировании базы, столько шума появляется.
zxtunes.com — неварт долго мне мозги морочил и резину тянул, а потом и вовсе обвинил в воровстве (!).
zxaaa — ААА матами покрывает ни за что.
WoS — уцепились за авторские права, хотя у самих две трети коллекции на птичьих правах, да разрешение получал Мартин, а не текущая команда.
В общем, мой опыт договаривания с владельцами коллекций пока что был скорее сугубо негативным, чем наоборот.
Люди мыслят категориями собственных коллекций и личных сайтов, а не платформенного архива общеспектрумовского культурного наследия. Не могу никого обвинять в недостатке амбиций, но, честно говоря, ожидал от вышеперечисленных бОлее высокого полета мысли. Впрочем, я готов работать и сотрудничать со всеми вышеперечисленными хоть прямо сейчас, у меня нет никаких объективных причин враждовать.
Да. Это было бы очень правильно, если бы не одно но: у разных юзеров и разных работ может быть GIF или PNG.
1. У юзера может быть выставлен noflick, может быть flicker для gigascreen-работ.
2. В картинке может быть flash-мерцание.
Следовательно, при рендеринге HTML для того, чтобы прописать расширение png или gif, мне нужно слазить на жесткий диск и теоретически уже прегенерить картинку, чтобы узнать — был в ней флэш/гига или нет, будет это гиф или пнг.
То есть, для показа 100 работ надо слазить на жесткий 100 раз — в принципе, не фатально, но:
1. Надо сначала этот проактивный пререндеринг реализовать.
2. Надо померять его влияние на скорость и количество айнодов в файловом кэше.
Сейчас обхожусь более простой схемой — в рендер-приложении для скринов передаю через ссылку имя файла, а расширение буду парсить на ходу. Все равно там контент отдавать, то есть я уже буду знать, какого формата результирующий файл будет и смогу расширение файла приписать к названию и передать в клиент через http-заголовки. На тренировку схожу и сделаю, это слегка костыльный, но относительно простой способ решить задачу.
Было бы всё легко — я бы уже давно прописал :)
Еще как вариант — отказаться от PNG и всё выдавать в GIF. В теории мы по цветам укладываемся в таком случае, тогда можно тупо хардкодить везде .gif и проблем не будет. Кроме возрастающего трафика, так как GIF значительно жирнее, но трафик картинок пока совсем далек от проблемного.
Немного не понял проблемы. Ты поменял гамму? Или что случилось?
Та ссылка, которую я приложил — это уже PNG, поэтому как и любой PNG (вручную приложенный или сгенерированный), он может быть модифицирован по гамме браузером.
Или в чем всё же загвоздка?
Отсутствие PNG-скачивания — результат определенной технической сложности, а более всего моей лени. Тут дело не в борьбе за нативность, одно другому не мешает, тут дело только в некотором юзабилити-разгильдяйстве.
В целом согласен, но я придерживаюсь того, что авторская графика — только нативные форматы. Иначе потом будут проблемы с точностью передачи палитры, получением мигающего гигаскрина, скрытыми пикселями итд.
Если рассматривать ZX-Art как «исторический архив», то в архивации нужно стремиться к максимальному сохранению оригинальной информации. У меня в архитектуре были ошибки, связанные с неверными решениями, теперь исправляем понемногу:
* Алиасы авторов сейчас хранятся тупо.
* Группы сейчас хранятся тупо.
* Description файлы работ в оригинальном виде не хранятся.
Первый пункт инфраструктурно почти готов, второй в ближайшем todo, третий пока на обсуждение.
Везде нужен PNG — больше ничего вообще не надо, везде PNG очевидным способом скачиваемый (а лучше копируемый в буфер штатными настройками браузера). Своей борьбой за нативность вы до диких вещей доводите ситуацию — банально картинку нельзя пошарить с сайта в Фейсбуке или блоге каком. Все норовит SCR какой отдать…
Скриншоты — PNG. Для скриншотов совсем не нужен scr. SCR необходим для графических авторских работ, как показатель нативности формата. А вот PNG необходим вообще всегда и везде.
Если есть не поддерживаемые больше ресурсы или ресурсы со слабым функционалом, но при этом есть новые силы у новых людей — надо брать и делать. Просто брать и делать. Личные мнения пусть высказывают сами авторы, уже на новом ресурсе. Должна быть эволюция, должны быть изменения на волне новых технологий.
Не хотел обобщать, просто как ни заикнусь о копировании базы, столько шума появляется.
zxtunes.com — неварт долго мне мозги морочил и резину тянул, а потом и вовсе обвинил в воровстве (!).
zxaaa — ААА матами покрывает ни за что.
WoS — уцепились за авторские права, хотя у самих две трети коллекции на птичьих правах, да разрешение получал Мартин, а не текущая команда.
В общем, мой опыт договаривания с владельцами коллекций пока что был скорее сугубо негативным, чем наоборот.
Люди мыслят категориями собственных коллекций и личных сайтов, а не платформенного архива общеспектрумовского культурного наследия. Не могу никого обвинять в недостатке амбиций, но, честно говоря, ожидал от вышеперечисленных бОлее высокого полета мысли. Впрочем, я готов работать и сотрудничать со всеми вышеперечисленными хоть прямо сейчас, у меня нет никаких объективных причин враждовать.
нахуйфтопку?казалось бы, причем тут спектрум…
1. У юзера может быть выставлен noflick, может быть flicker для gigascreen-работ.
2. В картинке может быть flash-мерцание.
Следовательно, при рендеринге HTML для того, чтобы прописать расширение png или gif, мне нужно слазить на жесткий диск и теоретически уже прегенерить картинку, чтобы узнать — был в ней флэш/гига или нет, будет это гиф или пнг.
То есть, для показа 100 работ надо слазить на жесткий 100 раз — в принципе, не фатально, но:
1. Надо сначала этот проактивный пререндеринг реализовать.
2. Надо померять его влияние на скорость и количество айнодов в файловом кэше.
Сейчас обхожусь более простой схемой — в рендер-приложении для скринов передаю через ссылку имя файла, а расширение буду парсить на ходу. Все равно там контент отдавать, то есть я уже буду знать, какого формата результирующий файл будет и смогу расширение файла приписать к названию и передать в клиент через http-заголовки. На тренировку схожу и сделаю, это слегка костыльный, но относительно простой способ решить задачу.
Было бы всё легко — я бы уже давно прописал :)
Еще как вариант — отказаться от PNG и всё выдавать в GIF. В теории мы по цветам укладываемся в таком случае, тогда можно тупо хардкодить везде .gif и проблем не будет. Кроме возрастающего трафика, так как GIF значительно жирнее, но трафик картинок пока совсем далек от проблемного.
Та ссылка, которую я приложил — это уже PNG, поэтому как и любой PNG (вручную приложенный или сгенерированный), он может быть модифицирован по гамме браузером.
Или в чем всё же загвоздка?
Давайте чините, а то пропаганда пиксельарта без этого простаивает
Выкладывая scr и png мы во всяком случае уверены, что png сделан не кустарно на коленке с хрен знает какими палитрами и цветами.
Если рассматривать ZX-Art как «исторический архив», то в архивации нужно стремиться к максимальному сохранению оригинальной информации. У меня в архитектуре были ошибки, связанные с неверными решениями, теперь исправляем понемногу:
* Алиасы авторов сейчас хранятся тупо.
* Группы сейчас хранятся тупо.
* Description файлы работ в оригинальном виде не хранятся.
Первый пункт инфраструктурно почти готов, второй в ближайшем todo, третий пока на обсуждение.
Смысл такой: авторская графика — scr, png; скриншот — png.