The minimum amount of RAM required to hold each row of an image will generally the number of pixels per row times the number of bits per pixel [most systems use the same number of bits for every pixel, though some historically have not]. In some cases, especially when this amount is close to being a multiple of some particular power of two, it may be rounded up [e.g. a display that's 640 pixels wide with 24 bits per pixel would require 15,360 bits per row, but for ease of addressing some such displays would round that up to 16,384 per row].
Some display subsystems require that the number of bits per pixel and the number of bits per row must both be powers of two. A display that was 160 pixels wide with 24 bits per pixel would thus end up requiring 8192 (256x32) bits per row even though less than half those bits were used. Scaling things back to 128 pixels of eight bits each would shrink the memory requirement to 1024 bits--an eightfold reduction in the amount of memory required [though less than a four-fold reduction in memory utilized].
Incidentally, when the number of bytes per row is something over a power of two, and the number of rows is a multiple of three, it's sometimes helpful to push the number of bytes per row by an "extra" power of two but subdivide the display vertically into thirds. This approach is used on the Apple II series of computers, which have 40 bytes per row. The top third of the display uses bytes 0-39 of rows that start 128 bytes apart; the middle third of the display uses the same rows as the top third, but uses bytes 40-79 of each; the bottom third uses bytes 80-119 of each row. The hardware for doing this is simpler than would be the hardware to deal with a non-power-of-two number of bytes per row, though software which has to draw across the boundaries between sections is a little more complicated.