|
Notes |
|
|
|
Он не дублирует, а дополняет.
В 0000041 упор на сам факт сведения в PNG.
В 0000368 - на сведение именно с прозрачностью, а не просто сохранение в данный формат файла как таковой. |
|
|
|
(0001159)
|
|
gpsMax
|
|
10-03-2011 19:22
|
|
|
Альфой предполагается заливать те места, где нет тайлов? Или что с ней делать? |
|
|
|
|
Альфу предлагается просто оставлять на своем месте там, где она существует на исходных тайлах. Это касается GIF и PNG. Например, тот же гибрид гугля - гиф с прозрачностью (на сервере), при попытке его сведения текущим САСом - получаем белый фон вместо альфы. То же самое и с PNG. То есть, исходно существующий альфа-канал безвозвратно теряется и способов его восстановить из сведенного изображения - нет (кроме как опять обработать в фотошопе и ручками снова добавить прозрачность, то есть - пересоздать всю альфу ручками). Безусловная потеря САСом части информации с изображения не есть гуд, отсюда и хотелка.
И да, как фичу - можно делать "альфа-дырки" на месте отсутствующих тайлов. Было бы приятно в фотошопе просто подложить бакграунд нужного цвета под всю карту, а не иметь сикес выделяя каждый пустой квадратик ручками и заливая краской...ведь оных на карте могут быть десятки, тысячи и даже миллионы... |
|
|
|
|
|
Так как фича касается и GIF(с альфой) в той же мере что и PNG - подредактировал название хотелки. |
|
|
|
|
|
Кстати, при проработке вопроса лучше всего было бы иметь ползунок "альфовости" этой альфы, то есть менять меру прозрачности (согласно обсужденного тут: http://sasgis.org/forum/viewtopic.php?f=2&t=1&p=19807#p19801) |
|
|
|
|
|
Ну и по какой формуле? Допустим на ползунке выбрано 63 из 255, то есть сильно прозрачное. А пиксел имеет прозрачность 195, тоесть почти не прозрачно. Что выводить в результат? |
|
|
|
|
>Ну и по какой формуле? Что выводить в результат?
Из твоих цифирок выше:
a=195 (пиксел)
n=63 (ползунок)
R=(a/100)*n, т.е. в результат выводить 123 (63% от значения 195). То есть - пиксел будет почти точно полупрозрачный, тогда как при исходных a=195 он был "сильно прозрачным" в исходнике.
Ползунок на максимум (100%) даст нам родную картину альфы как она пришла с сервера. Такое положение предлагаю сделать дефолтным.
Ползунок же на 0% - даст нам ноль альфы, т.е.полностью непрозрачные пиксели станут даже там, где они были прозрачными изначально (но RGB у них никто не отменял). То есть, слой визуально станет картой - без шаманства с ZMP. :)
Расчет результирующего цвета идет по каноничным: http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D1%8C%D1%84%D0%B0-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB , у нас лишь введется дополнительная "мера альфовости самой альфы" в процентах от user-defined ползунка. |
|
|
|
|
PS:
>пиксел имеет прозрачность 195, тоесть почти не прозрачно
Альфа - это обратная величина, и a=255 соответствует полной прозрачности, а a=0 - нативному цвету, декларируемому как "бакграунд" в хидере, что вкупе с разрешенной альфой дает прозрачность "баграунд-цвета".
Соответственно, пиксел с a=195 -> это "сильно прозрачный" пиксел. |
|
|
|
(0001815)
|
|
Tolik
|
|
12-04-2011 10:00
|
|
По этой формуле получается только "затемнение" (полу)прозрачных пикселей. Нужно также "осветление" непрозрачных.
Т.е. чтобы альфу 0 можно было превратить (в пределе) в 255. |
|
|
|
|
Ну в САС везде используется альфа в виде однобайтового числа без знака. Так что 0 это полностью прозрачный, а 255 полностью непрозрачный.
и 195 это таки очень непрозрачный.
|
|
|
|
|
>Т.е. чтобы альфу 0 можно было превратить (в пределе) в 255
Каким образом, если начальных данных об альфе по данному пикселу НЕТ? Того самого значения 'a' из примера выше. Будем всегда умножать ползунок, каким бы большим он ни был - на ноль? Результат немного предсказуем. :)
Это раз. А два - что будем делать с клиппингами? Любое положительное значение альфы, помноженное на растущий положительный ползунок, рано или поздно упрется в предел 1 байта (=255). А так как вся картинка у нас не однородная, а содержит какие-то плавные переходы по альфе - то практически сразу получаем ситуацию, когда более альфовые пиксели уже уперлись в 255, а более соседние можно бы и еще подвигать...То есть, придется либо "пересвечивать" (обрезать по 255) бОльшие пиксели и плевать на них с потерей их реальных значений, либо забыть про ползунок как только хоть один пиксель упрется в 255 чтобы не искажать всю картину (а там такие пиксели могут быть изначально с сервера, например полностью прозрачный участок).
>и 195 это таки очень непрозрачный.
Windows/Delphi feature? :(
------------
$tiletemp=Image::Magick->new(size=>255x255, magick=>'png', colorspace=>'RGBA');
$tiletemp->Read("xc:red");
$tiletemp->Set(alpha => 'transparent:255');
$tiletemp->Set('transparent-color' => 'red');
$tiletemp->Mogrify('transparent-color' => 'red');
$tiletemp->Write('test.png');
------------
На выхлопе - "стеклянный" (прозрачный) тайл (#FF0000FF в к.пикселе).
При "transparent:0" - красный непрозрачный тайл (#FF000000)
PS: а мы значение альфы со значением a-маски не путаем? ;) В a-маске как раз обратное положение дел, #00 в маске = прозрачность в изображении (и соответственно #FF альфы, сохраняемый в файл).
В любом случае, это некритично. Если в винде наоборот - ну и иметь это ввиду при расчетах, да и все. Имхо. |
|
|
|
(0001844)
|
|
Tolik
|
|
13-04-2011 09:34
|
|
Умножать на ноль я как бы не предлагал.
Если движок работает только на упрозрачнивание (0 - без изменений, 255 - полная прозрачность), то формула будет:
R = a + n*(255 - a)/255
Это если линейно, а можно и что-то вроде гамма-коррекции замутить. |
|
|
|
|
>Умножать на ноль я как бы не предлагал.
Однако вышеописанная ситуация - не исключена, не так ли?
А клиппинги будут всегда, как только мы попробуем увеличивать уже оптимизированные (изначально лежащие на промежутке 0...255 при максимуме в 255) значения.
>можно и что-то вроде гамма-коррекции замутить.
Угу. Осталось найти того, кто это "что-то" будет мутить. :) |
|
|
|
|
|
А разве есть экспорт в GIF? Если нету, то нужно переименовать хотелку. |
|
|
|
(0004616)
|
|
zed
|
|
23-12-2011 15:08
|
|
|
|
|
(0005185)
|
|
Parasite
|
23-01-2012 09:18
(edited on: 23-01-2012 09:19) |
|
>А разве есть экспорт в GIF? Если нету, то нужно переименовать хотелку.
Смысл хотелки и заключался в том, чтобы этот экспорт _сделать_. С прозрачностью. из числа тех ГИФ-тайлов (ГИФ, внимание), которые приходят в программу.
>Изменил.
Ай малацца! А теперь меняй обратно, ибо 50% описания хотелки - это еще не вся описанная хотелка. :)
|
|
|
|
(0005186)
|
|
zed
|
23-01-2012 09:20
(edited on: 23-01-2012 09:35) |
|
А нефиг распыляться в описании. Одна хотелка - одно пожелание. PNG и GIF это 2 хотелки. Хочешь ещё отдельно GIF - заводи новую. Тем более, что в истории правок тикета видно, что изначально хотелка была про PNG, а GIF был добавлен позже, как "однотипный".
|
|
|
|
|
>PNG и GIF это 2 хотелки.
Хотелка ОДНА - прекращение потерь альфа-канала там, где оно нужно.
А я не виноват, что альфа у нас в сас приходит И с гифом, И с пнг. Будет приходить с чем-то третьим - я его тоже сюда допишу, ибо смысл хотелки останется всё в том же: возможность сохранять альфу в тот формат, _в каком оно и пришло_ (или в соседний, коль скоро их два).
PS: Не вижу никакой особой технической сложности сохранять в ГИФ\ПНГ на выходе, коль скоро программой они токи давно и успешно принимаются на входе (то есть, как минимум декодер в проге есть, осталось включить и кодер в эти форматы). Подозреваю даже, что это делается даже той же либой что и другие общераспространенные и открытые форматы. |
|
|
|
(0005191)
|
|
Tolik
|
|
23-01-2012 10:04
|
|
Parasite, зачем спорить, легче открыть новую хотелку. С png ведь уже работает, стало быть и хотелка д.б. resolved, а с гифом неизвестно когда будет.
Для экспорта в png была присобачена libpng15.dll
Для гифа она, очевидно, не подходит, надо отыскать (или написать) другую. |
|
|
|
(0005192)
|
|
zed
|
|
23-01-2012 10:04
|
|
Нет, сохранение в GIF нужно прикручивать отдельно. Одно дело открыть/сохранить гифку 256*256 pix, а другое дело нормально сохранить снимок в большом разрешении (out of memory с jpeg'ом ещё помним?).
Так что, не важно, с какими форматами САС умеет работать в режиме просмотра карт, склейка это совсем другая кухня и на каждый формат нужна своя хотелка. Дописывание в уже отработанную хотелку новых пожеланий лишено смысла. |
|
|
|
|
>легче открыть новую хотелку
Кому легче?
Лично мне легче было год назад написать костыль и сделать ту конкретную работу тогда, а не после даты назначения хотелки (назначенной на ..хх, а потом и на ..хххх).
Хотелка тут осталась для тех, кому понадобится тот же функционал ровно в зоне моей же задачи (и посему редактирование\кастрацию оной я и не приветствую).
У кого другие пожелания\другие понимания оной - ать-два в "Создать новый инцидент", а мне-то зачем? Что хотел - я описал выше на момент того запроса, а сейчас оно давно неактуально. Если сделают - будет решпект, нет - так нет, можно вообще закрыть. :)
>нормально сохранить снимок в большом разрешении (out of memory с jpeg'ом ещё помним?)
Ну ГИФ намного "легче" жпега (и даже ПНГ, если ничего не путаю). "Снимок в большом разрешении" и так создается САСом для сохранения в любой формат (перед кодированием собственно в файл). Задача, имхо, брать линию с того "большого разрешения"\переводить в индексн.цвета\писать в файл, повторить пока линии не кончатся. Чтобы на одной линии вылез "out of memory" - это еще надо очень постараться.... Это если безо всяких либ. Имхо, повторюсь - кодингу САСа я не советчик, но если бы делал я - я бы делал именно так. :) |
|
|
|
(0005199)
|
|
zed
|
|
23-01-2012 10:58
|
|
>"Снимок в большом разрешении" и так создается САСом для сохранения в любой формат
Неа, САСом создаётся только битмапка 256*TargetWidth.
>Это если безо всяких либ.
Без всяких либ, при сохранении что в jpeg, что в png, что в gif будет out of memory. Либы умеют клеить снимки без дикого использования памяти, а вот внутренний компонент - нет, он создаёт (пытается) в памяти целиком битмапку, а потом только её кодирует. |
|
|
|
|
>САСом создаётся только битмапка 256*TargetWidth.
Вот в его пределах и плясать 256 раз, получая однопиксельные полоски и топча их в индекс и затем в out. Не? |
|
|
|
(0005204)
|
|
zed
|
|
23-01-2012 14:30
|
|
|