dunkaist
В английской Википедии вроде вполне подробное описание формата, даже с разбиением на версии. Отсылка к BITMAPINFOHEADER -- и есть документация Microsoft, далее по ссылкам.
libimg
Freeman, ты же сам прекрасно понимаешь, чем спецификация от описания отличается. По ссылкам я сходил.
Всё оказалось проще. Структуры были описаны в bmp.inc довольно хитрым образом, поэтому длины для проверки вбивались руками. Не все варианты были учтены.
Но после этого 3х5 картинка всё равно не захотела открываться из-за бага в img.flip.layer. Заменил цикл с постусловием на цикл с предусловием. Вроде, всё работает.
Всё оказалось проще. Структуры были описаны в bmp.inc довольно хитрым образом, поэтому длины для проверки вбивались руками. Не все варианты были учтены.
Но после этого 3х5 картинка всё равно не захотела открываться из-за бага в img.flip.layer. Заменил цикл с постусловием на цикл с предусловием. Вроде, всё работает.
Коротко об изменениях в библиотеке за прошедший год:
- Добавлены типы изображений, поддерживаемые 65-й функцией: grayscale, 2-х и 4-х битные типы с палитрой.
- Появилась поддержка некоторых расширений формата tiff. Из заметных глазу можно отметить чтение lzw-сжатых изображений.
- Новые функции: img.scale и img.convert для масштабирования изображения и преобразования его представления (глубины цвета и т.д.)
- Существенно обновлён декодер tga, поддержка нового формата xbm (XBitMap).
- Исправлены некоторые баги, убран лимит на размер декодированного изображения.
Из опыта проектирования и реализации zSea могу посоветовать переделать с конвертированием в 8-и битное. В дальнейшем с размерностями не кратными байту возникают проблемы с выводом - например, с прокруткой больших или сильно масштабирован изображений. Приходится либо прокручивать на количество точек содержащееся в одном байте за транзакцию, либо использовать все в кратном байту разрешении.dunkaist wrote:[*]Добавлены типы изображений, поддерживаемые 65-й функцией: grayscale, 2-х и 4-х битные типы с палитрой.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Да, действительно, отступ внутри байта никак не задать. Думаю, перекодировать имеет смысл просмотрщику, который захочет, скажем, масштабировать (всё равно масштабирование для 2-х бит я писать не буду). Как раз для этого img.convert появилась. Но совсем переписывать смысла не вижу, ведь если есть файлы в таких форматах и их вывод поддерживается ядром, то пусть и libimg умеет с ними "нативно" работать.Mario_r4 wrote:Из опыта проектирования и реализации zSea могу посоветовать переделать с конвертированием в 8-и битное. В дальнейшем с размерностями не кратными байту возникают проблемы с выводом - например, с прокруткой больших или сильно масштабирован изображений. Приходится либо прокручивать на количество точек содержащееся в одном байте за транзакцию, либо использовать все в кратном байту разрешении.
У меня сейчас другой вопрос: как отображать иконки, если они не влезают в окно? Допустим, есть иконка, в ней семь фреймов, по длине не умещаются в окно.
Пусть ширина всех фреймов вместе -- 707 пикселей, иконки одинаковые.
Первый случай: ширина области, куда можно рисовать -- 700 пикселей. Масштабировать каждую на -1 пиксель? Мыло, но ещё куда ни шло.
Второй случай: ширина области для рисования -- 704 пикселя. Всё равно масштабировать каждую на -1? Или только три из них? Но это будет выглядеть странно, т.к. все иконки одинаковые, но часть отображается нормально, а часть замылена.
Скроллбар использовать религия запрещает?dunkaist wrote: У меня сейчас другой вопрос: как отображать иконки, если они не влезают в окно? Допустим, есть иконка, в ней семь фреймов, по длине не умещаются в окно.
Пусть ширина всех фреймов вместе -- 707 пикселей, иконки одинаковые.
Первый случай: ширина области, куда можно рисовать -- 700 пикселей. Масштабировать каждую на -1 пиксель? Мыло, но ещё куда ни шло.
Второй случай: ширина области для рисования -- 704 пикселя. Всё равно масштабировать каждую на -1? Или только три из них? Но это будет выглядеть странно, т.к. все иконки одинаковые, но часть отображается нормально, а часть замылена.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Я имею в виду режим масштабирования изображения под размер окна. В таком режиме по определению всё должно вмещаться в окно без всяких скроллбаров.Mario_r4 wrote:Скроллбар использовать религия запрещает?
Дело в том, что у меня нет под рукой просмотрщиков, которые бы показывали иконки в ряд. Если кто-нибудь пользуется такими, было бы интересно узнать, как они ведут себя в такой ситуации.
Имеет смысл масштабировать общее изображение, на котором все иконки. Плевать на замыленность - пользователь ССЗБ, раз выбрал такой режим.dunkaist wrote:В таком режиме по определению всё должно вмещаться в окно без всяких скроллбаров.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Не нужно маштабировать иконки. Лучше обрезать или выводить в 2 ряда.
Очень не хватает в kiv функции, которая есть в zSea, - "вписать в окно". Из-за этого в kiv, а значит в Колибри в общем, просто невозможно смотреть фотографии.
Очень не хватает в kiv функции, которая есть в zSea, - "вписать в окно". Из-за этого в kiv, а значит в Колибри в общем, просто невозможно смотреть фотографии.
Из хаоса в космос
Наверно я чтото делаю не так...
> WebView
> нужно сделать загрузку цветов из скина
Есть код:
Изображение прекрасно выводится. НО.
Как я могу получить цвет первого пикселя из этого изображения? Следующий код не работает.
> 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];
Из хаоса в космос
Есть альтернативный способ, котором пользуется большинство разработчиков. Можно положить в ту же директорию, где лежит файл скина, еще и INI файл (например, skin.ini) и воспользоваться сервисами LibINI.Leency wrote:Наверно я чтото делаю не так...
> WebView
> нужно сделать загрузку цветов из скина
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Colors are 24-bit, need to do logical AND with 0x00ffffff.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];
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, но думаю, что следующий псевдокод разъяснит:
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
Сделал, получаю цвет 105000 вместо E4DFE1.
В чём может быть проблема?
строка $and col_bg, 0x00ffffff ничего не меняет.
Я не понимат T_T
Из хаоса в космос
Who is online
Users browsing this forum: No registered users and 14 guests