libimg

Discussing libraries simplifying applications development
  • Отличнейшая новость!
    Из хаоса в космос
  • punk_joker wrote:а другие пока не поддерживаются (если не ошибаюсь).
    Ещё поддерживается pnm(pbm|pgm|ppm)http://websvn.kolibrios.org/filedetails ... 9#line-201. Но он тоже много весит.
  • Объединил в ревизии 6673 библиотеки zlib и archiver что-бы оно уже было в сборке, потому как Leency обещал скоро выпустить Kolibri N10.
    В примере с сохранением *.png добился увеличения размера сохраняемого файла до 64 Кб (около 180*120 пикселей). Сделал также фильтр Up, для увеличения степени сжатия.
    Даю архив с кодом, но предупреждаю что там много лишнего. Делалось это на основе libpng 1.6.25, потому многие функции нам в ближайшем будущем будут не нужны, но и мешать не будут, т. к. макрос proc и endp не включают в бинарный файл функции которые нигде в коде не вызываются.
    Если возник вопрос почему именно 64 Кб, то вот объяснение почему:
    Алгоритм для упаковки данных:
    1) Вызов функции deflateInit или deflateInit2.
    2) Разбиение входного потока данных на порции по 64 Кб.
    Для каждого блока в 64 Кб в цикле должен делаться вызов функции deflate.
    За один вызов функции deflate сжатых данных образуется не более 16 Кб.
    Т. е. если сжимаемых данных менее 16 Кб, то их можно упаковать за один вызов deflate.
    Если сжимаемых данных менее 64 Кб, то их можно упаковать организовав один цикл с вызовом deflate.
    Если сжимаемых данных более 64 Кб, то их можно упаковать организовав двойной цикл с вызовом deflate.

    3) Вызов функции deflateEnd для очистки памяти.
    Просто пока что не стал делать двойной цикл.
    Attachments
    png1625.zip (310.77 KiB)
    исходники и бинарники
    Downloaded 354 times
  • Эм. Это от какого года алгоритм? Я могу понять, откуда может быть лимит в 64 Кб на 16-битных системах, но в 2016 году?
    Сделаем мир лучше!
  • CleverMouse wrote:Эм. Это от какого года алгоритм? Я могу понять, откуда может быть лимит в 64 Кб на 16-битных системах, но в 2016 году?
    Уже снял ограничение в ревизии 6704.
    Проблема была в том что в коде на C++ стояло uInt, которое могло компилироваться и как word и как dword. А библиотека libpng вообще разбивает изображение на строки и архивирует построчно. Наверное так нужно чтобы изображение могло подгружаться браузерами построчно а не целиком. Но я этого сразу не понял и подумал что лимит в 64 Кб неизбежен и что он имеет отношение к самому алгоритму сжатия. Пока что имею мало свободного времени для окончательного дописывания, но в примере который я выложил можно сделать немного исправлений и можно архивировать большие картинки, я уже пробовал получалось.
  • Пробовал добавить в ревизии 6733 сохранение 24-битных png файлов.
    Но сборка ночная почему-то не создалась. Думаю что может быть дело в том что было мало места на rd диске?
  • Можно уменьшить размер библиотеки на 2 Кб если отключить в pnglibconf.inc не используемые опции.
    Теперь хотелось-бы сделать в animage сохранение в png. Думаю что как получится сделать, тогда и обновленный pnglibconf.inc отправлю на svn.
  • Есть картинка, которая неверно отображается
    Spoiler:

    [The extension bmp has been deactivated and can no longer be displayed.]

    Но дело, думаю, не только в libimg. Пробовал выводить изображение с помощью SysFn65, но результат тоже не верный
    Spoiler:
    0.PNG
    0.PNG (42.25 KiB)
    Viewed 16950 times
    И, что интересно, MSPaint тоже отображает неправильно
    Spoiler:
    1.PNG
    1.PNG (8.17 KiB)
    Viewed 16950 times
    Но, например, браузеры и IrfanView отображают верно. В чём же тут проблема?
  • [Расширение bmp было запрещено, вложение больше недоступно.]
    Очень умно! У кого-то ну очень много мозгов. А разработчики libimg успели до запрета, интересно?

    Впрочем, ладно. Сейчас можно считать, что libimg неправильно определяет padding, а SysFn65 неправильно его учитывает. Хотя это касается не всех изображений. Вот, например, многие отображены верно
    Spoiler:
    Scr-999999999.png
    Scr-999999999.png (75.1 KiB)
    Viewed 16911 times
    Если кому интересно, вот эти картинки
    test_images.7z (136.82 KiB)
    Downloaded 339 times
  • 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?
  • 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
    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.
  • dunkaist, если ты обратил внимание, то также некорректно отображается файлик House16bit_93_1.bmp, а там biCompression = 0.
    Значит, вероятно, что неверно считается padding.
    Вот так он считается у меня

    Code: Select all

    Padding := (4 - biWidth * biBitCount Shr 3 Mod 4) And Not 4;
  • 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?
  • Here is the original of attached images https://commons.wikimedia.org/wiki/File ... 005%29.jpg It says:
    This file is licensed under the Creative Commons Attribution 2.0 Generic license.
  • Who is online

    Users browsing this forum: No registered users and 4 guests