TensorFlow and Keras for Vision

TensorFlow and Keras stack photos into channels-last batches and train with one compiled call, so the batch shape decides speed and memory.

A TensorFlow batch keeps channels last: 32 images of 224 by 224 by 3 hold 4816896 numbers

Why Does This Exist?

Some teams want training as one auditable call: hand over the data pipeline and the model, get back history curves and a saved artifact. TensorFlow with Keras is built for that shape of work. tf.data assembles the batch pipeline, a Sequential or functional model stacks the layers, and fit runs the compiled loop with callbacks watching. The same artifact then serves behind an API without rewriting.

Its convention is channels-last. Where PyTorch packs $(N, C, H, W)$ , TensorFlow stacks $(N, H, W, C)$ : batch, height, width, channels at the end. A batch of 32 photos at 224 by 224 holds $32 \times 150{,}528 = 4{,}816{,}896$ numbers, the diagram's count. This page covers batches, the model call, and serving shape. Classifiers built this way belong to image classification; shrinking them belongs to inference optimization.

Think of It Like This

A printing press versus a workbench

A workbench handles one piece at a time with the worker watching every cut. A printing press takes a configured run: plates set, paper stacked, one button, thousands of copies. The press wins on volume and auditability; the workbench wins when every piece differs.

Keras fit is the press run: data pipeline configured, callbacks set, one call prints the whole training history. Research scripts that poke each batch are the workbench. The analogy stops at setup cost: a press misconfigured on page one misprints the run, so the batch shape and pipeline get verified before the button, never after.

How It Actually Works

tf.data builds the input as a chain: list the files, decode and resize each image, batch 32 together, prefetch the next batch while the GPU works. Each link streams, so a million-file dataset never sits in memory. The model stacks layers that keep the batch axis untouched: a convolution reads $(N, H, W, C)$ and writes $(N, H', W', C')$ , and only the final dense layers collapse the spatial axes.

fit then runs epochs of that pipeline against labels, with the batch shape governing two budgets at once. Memory holds the batch plus activations, so doubling the batch roughly doubles the footprint. Speed rises with batch size only while the GPU stays fed, which is why prefetching sits in every serious pipeline rather than in none.

Counting the batch

One image holds $150{,}528$ numbers. Thirty-two hold $150{,}528 \times 30 = 4{,}515{,}840$ plus $150{,}528 \times 2 = 301{,}056$ , totaling $4{,}816{,}896$ . Channels-last stores each pixel's three values together, row by row, matching how image files lay out bytes. Porting weights from a channels-first framework permutes those axes; the count never changes, only the walk order.

Code

The batch shape and count, in the runnable array library:

1import numpy as np2
3batch = np.zeros((32, 224, 224, 3), dtype=np.uint8)  # NHWC: channels last4print(batch.shape, batch.ndim)                       # -> (32, 224, 224, 3) 45print(batch.size)                                    # -> 48168966print(batch.size // 32)                              # -> 150528

Four axes, batch first and channels last, 4,816,896 numbers that divide back to 150,528 per image. Real pipelines spell the same shape in tf.data batching; the arithmetic is identical either way.

Watch Out For

Porting channels-first weights into channels-last slots

The symptom is a converted model that loads without error and predicts noise, with layer shapes all matching. Every axis has the right length; two of them swapped meanings. Square images hide it completely, because nothing about $(224, 224)$ says which axis is which.

Fix it by transposing weight axes at conversion time and verifying with one known image: correct conversion reproduces the source model's scores exactly, not approximately.

Starving the GPU with an unbatched pipeline

A pipeline that reads and decodes on the spot, without batching or prefetching, leaves the GPU idle between images. The symptom is low utilization beside slow epochs: expensive hardware waiting on file reads, with per-epoch time far above the arithmetic estimate.

Fix it by batching, then prefetching, then parallelizing the mapping, in that order. Measure utilization after each step; the bottleneck moves visibly when a stage stops being the limit.

The Quick Version

TensorFlow stacks batches channels-last: $(32, 224, 224, 3)$ holds 4,816,896 numbers.
tf.data chains file listing, decoding, batching and prefetching so datasets stream past memory.
Layers keep the batch axis untouched until the final dense layers collapse the space.
Batch shape sets both budgets: memory grows with the batch, speed only while the GPU stays fed.
Converted weights need axis transposition checked against one known image, exactly.
Batch, prefetch, then parallelize the pipeline, measuring utilization after each step.