The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз libpng 1.6.0 с поддержкой упрощённого API

18.02.2013 21:26

Представлен первый стабильный релиз новой ветки libpng 1.6.0, популярной свободной библиотеки для чтения, сохранения и обработки растровых изображений в формате PNG. Новая ветка примечательна реализацией нового упрощённого API, встроенной поддержкой новых таблиц sRGB-to-linear и linear-to-sRGB, а также прекращением поддержки некоторых функций, ранее объявленных устаревшими.

Из элементов нового API можно отметить макросы PNG_FORMAT_* и PNG_IMAGE_*, структуры png_control и png_image, функции для чтения изображений png_image_begin_read_from_(file|stdio|memory), png_image_finish_read, png_image_free, функции для записи изображений png_image_write_to_file и png_image_write_to_stdio.

Прекращена поддержка вызовов: png_get_io_chunk_name заменён на png_get_io_chunk_type, удалены встроенные макросы png_sizeof(), png_strlen(), png_memcpy(), png_memcmp() и png_memset(). Объявлены устаревшими фунуции png_info_init_3, png_convert_to_rfc1123, png_data_freer, png_malloc_default, png_free_default, png_reset_zstream.

  1. Главная ссылка к новости (http://sourceforge.net/mailarc...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/36147-libpng
Ключевые слова: libpng, png, image
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:41, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Надо почитать что за упрощённое API. Возможно получится кое-где упростить код в своих проектах, а заодно устроить попоболь тем кто сидит на протухших дистрибутивах.
     
     
  • 2.2, paulus (ok), 21:48, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В raring 1.2.49
     
     
  • 3.3, Аноним (-), 21:56, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Класс, это ещё лучше.
     

  • 1.4, Mihail Zenkov (ok), 22:49, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимать/разжимать поток данных, можно ломать api чуть ли не с каждым выходом 1.x.0, да еще иногда, так что поправить с ходу это было нелегко.

    Надеюсь с выходом упрощенного API ситуация изменится к лучшему.

     
     
  • 2.7, kurokaze (ok), 00:02, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Меня всегда удивляло

    Попробуте попрограммировать, может тогда поймете

    >да еще иногда, так что поправить с ходу это было нелегко.

    [I] media-libs/libpng
         Available versions:  
            (1.2)   1.2.50
            (0)     1.5.13-r1 ~1.5.14

    в чем проблема? надо будет, отдельно для 1.6 сделают слот. вам то какая разница?

     
     
  • 3.9, Аноним (-), 02:27, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А вот и не сделают! Для 1.2 есть потому что LSB, а для 1.4 слота нет.
     
     
  • 4.10, runoverheads (ok), 03:00, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ну значит в пакет 1.6 будет помечен как тестируемый на долгое время
     
     
  • 5.42, all_glory_to_the_hypnotoad (ok), 23:15, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а потом всё наебнётся после долгого времени. В генте с png такое происходит регулярно
     
     
  • 6.54, mavriq_ (?), 16:10, 21/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В генте с png такое происходит регулярно

    вы хотите сказать - у вас в генте такое происходит регулярно?
    ну так пересядьте на другой дистр, коль для вас гента слишком сложна.

    или вам хочется и морковку съесть, и на ^W^W^W^W считать себя круче других(я gentoo 0дминю \m/.. у себя дома), и не читать хаутушки по обновлению мира (мануалы для ламеров \m/)?

     
  • 2.11, Аноним (-), 04:49, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимать/разжимать поток данных

    Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.

    > можно ломать api чуть ли не с каждым выходом 1.x.0, да еще иногда, так что поправить с ходу это было нелегко

    Чтобы поправить сходу было нелегко - такого не было. А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.

     
     
  • 3.15, www2 (??), 06:00, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.

    Не люблю крайностей. Должна быть золотая середина и разумный баланс. Крайность суждений свидетельствует о незрелости.

     
     
  • 4.39, ip1981 (ok), 20:42, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Похерил API - меняй soname, блеать!!
     
  • 4.50, Аноним (-), 00:43, 21/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Должна быть золотая середина и разумный баланс.

    Оно и есть. soname меняется, срок на deprecated даётся более чем достаточный. Но всё равно найдутся нытики-лентяи.

     
  • 3.28, Mihail Zenkov (ok), 18:19, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.

    Я в своей программе использую:
    extern (C) png_struct* png_create_write_struct(immutable(char)*, void*, void*, void*);
    extern (C) png_info_struct* png_create_info_struct(png_struct*);
    extern (C) void png_init_io(png_struct*, FILE*);
    extern (C) void png_set_IHDR(png_struct*, png_info_struct*, uint, uint, int, int color_type, int interlace_method, int compression_method, int filter_method);
    extern (C) void png_set_pHYs(png_struct*, png_info_struct*, uint res_x, uint res_y, int unit_type);
    extern (C) void png_write_info(png_struct*, png_info_struct*);
    extern (C) void png_write_image(png_struct*, ubyte**);
    extern (C) void png_write_end(png_struct*, png_info_struct*);

    только для того чтобы просто сохранить изображение из памяти (raw rgba) в png. Это нормальный API? Такая простая операция должна выполнятся одной функцией, максимум двумя. Многие приложения вообще не работают с libpng напрямую, а используют прослойки типа freeimage. Похоже и до авторов библиотеки дошло - что навороты хорошо, но нужны они очень редко.

     
     
  • 4.32, Аноним (-), 19:07, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это нормальный API?

    Для таких как вы, видимо, и сделали упрощённый API. И да, это нормалньый API, потому что просто сохранить rgba в png - это хорошо, но нужно это очень редко, и обычно нужна гораздо более широкая функциональность.

     
     
  • 5.36, Mihail Zenkov (ok), 20:15, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Приведите обычный пример, который применяется чаще (хотя бы не реже), чем просто сжать/распаковать в память/файл,  где нужна большая функциональность, а то сразу что-то даже ничего в голову не приходит.
     
  • 5.43, ip1981 (ok), 23:46, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Разве вы не написали уже свою функцию my_write_png_file() ?
     
  • 3.29, Mihail Zenkov (ok), 18:30, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтобы поправить сходу было нелегко - такого не было.

    Посмотри как gimp-2.7 переходил на новую версию. Я после обновления libpng сам хотел поправить, так как с другими библиотеками никогда проблем не было: максимум что-то переименовать или добавить параметр, а тут ... Хорошо нашел патч от другой версии гимпа и по аналогии поправил да и то кривовато, ибо по хорошему нужно было вникать гораздо глубже.

     
  • 2.24, iZEN (ok), 15:07, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО, от неё зависящее — факт.

    У этой библиотеки принципы модульности и обратной совместимости не в моде.

     
     
  • 3.25, maxst (?), 15:34, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
    > от неё зависящее — факт.
    > У этой библиотеки принципы модульности и обратной совместимости не в моде.

    Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.

     
     
  • 4.46, iZEN (ok), 00:59, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.

    Когда перепрыгивать, решают мантейнеры портов.

     
  • 3.33, Аноним (-), 19:09, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
    > от неё зависящее — факт.

    Нет. У вас же есть portupgrade/portmaster которые сохраняют старые версии библиотек, и такой хренью как в gentoo можно не страдать пока сильно не захочется.

     
     
  • 4.45, iZEN (ok), 00:54, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Совет использовать "pormaster -w" в /usr/ports/UPDATING  для libpng (пакет png) что-то не припомню. http://www.freshports.org/graphics/png/ — каждый раз: "portmaster -r png-" или "portupgrade -fr graphics/png".
     
     
  • 5.51, Аноним (-), 00:45, 21/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Совет использовать "pormaster -w" в /usr/ports/UPDATING  для libpng (пакет png) что-то
    > не припомню. http://www.freshports.org/graphics/png/ — каждый раз: "portmaster
    > -r png-" или "portupgrade -fr graphics/png".

    А тебе что, для каждого апдейта библиотеки должны в UPDATING писать? Не делаешь -w - сам дебил. portupgrade так по умолчанию сошки сохраняет.

     

  • 1.5, Аноним (-), 23:28, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    зачем, когда есть фотошоп?
     
     
  • 2.6, exn (??), 23:32, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  зачем, когда есть фотошоп?

    и не поспориш xD

     
  • 2.14, Аноним (-), 05:47, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    настолько неожиданно, что даже не толсто
     
  • 2.17, б.б. (?), 06:19, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Фотошоп тоже на новую 1.6 обновится, не переживайте. Только узнаем мы об этом через 100 лет из музея компьютерной техники.
     

  • 1.8, Аноним (-), 02:26, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk, cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать. Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo возникла цикличная зависимость. Он не собирался, так как librsvg собран с libpng14, а librsvg не собирался потому что Cairo собран с libpng14. Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново. В общем, еле обновил, а теперь, видимо, снова придётся сделать это.
     
     
  • 2.12, Аноним (-), 04:50, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk,
    > cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать.
    > Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo
    > возникла цикличная зависимость. Он не собирался, так как librsvg собран с
    > libpng14, а librsvg не собирался потому что Cairo собран с libpng14.
    > Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось
    > с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново.
    > В общем, еле обновил, а теперь, видимо, снова придётся сделать это.

    А что у вас за недосистема что она не умеет сохранять старые версии библиотек, чтобы и без пересборки всего это всё работало?

     
     
  • 3.16, www2 (??), 06:02, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А что у вас за недосистема что она не умеет сохранять старые
    > версии библиотек, чтобы и без пересборки всего это всё работало?

    Может у него LFS ;-) Или FreeBSD, или Arch.

     
     
  • 4.18, masakra (ok), 09:06, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Фря умеет сохранять старые либы.
     
     
  • 5.26, Аноним (-), 15:37, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, фряшные порты не умеют.
     
     
  • 6.27, masakra (ok), 17:23, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Порты и не должны этого уметь.
    potrmaster -w
     
  • 6.41, Куяврик (?), 23:13, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Как там ваш дядька в Киеве?
     
  • 2.22, лох (?), 11:31, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А просто не обновлять libpng что, религия не позволяет? package.mask там или portmaster -x...
    И вообще, есть хороший принцип "работает -- не трогай". Одно дело -- разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.
     
     
  • 3.30, Mihail Zenkov (ok), 18:35, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А просто не обновлять libpng что, религия не позволяет? package.mask там или
    > portmaster -x...
    > И вообще, есть хороший принцип "работает -- не трогай". Одно дело --
    > разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.

    А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит нормально? А потом в программе приходится липить кучу #ifdef на каждую версию библиотеки ибо не угадаешь, что будет у пользователя.

     
     
  • 4.34, Аноним (-), 19:11, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
    > нормально?

    Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии. Иначе либо библиотека ничего бы не умела либо была бы набором костылей для сохранения совместимости ради, опять же, ламерья.

     
     
  • 5.38, Mihail Zenkov (ok), 20:29, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
    >> нормально?
    > Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
    > Иначе либо библиотека ничего бы не умела либо была бы набором
    > костылей для сохранения совместимости ради, опять же, ламерья.

    Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик использующий libpng самостоятельно напишет их в своей программе.

     
     
  • 6.40, Аноним (-), 20:47, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
    >>> нормально?
    >> Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
    >> Иначе либо библиотека ничего бы не умела либо была бы набором
    >> костылей для сохранения совместимости ради, опять же, ламерья.
    > Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
    > использующий libpng самостоятельно напишет их в своей программе.

    зато как значимость библиотеки возрастает...

     
  • 6.52, Аноним (-), 00:47, 21/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
    > использующий libpng самостоятельно напишет их в своей программе.

    Нет, костылей в коде быть вообще не должно. Крайнее им место - в портах/пакетах.

     
  • 3.55, Resonance (ok), 13:45, 02/11/2014 [^] [^^] [^^^] [ответить]  
  • +/
    лох дело говорит
     

  • 1.13, Аноним (-), 04:55, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    apng?
     
     
  • 2.20, maxst (?), 09:27, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ...добавляется отдельным патчем.
     

  • 1.19, Аноним (-), 09:24, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    pngOS
     
  • 1.21, клоун Стаканчик (?), 10:40, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем, чьи проблемы ты должен решать?
     
     
  • 2.23, Аноним (-), 13:36, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > сохранили бы со статусом "obsolete" - и фиг с ним.
    > фиг с ним

    Windows way?

     
  • 2.31, Mihail Zenkov (ok), 18:42, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со
    > статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем,
    > чьи проблемы ты должен решать?

    Чистить код нужно постоянно - чем меньше кода, тем выше его читаемость, меньше ошибок, легче портировать.

    Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. Да и как правило библиотеки с хорошим дизайном редко сильно меняют API, в основном просто расширяют, соответственно обратная совместимость не ломается.

     
     
  • 3.35, Аноним (-), 19:13, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.

    Сами это написали, а выше ныли как страшно переписывать под новые версии. libpng так и делают, только времени доют ещё больше.

     
     
  • 4.37, Mihail Zenkov (ok), 20:21, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.
    > Сами это написали, а выше ныли как страшно переписывать под новые версии.
    > libpng так и делают, только времени доют ещё больше.

    Как раз с libpng и возникают проблемы, ибо программа собраная с ее поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.

    Где это они времени больше дают? Что-то не припомню при компиляции "Warning: xxxx this function depricated", за то вот error'ы как грибы после дождя, если версия не совпала.

     
     
  • 5.47, maxst (?), 08:35, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Где это они времени больше дают?

    Ну вот к примеру что можно найти в libpng-manual.txt в разделе где перечисляются изменения между 1.2.x и 1.4.x:

    The functions png_read_init(info_ptr), png_write_init(info_ptr),
    png_info_init(info_ptr), png_read_destroy(), and png_write_destroy()
    have been removed.  They have been deprecated since libpng-0.95.

    The png_permit_empty_plte() was removed. It has been deprecated
    since libpng-1.0.9.  Use png_permit_mng_features() instead.


     
     
  • 6.48, Mihail Zenkov (ok), 15:35, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот только на практике при попытке собрать приложение написанное под API 1.2.x с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.

    Я использую D как основной язык, так там API основной библиотеки долгое время был крайне нестабилен - ибо язык очень быстро развивался, но при этом я не ощущал от этого большого дискомфорта, так как реально старый API переставал работать только через продолжительный срок и при каждой компиляции я видел, что функция deprecated и дату/версию в которой ее удалят.

     
     
  • 7.49, maxst (?), 16:28, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот только на практике при попытке собрать приложение написанное под API 1.2.x
    > с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.

    В ветке 1.2.x ширину изображения можно было получить двумя способами:
    info_ptr->width
    png_get_image_width()

    В ветке 1.4.x прямой доступ убрали как небезопасный и оставили только
    png_get_image_width()

    Именно это изменение вызвало наибольший дискомфорт: во многих старых приложениях был прямой доступ и видимо разработчики libpng не смогли придумать, как сделать чтобы чтение info_ptr->width некоторое время работало, но предупреждало, что этот подход deprecated...

    По сравнению с этим, переход от 1.4.x к 1.5.x был относительно безболезненным, думаю 1.6.x тоже пройдет без особых проблем.

     
  • 5.53, Аноним (-), 00:49, 21/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Как раз с libpng и возникают проблемы, ибо программа собраная с ее
    > поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни
    > с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.

    И в glibc есть deprecated, и вообще вы сколько бибилотек пользуете? Я постоянно вижу развивающиеся (причём не ценой сотен костылей, а через устаревание старых интерфейсов) API, и это правильно. "Приводите" вы здесь один страдалец, и всё, что характерно, мимо.

     

  • 1.44, анонимаус (?), 23:56, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Прошлое многочасовое обновление с libpng 1.2 до 1.5 было со слезами на глазах и почти истерикой.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру