SASGIS

Веб-картография и навигация

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Project

Category

View Status

Date Submitted

Last Update

0003778

SAS.Планета

[All Projects] Хотелка

public

19-08-2021 11:03

23-08-2021 07:23

Reporter

VadimK

Assigned To

Priority

normal

Severity

minor

Reproducibility

always

Status

new

Resolution

open

Platform

Windows

OS

7

OS Version

Professional

Product Version

201212

Target Version

Fixed in Version

Summary

0003778: Сжатие PNG-тайлов при сохранении в кэш (без потерь)

Description

Подробности на форуме:
http://www.sasgis.org/forum/viewtopic.php?f=2&t=3565

Просьба добавить в программе возможность оптимизировать только что скачанные с сайта тайлы в формате PNG, и только потом сохранять их в кэш ?

Под "оптимизировать" я понимаю уменьшение размера PNG-тайла без потери качества и без потери прозрачности + сравнение размеров файлов до и после оптимизации + сохранение в кэш файла меньшего размера.

Случайно на глаза попалась спецификация, в которой сказано, что PNG бывают разные. С палитрой и без.
По идее, первый вариант с палитрой предпочтительнее для хранения тайлов: размер небольшой, цветов обычно мало (всяко меньше 256).

Полез смотреть, в каком формате хранятся PNG-тайлы в моей коллекции кэшей.
И был очень удивлён тем, что в основном используется более громоздкий вариант БЕЗ палитры (RGBA).

Steps To Reproduce

Если в Params.txt присутствует ContentType=image/png ,
то на форме загрузки или в настройках карты отобразить чекбокс (по-умолчанию выбран) "Оптимизировать размер PNG-тайлов".

НО!!! Может возникнуть проблема с опцией "[v] Заменять старые файлы[v] только при их различии", ведь сайт будет отдавать размер своего тайла, а сравнивать его придётся с размером уже оптимизированного, лежащего в кэше.

Если в базе данных кэша есть возможность хранить старый размер тайла (а заодно и информацию о том, был ли тайл оптимизирован), то очень хорошо.

Если нет - можно хранить размер старого файла в уже оптимизированном – добавить специальный chunck (+16 байт к размеру тайла). Само наличие этого чанка будет говорить о том, что файл оптимизирован, а при дальнейших преобразованиях его можно будет удалять.

Либо создать доп. базу с данными об оригинальных размерах оптимизированных тайлов.

А можно поступить кардинально: для оптимизированного кэша сделать недоступным чекбокс "[v] Заменять старые файлы только при их различии". :))

Additional Information

Другой подводный камень: возможное смешение в кэше оптимизированных и нет тайлов.

Если в свойствах карты пользователь установит галку оптимизации кэша, то при применении изменений можно сразу запустить процесс оптимизации кэша карты. А если наоборот, снимет ? (хотя, зачем ему это делать ?) Можно просто предупредить, что ему впоследствии придётся перекачать почти весь кэш заново и ограничиться этим.

По факту, кстати, “оптимизированный” кэш и так будет смешанным. Ведь не всегда размер “оптимизированного” тайла будет меньше оригинального. И часть тайлов в кэше по факту будут оригинальными. Так что может и не стоит заострять на это внимание.

Получается, кэш может быть в 3 состояниях:
1. оптимизирован – размер всех тайлов минимален- может содержать как преобразованные тайлы, так и оригинальные (чей размер меньше, чем размер преобразованных) Это состояние кэша при установленной галке «Оптимизировать кэш».
2. смешанный – возникает сразу после снятия галки «Оптимизировать кэш»
3. неоптимизирован – содержит только скачанные неоптимизированные тайлы. Он либо был таким изначально, либо пришёл к этому состоянию со временем из состояния 2 (смешанный).

Tags

заменять при наличии.png [^] (89,065 bytes) 19-08-2021 11:03

PngCacheLosslessReCompressResults.zip [^] (2,854 bytes) 22-08-2021 21:18

Relationships

Notes
(0020171) zed (manager) 19-08-2021 15:54	А стоит ли овчинка выделки? Ну сэкономите вы пару Гиг на терабайтном диске и что? Хотя, ещё не известно, будет ли эта самая экономия. Ведь при сохранении в кэш, место резервируется блоками, а не побайтово. Дефолтный размер кластера в NTFS - 4кБ, страницы в SQLite столько же. Так что может оказаться, что до сжатия и после сжатия (даже при уменьшении размера тайла), количество выделенных кластеров/страниц будет идентичным.

(0020172) gma (reporter) 21-08-2021 14:17 edited on: 21-08-2021 14:19	"Оптимизация" имеет смысл только на плашковых картах типа ГГЦ. На всяких спутниках и прочих полутонах разницы не будет или она будет незначительна. Разница же в тайлах ГГЦ была где-то в 2,5--3 раза примерно. Вот если бы СаС научился клеить карты в "оптимизированный" PNG -- вот было бы здорово.

(0020173) zed (manager) 21-08-2021 14:55 edited on: 21-08-2021 14:56	Со склейкой вам поможет небольшая прожка - pngquant 1. Склеить снимок в SAS в обычный png (пусть это будет файл с именем 24-bit.png) 2. Выполнить команду в консоли: pngquant.exe 256 < 24-bit.png > 8-bit.png

(0020174) VadimK (reporter) 22-08-2021 21:14	Выложил на форуме статистику по пережатию имеющихся у меня кэшей. http://www.sasgis.org/forum/viewtopic.php?p=50261#p50261 Да, итоговый размер, занимаемый файлами на диске, зависит не только от сжимаемости данного типа кэша, но и от размера кластера, причём существенно. К сожалению, на диске никто не будет заморачиваться с уменьшением кластера (если это не специально выделенный под кэш диск или виртуальный диск). Планета, понятное дело не может управлять размером кластера диска. Но кто же ей запретит менять размер страницы создаваемой базы! Вроде как в SQLite можно задавать размер страницы от 512 байт. А раньше дефолтный вообще был равен 1024. В моих экспериментах размер кэша yahyb при _одновременном_ ужатии и снижении размера кластера уменьшался почти в 5 раз! Даже если после сжатия общее занимаемое на диске место не уменьшится, всё равно итоговая карта, полученная при преобразовании из ужатого кэша, для некоторых форматов (например, Sas4Android) будет занимать заметно меньше места на мобильнике. ЗЫ: сабжевый вопрос плавно перетекает в "Оптимизация кэша, содержащего PNG-тайлы" :)

(0020176) zed (manager) 23-08-2021 07:23	> А раньше дефолтный вообще был равен 1024. В SQLite размер страницы всегда был 4kB, а вот в Беркли, да, дефолтный размер 1kB. Но тут ещё следует учитывать, что чем меньше размер кластера, там медленнее работает файловая система. И очень желательно, чтобы размер страницы в БД совпадал с размером кластера на диске. > будет занимать заметно меньше места на мобильнике Так может и стоит применять это только при экспорте? Например, при экспорте в Locus, OsmAnd и прочие, на основе SQLite, УЖЕ можно вручную выбрать формат тайлов. И там среди прочего, есть возможность выбрать 8-битный png. Впрочем, если вам таки очень нужна именно эта фишка с оптимизацией при сохранении, могу сделать за 1000 рублей - пишите мне на [email protected] для деталей.

Users who viewed this issue
User List	Anonymous (766x), VadimK (13x), ingener (2x), vdemidov (5x), zed (8x), gma (3x)
Total Views	797
Last View	06-05-2024 17:40

Issue History
Date Modified	Username	Field	Change
19-08-2021 11:03	VadimK	New Issue
19-08-2021 11:03	VadimK	File Added: заменять при наличии.png
19-08-2021 11:44	VadimK	Tag Attached: png
19-08-2021 15:54	zed	Note Added: 0020171
21-08-2021 14:17	gma	Note Added: 0020172
21-08-2021 14:19	gma	Note Edited: 0020172	View Revisions
21-08-2021 14:55	zed	Note Added: 0020173
21-08-2021 14:56	zed	Note Edited: 0020173	View Revisions
22-08-2021 21:14	VadimK	Note Added: 0020174
22-08-2021 21:18	VadimK	File Added: PngCacheLosslessReCompressResults.zip
23-08-2021 07:23	zed	Note Added: 0020176

Copyright © 2007 - 2024 SAS.Planet Team