TensorFlow I/O is a collection of file systems and file formats that are not available in TensorFlow's built-in support. A full list of supported file systems and file formats by TensorFlow I/O can be found here.
The use of tensorflow-io is straightforward with keras. Below is an example to Get Started with TensorFlow with the data processing aspect replaced by tensorflow-io:
import tensorflow as tf import tensorflow_io as tfio # Read the MNIST data into the IODataset. dataset_url = "https://storage.googleapis.com/cvdf-datasets/mnist/" d_train = tfio.IODataset.from_mnist( dataset_url + "train-images-idx3-ubyte.gz", dataset_url + "train-labels-idx1-ubyte.gz", ) # Shuffle the elements of the dataset. d_train = d_train.shuffle(buffer_size=1024) # By default image data is uint8, so convert to float32 using map(). d_train = d_train.map(lambda x, y: (tf.image.convert_image_dtype(x, tf.float32), y)) # prepare batches the data just like any other tf.data.Dataset d_train = d_train.batch(32) # Build the model. model = tf.keras.models.Sequential( [ tf.keras.layers.Flatten(input_shape=(28, 28)), tf.keras.layers.Dense(512, activation=tf.nn.relu), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10, activation=tf.nn.softmax), ] ) # Compile the model. model.compile( optimizer="adam", loss="sparse_categorical_crossentropy", metrics=["accuracy"] ) # Fit the model. model.fit(d_train, epochs=5, steps_per_epoch=200)
In the above MNIST example, the URL's
to access the dataset files are passed directly to the
tfio.IODataset.from_mnist API call.
This is due to the inherent support that
tensorflow-io provides for
HTTPS file system,
thus eliminating the need for downloading and saving datasets on a local directory.
tensorflow-io is able to detect and uncompress the MNIST dataset automatically if needed,
we can pass the URL's for the compressed files (gzip) to the API call as is.
Please check the official documentation for more detailed and interesting usages of the package.
tensorflow-io Python package can be installed with pip directly using:
$ pip install tensorflow-io
People who are a little more adventurous can also try our nightly binaries:
$ pip install tensorflow-io-nightly
In addition to the pip packages, the docker images can be used to quickly get started.
For stable builds:
$ docker pull tfsigio/tfio:latest $ docker run -it --rm --name tfio-latest tfsigio/tfio:latest
For nightly builds:
$ docker pull tfsigio/tfio:nightly $ docker run -it --rm --name tfio-nightly tfsigio/tfio:nightly
tensorflow-io Python package has been successfully installed, you
can install the development version of the R package from GitHub via the following:
if (!require("remotes")) install.packages("remotes") remotes::install_github("tensorflow/io", subdir = "R-package")
To ensure compatibility with TensorFlow, it is recommended to install a matching version of TensorFlow I/O according to the table below. You can find the list of releases here.
|TensorFlow I/O Version||TensorFlow Compatibility||Release Date|
|0.21.0||2.6.x||Sep 12, 2021|
|0.20.0||2.6.x||Aug 11, 2021|
|0.19.1||2.5.x||Jul 25, 2021|
|0.19.0||2.5.x||Jun 25, 2021|
|0.18.0||2.5.x||May 13, 2021|
|0.17.1||2.4.x||Apr 16, 2021|
|0.17.0||2.4.x||Dec 14, 2020|
|0.16.0||2.3.x||Oct 23, 2020|
|0.15.0||2.3.x||Aug 03, 2020|
|0.14.0||2.2.x||Jul 08, 2020|
|0.13.0||2.2.x||May 10, 2020|
|0.12.0||2.1.x||Feb 28, 2020|
|0.11.0||2.1.x||Jan 10, 2020|
|0.10.0||2.0.x||Dec 05, 2019|
|0.9.1||2.0.x||Nov 15, 2019|
|0.9.0||2.0.x||Oct 18, 2019|
|0.8.1||1.15.x||Nov 15, 2019|
|0.8.0||1.15.x||Oct 17, 2019|
|0.7.2||1.14.x||Nov 15, 2019|
|0.7.1||1.14.x||Oct 18, 2019|
|0.7.0||1.14.x||Jul 14, 2019|
|0.6.0||1.13.x||May 29, 2019|
|0.5.0||1.13.x||Apr 12, 2019|
|0.4.0||1.13.x||Mar 01, 2019|
|0.3.0||1.12.0||Feb 15, 2019|
|0.2.0||1.12.0||Jan 29, 2019|
|0.1.0||1.12.0||Dec 16, 2018|
We use github-pages to document the results of API performance benchmarks. The benchmark job is triggered on every commit to
master branch and
facilitates tracking performance w.r.t commits.
Tensorflow I/O is a community led open source project. As such, the project depends on public contributions, bug-fixes, and documentation. Please see:
|Linux CPU Python 2|
|Linux CPU Python 3|
|Linux GPU Python 2|
|Linux GPU Python 3|
Because of manylinux2010 requirement, TensorFlow I/O is built with Ubuntu:16.04 + Developer Toolset 7 (GCC 7.3) on Linux. Configuration with Ubuntu 16.04 with Developer Toolset 7 is not exactly straightforward. If the system have docker installed, then the following command will automatically build manylinux2010 compatible whl package:
for f in dist/*.whl; do docker run -i --rm -v $PWD:/v -w /v --net=host quay.io/pypa/manylinux2010_x86_64 bash -x -e /v/tools/build/auditwheel repair --plat manylinux2010_x86_64 $f done sudo chown -R $(id -nu):$(id -ng) . ls wheelhouse/*ls dist/*
It takes some time to build, but once complete, there will be python
3.7 compatible whl packages available in
On macOS, the same command could be used. However, the script expects
python in shell
and will only generate a whl package that matches the version of
python in shell. If
you want to build a whl package for a specific python then you have to alias this version
of python to
python in shell. See .github/workflows/build.yml
Auditwheel step for instructions how to do that.
Note the above command is also the command we use when releasing packages for Linux and macOS.
TensorFlow I/O uses both GitHub Workflows and Google CI (Kokoro) for continuous integration. GitHub Workflows is used for macOS build and test. Kokoro is used for Linux build and test. Again, because of the manylinux2010 requirement, on Linux whl packages are always built with Ubuntu 16.04 + Developer Toolset 7. Tests are done on a variatiy of systems with different python3 versions to ensure a good coverage:
|Python||Ubuntu 18.04||Ubuntu 20.04||macOS + osx9||Windows-2019|
TensorFlow I/O has integrations with many systems and cloud vendors such as Prometheus, Apache Kafka, Apache Ignite, Google Cloud PubSub, AWS Kinesis, Microsoft Azure Storage, Alibaba Cloud OSS etc.
We tried our best to test against those systems in our continuous integration whenever possible. Some tests such as Prometheus, Kafka, and Ignite are done with live systems, meaning we install Prometheus/Kafka/Ignite on CI machine before the test is run. Some tests such as Kinesis, PubSub, and Azure Storage are done through official or non-official emulators. Offline tests are also performed whenever possible, though systems covered through offine tests may not have the same level of coverage as live systems or emulators.
|Live System||Emulator||CI Integration||Offline|
|Alibaba Cloud OSS||✔️|
|Google BigTable/BigQuery||to be added|
References for emulators: