libimg

Discussing libraries simplifying applications development
  • Нет, указатель это skin.image+24, а DSDWORD[skin.image+24] - это "данные по адресу".
    Из хаоса в космос
  • А чем DSWORD отличается от DSDWORD?

    Структура, грубо говоря, такая:

    Code: Select all

    struct Image{
    ...
    int Width;
    int Height;
    ...
    int *Data;
    ...
    }
    
    Т.е. по адресу skin.image+4 лежит ширина изображения, а по адресу skin.image+24 лежит адрес, по которому лежат пиксели. Пиксели находятся не в самой структуре Image, они отдельно. В skin.image есть только указатель на ту область, и он находится в skin.image со смещением 24.

    skin.image+24 -- это указатель на указатель
  • Ох шайтан. Спасибо, дома попробую.
    Из хаоса в космос
  • Обнаружил в libimg несколько неприятных мелочей (не думаю, что их можно назвать багами).

    1) Некоторые функции (scale, к примеру) вообще не сохраняют значения никаких регистров. Для ассемблера это нестрашно, а вот для ЯВУ проблема.

    2) В документации к функции to_rgb говорится следующее:

    Code: Select all

    ;;================================================================================================;;
    proc img.to_rgb _img ;////////////////////////////////////////////////////////////////////////////;;
    ;;------------------------------------------------------------------------------------------------;;
    ;? decodes image data into RGB triplets and returns pointer to memory area containing them        ;;
    ;;------------------------------------------------------------------------------------------------;;
    ;> [_img] = pointer to source image                                                               ;;
    ;;------------------------------------------------------------------------------------------------;;
    ;< eax = 0 / pointer to rgb_data (array of [rgb] triplets)                                        ;;
    ;;================================================================================================;;
    Но на самом деле функция возвращает буфер в несколько другом виде. В начало буфера сохраняются ширина и высота изображения (каждое 4 байта) и только после них начинается массив с rgb значениями. Документацию стоит подправить.

    3) Функция scale масштабирует изображения даже тогда, когда масштабирование не требуется, так как в параметрах переданы исходные значения ширины и высоты. По крайней мере такое поведение наблюдается при использовании LIBIMG_SCALE_STRETCH и LIBIMG_INTER_BILINEAR, другие варианты я не тестировал.

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

    4) Еще неплохо было бы указать в документации, что функция scale работает не со всеми форматами изображений, а только Image.bpp24 / Image.bpp32 / Image.bpp8g.
  • Подтверждаю, там много не доделанного.

    Есть незакоммиченные изменения. На выходных посмотрю, в каком они состоянии, и исправлю по возможности.
  • anyone has used libimg with high-level lenguge like visual c++? I not found any example about how use it. Maybe dont work with hll. I try to use it with oberon-07, and when call to decode image my program crash with general memory protection fault.
  • ddarias
    I use with C--, it should work with any language.

    http://websvn.kolibrios.org/filedetails ... bimg_lib.h
    and more here http://websvn.kolibrios.org/listing.php ... 6dfa56425a
    Из хаоса в космос
  • The need has risen to draw images with the correct transparency.
    Is it planned to make a function "img.to_argb" and/or a function to draw an image into a 24bpp or 32bpp canvas?
    "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
  • img.to_argb will be implemented as img.convert with proper flags.

    Transparency requires significantly more work.
    Currently libimg uses f65 to output images which doesn't support neither alpha nor canvas.
    Experimental f73 is said in docs to support transparency, but actually it doesn't.

    If you have ideas for transparency API to satisfy your busyness need, they are very helpful.
  • What I mean with canvas is an off-screen buffer.
    Currently, I'm using img.decode, then img.to_rgb and then I manually blit it to the correct place in the offscreen buffer.
    This all works great as long as there no transparency involved, because I cannot know what 24bit value represents the magic transparent color.
    (As used in transparent GIF's for example).
    "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
  • Look at the buf2d library for the offscreen buffer with transparency support.
  • Ray wrote:Look at the buf2d library for the offscreen buffer with transparency support.
    The problem is not in the offscreen buffer routine, I'm missing information about the image.
    "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
  • hidnplayr wrote:
    Ray wrote:Look at the buf2d library for the offscreen buffer with transparency support.
    The problem is not in the offscreen buffer routine, I'm missing information about the image.
    That makes sense.
  • Сегодня впервые в эмуляторе колибри был создан *.png файл размером 72*72 пикселя!
    Для кодирования использована zlib.obj, которую я планирую объединить с системной archiver.obj.
    Код пока что экспериментальный, создаются файлы размером не более 16 Кб (это связано с тем что кодирование в deflate должно делаться в цикле порциями не больше 16 Кб, а я для простоты кода в один вызов сделал).
    Потому ни на svn ни на форум давать его наверное не буду.
    Если удастся довести до рабочего состояния то можно будет включить его в libimg.
    Attachments
    внешний вид тестовой программы
    test_png_011116.png (86.39 KiB)
    внешний вид тестовой программы Viewed 14067 times
  • Who is online

    Users browsing this forum: No registered users and 2 guests