Bitmap=>Jpeg без модуля Jpeg соотвтственно.

← →
Sub_Black (2006-04-17 11:20) [0]

Ребяты, подскажите возможно ли это, API вроде напрямую с Jpeg не работает. Может быть есть у кого наработки, а-то я пока в тупике.

← →
Brother © (2006-04-17 11:37) [1]

НЕ ВОЗМОЖНО! Твой тупик на всегда. Без модуля ниче не выйдет.
:(

← →
Sub_Black (2006-04-17 12:12) [2]

Тогда может быть есть варианты? Менее громоздкие модули, например от сторонних разработчиков? Неужели все вот так вот грустно?

← →
Elen © (2006-04-17 12:29) [3]

Поищи компоненты вроде ImageGear или Impulse Studio. Они распространяются как ActiveX и их легко встроить в Делфи. Это не настолько громоздкие компоненты

← →
balepa © (2006-04-17 13:08) [4]

> Sub_Black (17.04.06 12:12) [2]
> Тогда может быть есть варианты? Менее громоздкие модули, например от > сторонних разработчиков? Неужели все вот так вот грустно?

Напиши свой

← →
ZzzzZ © (2006-04-17 13:51) [5]

XЧерез оли или как ее там.
Где-то видел пример, на асме.

← →
Sub_Black (2006-04-17 14:52) [6]

>>Elen Спасибо, порыскаю
>>balepa, Гы :), да вы шутник
>>ZzzzZ Боюсь, что это будет работать не быстро :(

Да, ребят, попутный вопрос, как на API сохранить Bitmap в файл?

← →
Poirot © (2006-04-17 15:02) [7]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_7zfp.asp

← →
Sub_Black (2006-04-17 15:11) [8]

>>Poirot Ок, спасибо!

← →
MBo © (2006-04-17 15:26) [9]

>Bitmap=>Jpeg без модуля Jpeg
GDIPlus это умеет

← →
DVM © (2006-04-17 15:27) [10]

Intel Jpeg Library - очень хорошая и быстрая библиотека.

← →
Sub_Black (2006-04-17 16:01) [11]

>>MBo а можно по подробнее про GDIPlus - а-то я слышал кое что, входит ли он в винду и где интерфейсы модулей взять?

← →
Rouse_ © (2006-04-17 16:04) [12]

Jpeg.pas идет в составе дистрибутива (CD:\Info\Extras\Jpeg\) - вытащи оттуда необходимый код и не используй модуль :)

← →
Sub_Black (2006-04-17 16:07) [13]

>>DVM сейчас посмотрим на ентого зверя (IJL)
>>Rouse_ тоже идея, но по-моему Delphi включает в файл только те процедуры, которые реально используются, нет разве?

← →
DVM © (2006-04-17 16:14) [14]

> Sub_Black (17.04.06 16:07) [13]

http://www.ipcam.ru/IJL.ZIP - 1.5 и 2.0 версии библиотеки + заголовочные файлы + модуль-пример использования

← →
Sub_Black (2006-04-18 11:36) [15]

>>DVM СПАСИБИЩИ!
Спасибо, ребяты всем, очень было приятно получить столько полезных откликов ;)

← →
XProger © (2006-04-18 12:09) [16]

Sub_Black, нет ничего невозможного...
Используй OleLoadPictureFile и OleSavePictureFile из oleaut32.dll

← →
Sapersky (2006-05-02 12:19) [17]

http://www.ipcam.ru/IJL.ZIP - 1.5 и 2.0 версии библиотеки

Наконец-то протестировал скачанную версию 2.0... и обнаружил, что она медленнее 1.5. Для 1.5 нужно было установить ключ в реестре, чтобы она поняла, с каким процессором имеет дело:

CPUKey:=0;
// determine Pentium, Pentium Pro, Pentium II
if CPUInfo.VendorID="GenuineIntel" then
if CPUInfo.Family=5 then CPUKey:=1 else if CPUInfo.Family=6 then
if CPUInfo.Model > 1 then CPUKey:=4 else CPUKey:=2;

// determine MMX, Pentium III, Pentium 4
if(cfMMX in CPUInfo.Features)and(CPUKey < 3)then CPUKey:=3;
if cfSSE in CPUInfo.Features then CPUKey:=5;
if cfSSE2 in CPUInfo.Features then CPUKey:=6;

RegCreateKeyEx(
HKEY_LOCAL_MACHINE,"SOFTWARE\Intel Corporation\PLSuite\IJLib",0,nil,
REG_OPTION_NON_VOLATILE,KEY_WRITE,nil,Key,@Dummy);

RegSetValueEx(Key,"USECPU",0,REG_DWORD,@CPUKey,4);
RegCloseKey(Key);

(из FastLIB"а - FastFiles.pas).

Возможно, для 2.0 что-то изменилось?
На сайте Intel, т.к. они прекратили разработку IJL как отдельной библиотеки, по этому поводу ничего нет. Или плохо искал?

← →
DVM © (2006-05-03 10:25) [18]

> Sapersky (02.05.06 12:19) [17]

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

> Для 1.5 нужно было установить ключ в реестре, чтобы она
> поняла, с каким процессором имеет дело:

А для Athlon64 не в курсе, что лучше ставить в реестре?

← →
DVM © (2006-05-03 11:07) [19]

Сам себе отвечу - для Athlon64 оптимально - 6

← →
Sapersky (2006-05-03 12:34) [20]

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

Сомнительно всё-таки, что Intel ради стабильности специально затормозила свою библиотеку (и с чего тогда размер вырос? я полагал - от увеличения количества оптимизированных под разные процессоры ветвей).

Ещё вдобавок к затормаживанию версия 2.0 отказывается грузить картинки по частям, с указанием Rect (ругается, что invalid jpeg properties).
Это наводит на мысль, что структура JpegProperties изменилась (или её выравнивание?). Так же как и положение/значение ключа в реестре. И что где-то должны существовать обновлённые заголовки... документация какая-нибудь...

А ту скорость, которую мы сейчас имеем с версией 2.0, можно получить и от OleLoadPicture. Безо всяких дополнительных DLL. Правда, с многопоточностью и повреждёнными картинками не тестировал.

← →
DVM © (2006-05-03 14:00) [21]

> Sapersky (03.05.06 12:34) [20]

вот последний заголовочный файл, что удалось найти:
http://www.informsystems.ru/files/ijl.h
1998-2006 стоит

← →
DVM © (2006-05-03 14:08) [22]

> Так же как и положение/значение ключа в реестре.

в реестр новая версия библиотеки не лезет

← →
Sapersky (2006-05-03 16:52) [23]

Спасибо.
Посмотрел - вроде принципиальных изменений нет.
Проверил PROCESSOR_TYPE - у 1.5, как и положено, 6, у 2.0 - 0.
Есть подозрение - т.к. IJL теперь входит в состав платной IPP, определение процессора привязали к какой-то из IPP"шных DLL"ок (с динамической загрузкой), а получение через реестр вырезали.
К тому же и тип PROCESSOR_TYPE определён в заголовках ipp ("See ippdefs.h for details").

← →
Woolen © (2006-05-04 22:31) [24]

Товарищи, опомнитесь, у него XP в требованиях. Какие библиотеки? Там вся работа с JPEG встроена ось. Про gdiplus.dll кто-нибудь слышал?

← →
Sapersky (2006-05-05 12:05) [25]

Про gdiplus.dll кто-нибудь слышал?

Слышали, что памяти много жрёт и тормозит... Самому протестировать пока руки не дошли.
И можно ли через gdiplus грузить jpeg не полностью, а произвольные фрагменты?

← →
programania © (2006-05-05 21:27) [26]

3 примера из книги "программирование Win32 API в delphi":
показ кодеков, конвертирование между bmp jpg gif tiff png
изменение сжатия jpg и headers
http://programania.com/gdiplus.zip 160кб
и еще есть другие примеры
но почему-то 1-ый раз долго компилируются в delphi7
а потом все быстро

← →
homm © (2006-05-05 23:23) [27]

> Bitmap=>Jpeg без модуля Jpeg соотвтственно.

поиши на http://bonanzas.rinet.ru/ да и вообще, смысл писать на API, когда есть KOL - все плюсы RAD и компактный, быстрый exe

← →
Sapersky (2006-05-06 13:09) [28]

Протестировал.
Загрузка jpeg 3072 * 4096 (Cel 2.8):

OleLoadPicture: 1170 мс
GDIPlus: 920 мс
IJL 1.5: 380 мс

А теперь попробуйте убедить меня использовать GDIPlus... :)

но почему-то 1-ый раз долго компилируются в delphi7

Тоже замечал такое с некоторыми своими программами... возможно, заголовки DirectX виноваты.

← →
programania © (2006-05-06 13:37) [29]

Тоже испытал на C2.8 4000*2500 2мб
http://programania.com/test_jpg.zip 2кб

IJL15.DLL 430 мСек
IJL20.DLL 650 мСек
GDI+ часть картинки 540 мСек
GDI+ вся 790 мСек
Delphi Jpeg 1800 мСек

>Sapersky (06.05.06 13:09) [28]
>А теперь попробуйте убедить меня использовать GDIPlus... :)

Для нее не нужна dll она есть в windows
и в ней есть множество процедур например
качественной трансформации и масштабирования изображений
и не только jpg

← →
Sapersky (2006-05-06 14:55) [30]

Такое ощущение, что каждый немного "подтянул" результаты в сторону любимой библиотеки :)
В общем использовать то или другое - дело вкуса...
Добавлю только, что "есть в windows" означает "есть в windows XP". Тогда как сопоставимая по скорости OleLoadPicture работает и в 98. Безо всяких DLL и линкуемых obj.
А что касается IJL ... если уж начали меряться скоростью загрузки фрагментов... так вот, загрузка фрагмента картинки 532 * 336 с отступом 300 * 300... 35 мс (IJL 1.5).
Задать загружаемый прямоугольник можно через TJPEG_PROPERTIES.

← →
programania © (2006-05-07 00:00) [31]

>Такое ощущение, что каждый немного "подтянул" результаты в сторону любимой библиотеки :)

У меня результат IJL без изменения реестра, с изменением раза в 2 быстрее,
но не нравится мне менять реестр и зависеть от других программ и процессора
и хотя значение CPUKey=6 одинаково действует на Celeron и Atlon64
но ведь все какие есть и будут не проверишь
и IJL не читает jpg типа 32bit CMYK, а GDI+ читает

← →
DevilDevil © (2006-05-07 20:49) [32]

МАСТЕРА,
ссылка http://www.ipcam.ru/IJL.ZIP не работает!
Скиньте, пожалуйста, кто-гибудь на devil_home@mail.ru ,- в своё время очень интересовался сабжем, купил даже книжку "Методы Сжатия Данных", но жпег описан там очень плохо + реализовывать всё это самостоятельно - жуть!

← →
DVM © (2006-05-07 21:48) [33]

> null

Положил обратно http://ipcam.ru/files/ijl.zip
Добавил определение процессора

Все-таки Intel Jpeg Library вне конкуренции. В моих задачах в секунду удается декодировать более 150 jpeg 640*480 на приемлемом процессоре (P4 820 D).
Жаль что непонятно как работать с версией 2.0.

← →
DevilDevil © (2006-05-08 02:54) [34]

Посмотрел ссылку...
Скорость может быть и большая, но требовалось, насколько я понял, не это...
Требовался менее громоздкий модуль, чем в Delphi (менее 100кб в экзешнике). Так вот ни IJL, ни GDI+ этому условию не удовлетворяют. Кроме того заставляют таскать с собой dll

...Щас начнут писать, что GDIPlus.dll идёт вместе с Виндой... Не стоит

← →
Sapersky (2006-05-08 10:10) [35]

Требовался менее громоздкий модуль, чем в Delphi

Я уже два раза упоминал в этой ветке OleLoadPicture ([20], [30]). И ещё XProger в [16].
Пример с KOL.PBitmap (TinyPictures) здесь:
http://www.homm86.narod.ru
У меня есть c TFastDIB.

← →
DVM © (2006-05-08 11:39) [36]

> Требовался менее громоздкий модуль, чем в Delphi (менее
> 100кб в экзешнике). Так вот ни IJL, ни GDI+ этому условию
> не удовлетворяют. Кроме того заставляют таскать с собой
> dll

Я без проблем могу написать приложение килобайт на 15-20, которое будет работать с IJL. А dll - недостаток небольшой.

← →
Мефисто (2006-05-08 12:41) [37]

DevilDevil © (08.05.06 02:54) [34]

Ставить рекорды на уменьшение размера ПО у народа чето никак не пропадает. К чему бы это? Времена DOS уже как вроде прошли...

← →
antonn © (2006-05-08 13:59) [38]

Мефисто (08.05.06 12:41) [37]
да еще и упаковщиками увлекаются...

← →
homm © (2006-05-08 14:56) [39]

> [35] Sapersky (08.05.06 10:10)

Читай внимательнее:
> Bitmap=>Jpeg без модуля Jpeg соотвтственно.

http://kolnmck.ru/files/components/graphics/koljpegobj.zip
DevilDevil уже ей пользется похоже :)

← →
Sapersky (2006-05-08 15:27) [40]

Опс, забыл :(
А если OleSavePictureFile? Я, правда, ни разу не пользовался...

← →
DevilDevil © (2006-05-08 22:17) [41]

homm © (08.05.06 14:56) [39]
http://kolnmck.ru/files/components/graphics/koljpegobj.zip
DevilDevil уже ей пользется похоже :)
Да, действительно

Результат неплохой: приложение, имеющее возможность перекодировать bmp в jpeg и обратно + иконка(3кб) занимает 113кб. А если сжать ASPack-ом, то - 64,5 кб. Правда, хотелось бы ещё лучше (всё-таки 80кб на jpeg мне кажется много). Может, у кого-то ещё есть варианты?

Sapersky (08.05.06 10:10) [35]
XProger © (18.04.06 12:09) [16]
Используй OleLoadPictureFile и OleSavePictureFile из oleaut32.dll
Подскажите, где достать заголовочные файлы + документацию. Библиотека идёт в поставке с Windows?

Мефисто (08.05.06 12:41) [37]
antonn © (08.05.06 13:59) [38]
Вы когда нибудь пробовали написать стоящее приложение на чистом API? Вы не задумывались, почему талантливые программисты (такие как Владимир Кладов) тратят не один год жизни, чтобы облегчить остальным условия создания компактных приложений? Может настало время перестать демонстрировать свою необразованность...

← →
XProger © (2006-05-09 00:01) [42]

DevilDevil,
http://www.google.ru/search?q=OleLoadPictureFile
ole32.dll uses ActiveX

← →
antonn © (2006-05-09 07:33) [43]

DevilDevil © (08.05.06 22:17) [41]
Вы когда нибудь пробовали написать стоящее приложение на чистом API?
Пробовал.

ко мне какие притензии? :)
или упаковщики - это хорошо? архиватор то все равно лучше:)
вообще не понял фразу, к чему там В.Кладов и необразованность...

← →
DevilDevil © (2006-05-09 14:55) [44]

antonn © (09.05.06 07:33) [43]
упаковщики - это хорошо. API - это хорошо. KOL - это хорошо. API+УПАКОВЩИК - ну очень хорошо! Причины стремления уменьшить размер приложения слишком очевидны. Показывая незнание этих причин, вы показываете свою необразованность

XProger © (09.05.06 00:01) [42]
И почему Мастера до сих пор не научились давать стоящие ответы?
Знаем мы прекрасно, где какие поисковики!
статей много, я спрашивал про хорошие, ищут которые не одну неделю, которые вам (Мастерам) известны

← →
antonn © (2006-05-09 15:14) [45]

DevilDevil © (09.05.06 14:55) [44]
упаковщики - это хорошо.
а, все ясно...

> Причины стремления уменьшить размер приложения слишком
> очевидны.

видимо мне не слишком очевидны. Для уменьшения размера можно написать на WinApi (ну кол, если хочется). Еще есть Асм.
Объемы дисковой памяти, имхо, уже давно не критичны для exe. Оперативная память - тут стоит поспорить о полезности упаковщика. Имхо, дисковой памяти куда больше, чем оперативной, так путь же приложение на винте будет больше занимать, чем в памяти.
для передачи и распространения (по сети/на носителях) придуманы архиваторы.
Куда тут приткнуть упаковщик?
И не обманывайтесь размером exe, в памяти он ничуть не меньше будет занимать, чем не упакованный, либо доступ к данным будет медленней (при динамической распаковке). Так же как и скоростью работы.

короче говоря, не раз были подобные споры, ни к чему они не приводили, фанаты остались при своем мнении... :(

← →
X: (2006-05-09 18:54) [46]

DevilDevil, мастера как никто другой знают как научить неграмотного человека... ищи!

← →
homm © (2006-05-09 23:12) [47]

> видимо мне не слишком очевидны.

Знаете, у меня когда-то была машина AMD K5-100 МГц, 16 мб оперативы. Могу вас заверить, что приложение, скомпилированое из пустого проекта запускалось раза в 2 дольше, чем например Paint, или Блокнот. И не надо говорить, что включение кучи ненужного и, вдобавок, криво написаного кода не влечет за собой падения производительности.

Хотя, так и не понял, может Вы против только упаковщиков, тогда Вы правы относительно VCL, но опять-же если несжатый файл весит 100 кб, то его функциональность при написании на кол будет такой, что эти самые 100 кб, распакованые в оперативе никто не заметит.

← →
antonn © (2006-05-10 06:47) [48]

homm © (09.05.06 23:12) [47]
Знаете, у меня когда-то была машина
когда то по стране шло раскулачивание - нука быстренько компутер бедным отдать! :)
надо из сегодняшних реалий исходить, когда то и операционной системе хватало 640Кб в реальном режиме, чтож, писать на асме все программы?

> И не надо говорить, что включение кучи ненужного и,
> вдобавок, криво написаного кода не влечет за собой
> падения производительности.

а упаковщики, типа, мой корявый код выстраивают в логически правильный и максимально производительный?
может это и неправильно, но я предпочитаю получать код таким, как я его сам выстроил (ну через компилятор), и не доверяться программам, которые там что то свое правят.

Хотя, так и не понял, может Вы против только упаковщиков
именно, я против тех программ, которые чего то там копаются в моей программе, секции ровняют, пережимают...
по АПИ и сред "чуть повыше" не имею ничего против.

← →
homm © (2006-05-10 08:11) [49]

> надо из сегодняшних реалий исходить

И что? Хотите сказать, что если раньше приложения на VCL работали медленее, чем на API на порядок, то из-за того, что сейчас это не видно это не так?

> по АПИ и сред "чуть повыше" не имею ничего против.

Ну тогда ладно :) и спорить по сути не о чем, просто не надо говорить что программы на VCL не медленее чем на API.

← →
DevilDevil © (2006-05-10 13:48) [50]

antonn © (09.05.06 15:14) [45]
Задачи разные бывают, средства разработки - тоже. Для их реализации программисты сами определяют отношение время разработки/размер. По вышеуказанным тобой причинам, размер в большинстве случаев не имеет значения. Отчасти поэтому мы выбираем быструю Delphi даже не думая о размере. Однако, встречаются и другие задачи, в которых размер имеет значение, где лучше идти путём ASM+упаковщик. В общем, разные задачи бывают. В основном, это софт распространяемый по сети. Мне намного приятнее качать 30кб вместо 400кб. В этом смысле тандем KOL+упаковщик ИМХО оптимален. Можно ещё много приводить доводов, но сабж не об этом... В связи с вышесказанным, давайте перестанем обсуждать очевидное

Ну так даст кто-нить ссылку на нормальную статью по OleLoadPictureFile?

← →
homm © (2006-05-10 13:57) [51]

> Однако, встречаются и другие задачи, в которых размер имеет
> значение

LOL

← →
antonn © (2006-05-10 16:47) [52]

DevilDevil © (10.05.06 13:48) [50]
Однако, встречаются и другие задачи, в которых размер имеет значение, где лучше идти путём ASM+упаковщик. В общем, разные задачи бывают. В основном, это софт распространяемый по сети. Мне намного приятнее качать 30кб вместо 400кб.
архиватор (winrar/winzip/7zip/ace), надо полагать, вещь малополезная и ненужная?...

← →
XProger © (2006-05-10 17:08) [53]

DevilDevil, я так посмотрю, для тебя время разработки не имеет значения по сравнению с размером? Вместо нытья уже давно бы нашёл нужную тебе информацию по приведённой мною же ссылке...

← →
homm © (2006-05-10 22:29) [54]

> Вместо нытья уже давно бы нашёл нужную тебе информацию по
> приведённой мною же ссылке...

Нету по этой ссылке нужной ниформации. Т.к. не работает эта функция с jpg похоже.

← →
XProger © (2006-05-11 00:19) [55]

homm, не шути так...

← →
homm © (2006-05-12 15:19) [56]

> homm, не шути так...
Ты немного не понял, я имел ввиду конечно OleSavePictureFile, по ней действительно нет документации (http://msdn.rambler.ru/ , http://msdn.microsoft.com)

> DevilDevil, я так посмотрю, для тебя время разработки не
> имеет значения по сравнению с размером?
Время разработки на KOL+MCK не на много отличается от времени разработки на VCL.

>> Мне намного приятнее качать 30кб вместо 400кб.
> архиватор (winrar/winzip/7zip/ace), надо полагать, вещь
> малополезная и ненужная?...
Мне тоже намного приятнее качать 30кб(KOL+rar) вместо 200кб(VCL+rar).

← →
antonn © (2006-05-12 15:21) [57]

homm © (12.05.06 15:19) [56]
Мне тоже намного приятнее качать 30кб(KOL+rar) вместо 200кб(VCL+rar).
это шутка такая?

← →
antonn © (2006-05-12 15:22) [58]

а, пардон, разум затмился:)
мне тоже прияней меньше качать.
мне не приятно качать сжатую упаковщиком программу, которую сжимали "для передачи по сети".

← →
DevilDevil © (2006-05-12 16:36) [59]

МЛЯЯЯ

беру экзешник на D5 размером 293 888 байт. Зажимаю архиватором: 159 793 байт. Снова беру исходный, зажимаю ASPack-ом: 135 168 байт. Зажимаю архиватором: 123 488 байт. Ну так что лучше: 159 793 или 123 488? Причём с ростом размера exe, эффективность Будет УВЕЛИЧИВАТЬСЯ. В конце концов пакер сжимает лучше архиватора!

ЗЫ ну ёлки-палки, Мастера! Ну сами попробуйте, прежде чем высказываться :(

← →
WondeRu © (2006-05-12 16:57) [60]

Sub_Black (17.04.06 16:01) [11]
компоненты GDIPlus с кучей примеров на http://www.progdigy.com/

← →
XProger © (2006-05-12 17:25) [61]

homm, меня тоже неверно поняли. Человек уже вторую неделю пытается выпросить код функции, в то время как в сети (японские сайты никто не отменял) существует масса примеров использования OLE. Ссылку на эти примеры я уже привёл.

← →
homm © (2006-05-12 19:28) [62]

> беру экзешник на D5 размером 293 888 байт.

Ну-ну. 293 888 байт? Размер пустой формы? А 30 кб - средний размер готовой программя, которая реально что-то делает.

← →
antonn © (2006-05-12 20:07) [63]

homm © (12.05.06 19:28) [62]
да он не про это...
а про то, что лучше упаковать+архив, чем просто архив (хоть что, как я понял).
в примере упакованный меньше, но не на много. Dll тоже сжимаются?

← →
имя (2006-05-12 22:50) [64]

Удалено модератором

← →
DevilDevil © (2006-05-13 01:33) [65]

XProger © (09.05.06 00:01) [42]
подключил модуль ActiveX, использую OleLoadPictureFile, при запуске приложения компилятор кричит, что не найдена точка входа в DLL. Посмотрел, в модуле ActiveX идёт ссылка на olepro32.dll, попробовал с ole32.dll как ты говорил, результат прежний. Что делать? Да, и это... дай уже ссылку на хорошую стать.

ЗЫ там требуется класс CPictureHolder... где брать?

← →
DevilDevil © (2006-05-13 01:43) [66]

исправил, в своём модуле в разделе implementation сделал следующее объявление (olepro32.dll -> oleaut32.dll):
function OleLoadPictureFile(varFileName: OleVariant; var lpdispPicture: IDispatch): HResult; stdcall; external "oleaut32.dll" name "OleLoadPictureFile"; function OleSavePictureFile(dispPicture: IDispatch; bstrFileName: TBStr): HResult; stdcall; external "oleaut32.dll" name "OleSavePictureFile";

а сохраняю jpeg в другой формат так:
procedure TForm1.FormCreate(Sender: TObject); var Disp : IDispatch; begin OleLoadPictureFile("C:\Example.jpg", Disp); OleSavePictureFile(Disp, "C:\Ex.bmp"); Disp := nil; end;

Тем не менее остаётся ещё несколько вопросов:
1) существует возможность более продвинутой работы с графическими данными посредством этих функций. Как?
2) что за CPictureHolder, где его достать?
3) существует ли эквивалентная статья по Delphi?

С Уважением

← →
DevilDevil © (2006-05-13 02:00) [67]

вы уж извините меня за мой французский, но нихрена они не работают, как я того ожидалю Т.е. из жпега, гифа, может ещё какого формата В БИТМАП сохраняет. Зато вот обратно - никак. Точнее сохраняет например под именем Example.jpg, а по сути своей всё тот же битмап,- занимает РОВНО столько, сколько битмап

← →
homm © (2006-05-13 03:05) [68]

> 1) существует возможность более продвинутой работы с графическими
> данными посредством этих функций. Как?

По памяти:
procedure TForm1.FormCreate(Sender: TObject); var Disp : IPicture; Bitmap: HBitmap; begin OleLoadPictureFile("C:\Example.jpg", Disp); Disp.GetHandle(Bitmap); Disp := nil; end;

> вы уж извините меня за мой французский, но нихрена они не
> работают, как я того ожидалю
А ты должен не ожидать, а делать. Но в данном случае даже это не поможет. (см где-то выше)

← →
DevilDevil © (2006-05-15 01:20) [69]

homm © (13.05.06 03:05) [68]
var Disp : IPicture; w : integer; begin if SUCCEEDED(OleLoadPictureFile("C:\Ex.bmp", Disp)) then Caption := "Ok"; // Disp.get_Width(w); // Caption := IntToSTr(w); Disp := nil; end;

Если разкоментировать, то возникает ошибка чтения данных.
Подозреваю, не IPicture здесь должен быть, а IDispatch ... однако этот подобных методов не имеет...

← →
homm © (2006-05-15 08:18) [70]

http://homm86.narod.ru/files/tinypictures.rar

← →
имя (2006-05-26 06:18) [71]

Удалено модератором

← →
имя (2006-05-26 07:49) [72]

Удалено модератором

← →
имя (2006-05-26 07:57) [73]

Удалено модератором

← →
имя (2006-05-26 09:53) [74]

Удалено модератором

← →
имя (2006-05-26 11:33) [75]

Удалено модератором

← →
имя (2006-05-26 11:55) [76]

Удалено модератором

← →
имя (2006-05-26 12:40) [77]

Удалено модератором

← →
имя (2006-05-26 14:39) [78]

Удалено модератором

← →
имя (2006-05-26 15:01) [79]

Удалено модератором

← →
имя (2006-05-26 18:23) [80]

Удалено модератором

← →
имя (2006-05-26 18:55) [81]

Удалено модератором

← →
имя (2006-05-26 19:09) [82]

Удалено модератором

← →
antonn © (2006-05-26 19:30) [83]

спамер - сдохни, пожалуйста.

← →
имя (2006-05-26 19:47) [84]

Удалено модератором

← →
имя (2006-05-26 19:56) [85]

Удалено модератором

← →
имя (2006-05-26 19:58) [86]

Удалено модератором

← →
имя (2006-05-26 20:11) [87]

Удалено модератором

← →
имя (2006-05-26 20:19) [88]

Удалено модератором

← →
имя (2006-05-26 20:55) [89]

Удалено модератором

← →
имя (2006-05-26 21:00) [90]

Удалено модератором

← →
имя (2006-05-26 21:07) [91]

Удалено модератором

← →
имя (2006-05-26 21:12) [92]

Удалено модератором

← →
имя (2006-05-26 21:18) [93]

Удалено модератором

← →
имя (2006-05-26 21:28) [94]

Удалено модератором

← →
имя (2006-05-26 21:28) [95]

Удалено модератором

← →
имя (2006-05-27 00:54) [96]

Удалено модератором

← →
имя (2006-05-27 02:08) [97]

Удалено модератором

А по IP его нельзя забанить?

← →
имя (2006-05-27 03:37) [99]

Удалено модератором

← →
имя (2006-05-27 07:09) [100]

Удалено модератором

← →
имя (2006-05-27 08:11) [101]

Удалено модератором

← →
имя (2006-05-27 10:18) [102]

Удалено модератором

← →
имя (2006-05-27 11:41) [103]

Удалено модератором

← →
имя (2006-05-27 13:41) [104]

Удалено модератором

← →
имя (2006-05-27 13:44) [105]

Удалено модератором

← →
имя (2006-05-27 13:52) [106]

Удалено модератором

← →
имя (2006-05-27 13:55) [107]

Удалено модератором

← →
имя (2006-05-27 14:15) [108]

Удалено модератором

← →
имя (2006-05-27 14:19) [109]

Удалено модератором

← →
имя (2006-05-27 15:35) [110]

Удалено модератором

← →
имя (2006-05-27 16:08) [111]

Удалено модератором

← →
имя (2006-05-27 16:16) [112]

Удалено модератором

← →
имя (2006-05-27 17:29) [113]

Удалено модератором

← →
имя (2006-05-27 17:32) [114]

Удалено модератором

← →
имя (2006-05-27 18:41) [115]

Удалено модератором

← →
имя (2006-05-27 18:52) [116]

Удалено модератором

← →
имя (2006-05-27 19:22) [117]

Удалено модератором

← →
имя (2006-05-27 19:54) [118]

Удалено модератором

← →
имя (2006-05-27 21:19) [119]

Удалено модератором

← →
имя (2006-05-27 21:38) [120]

Удалено модератором

← →
имя (2006-05-27 22:38) [121]

Удалено модератором

← →
имя (2006-05-28 00:11) [122]

Удалено модератором

Bitmap=>Jpeg без модуля Jpeg соотвтственно. Найти похожие ветки