README.md

# Assignment: Image rotation
---
Лабораторная работа: Поворот картинки

# Подготовка

- Прочитайте главу 12 (стр. 221, 231–239) и 13 (целиком) "Low-level programming: C, assembly and program execution". 

На защите мы можем обсуждать любые вопросы из учебника из глав 8–13 включительно.

# Структура BMP файла

BMP файл состоит из заголовка и растрового массива.
Заголовок задаётся следующей структурой (обратите внимание на атрибут `packed`):

```c
// Описание для gcc и clang
#include  <stdint.h>
struct bmp_header __attribute__((packed))
{
        uint16_t bfType;
        uint32_t  bfileSize;
        uint32_t bfReserved;
        uint32_t bOffBits;
        uint32_t biSize;
        uint32_t biWidth;
        uint32_t  biHeight;
        uint16_t  biPlanes;
        uint16_t biBitCount;
        uint32_t biCompression;
        uint32_t biSizeImage;
        uint32_t biXPelsPerMeter;
        uint32_t biYPelsPerMeter;
        uint32_t biClrUsed;
        uint32_t  biClrImportant;
};
```

Сразу после него (всегда ли?) идёт растровый массив, в котором последовательно хранятся пиксели по строчкам.
Каждый пиксель задаётся структурой размером 3 байта:

```c
   struct pixel { uint8_t b, g, r; };
```

## Padding

Если ширина изображения в пикселах кратна четырём, то строчки идут одна за другой без пропусков.
Если ширина не кратна четырём, то она дополняется мусорными байтами до ближайшего числа байтов, кратного четырём.
Эти байты называются *padding*.

Пример:

1. Изображение имеет ширину 12 пикселей = 12 * 3 байт = 36 байт. Ширина кратна четырём, каждая следующая строчка начинается сразу после предыдущей.
2. Изображение имеет ширину 5 пикселей. 5 * 3 = 15 байт, ближайшее число кратное четырём (округление вверх) это 16. После каждой строчки будет отступ в один мусорный байт перед началом следующей.

Обратите внимание: отступы в *байтах*, не в пикселях.



# Пользователям компилятора от Microsoft 

Вам придётся задать структуру по-другому, без атрибута `packed`:

```c
#include  <stdint.h>
#pragma pack(push, 1)
struct bmp_header 
{
        uint16_t bfType;
        uint32_t  bfileSize;
        uint32_t bfReserved;
        uint32_t bOffBits;
        uint32_t biSize;
        uint32_t biWidth;
        uint32_t  biHeight;
        uint16_t  biPlanes;
        uint16_t biBitCount;
        uint32_t biCompression;
        uint32_t biSizeImage;
        uint32_t biXPelsPerMeter;
        uint32_t biYPelsPerMeter;
        uint32_t biClrUsed;
        uint32_t  biClrImportant;
};
#pragma pack(pop)
```

 
Объяснение этого прочтите находится на страницах 235&ndash;239 учебника. 


# Задание


- Необходимо реализовать поворот изображения в формате BMP на 90 градусов.
- Архитектура приложения должна содержать три чётко разделённых части:
   - Описание внутреннего представления картинки `struct image`, очищенное от деталей формата, и функции для работы с ним: создание, деинициализация и т.д.

   ```c
   struct image {
     uint64_t width, height;
     struct pixel* data;
   };
   ```
   
   - Функции для работы с BMP-файлами и сериализации/десериализации внутреннего представления.

    ```c
    /*  deserializer   */
    enum read_status  {
        READ_OK = 0,
        READ_INVALID_SIGNATURE,
        READ_INVALID_BITS,
        READ_INVALID_HEADER
        /* коды других ошибок  */
        };
        
    enum read_status from_bmp( FILE* in, struct image* img );
    
    /*  serializer   */
    enum  write_status  {
        WRITE_OK = 0,
        WRITE_ERROR
        /* коды других ошибок  */
    };
    
    enum write_status to_bmp( FILE* out, struct image const* img );
    
    ```
   
   Как только мы считали изображение во внутренний формат, мы должны забыть, из какого формата оно было считано! Иначе будет сложнее добавлять новые входные форматы, отличные от BMP (почему?).

    - Функции `from_bmp` и `to_bmp` принимают уже открытый файл, что позволяет
      им работать с заранее открытыми файлами `stdin`, `stdout`, `stderr`.
      Они не должны ни открывать, ни закрывать файлы.
    
    - Вам потребуются функции, аналогичные `from_bmp` и `to_bmp`, которые будут
      принимать имена файлов и заниматься корректным открытием (`fopen`) и
      закрытием (`fclose`) файлов; на открытых файлах они могут запускать `from_bmp`
      и `to_bmp`.

      Имеет смысл разделять открытие/закрытие файлов и работу с ними. Уже
      открытие и закрытие могут сопровождаться ошибками (см. `man fopen` и 
      `man fclose`) и хочется отделить обработку ошибок открытия/закрытия и
      обработку ошибок чтения/записи.

    - Для ошибок открытия/закрытия, возможно, вам захочется ввести отдельные типы перечислений.

    - Вам потребуется функция для поворота картинки в её внутреннем представлении:

      ```c
      /* создаёт копию изображения, которая повёрнута на 90 градусов */
      struct image rotate( struct image const source );
      ```

  Эти части имеет смысл держать **в разных модулях (файлах с расширением `.c`)**. Разумеется, для каждого нужен соответствующий заголовочный файл.

  - Кроме того, дополнительные функции, которые вы ввели для удобства, но
    которые не относятся по смыслу ни к одному из этих модулей, можно выделить
    в отдельный модуль. Часто его называют `util.c` или как-то похоже.


# Для самопроверки:

- Функции должны получать все необходимые им данные через аргументы. 
- Глобальные переменные запрещены.
- Сообщения об ошибках должны выводиться в `stderr`. Общее правило:  результаты вычислений &mdash; в `stdout`, информация о том, *как* происходят вычисления &mdash; в `stderr`.
- Нельзя смешивать логику вычислений и ввод-вывод.
- Нельзя использовать `typedef` для определения структур ([объяснение](https://stepik.org/lesson/408350/step/2)), кроме структур из одного поля, которые являются аналогом `typedef`, но без неявных преобразований.
- Ваш код должен компилироваться с флагами `-std=c18 -pedantic -Wall -Werror` (gcc) или `-std=c18 -pedantic -Wall -Werror` (clang).


  Пользователям MS Visual Studio придётся тяжко, поддержка C11/C17 пока есть только в [Visual Studio 2019 version 16.8 Preview 3](https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc). Установите флаги `/W4` (warning level 4) и `/WX` (warnings as errors).

  Можете попробовать использовать [`cl-clang`](https://clang.llvm.org/docs/MSVCCompatibility.html).
  
  Проверять Ваш код мы будем с помощью `gcc` и `Makefile`.
  
- Типы:

  - Проверьте, что вы максимально возможным образом расставили `const`.
  - Проверьте, что индексы используют только тип `size_t`.
  - Проверьте, что вы используете только платформо-независимые типы, такие, как `int64_t` или `int_fast64_t`.
  
- Проверьте, что вы используете правильные спецификаторы ввода и вывода.
- Вы можете добавлять любое число вспомогательных функций для удобства, это поощряется.
- Проверьте архитектуру. **Решение внутри одного файла приниматься не будет**.
  Думайте о том, как бы вы хотели организовать код, чтобы легко добавлять входные форматы (не только BMP) и трансформации (не только поворот на 90 градусов).

- Пожалуйста, присылайте решение в виде pull-request. [Инструкция](https://gitlab.se.ifmo.ru/cse/main/-/wikis/%D0%9A%D0%B0%D0%BA-%D0%BF%D0%BE%D1%81%D0%BB%D0%B0%D1%82%D1%8C-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D1%83).  В крайнем случае допускается ссылка на репозиторий на https://gitlab.se.ifmo.ru или https://github.com .
- Не забудьте написать `Makefile`. Он должен позволять при изменении одного `.c` файла пересобрать часть проекта не пересобирая всё остальное.