Форум SAS.Планета

Papazol писал(а):Я дико извиняюсь, если не нашёл нужного поиском, но при попытке указать путь к кэшу Google Earth программа выдаёт окно "Access violation at address 00402C2D in module 'SASPlanet.exe'. Read of address 000003FC" и не меняет ни зум, ни карту, хотя изображение показывает. Что я не так сделал?

У меня GE обновился до новой версии и я получил возможность исследовать ошибку.
Результаты таковы: новая версия хранит тайлы или не в jpg или как-то обрезает, или шифрует. По крайней мере читалка джепегов выдает IJL_ERR_NOT_JPEG. Дальше буду разбираться.
ЗЫЖ или парсилка кеша мусор выковирывает, что тоже может быть.

Подтверждаю, GE стал хранить картинки в кэше не в jpg формате (хотя из инета получает всё те же жпеги). Подозреваю, это они так оптимизировали быстродействие клиента, став хранить в кэше уже подготовленные/сырые снимки.
Тайл из инета: f1-0-i.250 - 7 561 Байт, он же, из кэша: f1-0-i.250 - 32 792 Байт. Причём, такого же размера (32 792 Байт) ВСЕ тайлы снимков в кэше...
Гляньте аттач, может кому-то знаком формат этого изображения?

интересно с первого взгляда не похож ни на один распространенный формат. Оптимальность поражает - 32 кб из которых 16 забита nul'ами)

Ну это не везде так. У меня из пары сотен тайлов что выковырял, большая часть забита совсем не нулами. Да и потом оптимальность оптимальности рознь. Может они расчитывают выиграть засчет скорости доступа или еще чем-то таким?

vdemidov писал(а): Может они расчитывают выиграть засчет скорости доступа или еще чем-то таким?

Скорее всего
Вот еще наковырял - в приведенном примере с 8217 по 9327 байты похоже на палитру и судя по всему количество цветов в районе 128

feya писал(а):в приведенном примере с 8217 по 9327 байты похоже на палитру

Хотя нет, туплю, там по 8 байт последовательности а в палитре должны бы по 4

feya писал(а):интересно с первого взгляда не похож ни на один распространенный формат.

Наверняка ещё один формат собственной разработки.

feya писал(а):Оптимальность поражает - 32 кб из которых 16 забита nul'ами)

Нули, это записи о чёрных пикселах: первый тайл в GE имеет снимок только посередине (128*256 pix), а сверху и снизу (по 64*256 pix) - чёрное поле.

Предварительно:
Файл состоит из 2-х частей: заголовок и хэш-таблица.
Заголовок:

Код: Выделить всё

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   4F 82 A3 31 00 01 00 00  00 01 00 00 00 00 00 00   O‚£1............
00000010   FF FF FF FF FF FF FF 7F                            ÿÿÿÿÿÿÿ

где,
Magic: 4F 82 A3 31
X:     00 01 00 00 (256) - размер тайла (хэш таблицы?) по X
Y:     00 01 00 00 (256) - размер тайла (хэш таблицы?) по Y
???:   00 00 00 00 - разделитель?
Mask:  FF FF FF FF FF FF FF 7F

Хэш-таблица - всё остальное, размерность 128*128 элементов (или 256*256, если размер элемента 2 бита). Для получения цвета пиксела, берётся соответствующий элемент из таблицы и прогоняется алгоритмом по маске.
Для начала, наверное, нужно определиться с размерностью таблицы, ну, и потом уже выйти на алгоритм. Надо пробовать скармливать GE тайлы с разноцветным пикселом, а остальное пространсво заполнять чёрным цветом и анализировать... Может, в хэш таблице описаны не все пикселы тайла, а только "узловые", а остальное дорисовывается соответствующим алгоритмом, может ещё что, нужно смотреть.

Может они расчитывают выиграть засчет скорости доступа или еще чем-то таким?

Оптимизация за счёт отказа от JPG -> Bitmap преобразования, у них уже лежит сразу готовый битмап, который можно без лишних задержек сразу передавать в алго, натягивающий битмап на глобус.

zed

zed писал(а):Нули, это записи о чёрных пикселах: первый тайл в GE имеет снимок только посередине (128*256 pix), а сверху и снизу (по 64*256 pix) - чёрное поле.

А, знать это был первый тайл, ясно.

Что то я не понимаю, если размер тайла 256*256 а размер таблицы 32768 то получается на один пиксел 4 бита = 16 цветов, маловато как то)

Вообще тему лучше отдельую завести бы

Вот 2 белых тайла, в одном первый пиксел черный, во втором - первая строка чёрная.


И что с этим делать?

Ну давай смотреть что получается. Выходит что у нас пикселы группируются квадратами 4 на 4. На каждый такой квадрат приходится 8 байт. Порядок квадратов в файла как пикслы в битмапке, тоесть снизу вверх справа налево.