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

← →
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;

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

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 ... однако этот подобных методов не имеет...

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]

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

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