Skip to main content
added 403 characters in body
Source Link

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades

  • If it is successfull it increase the size only once then every rotation keeps same quality.

  • That operation is successfull only if the image is made by equal chunks. (size of image is multiple of chunk's size).

The scottbb answer ins wrong and you can do a simple test:

  • Open the original image: Screenshot it
  • Rotate the image 4 times with WPV: Screenshot it
  • Compare the 2 screenshots

You will see the image changed (it is recompressed on first rotation). However that change is limited in time, you can now rotate it again without quality loss (if the image has a size that is a multiple of 8)

To directly answer OP:

I know it's rotating losslessly

Not it is not rotating losslessy, it lose quality at least once (on first rotation: because it should first compress it in a way that can be rotated), then it maintains its quality.

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades

  • If it is successfull it increase the size only once then every rotation keeps same quality.

  • That operation is successfull only if the image is made by equal chunks. (size of image is multiple of chunk's size).

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades

  • If it is successfull it increase the size only once then every rotation keeps same quality.

  • That operation is successfull only if the image is made by equal chunks. (size of image is multiple of chunk's size).

The scottbb answer ins wrong and you can do a simple test:

  • Open the original image: Screenshot it
  • Rotate the image 4 times with WPV: Screenshot it
  • Compare the 2 screenshots

You will see the image changed (it is recompressed on first rotation). However that change is limited in time, you can now rotate it again without quality loss (if the image has a size that is a multiple of 8)

To directly answer OP:

I know it's rotating losslessly

Not it is not rotating losslessy, it lose quality at least once (on first rotation: because it should first compress it in a way that can be rotated), then it maintains its quality.

added 718 characters in body
Source Link

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades

    If it fails to do so: the image quality degrades

  • If it is successfull it increase the size only once then every rotation keeps same quality.

    If it is successfull it increase the size only once then every rotation keeps same quality.

  • That operation is successfull only if the image is made by equal chunks. (size of image is multiple of chunk's size).

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades
  • If it is successfull it increase the size only once then every rotation keeps same quality.

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades

  • If it is successfull it increase the size only once then every rotation keeps same quality.

  • That operation is successfull only if the image is made by equal chunks. (size of image is multiple of chunk's size).

added 718 characters in body
Source Link

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades
  • If it is successfull it increase the size only once then every rotation keeps same quality.

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Because of how compression of images works. Any format like PNG or JPG in general do not preserve file size after rotation.

To the compressor the rotated image is just a different image, due to how compressione heuristic works there's no guarantee it will compress a rotated image the same.

Of course if the compression is lossless, if you rotate the image 4 times the 4th time the image is again the same (rotated until it becomes tilted as original): in that case it should become again of the same compressed size, if not then it is because one of the following reasons:

  • Added metadata: the program added some chunk of text for some reason
  • Compressor changed: the program may choose to just re-save the image as the original if there are no changes, but if you apply any change (even 4 rotations of 90 degrees) it may decide to re-compress the image again using its own compressor (the program no longer knows it is still the same image).
  • In general the same compressor (libPNG or libJPG) yields very different results across different implementations, different versions of same library and with different compression parameters (also operative system and compiler makes a difference here sometimes).

Image compression works by compressing images into 4x4 or other sizes chunks. In general a compressor sees a rotated image as a different image, however since a compressed pixel chunk is Just a linear decomposition, if the chunks on the image are the same it is possible just to Transpose/Mirror the linear decomposition matrices effectively keeping the same quality:

Note this has to be implemented on a per feature basis, and that also explain the initial increase in size => on first rotation it just trys to compress the image in chunks that are rotable:

  • If it fails to do so: the image quality degrades
  • If it is successfull it increase the size only once then every rotation keeps same quality.
Source Link
Loading