0000295: Сохранение (либо экспорт) графики в RAW-формат

Notes
(0007038) vdemidov (manager) 17-05-2012 05:14	Может кто-то сделает такую склейку? Сейчас это уже очень просто сделать. Нужно только фреймик с настройками нарисовать и сам формат придумать.

(0007041) zed (manager) 17-05-2012 06:41	>Сейчас это уже очень просто сделать. Это смотря как делать. Если вроде BMP, то просто, но там идёт расход памяти на удержание всей строки тайлов (в распакованном виде) и больших размеров RAW всё равно не склеишь. А вот если делать железо-бетонный RAW, с возможностью сводить всю землю на 20-м зуме, то нужно действовать более аккуратно - таскать из кэша тайлики, применять к ним настройки, накладывать оверлеи и потом по-тайлово клеить в RAW. >Нужно только фреймик с настройками На вкладке Склеить или Экспорт? На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали".

(0007045) zed (manager) 17-05-2012 06:56 edited on: 17-05-2012 06:57	Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени.

(0007046) vdemidov (manager) 17-05-2012 07:08	Ну при возможности выделить 1 гиг оперативки этого хватит на склейку картинки шириной в 1 000 000 пикселов. Сравни с 32767 при склейке в bmp. Так что хватит и текущей реализации.

(0007047) vdemidov (manager) 17-05-2012 07:09	>На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали". Ага. Нужно сделать.

(0007048) vdemidov (manager) 17-05-2012 07:12	>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени. Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл по запросу строки попадающей в диапазон покрываемый талом. Главное что бы эти строки запрашивались последовательно, а в каком порядке не важно.

(0007049) zed (manager) 17-05-2012 07:30	>на склейку картинки шириной в 1 000 000 пикселов Делать, так уж нормально и чтоб не возвращаться потом к этому вопросу. А так, размер сводимого RAW будет ограничен размером ОЗУ у пользователя. А кто-то и при 256Мб оперативки захочет создать большой снимок. Имхо, формат RAW тут вопрошается именно как абсолютно безлимитный, с единственным ограничением - свободное место на HDD. >Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл Это я про вариант по-тайловой склейки, а не строками.

(0007050) vdemidov (manager) 17-05-2012 07:44	Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет? На ближайшие годы хватит и текущей реализации. >А кто-то и при 256Мб оперативки захочет создать большой снимок. Будет просто своп работать. Долго и беспощадно.

(0007051) Parasite (administrator) 17-05-2012 08:32	>Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет? Не шибко дольше, чем линейная запись одного 4Тб файла. При скорости среднестатистического винта в 66Мб\сек - это 16 часов. При учете того, что параллельно надо будет подчитывать мелкие тайлы и таки дергать диск - хрен с ним, сутки работы. Весьма малая кровь для терапиксельного лосслесса...:) >>А кто-то и при 256Мб оперативки захочет создать большой снимок. >Будет просто своп работать. Долго и беспощадно. При нормальной реализации вопроса и обработке потайлово - свопа вообше не будет, так как в памяти одновременно будет висеть не более 1 битмапа 256х256.

(0007052) Parasite (administrator) 17-05-2012 08:38	>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Где это "там"? RAW как раз и подразумевает отсутствие фиксированного формата, это просто голые данные - и свизуализировать их "в картинку" задача просмотрщика, а не писателя. Как сделаешь - так и будет, другими словами. Хоть в шахматном порядке пиксели клей, главное - задокументировать схему записи и размеры по X\Y\bits (для этого и нужен отдельный мелкий файлик рядом). Обычно предпочитают (чтобы можно было начать отрисовывать сразу по началу чтения) последовательную запись, где начало файла - левый верхний угол картинки, и далее - вправо\вниз. Но это не стандарт, а просто так обычно делают.

(0007053) zed (manager) 17-05-2012 08:50	>Будет просто своп работать. Долго и беспощадно. А по-моему, свалится в Out of memory.

(0007054) vdemidov (manager) 17-05-2012 08:52 edited on: 17-05-2012 08:57	>>Будет просто своп работать. Долго и беспощадно. > А по-моему, свалится в Out of memory. Ну если запретить своп или поставить его очень маленьким, то будет. А при достаточном свопе 32-битному приложению доступно до 2 гигов рамки, танцами с бубном можно увеличить до 3-х.

(0007055) vdemidov (manager) 17-05-2012 08:57	Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :) >Не шибко дольше, чем линейная запись одного 4Тб файла. Это если писать построчно с буфером как я предлагаю. А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест по килобайту в разных местах диска. Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.

(0007056) Parasite (administrator) 17-05-2012 09:31	>Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :) Те, кому мало картинок шириной в 1 000 000 пикселей - уже давно написали свои тулзы, благо что это буквально страница кода, а дальше нужно только откинуться на спинку кресла на сутки. А вот планирование совершенно ненужных костылей по разрезанию битмапов в теме, которая была создана как раз для ухода от разрезания битмапов - это какой-то неверный путь. Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня. >А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест Совершенно верно. >Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту. Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это. Разумеется, некий вменяемый буфер для скорости - нужен, но не такой чтобы сваливать его в своп. Имхо, ниже 256Мб щас ни у кого нет - вот оное и использовать. PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд. Выигрыш в том, что сжатые лежащие практически в одном месте жпеги читать много быстрее, чем метаться по всему многогигабайтному РАВу с рандомной записью.

(0007057) vdemidov (manager) 17-05-2012 09:52	>>Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту. > Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это. Ради интереса посмотрел скорость рендомного чтения блоками по 512 байт и 4К на своем винте. Вышло 0.035 Mb/s и 0.287 Mb/s. Тоесть для килобайта будет где-то 0.1 Mb/s Пересчитай время наполнения 4-х терабайт. :) >PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд. Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку, и винт для чтения этой тучи файлов каждый раз. Так что будет приблизительно эквивалентно свопу по скорости. >Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня. Хорошо. Я предложил как получить быстро и просто чуток ограниченное решение. Если его делать никто не хочет, мне то что. Продвинутое и универсальное решение в таком случае делать точно никто не будет.

(0007058) vdemidov (manager) 17-05-2012 10:02	В общем самый производительный метод склейки в RAW это клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM, а потом склеивать из полученных файлов один гигантский. Быстрее ничего не получится. Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится.

(0007059) Parasite (administrator) 17-05-2012 10:39	>Пересчитай время наполнения 4-х терабайт. :) Еще раз: я обсуждал крайний пункт пункт отхода от свопа, а не скорость общей работы. Истина, как водится - посередине. >Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку и винт для чтения этой тучи файлов каждый раз. Ну процессор-то имхо ни при делах - 1Mx1 битмап есть аналог распаковки 1000х1000 цветного жпег-битмапа в памяти (да у меня валлпейпер в 4 раза больше) - особенно если распараллелить эту распаковку 3900 одинаковых тайлов, а вот винту придется попотеть в любом случае. Но это и ожидалось, собссно. Лично я на это полностью согласныйя - цель оправдывает средства. >клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM Вернее, которую позволит 32хбитный САС. Я правильно понимаю? РАМы-то у меня мноооого, только вот ни сас ни 32бит винда не видят больше 3гиг с копейками, а на винде64 подозреваю что ее не увидит один сас...... >а потом склеивать из полученных файлов один гигантский. Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно?

(0007060) vdemidov (manager) 17-05-2012 10:53	>Ну процессор-то имхо ни при делах - 1Mx1 битмап Нет. Он будет распаковывать каждый тайл полностью. Так что для того что бы получить 4 мегабайта строчки результата, ему придется распаковать джепегов на 1 гиг битмапок. И так для каждой строчки. Будет ну очень медленно. >Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно? А это как захочет тот кто будет эту хотелку реализовывать. Я лишь подсказываю способ как это можно реализовать с минимальной сложностью.

(0007061) Tolik (manager) 17-05-2012 11:01	> Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится. > Хоть в шахматном порядке пиксели клей Так может и правда, можно клеить в тайловом порядке?

(0007062) Dima2000 (developer) 17-05-2012 11:09	Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов. Насчёт памяти, 32-х битное приложение не может вроде как получить более 3Г памяти. Но это относится лишь к линейной памяти, в винде есть механизм по типу старого досовского EMS (http://ru.wikipedia.org/wiki/Address_Windowing_Extensions), и вот там получай сколько хочешь (до ограничения самой винды на размер поддерживаемой памяти). И это работает в 32-битной винде. Зато требует явной поддержки со стороны приложения. PS. Если что, я не проверял как оно работает, но по идее должно.

(0007063) vdemidov (manager) 17-05-2012 11:12	>Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов. Ну оно именно так сейчас и работает, а некоторым кажется, что это слишком просто :)

(0007064) Dima2000 (developer) 17-05-2012 11:24	>Так может и правда, можно клеить в тайловом порядке? Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?

(0007067) Tolik (manager) 17-05-2012 12:00	А, значит, "отсутствие фиксированного формата" - нам не подходит, надо делать под определённые открывалки-гляделки. Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки?

(0007070) Parasite (administrator) 17-05-2012 12:16	>Нет. Он будет распаковывать каждый тайл полностью. Я про буфер 1Мх1, который придется держать в памяти как RW (куда и будем клеить полоски 256х1) А распаковывать (в памяти) тайлы можно и поочередно. Вовсе не обязательно их открывать все сразу. И более того, все нужные тайлы можно закэшировать в память заранее, это для полоски в 1Мх256 - всего лишь 3900 тайлов, т.е.39мб. Загнав в память 39Мб - на выходе поимеем 1Мх256 на вполне себе линейную запись, и никаких промежуточных дерганий диска на чтение. >Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть? Кто угодно. Надо просто знать что делаешь и зачем - а это уже за рамками и этого тикета, и этого форума. >надо делать под определённые открывалки-гляделки. Вот только попробуй....!! >Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки? ГеоЭкспресс жрет их на ура и выдает вполне кошерный .sid. Гисы тоже работают с равами, обеспечивая селективную выборку из файла. Разумеется, попробовать открыть ЭТО фотошопом - смерти подобно, но это уже не к программе а к юзеру оной, повторяю. Надо понимать, ЗАЧЕМ такие файлы и как с ними делать любоff. То есть - задача довольно специфична сама по себе, но таки нужна.

(0007072) Dima2000 (developer) 17-05-2012 12:27 edited on: 17-05-2012 12:30	>А распаковывать (в памяти) тайлы можно и поочередно. Это увеличивает нагрузку на CPU ровно в 256 раз. Хотя, при отсутствии другого выхода, можно и так. А закэшировать 4к тайлов должна и сама винда, уже со второго (и даже первого) их чтения. Да, согласен, в самой SAS проще и быстрее. >>Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть? >Кто угодно. Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-) Вопрос как раз в том, чтобы клеить под что-то известное, что может быть открыто (тем же ГеоЭкспрессом). И с текущими ограничениями на память в SAS/винде. Вот я почти уверен, что с интерливом по тайлам открыть никто не сможет, какой бы текстовый файлик не приложили ...

(0007073) zed (manager) 17-05-2012 12:29	Мне эта задача видится так: спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте. Загружаем подстроку тайлов, гарантированно влезающую в этот кусок озу, производим необходимую обработку и пишем эту подстроку в RAW. Тогда получится, что мы не упадём с out of memory и будем писать на винт не кусочками по 256 пикселей, а достаточно длинными подстроками. Т.е. в частном случае, когда все тайлы строки влазят в память, мы получим тот же вариант, что и сейчас работает для склейки в остальные форматы. Другими словами, по-хорошему, тут нужен СВОЙ алгоритм манипуляции с тайлами. Тогда будет надёжно и универсально - с любым размером памяти можно будет склеить любой сколь-угодно большой RAW.

(0007074) Dima2000 (developer) 17-05-2012 12:33 edited on: 17-05-2012 12:35	>спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте Имхо совершенно лишний и непонятный вопрос. Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80% (остальное - запас винде на всякий случай) свободной _физической_ памяти на текущий момент. Или половину не свободной, а вообще всей.

(0007075) zed (manager) 17-05-2012 12:39	>Имхо совершенно лишний и непонятный вопрос. Человеку, решившему связаться с RAW этот вопрос должен быть абсолютно ясен. К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб).

(0007076) Dima2000 (developer) 17-05-2012 12:48 edited on: 17-05-2012 12:54	Что-то вообще не пойму о чём копья ломаются. Уж если хочется работать с RAW, то память (RAM) нужна по любому. А в 1.5Г памяти влезает полоса 2М*256 ... Т.е. сейчас, без всяких ухищрений, SAS должна клеить картинки до 2М пикселей шириной! Остальное убил, извините, попутал в расчётах.

(0007077) zed (manager) 17-05-2012 13:07	>Что-то вообще не пойму о чём копья ломаются. О том, что нужно либо заранее, перед началом склейки, как-то сообщить юзеру, что он не сможет склеить снимок с Width более чем xxxx, при текущем размере памяти (и выделять память контролируемо, а не полагаясь на авось - упаду с эксепшеном или нет), либо написать алгоритм без такого ограничения. Вы же, и vdemidov выше, походу предлагаете вообще никак не контролировать этот вопрос и пускай юзер ограбает сам по первое число, если у него мало оперативки.

(0007078) Parasite (administrator) 17-05-2012 13:22 edited on: 17-05-2012 13:22	>то увеличивает нагрузку на CPU ровно в 256 раз. Это если попытаться их одновременно распаковать (а зачем?), и до кучи отожрать в памяти х256 места. >Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-) Ну так и попробуйте потом из этого тара со жпегами взять RGB конкретного пикселя с конкретными координатами. >интерливом по тайлам открыть никто не сможет Даже собственный скрипт не сможет? >Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80% А то, что в этой винде может быть УЖЕ запущен какой-нибудь Оракл на 146% ее памяти (УЖЕ со свопом, в смысле) - ты не подумал? >свободной _физической_ памяти на текущий момент. А через минуту там запустится Оракл - который так не спрашивает, а тупо ХОЧЕТ свои 80%. А ее нет. И будет тут тикет "А почему Оракла с Сасом конфликтует???" >К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб). Настоятельно прошу не делать этот совершенно ненужный комбобокс. Надо памяти - либо брать ее от системы МОЛЧА (хай просвопится. Не смертельно), либо см.ниже. >О том, что нужно либо заранее, перед началом склейки, как-то сообщить юзеру, что он не сможет склеить снимок с Width более чем xxxx, при текущем размере памяти А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО? Склейка-то та же, вопрос лишь в объеме наполнения входного буфера: 1 тайл или их полоска на всю ширину изображения. Либо вообще сделать оптимальный автодетект этого буфера (например, делить физ.память на 4 - и упихивать в это макс.кол-во тайлов).

(0007079) zed (manager) 17-05-2012 13:37 edited on: 17-05-2012 13:38	>А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО? Нет не слабо. Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb. В общем, сделать можно по-разному, поэтому кто первый возмётся (если вообще возмётся) за реализацию, так оно и будет :)

(0007080) Dima2000 (developer) 17-05-2012 13:42	>>то увеличивает нагрузку на CPU ровно в 256 раз. >Это если попытаться их одновременно распаковать (а зачем?), Нет, это если каждый тайл распаковывать по нескольку раз (для получения каждый раз одной строки пикселей, а не всех 256-ти), а не строго один, как сейчас. Закругляюсь, я похоже не в теме. Вообще не понимаю как можно использовать Планету для работы неделю и более. Картинка 2М2М пикселей занимает 8К8К тайлов, 64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток! А читать намного быстрее мелкие тайлы не получится, даже из контейнера трукрипт. Как получить много памяти под выходной буфер в почти любой винде я вариант предложил, его надо брать проверять, MSDN утверждает что он работает. И даже в своп не попадает! Уж выделить окно в 200К памяти (под один тайл) в _виртуальном_ пространстве всегда можно, это физической памяти не занимает, а дальше лишь успевай дёргать винду для переключения страничек. Для ускорения (чтобы пореже в винду улетать) можно выделить не под 1 тайл, а под 1000, ну или сколько свободно в пространстве SAS-а (а там почти всегда 1.5Г-1.9Г есть).

(0007081) Parasite (administrator) 17-05-2012 13:43	>Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb. Угу. Но лично мне и со свопом сойдет - для такой задачи я готов освободить систему. Первый раз что ли "винтом думать"... Это vdemidov тут раскачал лодку. :)

(0007082) Parasite (administrator) 17-05-2012 13:50	>Нет, это если каждый тайл распаковывать по нескольку раз Ну и пусть распаковывается. Что такое для современного камня задача "распаковать _из памяти в память_ стандарт прошлого века на битмапе, который без тормозов распаковывается даже на телефоне"? >Вообще не понимаю как можно использовать Планету для работы неделю и более. (по секрету) - у меня в job'ах прямо сейчас висит САС с октября прошлого года... Скоро закончит, 98% уже почти по всем из 20и проходов. :) >64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток! ...а линейное копирование того же тома (с ровно тем же объемом инфы!) занимает какие то часы. Вывод? Не юзайте медленный и ущербный НТФС, особенно в плане ее давно известных проблем при хранении куч мелких файлов.

(0007083) vdemidov (manager) 17-05-2012 14:15	>Это vdemidov тут раскачал лодку. :) А я то чем провинился. Я агитирую делать самым простым возможным способом. Пусть, в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз. И сделать ее просто. Это вы тут развели демагогию, что чем делать ограниченное лучше не делать вообще.

(0007084) Parasite (administrator) 17-05-2012 14:36	>А я то чем провинился. Ну первым про своп-то именно ты заикнулся, а зря. Можно подумать, САС сам по себе не свопится, огаога.....А так бы сделал сразу со свопом, и никто бы особо и не заметил. >в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз. Так хочется ж без ограничений. И без свопа. И чтобы быстро! :) Резюмирую: делать со свопом, но без нарезки на части. Если у юзверя мало памяти - то можно лио попапить ему мессиджбокс, либо тупо забить и пихать в своп (а не хватит - значит, не хватит. Тут уже подсчитали, что 2М по длинной - вполне влезет в своп, а для большего - разумеется и затраты должны быть больше, и там уже будет другой тикет если что).

(0007085) zed (manager) 17-05-2012 14:52	>она будет превосходить существующие в десятки раз Забыл добавить: если у пользователя есть +100500 Гб оперативки. Так же, не путай: ограниченный вариант - это когда мы заранее просчитываем, сколько нам и чего можно выделять для текущей операции и ставим себя в эти рамки. Текущая же склейка, ничем не ограничена, и будет вываливаться с ошибками (и не вываливается до сих пор только из-за того, что максимальное разрешение существующих форматов относительно невелико). Оно тебе надо? Ну закроешь ты этот тикет - появится рядышком новый - сделать экспорт в RAW без ограничений на использование оперативки. И будет стоять ровно та же задача - написать новый алгоритм. Я ещё понимаю, если бы формат был "горячий" вроде jpeg, без которого в общем-то никуда (потому и терпели вылеты), но тут же никто в плечи не гонит, главное чтобы работало стабильно.

(0007086) Dima2000 (developer) 17-05-2012 14:52 edited on: 17-05-2012 15:14	>2М по длинной Не по длинной, а именно по ширине. Высота может быть любой, раз говорят что SAS теперь клеит потайлово по вертикали. Натыкался на какой-то баг при общем количестве тайлов более 2млрд, но не помню где именно. Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали). А вполне вероятно в склейке бага и нет.

(0007087) zed (manager) 17-05-2012 14:53	>и там уже будет другой тикет если что). Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :)

(0007089) Parasite (administrator) 17-05-2012 15:15	>но тут же никто в плечи не гонит, главное чтобы работало стабильно. +100500, и вот например у меня 32Гб оперативки - и вот убедите меня (как юзера), что мне ее не хватит? Когда скриптам - хватает и 128Мб на всё (клею потайлово - медленно, зато гарантированно и ДЕЙСТВИТЕЛЬНО безразмерно). А так как клею через весьма большие многогигабайтные системные буферы - то и ничуть не медленно даже. :) >Не по длинной, а именно по ширине. Тем более. >Ну значит нефик клеить сразу весь мир на z20 и выше. А если ВНЕЗАПНО захочется? :) >Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :) C другой стороны, таких упоротых гиков надо будет тут на сасгисе еще поискать. Для начала - таких винтов пока еще нету, чтобы прочувствовать лимиты и тикет делать... :) Да, кстати - до кучи надо продумать момент дырок в РАВе. Либо клеить заранее определенное значение RGB при натыкании на дырку (и тогда нужно бы возможность определения этого дефолтового цвета для дырок), либо сперва заполнять весь рав этим цветом - а потом клеить тайлы какие найдутся (а в дырках цвет останется автоматически). Первый вариант имхо более разумен.

(0007090) Parasite (administrator) 17-05-2012 15:19	>Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали). Минус дырки, заметь.

(0007092) Dima2000 (developer) 17-05-2012 15:44	>Минус дырки, заметь. В полосе выделения дырок быть не может. Насколько я знаю, SAS не поддерживает многосвязные выделения. >>Ну значит нефик клеить сразу весь мир на z20 и выше. >А если ВНЕЗАПНО захочется? :) Уменьшать ширину, не 8К тайлов в полосе, а меньше. Или использовать не SAS. ;-)

(0007093) Parasite (administrator) 17-05-2012 15:50	>В полосе выделения дырок быть не может. Неужели? >Уменьшать ширину, не 8К тайлов в полосе, а меньше. >Или использовать не SAS. ;-) ...или сделать нормальный, безлимитный алгоритм. Время-то есть, как правильно указал товарищ zed.

(0007096) Parasite (administrator) 17-05-2012 16:45 edited on: 17-05-2012 16:53	>Неужели? Объясните плиз в личку или на форуме как создать область выделения, с внутренней не соединённой с границами дыркой? Или хоть ссылку где про это написано? Понятия не имею. Выше я про дырки в кэше (= отсуствующие на сервере тайлы) в границах пользовательского выделения, а не про саму "изящно-дырявую" рамку выделения как таковую. Очевидно же, что выделив ВЕСЬ мир и сводя его например в 19м уровне - получим пустые места в кэше весьма много где, ибо те же окияны кончаются на 12м уровне если не ошибаюсь (а они токи попадают в выделение "весь_мир"). То есть, на 19м зуме на 2\3 выделения будет 404 еррор, и этот момент нам надо будет как-то отдельно отрабатывать. Заливать дефолтовым цветом или еще как иначе, бо "истинно-дырявых" форматов растров пока еще не придумали.

(0007523) Parasite (administrator) 19-06-2012 09:48	Кстати, вот тулза делающая как раз "сведение безразмерных битмапов через винт" (но платная): http://www.mcrenox.com.ar/vlijoiner/ Интересно, как они обошли лимиты BMP на размер? Скорее всего - никак.... :)

(0015933) zed (manager) 16-05-2015 08:26	Да ну, каких безразмерных? Ты почитай: "output format is PNG or BMP", так что у них максимум 64k для PNG и 32k для BMP. Эти лимиты не обойдёшь. Безразмерные это всякие ECW/J2K/RAW, но никак не BMP :)

Users who viewed this issue
User List	Anonymous (5270x), VMatveev (6x), netsky (1x)
Total Views	5277
Last View	21-11-2024 13:21

Issue History
Date Modified	Username	Field	Change
04-12-2010 20:02	Parasite	New Issue
06-12-2010 09:28	vdemidov	Status	new => acknowledged
06-12-2010 09:28	vdemidov	Product Version	=> 101201
06-12-2010 09:28	vdemidov	Target Version	=> 110311.Alfa
06-12-2010 10:21	vdemidov	Target Version	110311.Alfa => 24xxxx
07-04-2011 01:38	gpsMax	Tag Attached: склейка
07-04-2011 01:38	gpsMax	Tag Attached: экспорт
09-04-2011 14:04	gpsMax	Tag Attached: raw
11-04-2011 07:09	vdemidov	Status	acknowledged => confirmed
17-05-2012 05:14	vdemidov	Note Added: 0007038
17-05-2012 05:15	vdemidov	Relationship added	related to 0001213
17-05-2012 06:41	zed	Note Added: 0007041
17-05-2012 06:56	zed	Note Added: 0007045
17-05-2012 06:57	zed	Note Edited: 0007045	View Revisions
17-05-2012 07:08	vdemidov	Note Added: 0007046
17-05-2012 07:09	vdemidov	Note Added: 0007047
17-05-2012 07:12	vdemidov	Note Added: 0007048
17-05-2012 07:30	zed	Note Added: 0007049
17-05-2012 07:44	vdemidov	Note Added: 0007050
17-05-2012 08:32	Parasite	Note Added: 0007051
17-05-2012 08:38	Parasite	Note Added: 0007052
17-05-2012 08:50	zed	Note Added: 0007053
17-05-2012 08:52	vdemidov	Note Added: 0007054
17-05-2012 08:57	vdemidov	Note Added: 0007055
17-05-2012 08:57	vdemidov	Note Edited: 0007054	View Revisions
17-05-2012 09:31	Parasite	Note Added: 0007056
17-05-2012 09:52	vdemidov	Note Added: 0007057
17-05-2012 10:02	vdemidov	Note Added: 0007058
17-05-2012 10:39	Parasite	Note Added: 0007059
17-05-2012 10:53	vdemidov	Note Added: 0007060
17-05-2012 11:01	Tolik	Note Added: 0007061
17-05-2012 11:09	Dima2000	Note Added: 0007062
17-05-2012 11:12	vdemidov	Note Added: 0007063
17-05-2012 11:24	Dima2000	Note Added: 0007064
17-05-2012 12:00	Tolik	Note Added: 0007067
17-05-2012 12:16	Parasite	Note Added: 0007070
17-05-2012 12:27	Dima2000	Note Added: 0007072
17-05-2012 12:29	zed	Note Added: 0007073
17-05-2012 12:30	Dima2000	Note Edited: 0007072	View Revisions
17-05-2012 12:33	Dima2000	Note Added: 0007074
17-05-2012 12:35	Dima2000	Note Edited: 0007074	View Revisions
17-05-2012 12:39	zed	Note Added: 0007075
17-05-2012 12:48	Dima2000	Note Added: 0007076
17-05-2012 12:54	Dima2000	Note Edited: 0007076	View Revisions
17-05-2012 13:07	zed	Note Added: 0007077
17-05-2012 13:22	Parasite	Note Added: 0007078
17-05-2012 13:22	Parasite	Note Edited: 0007078	View Revisions
17-05-2012 13:37	zed	Note Added: 0007079
17-05-2012 13:38	zed	Note Edited: 0007079	View Revisions
17-05-2012 13:42	Dima2000	Note Added: 0007080
17-05-2012 13:43	Parasite	Note Added: 0007081
17-05-2012 13:50	Parasite	Note Added: 0007082
17-05-2012 14:15	vdemidov	Note Added: 0007083
17-05-2012 14:36	Parasite	Note Added: 0007084
17-05-2012 14:52	zed	Note Added: 0007085
17-05-2012 14:52	Dima2000	Note Added: 0007086
17-05-2012 14:53	zed	Note Added: 0007087
17-05-2012 15:14	Dima2000	Note Edited: 0007086	View Revisions
17-05-2012 15:15	Parasite	Note Added: 0007089
17-05-2012 15:19	Parasite	Note Added: 0007090
17-05-2012 15:44	Dima2000	Note Added: 0007092
17-05-2012 15:50	Parasite	Note Added: 0007093
17-05-2012 16:03	Dima2000	Note Added: 0007094
17-05-2012 16:31	Dima2000	Note Deleted: 0007094
17-05-2012 16:45	Parasite	Note Added: 0007096
17-05-2012 16:53	Parasite	Note Edited: 0007096	View Revisions
19-06-2012 09:48	Parasite	Note Added: 0007523
30-04-2015 14:09	vdemidov	Assigned To	=> vdemidov
30-04-2015 14:09	vdemidov	Status	confirmed => assigned
15-05-2015 19:55	vdemidov	Tag Attached: VIP
15-05-2015 19:56	vdemidov	Status	assigned => resolved
15-05-2015 19:56	vdemidov	Fixed in Version	=> 150915
15-05-2015 19:56	vdemidov	Resolution	open => fixed
15-05-2015 19:56	vdemidov	Target Version	24xxxx => 150915
16-05-2015 08:26	zed	Note Added: 0015933

SASGIS