Пожалуйсто помогите!!! Нужно сделать кодер из bmp в gif и обратно... С чего начать? Где можно почитать попонятней?.... может у кого есть исходники

Заранее благодарен...

http://ru.wikipedia.org/wiki/GIF и по ссылкам.

Вроде разобрался... Тока вот с LZW не до конца понял. Сгенерированный код может быть 0..4095. Т.е. сначала его размер 8 бит, потом 9 и до 12 бит. Как это записать в файл?

Сдвигами объединяешь нужную последовательность бит в байты и уже их записываешь в файл.

Ага... Т.е. если LZW код выглядит так: 1 0 2, прибавляем вначале и в конце коды 256 и 257(на сколько я понял), получаем код: 256 1 0 2 257. Как мне записать его в файл... можно пример, что то я никак не могу понять...

И еще вопрос:
есть гиф, который закодирован в Photoshop. Исходный файл содержит 3 пикселя: белый, черный, красный. Т.е. картинка 3х1. Следовательно мы имеем 1 субблок данных.
6 0 255 1 200 23 16 0 59 - эти данные содержаться в файле, где 6 - это размер субблока. Как я понимаю 59 - символ ";" как конец файла, и "0" - терминатор блока.
Следовательно LZW код: 0 255 1 200 23 16. Красный цвет имеет номер в политре 249, белый - 0, черный - 255. Как я понимаю 0 255 это как раз и есть белый и черный пиксели. что же тогда такое 1 200 23 16.
Помогите разобраться.

Заранее спасибо

Ну что? Никто не поможет??? Объясните как работает LZW для гифа... т.е. с переменным размером кода... никак не могу понять

В чем проблема?
Берешь любой GIF, преобразовываешь его в BMP, берешь любой HEX-viewer и сравниваешь их между собой.
Описание формата + пример его использования = вполне достаточно, чтобы разобраться.

Сам гиф то записывается, только вот кодируется неправильно... Я не понимаю разницу между обычным LZW и LZW с переменным размером кода... А если я буду просто кодировать с максимальным размером LZW, т.е. 12 бит?

Еще раз: возьми конкретный BMP, попытайся его закодировать и сравни свой результат с тем, что записано в уже существующем GIF.
Это к тому, что в данный момент никто из присутствующих непосредственно GIF не занимается и не имеет желания с этим досконально разбираться.
Но, с другой стороны, при наличии документации и ОБРАЗЦА разобраться вполне можно без посторонней помощи.
Просить выполнить за тебя работу, которую ты можешь сделать сам, но которая занимает определенное время, или, другими словами, просить других затратить время, чтобы сэкономить время тебе, не вполне этично.

Извините, что потратил ваше вермя... Я не хотел чтобы мне кто-то что-то решал. Я просто просил объяснить. Думаю форум для этого и создан...

Нет, форум не для того, чтобы объяснить, а для того, чтобы научить.
Вот я тебе и пытаюсь рассказать, что нужно делать для того, чтобы научиться решать такие вопросы самостоятельно. Согласись, это гораздо больше, чем объяснить одну какую-то вещь.

Еще раз: сравниваешь результат работы своей программы с тем, что уже заведомо закодировано правильно. Это чтобы понять, по какому поти идти, если в документации получается неопределенность.
Если же "а что будет, если я сделаю...?", - то сделай и посмотри, будут ли стандартные viewer'ы читать твои файлы.
Нужно пытаться использовать подручные средства, чтобы находить ответы на вопросы.

Ладно, не будем спорить... Я вроде разобрался и сделал все, кроме одного... Подскажите как преобразовывать палитру из 24 битной в 256 битную??

Простого, очевидного и однозначного алгоритма здесь не существует.
Более того, для того, чтобы вычислить палитру близкую к оптимальной, следует занть алгоритм приведения труколорного изображения к новой палитре, т.к. при разных алгоритмах и оптимальные палитры будут различными.
Самый простой и быстрый способ - использовать одну и ту же палитру на все случаи жизни, как это делает Microsoft Paint.
Если нужна адаптивная палитра - несколько сложнее.
Кстати, возможно, в этом случае целесообразно воспользоваться внешней программой, которая сделает всю необходимую работу для указанного файла.
Кстати, если несколько файлов нужно привести к одной и той же палитре, то их надо объединить в один, после чего обрабатывать уже суммарное изображение.
Если же хочется реализовать алгоритм самому, то начинают обычно с того, что заводят трехмерный массив (описывающий цвета в RGB-кубе), в каждую ячейку которого заносится количество повторений данного цвета.
В самом общем случае - это 16.7 млн чисел, вероятно, 32-разрядных, т.е. 64 Мбайта. В принципе не так уж много для современных компьютеров. Но, учитывая, что потери все равно неизбежны, можно перейти от 8-битного представления каждой цветовой составляющей к 7- или 6-битному, сократив объем используемой памяти до 8 или 1 Мбайта.
Проходим по изображению - заполняем массив.
Находим ограничивающие плоскости, т.е. минимальные и максмальные интенсивности цветовых составляющих, встречающихся в изображении. Получаем некоторый объем цветоавого пространства, которое затем нам предстоит разбить на 256 частей, каждая из которых представляет цвет в результирующей палитре.
Вот алгоритм разбиения объема на части - и есть вещь неочевидная и зависящая от дальнейшего алгоритма преобразования цвета.

Палитру я решил делал самым простым способом, как делает paint. Вроде все нормально... Только вот еще одна проблема: когда происходит переполнение таблицы LZW, то картинка почему то смещается влево. Например:

-******+
-******+
-******+ -вот здесь происходит переполнение и нижняя часть картинки сдвигается.
******+-
******+-
******+-

Т.е. сама картинка распознается, значит код правильный, но только нижняя часть смещена... Никак не могу понять в чем дело... Помогите разобраться

Заранее спасибо

Раз картинка смещается, значит, в программе ошибка.