Leency wrote:Файлы:
https://imgur.com/a/Z2harCK
Code: Select all
$ gm identify -verbose ZAX6lLa.png | grep Depth -A4
Depth: 8 bits-per-pixel component
Channel Depths:
Red: 8 bits
Green: 8 bits
Blue: 8 bits
Opacity: 1 bits
$ gm identify -verbose tsQZcP4.png | grep Depth -A4
Depth: 16 bits-per-pixel component
Channel Depths:
Red: 16 bits
Green: 16 bits
Blue: 16 bits
Opacity: 1 bitsWow, thanks for the article, now its clear.dunkaist wrote:For image processing and for hardware that supports more than 8 bits per channel.
For example,
Philips 203V5LSB26 supports "16.7M" colors. Which is 2^(8*3) = 16,777,216, i.e. 3 color channels, 8bpp each.
Philips 329P9H supports "1.07 billion" colors. Which is 2^(10*3) = 1,073,741,824, i.e. 3 color channels, 10bpp each.
KolibriOS doesn't support such color modes.
dunkaist, thanks a lot! I will try to implement it after fix all issues of image support in WebView.dunkaist wrote:There has been alpha blending code in libimg for quite a long time, I wrapped it into img.blend function and exported in #8341.
I also committed an example in #8342.
BTW, the example uses img.from_file function, which helps to avoid calling file.open, file.read and file.close from libio.
It is to be done one day.Leency wrote:BTW, what about adding such blend into KIV for PNG and ICONS?
Думаю так будет оптимальнее, хотя пока не проверял работоспособность по причине указанной вышеLeency wrote:#8363 libimg: img.decode now checks that _length is not null (fix crash)
Code: Select all
proc img.decode _data, _length, _options ;////////////////////////////////////////////////////////;;
;;------------------------------------------------------------------------------------------------;;
;? decodes loaded into memory graphic file ;;
;;------------------------------------------------------------------------------------------------;;
;> [_data] = pointer to file in memory ;;
;> [_length] = size in bytes of memory area pointed to by [_data] ;;
;> [_options] = 0 / pointer to the structure of additional options ;;
;;------------------------------------------------------------------------------------------------;;
;< eax = 0 / pointer to image ;;
;;================================================================================================;;
mov eax, [_length]
or eax,eax
jz .fail
push ebx
mov ebx, img.formats_table
@@: stdcall [ebx + FormatsTableEntry.Is], [_data], [_length]
or eax, eax
jnz @f
add ebx, sizeof.FormatsTableEntry
cmp dword[ebx], eax ;0
jnz @b
pop ebx
.fail:
ret
@@: mov eax, [ebx + FormatsTableEntry.Decode]
pop ebx
leave
jmp eax
endpThanks for a hint with img.from_file. It helped me to decrease the C-- app sizes in #8381, in general we got 2 additional IMG sectors free.
I don't understand why people keep using *.bat and make files to build KolibriOS. There is build.txt in the root of the repository that explains how to build with tup. You don't need Windows-specific bat files or GNU-specific makefiles. Just use tup. Tup files are used on the autobuild server and therefore are always up-to-date. Custom bat files and makefiles are to be avoided if tup autobuild is set up.IgorA wrote:После ревизии 8341 перестала компилироваться libimg через файл build.bat
After revision 8341 libimg stopped compiling through the build.bat file
тут виноват редактор FASMW)Code: Select all
stdcall [img_create], [buf_png.w], [buf_png.h], Image.bpp24
...Code: Select all
stdcall [img_create], [buf_png.w], [buf_png.h], Image.bpp32
...