Board.KolibriOS.org
http://board.kolibrios.org/

libimg
http://board.kolibrios.org/viewtopic.php?f=24&t=1728
Page 4 of 5

Author:  punk_joker [ Wed Nov 02, 2016 12:26 am ]
Post subject:  Re: libimg

Отличная новость. PNG очень нужен, а то формат BMP много весит, а другие пока не поддерживаются (если не ошибаюсь).

Author:  Leency [ Wed Nov 02, 2016 12:35 am ]
Post subject:  Re: libimg

Отличнейшая новость!

Author:  0CodErr [ Thu Nov 03, 2016 4:39 pm ]
Post subject:  Re: libimg

punk_joker wrote:
а другие пока не поддерживаются (если не ошибаюсь).
Ещё поддерживается pnm(pbm|pgm|ppm)http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+OS&path=%2Fprograms%2Fdevelop%2Flibraries%2Flibs-dev%2Flibimg%2Fpnm%2Fpnm.asm&rev=4229#line-201. Но он тоже много весит.

Author:  IgorA [ Fri Nov 04, 2016 11:24 pm ]
Post subject:  Re: libimg

Объединил в ревизии 6673 библиотеки zlib и archiver что-бы оно уже было в сборке, потому как Leency обещал скоро выпустить Kolibri N10.
В примере с сохранением *.png добился увеличения размера сохраняемого файла до 64 Кб (около 180*120 пикселей). Сделал также фильтр Up, для увеличения степени сжатия.
Даю архив с кодом, но предупреждаю что там много лишнего. Делалось это на основе libpng 1.6.25, потому многие функции нам в ближайшем будущем будут не нужны, но и мешать не будут, т. к. макрос proc и endp не включают в бинарный файл функции которые нигде в коде не вызываются.


Если возник вопрос почему именно 64 Кб, то вот объяснение почему:
Quote:
Алгоритм для упаковки данных:
1) Вызов функции deflateInit или deflateInit2.
2) Разбиение входного потока данных на порции по 64 Кб.
Для каждого блока в 64 Кб в цикле должен делаться вызов функции deflate.
За один вызов функции deflate сжатых данных образуется не более 16 Кб.
Т. е. если сжимаемых данных менее 16 Кб, то их можно упаковать за один вызов deflate.
Если сжимаемых данных менее 64 Кб, то их можно упаковать организовав один цикл с вызовом deflate.
Если сжимаемых данных более 64 Кб, то их можно упаковать организовав двойной цикл с вызовом deflate.

3) Вызов функции deflateEnd для очистки памяти.

Просто пока что не стал делать двойной цикл.

Attachments:
File comment: исходники и бинарники
png1625.zip [310.77 KiB]
Downloaded 117 times

Author:  CleverMouse [ Fri Nov 11, 2016 9:23 pm ]
Post subject:  Re: libimg

Эм. Это от какого года алгоритм? Я могу понять, откуда может быть лимит в 64 Кб на 16-битных системах, но в 2016 году?

Author:  IgorA [ Sat Nov 12, 2016 7:32 pm ]
Post subject:  Re: libimg

CleverMouse wrote:
Эм. Это от какого года алгоритм? Я могу понять, откуда может быть лимит в 64 Кб на 16-битных системах, но в 2016 году?

Уже снял ограничение в ревизии 6704.
Проблема была в том что в коде на C++ стояло uInt, которое могло компилироваться и как word и как dword. А библиотека libpng вообще разбивает изображение на строки и архивирует построчно. Наверное так нужно чтобы изображение могло подгружаться браузерами построчно а не целиком. Но я этого сразу не понял и подумал что лимит в 64 Кб неизбежен и что он имеет отношение к самому алгоритму сжатия. Пока что имею мало свободного времени для окончательного дописывания, но в примере который я выложил можно сделать немного исправлений и можно архивировать большие картинки, я уже пробовал получалось.

Author:  IgorA [ Mon Nov 21, 2016 7:06 pm ]
Post subject:  Re: libimg

Пробовал добавить в ревизии 6733 сохранение 24-битных png файлов.
Но сборка ночная почему-то не создалась. Думаю что может быть дело в том что было мало места на rd диске?

Author:  IgorA [ Tue Nov 22, 2016 5:42 pm ]
Post subject:  Re: libimg

Можно уменьшить размер библиотеки на 2 Кб если отключить в pnglibconf.inc не используемые опции.
Теперь хотелось-бы сделать в animage сохранение в png. Думаю что как получится сделать, тогда и обновленный pnglibconf.inc отправлю на svn.

Author:  0CodErr [ Tue Nov 22, 2016 10:38 pm ]
Post subject:  Re: libimg

Есть картинка, которая неверно отображается
Spoiler: Show
Attachment:
[The extension bmp has been deactivated and can no longer be displayed.]
Но дело, думаю, не только в libimg. Пробовал выводить изображение с помощью SysFn65, но результат тоже не верный
Spoiler: Show
Attachment:
0.PNG
0.PNG [ 42.25 KiB | Viewed 8613 times ]

И, что интересно, MSPaint тоже отображает неправильно
Spoiler: Show
Attachment:
1.PNG
1.PNG [ 8.17 KiB | Viewed 8613 times ]
Но, например, браузеры и IrfanView отображают верно. В чём же тут проблема?

Author:  0CodErr [ Fri Nov 25, 2016 3:14 pm ]
Post subject:  Re: libimg

Quote:
[Расширение bmp было запрещено, вложение больше недоступно.]
Очень умно! У кого-то ну очень много мозгов. А разработчики libimg успели до запрета, интересно?

Впрочем, ладно. Сейчас можно считать, что libimg неправильно определяет padding, а SysFn65 неправильно его учитывает. Хотя это касается не всех изображений. Вот, например, многие отображены верно
Spoiler: Show
Attachment:
Scr-999999999.png
Scr-999999999.png [ 75.1 KiB | Viewed 8574 times ]
Если кому интересно, вот эти картинки
Attachment:
test_images.7z [136.82 KiB]
Downloaded 116 times

Author:  dunkaist [ Fri Nov 25, 2016 3:45 pm ]
Post subject:  Re: libimg

0CodErr,

I downloaded the file you attached to the previous post and did some research:
  1. The reason for such a strange behaviour of viewers is a combination of 16bpp and Compression=3;
  2. There is no formal specification for BMP, Wikipedia stresses that 16/32bpp images are always uncompressed;
  3. ImageMagick displays the picture, GraphicsMagick is patched in 2002 to explicitly check for (bpp >= 16) and (compression == 0) and thus detects the file as invalid.

I don't know why GraphicsMagick and Wikipedia mention that limitation. Also I don't have any specification, only informal descriptions.
Possible solutions are to report an error or to display the image "properly". Both require writing code, so the latter one is preferable.

Btw, why do you think this picture is valid?

Author:  0CodErr [ Fri Nov 25, 2016 3:59 pm ]
Post subject:  Re: libimg

dunkaist wrote:
The reason for such a strange behaviour of viewers is a combination of 16bpp and Compression=3;
As MSDN says http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Quote:
biCompression
..............
BI_BITFIELDS Specifies that the bitmap is not compressed and that the color table consists of three DWORD color masks that specify the red, green, and blue components, respectively, of each pixel. This is valid when used with 16- and 32-bpp bitmaps.

Author:  0CodErr [ Fri Nov 25, 2016 10:31 pm ]
Post subject:  Re: libimg

dunkaist, если ты обратил внимание, то также некорректно отображается файлик House16bit_93_1.bmp, а там biCompression = 0.
Значит, вероятно, что неверно считается padding.
Вот так он считается у меня
Code:
Padding := (4 - biWidth * biBitCount Shr 3 Mod 4) And Not 4;

Author:  dunkaist [ Fri Nov 25, 2016 11:08 pm ]
Post subject:  Re: libimg

I didn't see in code at all, only at viewers' behaviour and their motivation. I'll take a look at this padding issue, thank you for reporting it and for providing explicit formula.

What is the license of the attached images? May I use them in my test suite etc?

Author:  0CodErr [ Fri Nov 25, 2016 11:19 pm ]
Post subject:  Re: libimg

Here is the original of attached images https://commons.wikimedia.org/wiki/File ... 005%29.jpg It says:
Quote:
This file is licensed under the Creative Commons Attribution 2.0 Generic license.

Page 4 of 5 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/