Доброй ночи. Люди, кто знает какие-нибудь нормальные либы (или dll) для работы с gif, png, tiff c sdk (примерами) поделитесь ссылками, а то все что попадается - сплошные COM да OLE да Си-классы Через OLE png-tiff не катят, да и gif очень медленно обрабатывается. Для png нашёл на форуме ссылку (bogrus давал), но там либа с файлами не работает, только с ресурсов нормально грузит И ещё вопрос: есть ли альтернатива StretchBlt в плане скорости?
Погуглил imlib - что-то кругом пестреют никсы, редхэты, не к добру это. Похоже, все сорсы на сях и под nix. load PPM, PGM, TIFF, PNG, XPM, JPEG and EIM format images про gif забыли. Нашёл тоже одну библу - Victor Image Processing Library. http://www.catenary.com С кучей примеров. Есть dll, есть вариант c lib (правда для си) Единственно она не бесплатная. До 31 июля
Зип 3 метра. Посмотрим, что там есть. Victor Image Processing Library тоже довольно простая в использовании. И работает достаточно быстро, значительно быстрее методов интерфейса IPicture. И размер dll 232 кб, а lib - 58 кб.
Уже проверил ?? Кстати о защите. Там для gif lzw используется, и он с символическим кодом, который надо заменить на настоящий (покупкой лицензии). Интересно, ограничение на lzw тоже сработает вместе с ограничением на саму либу? А GFL действительно мощная (и тяжёлая)
Видимо Quantum использовал её (предположительно). Если да, то вопрос: там в комплекте есть файлы libgfle240.dll libgfl240.dll libgfle.lib libgfl.lib Эти .lib - просто переходники для dll?
Проще глянуть самому: если lib содержит obj - значит она для статической линковки. Если имена вида "_imp__XXX", причём не системные (_imp__GetLastError@0), а из этой либы, то она — для динамической линковки.
cresta unisys уже года 2 как не владеет патентом на лзв, поэтому ничего не нужно лицензировать. А вообще для гифа и пнг такая либа за 2-4 дня пишется, я на пнг 4 дня потратил, и то из них большая половина на злиб ушло. Тиф посложнее, но там просто внутри куча разных алгоритмов может использоваться. Или купить уже готовое.
masquer Если несколько простых функций, то можно самому быстренько управиться, но там столько функций, что я и за 2 месяца не управлюсь Проще за два дня поломать А купить - за 2 дня полтысячи козлов не заработаю. IceStudent Раз завел речь о , то вопрос: Конвертирую Victor Image Processing Library с помощью DLL2LIB, так после конвертации некоторые функции оказались с именами: __imp__loadgif@8 или __imp__allocimage@16. А большая часть приняла вид __imp__defaultpalette, __imp__blur, __imp__loadpngpalette и т.д. Так те, что с "@x" не работают, то вылетят, то неверный результат возвращают, хотя и компилится с ними exe нормально. Приходится с ними через GetProcAddress общаться. Те, которые без "@x" получились - работают напрямую, в т.ч. и с invoke. Хотя и для тех и для других указал resolve symbol Это что, баг DLL2LIB или что-то не так делаю? Хотя это наверное больше для Quantum'а вопрос.
если для себя пишешь, то еще ладно, а вот если на заказ, и потом твоего клиента иметь будут прежде всего
cresta Можно нагуглить старую (относительно) vic32.dll, которая то ли бесплатная, то ли без защиты. Правда, функциональность у неё чуть ли не вдвое меньше теперешней Нужно смотреть, что там не так в статической связке, так с ходу не скажешь.
Нашёл, в чем проблема с DLL2LIB, но не знаю, как поправить Суть такова: некоторые функции из dll используют данные, зашитые в dll (возможно в секции .data) На примере одной процедуры: Код (Text): 60CB2FC1 > FF35 8C5FCC60 PUSH DWORD PTR DS:[60CC5F8C] 60CB2FC7 FF7424 14 PUSH DWORD PTR SS:[ESP+14] 60CB2FCB FF7424 14 PUSH DWORD PTR SS:[ESP+14] 60CB2FCF FF7424 14 PUSH DWORD PTR SS:[ESP+14] 60CB2FD3 FF7424 14 PUSH DWORD PTR SS:[ESP+14] 60CB2FD7 E8 03000000 CALL vic32.60CB2FDF 60CB2FDC C2 1000 RETN 10 После этого на стеке имеются данные: 60CB2FDF ;четыре параметра передавал я 00000690 ;из exe при вызове функции 0000091F 00000008 [b]00000001[/b] ;этот параметр dll добавляет сама из DWORD PTR DS:[60CC5F8C] Если вызывать функцию из .lib (сделанную DLL2LIB), то код тот же, но один параметр берётся из exe. Код (Text): 004272E5 /$ FF35 41C44300 PUSH DWORD PTR DS:[43C441] 004272EB |. FF7424 14 PUSH DWORD PTR SS:[ESP+14] 004272EF |. FF7424 14 PUSH DWORD PTR SS:[ESP+14] 004272F3 |. FF7424 14 PUSH DWORD PTR SS:[ESP+14] 004272F7 |. FF7424 14 PUSH DWORD PTR SS:[ESP+14] 004272FB |. E8 03000000 CALL My_Exe.00427303 00427300 \. C2 1000 RETN 10 После этого на стеке имеются данные: 60CB2FDF ;четыре параметра 00000690 ;из exe при вызове функции 0000091F ;совпадают 00000008 [b]00000000[/b] ;этот параметр теперь берется из exe DWORD PTR DS:[43C441] Т.е. данные , хранящиеся в dll, при конвертации в lib теряются/заменяются. И функция не отрабатывает нормально. Можно ли это поправить?
а подробнее, что за функция? ага, нашёл, это alloc_image. та переменная (dw_AllocImage) инициализируется в DllMain в зависимости от версии системы, вроде: Код (Text): .text:60CB2F0D mov eax, ebx ; eax = GetVersion .text:60CB2F0F xor ecx, ecx .text:60CB2F11 and eax, 0FFh .text:60CB2F16 mov cl, bh .text:60CB2F18 imul eax, 64h .text:60CB2F1B add eax, ecx .text:60CB2F1D cmp ebx, 80000000h .text:60CB2F23 mov dword_60CC5F90, eax .text:60CB2F28 jnb short loc_60CB2F2F .text:60CB2F2A push 2 .text:60CB2F2C pop ecx .text:60CB2F2D jmp short loc_60CB2F37 .text:60CB2F2F ; ----------------------------------------- .text:60CB2F2F .text:60CB2F2F loc_60CB2F2F: .text:60CB2F2F cmp eax, 18Bh .text:60CB2F34 sbb ecx, ecx .text:60CB2F36 inc ecx .text:60CB2F37 .text:60CB2F37 loc_60CB2F37: .text:60CB2F37 cmp ecx, edi ; edi = 1 .text:60CB2F39 mov dword_60CC5F94, ecx .text:60CB2F3F mov dw_AllocImage, esi ; dw_AllocImage = 0 .text:60CB2F45 jz short loc_60CB2F53 .text:60CB2F47 cmp ecx, 2 .text:60CB2F4A jnz short loc_60CB2F59 .text:60CB2F4C cmp eax, 15Eh .text:60CB2F51 jb short loc_60CB2F59 .text:60CB2F53 .text:60CB2F53 loc_60CB2F53: .text:60CB2F53 mov dw_AllocImage, edi .text:60CB2F59 .text:60CB2F59 loc_60CB2F59:
cresta Да. Кстати, я этой либой давно пользуюсь и очень доволен (не сочтите за рекламу Вы не забыли вызвать DllMain перед тем как использовать любую другую функцию из либы? (Айс уже подметил)
IceStudent Угу, это allocimage. Неизвестно, где ещё такие подводные камни могут оказаться Quantum :-0 invoke VIC32_DllMain, NULL, DLL_PROCESS_ATTACH, NULL Никогда самому не приходилось вызывать DllMain. Тем более в .lib. Поэтому даже и не думал об этом. А действительно, инициализируются данные. Хм. Остается надеяться, что все необходимые. Если продукт достойный, почему бы и не порекламировать Попробовал несколько примеров для GFL - возможностей несколько больше, чем у VIC, но пробовал только как ActiveX (из VB6). Непосредственно с dll не получилось, кругом поинтеры на поинтеры, из VB не удалось инициализировать dll, не нашёл GFL_ERROR gflLibraryInitEx( GFL_ALLOC_CALLBACK alloc_callback, GFL_REALLOC_CALLBACK realloc_callback, GFL_FREE_CALLBACK free_callback, void * user_parms ); да и callback'и честно говоря, не нравятся, неизвестно, что в них делать. Как ActiveX она работает медленнее VIC, возможно из-за COM (не самая быстрая технология).
Quantum Достаточно вызвать 1 раз, кстати, cresta, hInstance используется только в Victorversionex, так что если звать её, то в DllMain лучщше передать реальный hInstance модуля. И позвать в конце с DLL_PROCESS_DETACH, там ресурсы освобождаются. Если нужна мультипоточность, то желательно звать ещё и с DLL_THREAD_ATTACH. А вообще, там инициализируются всего 3 переменных (кстати, две из них я не нашёл где используются дальше), можно придумать что-то оригинальнее вызова DllMain
Ага сорцы, на сях. Но под винду собирается. Кроме того погугли такие либы libxpm, libtiff, libpng, libjpeg и так далее. они тоже сорцы и на сях... но MinGW + gcc всё скомпилирует без проблем. Если боишься компилировать, посмотри на cygwin, там можно найти уже скомпилированные.