Page 2 of 2

Re: Теория разработки графического редактора (иконок)

Posted: Wed Feb 07, 2018 8:23 pm
by Leency
В смысле сохранение ресурсов для приложений?

Re: Теория разработки графического редактора (иконок)

Posted: Wed Feb 07, 2018 8:36 pm
by 0CodErr
Прикольно :)

А в каком формате иконки?
Размер иконок произвольный?
Цвета только те, что в палитре?

Мне кажется, вместо нескольких DrawRectangle можно было бы использовать Frame из box_lib.
Если помнишь, то там можно выбрать из 5-ти вариантов border style http://board.kolibrios.org/viewtopic.ph ... 494#p66494

Re: Теория разработки графического редактора (иконок)

Posted: Thu Feb 08, 2018 1:24 pm
by Leency
0CodErr
А в каком формате иконки?
Размер иконок произвольный?
Цвета только те, что в палитре?
Много вопросов и все хорошие и правильные.
Вот только программа пока что 0.08, даже не 0.1 и не спроста. Я до этого граф редакторы не разрабатывал и тот процесс что идет сейчас я бы назвал "Разработка через переписывание".

DrawRectangle там одноцветные, просто прямоугольники для этого либы не нужны.

Я двигаюсь от создания базового функционала к расширению функций.
Пока что иконки сохраняются в BMP 32х32х16 и очень криворуким способом. Я не знал как сделать сохранение через структуру BITMAPINFOHEADER, не знал как сделать сохранение через LIBIMG. Так что я взял создал изображение BMP 32х32х16 и через HEX редактор обрезал у него хедер и использую :D

Code: Select all

dword bmp_32x32x16_header[] = FROM "bmp32x32header";
void EventSave()
{
	char save_buf[3126];
	memmov(#save_buf, #bmp_32x32x16_header, sizeof(bmp_32x32x16_header));
	memmov(#save_buf+sizeof(bmp_32x32x16_header), image.get_image(), sizeof(save_buf)-sizeof(bmp_32x32x16_header));
	WriteFile(sizeof(save_buf), #save_buf, "/rd/1/saved_image.bmp")
}
Если кто-то напишет мне функцию в файле /cmm/lib/obj/libimg.h которая реализует сохранение в BMP или еще круче в PNG я его расцелую))
SaveBMP(pointer_buf, width, height, bit, save_path);
SavePNG(pointer_buf, width, height, bit, save_path);

Открытие изображений идет через LIBIMG, а потому теоретически можно сделать чтобы размер был любым. Пока что захардкодено 32х32, потом возможно сделаю размер до 256х256. Потом произвольно когда дойдут руки. При больших размерах нужен будет скролл, а это муторная штука.

С палитрой планирую так:
1. Будет блок фиксированных цветов что сейчас.
2. Плюс будет блок со списком последний использованых цветов.
3. Плюс будет блок с изменением текущего цвета к светлому и темному.

Re: Теория разработки графического редактора (иконок)

Posted: Fri Feb 09, 2018 1:17 pm
by 0CodErr
Leency wrote:Если кто-то напишет мне функцию в файле /cmm/lib/obj/libimg.h которая реализует сохранение в BMP или еще круче в PNG я его расцелую))
SaveBMP(pointer_buf, width, height, bit, save_path);
SavePNG(pointer_buf, width, height, bit, save_path);
Как мне кажется, здесь сама постановка вопроса некорректна.
Поскольку данные сохраняются как обыкновенный файл с помощью WriteFile.
Можешь посмотреть, как в других программах. Из тех, что делал я — это imgC. Вроде в ЛС тебе скидывал, вот здесь под спойлером есть исходник imgC http://board.kolibrios.org/viewtopic.ph ... 859#p66859 там так сохраняется

Code: Select all

; if converted, try to save ; |-------------------------------------- ;
        push   dword [dstpath]
        push   eax
        push   ecx
        call   file.write

Code: Select all

 image.move(FLIP_VER); //fix an issue that BMP image is flipped vertically
Я просто напомню, уже вопрос похожий был на форуме http://board.kolibrios.org/viewtopic.ph ... 810#p44810
0CodErr wrote:
Heavyiron wrote:Почему 7-я функция выводит изображение снизу вверх справа налево, я не в курсе.
Это потому что данные изображения в файле так хранятся. Это можно определить по значению Height в структуре BITMAPINFOHEADER. Если файл с изображением содержит не зеркально отражённые данные, то в этом случае Height в BITMAPINFOHEADER записывается со знаком минус. Например, чтобы получить такое изображение в фотошопе надо при сохранении поставить флажок "flip row order".
Проще говоря, дополнительно переворачивать изображение — лишняя, ненужная работа, достаточно изменить Height.
Leency wrote: Я не знал как сделать сохранение через структуру BITMAPINFOHEADER
Как уже выше сказано, работаем как с обычным файлом, то есть, это как загрузка, только наоборот.
В теме Delphi7 examples есть пример использования функции DrawImageEx http://board.kolibrios.org/viewtopic.ph ... 469#p68938 в котором происходит работа с TBitmapInfoHeader.
Чтение идёт с помощью функции ReadFile, соответственно, если сделать WriteFile, то это по сути и будет SaveBMP.

Re: Теория разработки графического редактора (иконок)

Posted: Fri Feb 09, 2018 2:21 pm
by Leency
Я уже использую LIBIMG.
И сорри, я ничего не пому понять из ассмеблерного исходника на 900 строк.

Re: Теория разработки графического редактора (иконок)

Posted: Fri Feb 09, 2018 2:47 pm
by Leency
Проще говоря, дополнительно переворачивать изображение — лишняя, ненужная работа, достаточно изменить Height.
Спасибо, сделал, скоро залью.

Re: Теория разработки графического редактора (иконок)

Posted: Fri Feb 09, 2018 11:47 pm
by IgorA
libimg пока что позволяет сохранять только 24 битные png изображения. Для других разрядностей нужно доделывать код который в брался из lib_png.
В libimg можно сохранять в bmp и png, отличие там только в одной из констант которая задает формат для сохранения.

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 10, 2018 11:43 am
by Leency
IgorA
Можешь написать мне функцию на С--?
Или хоть предоставить функцию для сохранения на асме?

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 10, 2018 2:55 pm
by IgorA
Могу дать кусок кода на asm :

Code: Select all

		mov dword[png_data],0

		;(1) create image struct
		stdcall [img_create], [buf_png.w], [buf_png.h], Image.bpp24
		mov ebx,eax
		test eax,eax
		jz @f
			;(2) copy foto to image buffer
			mov edi,[eax+Image.Data]
			mov esi,[buf_png]
			mov ecx,[buf_png.w]
			mov edx,[buf_png.h]
			imul ecx,edx
			imul ecx,3
			shr ecx,2 ;OpenGL buffer align to 4
			rep movsd

			;(3) encode image
			stdcall [img_encode], eax, LIBIMG_FORMAT_PNG, 0
			test eax,eax
			jz @f
				mov [png_data],eax
				mov [png_size],ecx
		@@:
		;(4)
		stdcall [img_destroy],ebx
Сохранение делается в 4 основных этапа:
1) создается буфер изображения функцией img_create
2) копируется сохраняемое изображение в созданный буфер
3) вызывается само сохранение img_encode (константа LIBIMG_FORMAT_PNG задает формат)
4) удаляется буфер изображения функцией img_destroy

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 10, 2018 3:42 pm
by 0CodErr
Leency wrote:DrawRectangle там одноцветные, просто прямоугольники для этого либы не нужны.
Не, дело-то хозяйское: хочется велосипед изобрести — изобретай :)
Просто не надо говорить того, чего нет. Судя по коду и скриншоту ты явно пытался соорудить Frame. Ну вот я и предложил поэтому.
1.PNG
1.PNG (43.28 KiB)
Viewed 6756 times

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 10, 2018 9:03 pm
by Leency
Это я удолил http://prntscr.com/icviit
Это баг http://prntscr.com/icvipb, просвет фона.

Last http://prntscr.com/icvjx2
Гуй будет измененен.

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 10, 2018 9:58 pm
by 0CodErr
Leency, тогда ладно :)
А что насчёт ColorDialog? Там тоже есть "блок со списком последний использованых цветов"

Re: Теория разработки графического редактора (иконок)

Posted: Sat Feb 17, 2018 11:33 pm
by IgorA
Попробовал перевести на C--. Код может быть примерно такой:

Code: Select all

// list of format id's
#define LIBIMG_FORMAT_BMP       1
#define LIBIMG_FORMAT_ICO       2
#define LIBIMG_FORMAT_CUR       3
#define LIBIMG_FORMAT_GIF       4
#define LIBIMG_FORMAT_PNG       5
#define LIBIMG_FORMAT_JPEG      6
#define LIBIMG_FORMAT_TGA       7
#define LIBIMG_FORMAT_PCX       8
#define LIBIMG_FORMAT_XCF       9
#define LIBIMG_FORMAT_TIFF     10
#define LIBIMG_FORMAT_PNM      11
#define LIBIMG_FORMAT_WBMP     12
#define LIBIMG_FORMAT_XBM      13
#define LIBIMG_FORMAT_Z80      14

struct Image
{
	DWORD Checksum; // ((Width ROL 16) OR Height) XOR Data[0]        ; ignored so far
	DWORD Width;
	DWORD Height;
	DWORD Next;
	DWORD Previous;
	DWORD Type;     // one of Image.bppN
	DWORD Data;
	DWORD Palette;  // used iff Type eq Image.bpp1, Image.bpp2, Image.bpp4 or Image.bpp8i
	DWORD Extended;
	DWORD Flags;    // bitfield
	DWORD Delay;    // used iff Image.IsAnimated is set in Flags
};

// values for Image.Type
// must be consecutive to allow fast switch on Image.Type in support functions
#define Image.bpp8i  1  // indexed
#define Image.bpp24  2
#define Image.bpp32  3
#define Image.bpp15  4
#define Image.bpp16  5
#define Image.bpp1   6
#define Image.bpp8g  7  // grayscale
#define Image.bpp2i  8
#define Image.bpp4i  9
#define Image.bpp8a 10  // grayscale with alpha channel; application layer only!!! kernel doesn't handle this image type, libimg can only create and destroy such images

...

void SaveImage(DWORD* pointer_buf, DWORD width, DWORD height, DWORD bit)
{
	DWORD* png_data=0;
	DWORD png_size=0;

	if(bit!=24)
	{
		... not support ...
		return;
	}
	//(1) create image struct
	Image* h_img = img_create(buf_png.w, buf_png.h, Image.bpp24);
	if(h_img)
	{
		//(2) copy foto to image buffer
		memcpy(h_img->Data, pointer_buf, width*height*3);

		//(3) encode image
		png_data = img_encode(eax, LIBIMG_FORMAT_PNG, 0);
		if(png_data) png_size = ECX;
	}
	//(4)
	img_destroy(h_img);
	if(png_size)
	{
		... save image to file (use function 70) ...
		... png_data - данные файла с изображением ...
		... png_size - размер файла с изображением ...
	}
}
Возможно что потребуется сделать обертки для функций lib_img. Но эта библиотека уже используется потому возможно что обертки ко всем ее функциям уже есть.