Будующее - это когда в метаданных формата, описывающего двумерный массив пикселей, содержится то, насколько этот массив нужно повернуть (из четырёх вариантов, ага).
@l29ah Так это не брак. Фотограф мог держать фотик вертикально. А в фотоаппарат встроен гироскоп например. Или ты хочешь чтобы тебе прямо на слабом процессоре фотоаппарата на лету перекодировали матрицу? Или просто чтобы не записывали нигде данные о повороте? Ты всегда можешь перекодировать сам, если не нравится.
@l29ah Они выплёвывают bmp скорее. // На самом деле RAW. И "правильно" повернуть этот bmp перед конвертацией в джпег занимает значительные ресурсы вообще-то. Быстрее сразу конвертировать в джпег.
@l29ah Как ты их в обратном направлении читать будешь? Если они представлены как одна строка. Каждый тысячные три байта (RGB) по тысячу раз? Это еще медленней.
@l29ah Ну на диске и в ОЗУ они так и представлены. В ОЗУ то они сразу идут из матрицы фотика прям в RAW. Нет там четырех способов чтения с матрицы (с каждой стороны). По крайней мере я о таких не слышал. Это было бы слишком ебануто если честно.
Это разве плохо?
@l29ah Так это не брак. Фотограф мог держать фотик вертикально. А в фотоаппарат встроен гироскоп например.
Или ты хочешь чтобы тебе прямо на слабом процессоре фотоаппарата на лету перекодировали матрицу? Или просто чтобы не записывали нигде данные о повороте?
Ты всегда можешь перекодировать сам, если не нравится.
@l29ah Они выплёвывают bmp скорее. // На самом деле RAW.
И "правильно" повернуть этот bmp перед конвертацией в джпег занимает значительные ресурсы вообще-то. Быстрее сразу конвертировать в джпег.
@l29ah Как ты их в обратном направлении читать будешь? Если они представлены как одна строка. Каждый тысячные три байта (RGB) по тысячу раз? Это еще медленней.
@l29ah Ну на диске и в ОЗУ они так и представлены. В ОЗУ то они сразу идут из матрицы фотика прям в RAW. Нет там четырех способов чтения с матрицы (с каждой стороны). По крайней мере я о таких не слышал. Это было бы слишком ебануто если честно.