|
Notes |
|
|
|
|
Может кто-то сделает такую склейку? Сейчас это уже очень просто сделать. Нужно только фреймик с настройками нарисовать и сам формат придумать. |
|
|
|
(0007041)
|
|
zed
|
|
17-05-2012 06:41
|
|
>Сейчас это уже очень просто сделать.
Это смотря как делать. Если вроде BMP, то просто, но там идёт расход памяти на удержание всей строки тайлов (в распакованном виде) и больших размеров RAW всё равно не склеишь. А вот если делать железо-бетонный RAW, с возможностью сводить всю землю на 20-м зуме, то нужно действовать более аккуратно - таскать из кэша тайлики, применять к ним настройки, накладывать оверлеи и потом по-тайлово клеить в RAW.
>Нужно только фреймик с настройками
На вкладке Склеить или Экспорт? На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали". |
|
|
|
(0007045)
|
|
zed
|
17-05-2012 06:56
(edited on: 17-05-2012 06:57) |
|
Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени.
|
|
|
|
|
|
Ну при возможности выделить 1 гиг оперативки этого хватит на склейку картинки шириной в 1 000 000 пикселов. Сравни с 32767 при склейке в bmp. Так что хватит и текущей реализации. |
|
|
|
|
>На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали".
Ага. Нужно сделать. |
|
|
|
|
>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени.
Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл по запросу строки попадающей в диапазон покрываемый талом. Главное что бы эти строки запрашивались последовательно, а в каком порядке не важно. |
|
|
|
(0007049)
|
|
zed
|
|
17-05-2012 07:30
|
|
>на склейку картинки шириной в 1 000 000 пикселов
Делать, так уж нормально и чтоб не возвращаться потом к этому вопросу. А так, размер сводимого RAW будет ограничен размером ОЗУ у пользователя. А кто-то и при 256Мб оперативки захочет создать большой снимок. Имхо, формат RAW тут вопрошается именно как абсолютно безлимитный, с единственным ограничением - свободное место на HDD.
>Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл
Это я про вариант по-тайловой склейки, а не строками. |
|
|
|
|
Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет? На ближайшие годы хватит и текущей реализации.
>А кто-то и при 256Мб оперативки захочет создать большой снимок.
Будет просто своп работать. Долго и беспощадно. |
|
|
|
|
>Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет?
Не шибко дольше, чем линейная запись одного 4Тб файла. При скорости среднестатистического винта в 66Мб\сек - это 16 часов. При учете того, что параллельно надо будет подчитывать мелкие тайлы и таки дергать диск - хрен с ним, сутки работы. Весьма малая кровь для терапиксельного лосслесса...:)
>>А кто-то и при 256Мб оперативки захочет создать большой снимок.
>Будет просто своп работать. Долго и беспощадно.
При нормальной реализации вопроса и обработке потайлово - свопа вообше не будет, так как в памяти одновременно будет висеть не более 1 битмапа 256х256. |
|
|
|
|
>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла?
Где это "там"? RAW как раз и подразумевает отсутствие фиксированного формата, это просто голые данные - и свизуализировать их "в картинку" задача просмотрщика, а не писателя. Как сделаешь - так и будет, другими словами. Хоть в шахматном порядке пиксели клей, главное - задокументировать схему записи и размеры по X\Y\bits (для этого и нужен отдельный мелкий файлик рядом).
Обычно предпочитают (чтобы можно было начать отрисовывать сразу по началу чтения) последовательную запись, где начало файла - левый верхний угол картинки, и далее - вправо\вниз. Но это не стандарт, а просто так обычно делают. |
|
|
|
(0007053)
|
|
zed
|
|
17-05-2012 08:50
|
|
>Будет просто своп работать. Долго и беспощадно.
А по-моему, свалится в Out of memory. |
|
|
|
(0007054)
|
|
vdemidov
|
17-05-2012 08:52
(edited on: 17-05-2012 08:57) |
|
>>Будет просто своп работать. Долго и беспощадно.
> А по-моему, свалится в Out of memory.
Ну если запретить своп или поставить его очень маленьким, то будет. А при достаточном свопе 32-битному приложению доступно до 2 гигов рамки, танцами с бубном можно увеличить до 3-х.
|
|
|
|
|
Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :)
>Не шибко дольше, чем линейная запись одного 4Тб файла.
Это если писать построчно с буфером как я предлагаю. А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест по килобайту в разных местах диска. Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту. |
|
|
|
|
>Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :)
Те, кому мало картинок шириной в 1 000 000 пикселей - уже давно написали свои тулзы, благо что это буквально страница кода, а дальше нужно только откинуться на спинку кресла на сутки.
А вот планирование совершенно ненужных костылей по разрезанию битмапов в теме, которая была создана как раз для ухода от разрезания битмапов - это какой-то неверный путь. Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня.
>А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест
Совершенно верно.
>Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.
Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это.
Разумеется, некий вменяемый буфер для скорости - нужен, но не такой чтобы сваливать его в своп. Имхо, ниже 256Мб щас ни у кого нет - вот оное и использовать.
PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд.
Выигрыш в том, что сжатые лежащие практически в одном месте жпеги читать много быстрее, чем метаться по всему многогигабайтному РАВу с рандомной записью. |
|
|
|
|
>>Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.
> Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это.
Ради интереса посмотрел скорость рендомного чтения блоками по 512 байт и 4К на своем винте. Вышло 0.035 Mb/s и 0.287 Mb/s. Тоесть для килобайта будет где-то 0.1 Mb/s
Пересчитай время наполнения 4-х терабайт. :)
>PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд.
Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку, и винт для чтения этой тучи файлов каждый раз. Так что будет приблизительно эквивалентно свопу по скорости.
>Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня.
Хорошо. Я предложил как получить быстро и просто чуток ограниченное решение. Если его делать никто не хочет, мне то что. Продвинутое и универсальное решение в таком случае делать точно никто не будет. |
|
|
|
|
|
В общем самый производительный метод склейки в RAW это клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM, а потом склеивать из полученных файлов один гигантский. Быстрее ничего не получится. Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится. |
|
|
|
|
>Пересчитай время наполнения 4-х терабайт. :)
Еще раз: я обсуждал крайний пункт пункт отхода от свопа, а не скорость общей работы. Истина, как водится - посередине.
>Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку и винт для чтения этой тучи файлов каждый раз.
Ну процессор-то имхо ни при делах - 1Mx1 битмап есть аналог распаковки 1000х1000 цветного жпег-битмапа в памяти (да у меня валлпейпер в 4 раза больше) - особенно если распараллелить эту распаковку 3900 одинаковых тайлов, а вот винту придется попотеть в любом случае. Но это и ожидалось, собссно. Лично я на это полностью согласныйя - цель оправдывает средства.
>клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM
Вернее, которую позволит 32хбитный САС. Я правильно понимаю?
РАМы-то у меня мноооого, только вот ни сас ни 32бит винда не видят больше 3гиг с копейками, а на винде64 подозреваю что ее не увидит один сас......
>а потом склеивать из полученных файлов один гигантский.
Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно? |
|
|
|
|
>Ну процессор-то имхо ни при делах - 1Mx1 битмап
Нет. Он будет распаковывать каждый тайл полностью. Так что для того что бы получить 4 мегабайта строчки результата, ему придется распаковать джепегов на 1 гиг битмапок. И так для каждой строчки. Будет ну очень медленно.
>Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно?
А это как захочет тот кто будет эту хотелку реализовывать. Я лишь подсказываю способ как это можно реализовать с минимальной сложностью. |
|
|
|
(0007061)
|
|
Tolik
|
|
17-05-2012 11:01
|
|
> Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится.
> Хоть в шахматном порядке пиксели клей
Так может и правда, можно клеить в тайловом порядке? |
|
|
|
|
Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов.
Насчёт памяти, 32-х битное приложение не может вроде как получить более 3Г памяти. Но это относится лишь к линейной памяти, в винде есть механизм по типу старого досовского EMS (http://ru.wikipedia.org/wiki/Address_Windowing_Extensions), и вот там получай сколько хочешь (до ограничения самой винды на размер поддерживаемой памяти). И это работает в 32-битной винде. Зато требует явной поддержки со стороны приложения.
PS. Если что, я не проверял как оно работает, но по идее должно. |
|
|
|
|
>Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов.
Ну оно именно так сейчас и работает, а некоторым кажется, что это слишком просто :) |
|
|
|
|
>Так может и правда, можно клеить в тайловом порядке?
Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть? |
|
|
|
(0007067)
|
|
Tolik
|
|
17-05-2012 12:00
|
|
|
А, значит, "отсутствие фиксированного формата" - нам не подходит, надо делать под определённые открывалки-гляделки. Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки? |
|
|
|
|
>Нет. Он будет распаковывать каждый тайл полностью.
Я про буфер 1Мх1, который придется держать в памяти как RW (куда и будем клеить полоски 256х1)
А распаковывать (в памяти) тайлы можно и поочередно. Вовсе не обязательно их открывать все сразу.
И более того, все нужные тайлы можно закэшировать в память заранее, это для полоски в 1Мх256 - всего лишь 3900 тайлов, т.е.39мб. Загнав в память 39Мб - на выходе поимеем 1Мх256 на вполне себе линейную запись, и никаких промежуточных дерганий диска на чтение.
>Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?
Кто угодно. Надо просто знать что делаешь и зачем - а это уже за рамками и этого тикета, и этого форума.
>надо делать под определённые открывалки-гляделки.
Вот только попробуй....!!
>Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки?
ГеоЭкспресс жрет их на ура и выдает вполне кошерный .sid.
Гисы тоже работают с равами, обеспечивая селективную выборку из файла.
Разумеется, попробовать открыть ЭТО фотошопом - смерти подобно, но это уже не к программе а к юзеру оной, повторяю. Надо понимать, ЗАЧЕМ такие файлы и как с ними делать любоff. То есть - задача довольно специфична сама по себе, но таки нужна. |
|
|
|
(0007072)
|
|
Dima2000
|
17-05-2012 12:27
(edited on: 17-05-2012 12:30) |
|
>А распаковывать (в памяти) тайлы можно и поочередно.
Это увеличивает нагрузку на CPU ровно в 256 раз. Хотя, при отсутствии другого выхода, можно и так. А закэшировать 4к тайлов должна и сама винда, уже со второго (и даже первого) их чтения. Да, согласен, в самой SAS проще и быстрее.
>>Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?
>Кто угодно.
Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-)
Вопрос как раз в том, чтобы клеить под что-то известное, что может быть открыто (тем же ГеоЭкспрессом). И с текущими ограничениями на память в SAS/винде. Вот я почти уверен, что с интерливом по тайлам открыть никто не сможет, какой бы текстовый файлик не приложили ...
|
|
|
|
(0007073)
|
|
zed
|
|
17-05-2012 12:29
|
|
Мне эта задача видится так: спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте. Загружаем подстроку тайлов, гарантированно влезающую в этот кусок озу, производим необходимую обработку и пишем эту подстроку в RAW. Тогда получится, что мы не упадём с out of memory и будем писать на винт не кусочками по 256 пикселей, а достаточно длинными подстроками. Т.е. в частном случае, когда все тайлы строки влазят в память, мы получим тот же вариант, что и сейчас работает для склейки в остальные форматы.
Другими словами, по-хорошему, тут нужен СВОЙ алгоритм манипуляции с тайлами. Тогда будет надёжно и универсально - с любым размером памяти можно будет склеить любой сколь-угодно большой RAW. |
|
|
|
(0007074)
|
|
Dima2000
|
17-05-2012 12:33
(edited on: 17-05-2012 12:35) |
|
>спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте
Имхо совершенно лишний и непонятный вопрос. Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80% (остальное - запас винде на всякий случай) свободной _физической_ памяти на текущий момент. Или половину не свободной, а вообще всей.
|
|
|
|
(0007075)
|
|
zed
|
|
17-05-2012 12:39
|
|
>Имхо совершенно лишний и непонятный вопрос.
Человеку, решившему связаться с RAW этот вопрос должен быть абсолютно ясен. К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб). |
|
|
|
(0007076)
|
|
Dima2000
|
17-05-2012 12:48
(edited on: 17-05-2012 12:54) |
|
Что-то вообще не пойму о чём копья ломаются. Уж если хочется работать с RAW, то память (RAM) нужна по любому. А в 1.5Г памяти влезает полоса 2М*256 ... Т.е. сейчас, без всяких ухищрений, SAS должна клеить картинки до 2М пикселей шириной!
Остальное убил, извините, попутал в расчётах.
|
|
|
|
(0007077)
|
|
zed
|
|
17-05-2012 13:07
|
|
>Что-то вообще не пойму о чём копья ломаются.
О том, что нужно либо заранее, перед началом склейки, как-то сообщить юзеру, что он не сможет склеить снимок с Width более чем xxxx, при текущем размере памяти (и выделять память контролируемо, а не полагаясь на авось - упаду с эксепшеном или нет), либо написать алгоритм без такого ограничения.
Вы же, и vdemidov выше, походу предлагаете вообще никак не контролировать этот вопрос и пускай юзер ограбает сам по первое число, если у него мало оперативки. |
|
|
|
|
>то увеличивает нагрузку на CPU ровно в 256 раз.
Это если попытаться их одновременно распаковать (а зачем?), и до кучи отожрать в памяти х256 места.
>Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-)
Ну так и попробуйте потом из этого тара со жпегами взять RGB конкретного пикселя с конкретными координатами.
>интерливом по тайлам открыть никто не сможет
Даже собственный скрипт не сможет?
>Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80%
А то, что в этой винде может быть УЖЕ запущен какой-нибудь Оракл на 146% ее памяти (УЖЕ со свопом, в смысле) - ты не подумал?
>свободной _физической_ памяти на текущий момент.
А через минуту там запустится Оракл - который так не спрашивает, а тупо ХОЧЕТ свои 80%. А ее нет. И будет тут тикет "А почему Оракла с Сасом конфликтует???"
>К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб).
Настоятельно прошу не делать этот совершенно ненужный комбобокс. Надо памяти - либо брать ее от системы МОЛЧА (хай просвопится. Не смертельно), либо см.ниже.
>О том, что нужно либо заранее, перед началом склейки, как-то сообщить юзеру, что он не сможет склеить снимок с Width более чем xxxx, при текущем размере памяти
А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО? Склейка-то та же, вопрос лишь в объеме наполнения входного буфера: 1 тайл или их полоска на всю ширину изображения.
Либо вообще сделать оптимальный автодетект этого буфера (например, делить физ.память на 4 - и упихивать в это макс.кол-во тайлов).
|
|
|
|
(0007079)
|
|
zed
|
17-05-2012 13:37
(edited on: 17-05-2012 13:38) |
|
>А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО?
Нет не слабо. Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb.
В общем, сделать можно по-разному, поэтому кто первый возмётся (если вообще возмётся) за реализацию, так оно и будет :)
|
|
|
|
|
>>то увеличивает нагрузку на CPU ровно в 256 раз.
>Это если попытаться их одновременно распаковать (а зачем?),
Нет, это если каждый тайл распаковывать по нескольку раз (для получения каждый раз одной строки пикселей, а не всех 256-ти), а не строго один, как сейчас.
Закругляюсь, я похоже не в теме. Вообще не понимаю как можно использовать Планету для работы неделю и более. Картинка 2М*2М пикселей занимает 8К*8К тайлов, 64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток! А читать намного быстрее мелкие тайлы не получится, даже из контейнера трукрипт.
Как получить много памяти под выходной буфер в почти любой винде я вариант предложил, его надо брать проверять, MSDN утверждает что он работает. И даже в своп не попадает! Уж выделить окно в 200К памяти (под один тайл) в _виртуальном_ пространстве всегда можно, это физической памяти не занимает, а дальше лишь успевай дёргать винду для переключения страничек. Для ускорения (чтобы пореже в винду улетать) можно выделить не под 1 тайл, а под 1000, ну или сколько свободно в пространстве SAS-а (а там почти всегда 1.5Г-1.9Г есть). |
|
|
|
|
>Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb.
Угу. Но лично мне и со свопом сойдет - для такой задачи я готов освободить систему. Первый раз что ли "винтом думать"... Это vdemidov тут раскачал лодку. :) |
|
|
|
|
>Нет, это если каждый тайл распаковывать по нескольку раз
Ну и пусть распаковывается. Что такое для современного камня задача "распаковать _из памяти в память_ стандарт прошлого века на битмапе, который без тормозов распаковывается даже на телефоне"?
>Вообще не понимаю как можно использовать Планету для работы неделю и более.
(по секрету) - у меня в job'ах прямо сейчас висит САС с октября прошлого года... Скоро закончит, 98% уже почти по всем из 20и проходов. :)
>64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток!
...а линейное копирование того же тома (с ровно тем же объемом инфы!) занимает какие то часы. Вывод? Не юзайте медленный и ущербный НТФС, особенно в плане ее давно известных проблем при хранении куч мелких файлов. |
|
|
|
|
>Это vdemidov тут раскачал лодку. :)
А я то чем провинился. Я агитирую делать самым простым возможным способом. Пусть, в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз. И сделать ее просто. Это вы тут развели демагогию, что чем делать ограниченное лучше не делать вообще. |
|
|
|
|
>А я то чем провинился.
Ну первым про своп-то именно ты заикнулся, а зря. Можно подумать, САС сам по себе не свопится, огаога.....А так бы сделал сразу со свопом, и никто бы особо и не заметил.
>в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз.
Так хочется ж без ограничений. И без свопа. И чтобы быстро! :)
Резюмирую: делать со свопом, но без нарезки на части. Если у юзверя мало памяти - то можно лио попапить ему мессиджбокс, либо тупо забить и пихать в своп (а не хватит - значит, не хватит. Тут уже подсчитали, что 2М по длинной - вполне влезет в своп, а для большего - разумеется и затраты должны быть больше, и там уже будет другой тикет если что). |
|
|
|
(0007085)
|
|
zed
|
|
17-05-2012 14:52
|
|
>она будет превосходить существующие в десятки раз
Забыл добавить: если у пользователя есть +100500 Гб оперативки.
Так же, не путай: ограниченный вариант - это когда мы заранее просчитываем, сколько нам и чего можно выделять для текущей операции и ставим себя в эти рамки. Текущая же склейка, ничем не ограничена, и будет вываливаться с ошибками (и не вываливается до сих пор только из-за того, что максимальное разрешение существующих форматов относительно невелико). Оно тебе надо? Ну закроешь ты этот тикет - появится рядышком новый - сделать экспорт в RAW без ограничений на использование оперативки. И будет стоять ровно та же задача - написать новый алгоритм. Я ещё понимаю, если бы формат был "горячий" вроде jpeg, без которого в общем-то никуда (потому и терпели вылеты), но тут же никто в плечи не гонит, главное чтобы работало стабильно. |
|
|
|
(0007086)
|
|
Dima2000
|
17-05-2012 14:52
(edited on: 17-05-2012 15:14) |
|
>2М по длинной
Не по длинной, а именно по ширине. Высота может быть любой, раз говорят что SAS теперь клеит потайлово по вертикали.
Натыкался на какой-то баг при общем количестве тайлов более 2млрд, но не помню где именно. Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали). А вполне вероятно в склейке бага и нет.
|
|
|
|
(0007087)
|
|
zed
|
|
17-05-2012 14:53
|
|
>и там уже будет другой тикет если что).
Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :) |
|
|
|
|
>но тут же никто в плечи не гонит, главное чтобы работало стабильно.
+100500, и вот например у меня 32Гб оперативки - и вот убедите меня (как юзера), что мне ее не хватит? Когда скриптам - хватает и 128Мб на всё (клею потайлово - медленно, зато гарантированно и ДЕЙСТВИТЕЛЬНО безразмерно). А так как клею через весьма большие многогигабайтные системные буферы - то и ничуть не медленно даже. :)
>Не по длинной, а именно по ширине.
Тем более.
>Ну значит нефик клеить сразу весь мир на z20 и выше.
А если ВНЕЗАПНО захочется? :)
>Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :)
C другой стороны, таких упоротых гиков надо будет тут на сасгисе еще поискать. Для начала - таких винтов пока еще нету, чтобы прочувствовать лимиты и тикет делать... :)
Да, кстати - до кучи надо продумать момент дырок в РАВе. Либо клеить заранее определенное значение RGB при натыкании на дырку (и тогда нужно бы возможность определения этого дефолтового цвета для дырок), либо сперва заполнять весь рав этим цветом - а потом клеить тайлы какие найдутся (а в дырках цвет останется автоматически). Первый вариант имхо более разумен. |
|
|
|
|
>Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали).
Минус дырки, заметь. |
|
|
|
|
>Минус дырки, заметь.
В полосе выделения дырок быть не может. Насколько я знаю, SAS не поддерживает многосвязные выделения.
>>Ну значит нефик клеить сразу весь мир на z20 и выше.
>А если ВНЕЗАПНО захочется? :)
Уменьшать ширину, не 8К тайлов в полосе, а меньше.
Или использовать не SAS. ;-) |
|
|
|
|
>В полосе выделения дырок быть не может.
Неужели?
>Уменьшать ширину, не 8К тайлов в полосе, а меньше.
>Или использовать не SAS. ;-)
...или сделать нормальный, безлимитный алгоритм. Время-то есть, как правильно указал товарищ zed. |
|
|
|
(0007096)
|
|
Parasite
|
17-05-2012 16:45
(edited on: 17-05-2012 16:53) |
|
>Неужели? Объясните плиз в личку или на форуме как создать область выделения, с внутренней не соединённой с границами дыркой? Или хоть ссылку где про это написано?
Понятия не имею. Выше я про дырки в кэше (= отсуствующие на сервере тайлы) в границах пользовательского выделения, а не про саму "изящно-дырявую" рамку выделения как таковую.
Очевидно же, что выделив ВЕСЬ мир и сводя его например в 19м уровне - получим пустые места в кэше весьма много где, ибо те же окияны кончаются на 12м уровне если не ошибаюсь (а они токи попадают в выделение "весь_мир"). То есть, на 19м зуме на 2\3 выделения будет 404 еррор, и этот момент нам надо будет как-то отдельно отрабатывать. Заливать дефолтовым цветом или еще как иначе, бо "истинно-дырявых" форматов растров пока еще не придумали.
|
|
|
|
|
Кстати, вот тулза делающая как раз "сведение безразмерных битмапов через винт" (но платная): http://www.mcrenox.com.ar/vlijoiner/
Интересно, как они обошли лимиты BMP на размер? Скорее всего - никак.... :) |
|
|
|
(0015933)
|
|
zed
|
|
16-05-2015 08:26
|
|
|
Да ну, каких безразмерных? Ты почитай: "output format is PNG or BMP", так что у них максимум 64k для PNG и 32k для BMP. Эти лимиты не обойдёшь. Безразмерные это всякие ECW/J2K/RAW, но никак не BMP :) |
|