Лучше тут задам вопрос.

Где можно посмотреть взаимодействие Jpeg и библиотеки FastLib ?

Уже ответил в почту, но повторю здесь, вдруг кому пригодится.
http://sapersky.narod.ru/files/FastLIBv389i.rar
Пример Bumpmap, только Smooth рекомендую ставить в False - так быстрее. Да и вообще непонятно, в чём смысл этого сглаживания - убирать артефакты у сильно пожатых картинок? но сейчас в моде слабо пожатые...

Спасибо, Александр.

А нет какой-нибудь другой реализации, без dll?

И что, кстати, в этой библиотеке лучше?

Думаю, если сильно поколдовать - можно объединить с http://kolnmck.kolmck.net/files/components/graphics/koljpegobj.7z

> DevilDevil ©   (27.05.09 09:40) [2]


> А нет какой-нибудь другой реализации, без dll?

сделай, но IJL по скорости вне конкуренции.


> И что, кстати, в этой библиотеке лучше?

в смысле лучше, лучше чем что?

>в смысле лучше, лучше чем что?
сравнивая со "стандартным юнитом JPEG"
кроме скорости есть ещё плюсы?

>сделай, но IJL по скорости вне конкуренции.
есть ли какие замеры по скорости кодирования/декодирования ?

Вопрос в догонку:
Почему TJpegImage со качеством 100% значительно тяжелее, сделанного в PhotoShop-е и IrfanView ?

А нет какой-нибудь другой реализации, без dll?

Письмо не дошло что ли? OleLoadPicture (там пример был), GdiPlus.

Думаю, если сильно поколдовать - можно объединить с koljpegobj

Я даже объединял в своё время, но затем отказался от этой идеи. Просто смысла нет. Для "какую-нибудь мелочь загрузить" есть OleLoadPicture. Для "загрузить/сохранить во всех режимах и чтобы быстро" есть IJL.

сравнивая со "стандартным юнитом JPEG"
кроме скорости есть ещё плюсы?

Например, можно читать jpeg произвольными фрагментами почти без потери скорости по сравнению с чтением картинки полностью.
Недостатки - не читает "битые" прогрессивные файлы. Версия 1.5 вроде бы плохо переносит многопоточность.

есть ли какие замеры по скорости кодирования/декодирования ?

Я делал в своё время. Точные цифры не сохранились, но в общем, на чтении полноразмерной картинки IJL1.5 раза в 2 быстрее прочих средств (для условно говоря "стандартных" картинок, т.е. не прогрессивных, не повёрнутых через lossless transform и т.д.). Чтение уменьшенной (в 2,4,8 раз) - примерно одинаково с другими средствами.
Стандартный модуль jpeg и koljpegobj - одинаково, GdiPlus немного быстрее их, OleLoadPicture немного медленнее.
Хотя тестировал давно и на старом железе, возможно, новые версии GdiPlus лучше (или хотя бы не хуже) оптимизированы под современные процессоры, чем старая IJL.

У Кладова есть ещё CxKOLTiffJpg, портированная сишная CxImage:
http://kolmck.net/Components/graphics/CxKOLTiffJpg.zip
Толком не тестировал, пытался только "на глаз" сравнивать скорость кладовского Zoomer (CxImage) и моего FastView (IJL). Вроде бы уменьшенную картинку быстрее читает CxImage, а полноразмерную - IJL.

Почему TJpegImage со качеством 100% значительно тяжелее, сделанного в PhotoShop-е и IrfanView ?

Здесь исследуется вопрос по степени/качеству сжатия разными программами:
http://www.impulseadventure.com/photo/jpeg-compression.html
Хотя внимательно прочитать у самого ещё руки не дошли...

> Sapersky   (27.05.09 16:45) [6]

благодарствую! OleLoadPicture и GdiPlus не подходит

> DevilDevil ©   (27.05.09 15:25) [5]


> есть ли какие замеры по скорости кодирования/декодирования
> ?

Раза 2-3 быстрее по сравнению со стандартным модулем JPEG. Новые версии ijl, собранные на базе IPP еще быстрее, особенно на больших изображениях.


> кроме скорости есть ещё плюсы?

Модуль jpeg остановился в своем развитии много лет назад. IJL же развивается (правда теперь платная в составе IPP).

> Sapersky   (27.05.09 16:45) [6]


> Версия 1.5 вроде бы плохо переносит многопоточность.

Есть "патченная" версия у которой нет проблем с многопоточностью.

где бы её ещё найти? :)

В IJL есть калбек ?

Вроде нет. Может, я не разглядел - смотри сам, вот полная версия заголовков:
http://www.satsignal.eu/software/JPEG_IO.zip
А так, если колбэк нужен для отображения прогресса/прерывания загрузки, то можно читать картинку по кусочкам, напр. гор. полосками, будет тот же эффект. Потери скорости, как я уже говорил, почти нет, если не брать совсем уж мелкие фрагменты. Разве что прогрессивные картинки обрабатываются неравномерно (с задержкой в начале) - ну, "не любит" IJL прогрессив...
У CxKOLTiffJpg есть колбэк.

нет ли какого более цивилизованого способа сохрания в Stream ?

А чем существующий не устраивает? Памяти жалко? Ну пиши самые крупные картинки во временный файл...
Можно попробовать прикинуть размер jpeg и выделять буфер с меньшим запасом, не по размеру bmp. Если не влезет - ничего страшного, скорее всего, не произойдёт, ijlWrite вернёт ошибку. Тогда увеличить буфер и повторить.

В FastFiles.SaveJPGStream автор ошибся, там SaveStream должен быть, конечно.

>А чем существующий не устраивает? Памяти жалко?
Для jpg в 500кб приходится выделять буфер 36мб - долго.

> Можно попробовать прикинуть размер jpeg
в том то и вопрос - как его прикинуть.

p.s. как-то уже не особо меня радует IJL

> Для jpg в 500кб приходится выделять буфер 36мб - долго.

Долго это сколько? Замерял или просто так сказал?


> p.s. как-то уже не особо меня радует IJL

Поищи другие варианты, уверен, что лучше варианта не найдешь.

Для jpg в 500кб приходится выделять буфер 36мб - долго.

Мне кажется, не так уж и страшно по современным меркам. Если картинок несколько (а иначе какой смысл вообще имеет запись в поток?) - можно выделить буфер один раз.
Опять же, дельфийский FileStream - пример противоположной крайности, он вообще не буферизованный (кроме D2009), что хотя и экономит память, но может добавить тормозов, если jpeg-библиотека вздумает писать в файл по одному байту.

> Можно попробовать прикинуть размер jpeg
в том то и вопрос - как его прикинуть.

Да хоть опытным путём. Взять картинку с макс. кол-вом мелких деталей, чтобы был наихудший для jpeg случай, посохранять с разным качеством, построить график... (от размера картинки размер jpeg-файла должен по идее зависеть более-менее линейно).
Даже если буфер будет недостаточного размера - проверил, IJL нормально реагирует (не валится в AV, по крайней мере), возвращает ошибку IJL_BUFFER_TOO_SMALL.

Спасибо.

У меня обработка нескольких jpeg-ов. Думаю один раз буфер создать на 5-10 мб и позже его юзать.