• DevilDevil © (26.05.09 17:46) [0]
    Лучше тут задам вопрос.

    Где можно посмотреть взаимодействие Jpeg и библиотеки FastLib ?
  • Sapersky (26.05.09 18:25) [1]
    Уже ответил в почту, но повторю здесь, вдруг кому пригодится.
    http://sapersky.narod.ru/files/FastLIBv389i.rar
    Пример Bumpmap, только Smooth рекомендую ставить в False - так быстрее. Да и вообще непонятно, в чём смысл этого сглаживания - убирать артефакты у сильно пожатых картинок? но сейчас в моде слабо пожатые...
  • DevilDevil © (27.05.09 09:40) [2]
    Спасибо, Александр.

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

    И что, кстати, в этой библиотеке лучше?
  • DevilDevil © (27.05.09 11:36) [3]
    Думаю, если сильно поколдовать - можно объединить с http://kolnmck.kolmck.net/files/components/graphics/koljpegobj.7z
  • DVM © (27.05.09 15:13) [4]

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


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

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


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

    в смысле лучше, лучше чем что?
  • DevilDevil © (27.05.09 15:25) [5]
    >в смысле лучше, лучше чем что?
    сравнивая со "стандартным юнитом JPEG"
    кроме скорости есть ещё плюсы?

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

    Вопрос в догонку:
    Почему TJpegImage со качеством 100% значительно тяжелее, сделанного в PhotoShop-е и IrfanView ?
  • Sapersky (27.05.09 16:45) [6]
    А нет какой-нибудь другой реализации, без 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
    Хотя внимательно прочитать у самого ещё руки не дошли...
  • DevilDevil © (27.05.09 16:58) [7]
    > Sapersky   (27.05.09 16:45) [6]

    благодарствую! OleLoadPicture и GdiPlus не подходит
  • DVM © (27.05.09 23:40) [8]

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


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

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


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

    Модуль jpeg остановился в своем развитии много лет назад. IJL же развивается (правда теперь платная в составе IPP).
  • DVM © (27.05.09 23:42) [9]

    > Sapersky   (27.05.09 16:45) [6]


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

    Есть "патченная" версия у которой нет проблем с многопоточностью.
  • CrytoGen (28.05.09 04:10) [10]
    где бы её ещё найти? :)
  • DVM © (28.05.09 10:47) [11]

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

    http://dvmuratov.narod.ru/ijl15.dll
  • DevilDevil © (28.05.09 14:55) [12]
    В IJL есть калбек ?
  • Sapersky (28.05.09 15:52) [13]
    Вроде нет. Может, я не разглядел - смотри сам, вот полная версия заголовков:
    http://www.satsignal.eu/software/JPEG_IO.zip
    А так, если колбэк нужен для отображения прогресса/прерывания загрузки, то можно читать картинку по кусочкам, напр. гор. полосками, будет тот же эффект. Потери скорости, как я уже говорил, почти нет, если не брать совсем уж мелкие фрагменты. Разве что прогрессивные картинки обрабатываются неравномерно (с задержкой в начале) - ну, "не любит" IJL прогрессив...
    У CxKOLTiffJpg есть колбэк.
  • DevilDevil © (28.05.09 15:55) [14]
    нет ли какого более цивилизованого способа сохрания в Stream ?
  • Sapersky (28.05.09 16:16) [15]
    А чем существующий не устраивает? Памяти жалко? Ну пиши самые крупные картинки во временный файл...
    Можно попробовать прикинуть размер jpeg и выделять буфер с меньшим запасом, не по размеру bmp. Если не влезет - ничего страшного, скорее всего, не произойдёт, ijlWrite вернёт ошибку. Тогда увеличить буфер и повторить.

    В FastFiles.SaveJPGStream автор ошибся, там SaveStream должен быть, конечно.
  • DevilDevil © (28.05.09 17:03) [16]
    >А чем существующий не устраивает? Памяти жалко?
    Для jpg в 500кб приходится выделять буфер 36мб - долго.

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

    p.s. как-то уже не особо меня радует IJL
  • DVM © (28.05.09 18:06) [17]

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

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


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

    Поищи другие варианты, уверен, что лучше варианта не найдешь.
  • Sapersky (28.05.09 18:32) [18]
    Для jpg в 500кб приходится выделять буфер 36мб - долго.

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

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


    Да хоть опытным путём. Взять картинку с макс. кол-вом мелких деталей, чтобы был наихудший для jpeg случай, посохранять с разным качеством, построить график... (от размера картинки размер jpeg-файла должен по идее зависеть более-менее линейно).
    Даже если буфер будет недостаточного размера - проверил, IJL нормально реагирует (не валится в AV, по крайней мере), возвращает ошибку IJL_BUFFER_TOO_SMALL.
  • DevilDevil © (29.05.09 09:01) [19]
    Спасибо.

    У меня обработка нескольких jpeg-ов. Думаю один раз буфер создать на 5-10 мб и позже его юзать.
Есть новые Нет новых   [118241   +28][b:0][p:0.001]