"J. P. Gilliver (John)" wrote

| That's true for lossless. But the cropping itself is always destructive.
|
| Other than that cropping obviously removes information, what do you
| mean: I thought the non-destructive crop was just that (in the part of
| the image you keep, obviously). Being as it (as implemented in
| IrfanView, anyway) crops to the nearest 16 (I think it's 16) pixel
| boundary. I assumed the reason it does that is t avoid loss.
|

It's a clever method, but in general editing JPG
is lossy. How often will one need to crop to the
nearest 16 pixels but have no reason to do other
editing? If one will do other editing then the image
should be taken out of JPG format. So it's a kind of
silk purse from a sow's ear thing.

Nospam was just arguing, splitting hairs. It's
really all he does.

| IMO, BMP should only be used when a software doesn't support a better
image
| format. How it stores 24bpp image pixels is unacceptably wasteful.
|
| In what way - does it use two 16-bit words, or something? Or do you just
| mean it doesn't do any (even lossless) data-compression?

It has no compression. It's very straightforward.
In general a BMP will be a 24-bit, uncompressed
image. (There are other options, but they're no
longer used as far as I know.) The header looks
like so:
-----------------------------------------
BITMAPFILEHEADER '14 bytes
bfType As Integer (file "magic": "BM")
bfSize As Long
bfReserved1 As Integer
bfReserved2 As Integer
bfOffBits As Long (offset to start of image)

BITMAPINFOHEADER '40 bytes
biSize As Long
biWidth As Long
biHeight As Long
biPlanes As Integer
biBitCount As Integer
biCompression As Long
biSizeImage As Long
biXPelsPerMeter As Long
biYPelsPerMeter As Long
biClrUsed As Long
biClrImportant As Long

----------------------------------------
So, 54 bytes for the header. Following that are
the bytes that represent pixels. The header is just
enough to interpret the image data. So bytes 55-58
will be the first pixel, and so on:
55 56 57 58 59 60 61 62 63 (byte numbers)
00 00 FF 00 00 FF 00 00 FF (3 red pixels, using big endian
notation. Blue is in the high byte. Green is in the middle.)

That's what all raster images are. Pixel grids. Bitmaps.
No raster image format stores anything different. They
just store it in different ways, with varying degrees
of damage to the image. JPG degrades the image to make
it compress better, with less color variety. GIF reduces
to 256 colors and compresses that. (256 colors requires
an embedded color table, which takes up extra space,
but then each pixel can be stored as a single byte.)
I don't know how PNG works but I'm guessing it's
basically a BMP in a ZIP, with the addition of alpha
channel data (transparency) requiring 4 bytes per pixel.
(GIF, by contrast, stores transparency data by indentifying
one specific color that's not to be painted onscreen.)
TIF, likewise, is basically a BMP in a ZIP. (Though a ZIP
can often shrink a BMP by 90%, while a TIF seems to only
manage about 50%. I don't know why.)

They're all just ways to store a BMP. None of those
image formats means anything until the BMP is extracted.
One can't render a JPG onscreen any more than the words
of a ZIPped Word DOC can be read from the ZIP bytes.
It has to be decompressed to get the BMP.

Similarly, when one applies filters in an editing program
it's just a math formula applied to the bitmap bytes.
Sharpening increases the difference between the numeric
values. Interpolation for resizing calculates a new pixel
grid by examining the values of neighboring pixels.
Lightening increases the byte values of the pixel bytes.
It's all just math operations on 3-byte RGB pixels stored
as grids in a BMP.

In other words, the idea that BMP is outdated is a
misunderstanding of what raster images are.