Board.KolibriOS.org

Official KolibriOS board
It is currently Sat May 25, 2019 10:55 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 75 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
 Post subject: Re: libimg
PostPosted: Tue Mar 25, 2014 12:20 am 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
Leency wrote:
col_bg = DSDWORD[skin.image+24];
Это ты указатель на пиксели получил. А теперь сделай col_bg[0].


Top
   
 Post subject: Re: libimg
PostPosted: Tue Mar 25, 2014 12:38 am 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Нет, указатель это skin.image+24, а DSDWORD[skin.image+24] - это "данные по адресу".

_________________
Через тернии к звездам


Top
   
 Post subject: Re: libimg
PostPosted: Tue Mar 25, 2014 12:47 am 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
А чем DSWORD отличается от DSDWORD?

Структура, грубо говоря, такая:
Code:
struct Image{
...
int Width;
int Height;
...
int *Data;
...
}


Т.е. по адресу skin.image+4 лежит ширина изображения, а по адресу skin.image+24 лежит адрес, по которому лежат пиксели. Пиксели находятся не в самой структуре Image, они отдельно. В skin.image есть только указатель на ту область, и он находится в skin.image со смещением 24.

skin.image+24 -- это указатель на указатель


Top
   
 Post subject: Re: libimg
PostPosted: Tue Mar 25, 2014 10:50 am 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Ох шайтан. Спасибо, дома попробую.

_________________
Через тернии к звездам


Top
   
 Post subject: Re: libimg
PostPosted: Wed Jan 21, 2015 9:47 pm 
Offline
User avatar

Joined: Thu Nov 27, 2014 1:24 am
Posts: 71
Обнаружил в libimg несколько неприятных мелочей (не думаю, что их можно назвать багами).

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

2) В документации к функции to_rgb говорится следующее:
Code:
;;================================================================================================;;
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.


Top
   
 Post subject: Re: libimg
PostPosted: Wed Jan 21, 2015 11:53 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
Подтверждаю, там много не доделанного.

Есть незакоммиченные изменения. На выходных посмотрю, в каком они состоянии, и исправлю по возможности.


Top
   
 Post subject: Re: libimg
PostPosted: Mon Feb 23, 2015 5:59 pm 
Offline

Joined: Tue Jun 11, 2013 3:29 pm
Posts: 24
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.


Top
   
 Post subject: Re: libimg
PostPosted: Mon Feb 23, 2015 6:28 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
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

_________________
Через тернии к звездам


Top
   
 Post subject: Re: libimg
PostPosted: Mon Nov 09, 2015 1:37 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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


Top
   
 Post subject: Re: libimg
PostPosted: Mon Nov 09, 2015 11:10 pm 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 416
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.


Top
   
 Post subject: Re: libimg
PostPosted: Mon Nov 09, 2015 11:36 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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


Top
   
 Post subject: Re: libimg
PostPosted: Sun Nov 15, 2015 10:16 am 
Offline

Joined: Sun Aug 09, 2015 3:41 pm
Posts: 112
Look at the buf2d library for the offscreen buffer with transparency support.


Top
   
 Post subject: Re: libimg
PostPosted: Sun Nov 15, 2015 11:42 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1247
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


Top
   
 Post subject: Re: libimg
PostPosted: Sun Nov 15, 2015 7:36 pm 
Offline

Joined: Sun Aug 09, 2015 3:41 pm
Posts: 112
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.


Top
   
 Post subject: Re: libimg
PostPosted: Tue Nov 01, 2016 10:32 pm 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 811
Сегодня впервые в эмуляторе колибри был создан *.png файл размером 72*72 пикселя!
Для кодирования использована zlib.obj, которую я планирую объединить с системной archiver.obj.
Код пока что экспериментальный, создаются файлы размером не более 16 Кб (это связано с тем что кодирование в deflate должно делаться в цикле порциями не больше 16 Кб, а я для простоты кода в один вызов сделал).
Потому ни на svn ни на форум давать его наверное не буду.
Если удастся довести до рабочего состояния то можно будет включить его в libimg.


Attachments:
File comment: внешний вид тестовой программы
test_png_011116.png
test_png_011116.png [ 86.39 KiB | Viewed 3850 times ]
Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 75 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited