Для создания формата прежде всего нужен заголовок.
Файлы различаются не по расширению (посмотрите на движки idtech хотя бы, zip'ы с другими расширениями), а по заголовкам (ибо расширение может быть любым, но файл также его может и не иметь). Так что все форматы файлов сначала читают заголовок.
Далее. У нас графический файл, мы можем сразу вжучить информацию о разрешении и цвете, но если не знаем как цвет будет обрабатываться, мы вьювер не напишем (а собственный формат, значит и собственный вьювер). Сначала нужна палитра. Лучше всего обратиться к палитре видеодрайвера, посредством какого-нибудь WinAPI, но можно использовать возможности MS-DOS, которые из 7 винды, к слову, не удаляли. Но тут у нас будет всего 16 цветов, зато проще сделать вьювер и формат в целом.
Хранение цвета. Знаете, сколько "по умолчанию" занимает цветовая информация? Белый кодируется как FFFFFFF, оттенки серого от нуля до фффф. И это только градация серого, а вам скорее всего нужен цветной файл. Но известные форматы картинок так информацию на хранят. Пара красный-синий-зеленый представлена как два байта вида F2 23 D0. Это уже три цвета в двух байтах. Как сделано? Использование таблиц замен, которые надо расшифровывать (у них в спецификации куча настроек типа размера словаря и так далее). Почему загрузка больших картинок тормозит, как вообще может тормозить например 50МБ файл на двухядерных процессорах и порядка 4ГБ оперативной памяти? А вы знаете, сколько информации нужно расшифровать вьюверу впринципе, плюс учитывайте зарезервированную память для системы.
PNG например, использует LZW. Тот же алгоритм, что и архиватора 7зип, используемый в основном в unix. По сути, без этого ни один современный формат картинок не обходиться.
Помните про заголовки в начале? А что если ваш формат файла предусматривает несколько таблиц замен разных разработчиков (к примеру, вьювер расшифровывает и PK (зиповский заголовок) и LZW). Значит нужен второй заголовок, который определяет алгоритм паковки в этом файле и определяет дальнейший принцип работы вьювера, отдельного редактора или плагина к фотошопу. Иначе пользователю, в лучшем случае, придется задавать это самому. А что обычному человеку до того, этот PNG LZWшный или использует другой алгоритм паковки цветовых байтов?
Файлы принято разделять на строгие (поддерживают только один алгоритм) и со свободной спецификацией (гуляют несколько алгоритмов паковки, что для простого юзера просто одни и те же PNG, JPG). Из тех, которые читаются браузером (а значит известны всем), почти все форматы свободные, кроме SVG. Кстати, SVG информацию вообще не шифрует, цвет и вектор представлены в открытом виде.
В идеале программа, я считаю, файлы должна читать независимо от расширения, ориентируясь на заголовки. Но на практике, проще всего реализовать программу, где проверка идет по расширению, да и файлы JPG без расширения или с другим, практически не встречаются. В MS-DOS расширением файла программе (а тогда они в основном консольные) передавали заголовок, который сейчас является содержанием файлов. Там когда-то не было заголовков, только байты. Если мы диалоговое окно возьмем (просмотр папок после нажатия кнопки "Обзор"), то оно проверяет по расширению. А можно написать окно, которое будет просматривать каждый файл и ориентироваться только по заголовку, но больше памяти займет. Так что расширение файла, пока это сделано для экономии памяти (здесь она существенна даже на современных компьютерах). А ассоциации файлов, тоже "текстовый редактор по умолчанию", "браузер по умолчанию"? Как из тысячи файлов без расширения они будут работать и вьювер найдет свои в проводнике Windows? Это возможно, но проводник читает реестр и ищет там заголовки файлов установленных программ, читая каждый файл в папке, сейчас он ищет только расширения в имени.