libimg

Discussing libraries simplifying applications development
  • Freeman, ты же сам прекрасно понимаешь, чем спецификация от описания отличается. По ссылкам я сходил.

    Всё оказалось проще. Структуры были описаны в bmp.inc довольно хитрым образом, поэтому длины для проверки вбивались руками. Не все варианты были учтены.

    Но после этого 3х5 картинка всё равно не захотела открываться из-за бага в img.flip.layer. Заменил цикл с постусловием на цикл с предусловием. Вроде, всё работает.
  • Коротко об изменениях в библиотеке за прошедший год:
    • Добавлены типы изображений, поддерживаемые 65-й функцией: grayscale, 2-х и 4-х битные типы с палитрой.
    • Появилась поддержка некоторых расширений формата tiff. Из заметных глазу можно отметить чтение lzw-сжатых изображений.
    • Новые функции: img.scale и img.convert для масштабирования изображения и преобразования его представления (глубины цвета и т.д.)
    • Существенно обновлён декодер tga, поддержка нового формата xbm (XBitMap).
    • Исправлены некоторые баги, убран лимит на размер декодированного изображения.
    Прежняя просьба прикреплять изображения, которые не открываются или отображаются неправильно.
  • dunkaist wrote:[*]Добавлены типы изображений, поддерживаемые 65-й функцией: grayscale, 2-х и 4-х битные типы с палитрой.
    Из опыта проектирования и реализации zSea могу посоветовать переделать с конвертированием в 8-и битное. В дальнейшем с размерностями не кратными байту возникают проблемы с выводом - например, с прокруткой больших или сильно масштабирован изображений. Приходится либо прокручивать на количество точек содержащееся в одном байте за транзакцию, либо использовать все в кратном байту разрешении.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:Из опыта проектирования и реализации zSea могу посоветовать переделать с конвертированием в 8-и битное. В дальнейшем с размерностями не кратными байту возникают проблемы с выводом - например, с прокруткой больших или сильно масштабирован изображений. Приходится либо прокручивать на количество точек содержащееся в одном байте за транзакцию, либо использовать все в кратном байту разрешении.
    Да, действительно, отступ внутри байта никак не задать. Думаю, перекодировать имеет смысл просмотрщику, который захочет, скажем, масштабировать (всё равно масштабирование для 2-х бит я писать не буду). Как раз для этого img.convert появилась. Но совсем переписывать смысла не вижу, ведь если есть файлы в таких форматах и их вывод поддерживается ядром, то пусть и libimg умеет с ними "нативно" работать.

    У меня сейчас другой вопрос: как отображать иконки, если они не влезают в окно? Допустим, есть иконка, в ней семь фреймов, по длине не умещаются в окно.

    Пусть ширина всех фреймов вместе -- 707 пикселей, иконки одинаковые.

    Первый случай: ширина области, куда можно рисовать -- 700 пикселей. Масштабировать каждую на -1 пиксель? Мыло, но ещё куда ни шло.
    Второй случай: ширина области для рисования -- 704 пикселя. Всё равно масштабировать каждую на -1? Или только три из них? Но это будет выглядеть странно, т.к. все иконки одинаковые, но часть отображается нормально, а часть замылена.
  • dunkaist wrote: У меня сейчас другой вопрос: как отображать иконки, если они не влезают в окно? Допустим, есть иконка, в ней семь фреймов, по длине не умещаются в окно.

    Пусть ширина всех фреймов вместе -- 707 пикселей, иконки одинаковые.

    Первый случай: ширина области, куда можно рисовать -- 700 пикселей. Масштабировать каждую на -1 пиксель? Мыло, но ещё куда ни шло.
    Второй случай: ширина области для рисования -- 704 пикселя. Всё равно масштабировать каждую на -1? Или только три из них? Но это будет выглядеть странно, т.к. все иконки одинаковые, но часть отображается нормально, а часть замылена.
    Скроллбар использовать религия запрещает?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:Скроллбар использовать религия запрещает?
    Я имею в виду режим масштабирования изображения под размер окна. В таком режиме по определению всё должно вмещаться в окно без всяких скроллбаров.

    Дело в том, что у меня нет под рукой просмотрщиков, которые бы показывали иконки в ряд. Если кто-нибудь пользуется такими, было бы интересно узнать, как они ведут себя в такой ситуации.
  • dunkaist wrote:В таком режиме по определению всё должно вмещаться в окно без всяких скроллбаров.
    Имеет смысл масштабировать общее изображение, на котором все иконки. Плевать на замыленность - пользователь ССЗБ, раз выбрал такой режим.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Не нужно маштабировать иконки. Лучше обрезать или выводить в 2 ряда.
    Очень не хватает в kiv функции, которая есть в zSea, - "вписать в окно". Из-за этого в kiv, а значит в Колибри в общем, просто невозможно смотреть фотографии.
    Из хаоса в космос
  • Наверно я чтото делаю не так...

    > WebView
    > нужно сделать загрузку цветов из скина
    Есть код:

    Code: Select all

    skin.image = load_image(abspath("wv_skin.png"));
    skin.w = DSWORD[skin.image+4];
    skin.h = DSWORD[skin.image+8];
    img_draw stdcall(skin.image, 0, 0, skin.w, skin.h, 101, 0); //вывести изображение
    
    Изображение прекрасно выводится. НО.
    Как я могу получить цвет первого пикселя из этого изображения? Следующий код не работает.

    Code: Select all

    first_pixel_color = DSDWORD[skin.image+12];
    first_pixel_color = DSDWORD[skin.image+30];
    
    Из хаоса в космос
  • Leency wrote:Наверно я чтото делаю не так...

    > WebView
    > нужно сделать загрузку цветов из скина
    Есть альтернативный способ, котором пользуется большинство разработчиков. Можно положить в ту же директорию, где лежит файл скина, еще и INI файл (например, skin.ini) и воспользоваться сервисами LibINI.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Leency wrote:Наверно я чтото делаю не так...

    > WebView
    > нужно сделать загрузку цветов из скина
    Есть код:

    Code: Select all

    skin.image = load_image(abspath("wv_skin.png"));
    skin.w = DSWORD[skin.image+4];
    skin.h = DSWORD[skin.image+8];
    img_draw stdcall(skin.image, 0, 0, skin.w, skin.h, 101, 0); //вывести изображение
    
    Изображение прекрасно выводится. НО.
    Как я могу получить цвет первого пикселя из этого изображения? Следующий код не работает.

    Code: Select all

    first_pixel_color = DSDWORD[skin.image+12];
    first_pixel_color = DSDWORD[skin.image+30];
    
    Colors are 24-bit, need to do logical AND with 0x00ffffff.
    Also possible that it's required to swap colors from "BGR" to "RGB" but i'm not sure.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Leency,

    DSDWORD[skin.image+24] -- это указатель на raw изображение

    Не знаю, что за DSDWORD, но думаю, что следующий псевдокод разъяснит:

    Code: Select all

    pixel *raw = DSDWORD[skin.image+24];   // указатель на пиксели
    first_pixel_color = raw[0];
    
    Last edited by dunkaist on Mon Mar 24, 2014 2:08 pm, edited 1 time in total.
  • О, спасибо. Попробую.
    Из хаоса в космос
  • col_bg = DSDWORD[skin.image+24];
    Сделал, получаю цвет 105000 вместо E4DFE1.
    В чём может быть проблема?

    строка $and col_bg, 0x00ffffff ничего не меняет.
    Я не понимат T_T
    Из хаоса в космос
  • Who is online

    Users browsing this forum: No registered users and 4 guests