Tfrecord против TF.image?

Question

У меня сложилось впечатление, что наличие предварительно вычисленного файла Tfrecord является наиболее эффективным способом передачи вашей функции ввода. Тем не менее, я продолжаю видеть прекрасно выглядящих статей, таких как эта , где функция ввода берет ссылку на необработанный файл на диске и выполняет декодирование на месте.

1. Есть ли преимущество в создании файлов Tfrecord или же столь же эффективно декодировать и подготавливать каждый семпл прямо внутри функции ввода (в отличие от того, чтобы функция ввода просто декодировала Tfrecord)?
2. При использовании прямых необработанных файлов в функции ввода, как в примере выше, куда бы вы добавили шаг увеличения данных?

Способ, которым я делал это в прошлом, заключается в том, что у меня будет отдельный скрипт, который, учитывая ссылку на некоторые файлы, будет генерировать файл Tfrecord с дополнением данных как его частью. Например, первые n изображения в Tfrecord были заданным изображением, за которым следовали его случайные преобразования и т. Д. Затем функция ввода просто декодировала каждую запись и определяла пакетирование, перемешивание и т. Д.

Answer 1

У вас, вероятно, такое впечатление, потому что этот формат ввода представлен на веб-сайте tenorflow, где он обозначен как « рекомендуемый формат » или даже «». стандартный формат TensorFlow ”.

На мой взгляд, основные преимущества формата TFRecord заключаются в том, что

1. он получает первоклассную поддержку граждан от tenorflow с выделенными функциями для чтения и декодирования
2. это гибкий формат, который может хранить вместе несколько различных категорий данных, а не только изображение,
3. может хранить более одной записи,
4. это портативный.

Однако сам формат, основанный на protobuf, изначально не был рассчитан на производительность. Например, метки хранятся в виде простого текста и повторяются для каждой записи - следовательно, файлы TFRecord могут оказаться намного больше, чем простые текстовые CSV-файлы . Способ сохранения числовых значений также не предназначен для производительности: количество битов, используемых для кодирования значения, не обязательно соответствует типу ввода (например, uint8 может быть сохранено с использованием одного или двух байтов в зависимости от его значения); хуже того, отрицательные целые значения сохраняются с использованием 10 (!) байтов независимо от того, что .

По моему опыту, файлы TFRecord никогда не обеспечивали повышение производительности моего входного конвейера - в лучшем случае они были на уровне исходных данных, в большинстве случаев они приводили к чуть худшей производительности. С другой стороны, формат в значительной степени неизвестен вне тензорного потока, и даже внутри тензорного потока вам нужно немного почесать голову, чтобы прочитать одну запись для отладки .

Так что, если вы не стремитесь к переносимости, вы можете работать с необработанными двоичными данными, не опасаясь пропустить многое; однако, если ваши файлы очень маленькие, попробуйте сгруппировать несколько образцов в один файл для повышения производительности или использовать что-то более сложное, например HDF5 . (Если переносимость является проблемой, то я все равно рассмотрю возможность сравнения с HDF5, который также переносим).

И наконец, не принимайте мои слова как должное и сравнительные форматы для вашей проблемы. Преимущество TFRecord, предложенного командой разработчиков, состоит в том, что вы найдете много примеров того, как его использовать, начиная с преобразования данных в этот формат .