SASGIS - SAS.Планета |
| View Issue Details |
|
| 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 |
| Relationships | |
| Attached Files |  заменять при наличии.png (89,065) 19-08-2021 11:03
http://www.sasgis.org/mantis/file_download.php?file_id=2534&type=bug
 PngCacheLosslessReCompressResults.zip (2,854) 22-08-2021 21:18
http://www.sasgis.org/mantis/file_download.php?file_id=2535&type=bug |
|
| 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 | bug_revision_view_page.php?bugnote_id=20172#r7767 |
| 21-08-2021 14:55 | zed | Note Added: 0020173 | |
| 21-08-2021 14:56 | zed | Note Edited: 0020173 | bug_revision_view_page.php?bugnote_id=20173#r7769 |
| 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 | |
|
Notes |
|
|
(0020171)
|
|
zed
|
|
19-08-2021 15:54
|
|
А стоит ли овчинка выделки? Ну сэкономите вы пару Гиг на терабайтном диске и что?
Хотя, ещё не известно, будет ли эта самая экономия. Ведь при сохранении в кэш, место резервируется блоками, а не побайтово. Дефолтный размер кластера в NTFS - 4кБ, страницы в SQLite столько же. Так что может оказаться, что до сжатия и после сжатия (даже при уменьшении размера тайла), количество выделенных кластеров/страниц будет идентичным. |
|
|
|
(0020172)
|
|
gma
|
21-08-2021 14:17
(edited on: 21-08-2021 14:19) |
|
"Оптимизация" имеет смысл только на плашковых картах типа ГГЦ. На всяких спутниках и прочих полутонах разницы не будет или она будет незначительна.
Разница же в тайлах ГГЦ была где-то в 2,5--3 раза примерно.
Вот если бы СаС научился клеить карты в "оптимизированный" PNG -- вот было бы здорово.
|
|
|
|
(0020173)
|
|
zed
|
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
|
|
22-08-2021 21:14
|
|
Выложил на форуме статистику по пережатию имеющихся у меня кэшей.
http://www.sasgis.org/forum/viewtopic.php?p=50261#p50261
Да, итоговый размер, занимаемый файлами на диске, зависит не только от сжимаемости данного типа кэша, но и от размера кластера, причём существенно.
К сожалению, на диске никто не будет заморачиваться с уменьшением кластера (если это не специально выделенный под кэш диск или виртуальный диск). Планета, понятное дело не может управлять размером кластера диска.
Но кто же ей запретит менять размер страницы создаваемой базы! Вроде как в SQLite можно задавать размер страницы от 512 байт. А раньше дефолтный вообще был равен 1024.
В моих экспериментах размер кэша yahyb при _одновременном_ ужатии и снижении размера кластера уменьшался почти в 5 раз!
Даже если после сжатия общее занимаемое на диске место не уменьшится, всё равно итоговая карта, полученная при преобразовании из ужатого кэша, для некоторых форматов (например, Sas4Android) будет занимать заметно меньше места на мобильнике.
ЗЫ: сабжевый вопрос плавно перетекает в "Оптимизация кэша, содержащего PNG-тайлы" :) |
|
|
|
(0020176)
|
|
zed
|
|
23-08-2021 07:23
|
|
> А раньше дефолтный вообще был равен 1024.
В SQLite размер страницы всегда был 4kB, а вот в Беркли, да, дефолтный размер 1kB. Но тут ещё следует учитывать, что чем меньше размер кластера, там медленнее работает файловая система. И очень желательно, чтобы размер страницы в БД совпадал с размером кластера на диске.
> будет занимать заметно меньше места на мобильнике
Так может и стоит применять это только при экспорте? Например, при экспорте в Locus, OsmAnd и прочие, на основе SQLite, УЖЕ можно вручную выбрать формат тайлов. И там среди прочего, есть возможность выбрать 8-битный png.
Впрочем, если вам таки очень нужна именно эта фишка с оптимизацией при сохранении, могу сделать за 1000 рублей - пишите мне на [email protected] для деталей. |
|