No subject

> The transpose transformation has no restrictions regarding image dimensions.
> The other transformations operate rather oddly if the image dimensions are not
> a multiple of the iMCU size (usually 8 or 16 pixels), because they can only
> transform complete blocks of DCT coefficient data in the desired way.

> jpegtran's default behavior when transforming an odd-size image is designed to
> preserve exact reversibility and mathematical consistency of the
> transformation set. As stated, transpose is able to flip the entire image
> area. Horizontal mirroring leaves any partial iMCU column at the right edge
> untouched, but is able to flip all rows of the image. Similarly, vertical
> mirroring leaves any partial iMCU row at the bottom edge untouched, but is
> able to flip all columns. The other transforms can be built up as sequences of
> transpose and flip operations; for consistency, their actions on edge pixels
> are defined to be the same as the end result of the corresponding
> transpose-and-flip sequence.

I think lossless transformation is a useful feature and I like to see it in KDE
programs like gwenview. However, rotation and flipping are simple
one-click-operations in gwenview. The ugly results that you currently get
sometimes are not what a normal user would intuitively expect.

As it seems, gwenview is expecting that the transformations are lossless *and*
complete, because step 2b was needed: gwenview is doing a fast rotation of the
internal bitmap representation of the image instead of reloading the
transformed source image.

Please find a solution for all of this. Ideally, lossless transformations would
be possible and indicated as such. But also a simple rotation of the *whole*
image should be possible in one click.

Is it mathematically possible at all to apply the transformation to the cropped
DCT blocks? I mean: is there to every cropped block a rotated and cropped block
that yields exactly the same values? Or at least: is there a bijection between
them? Intuitively, I would guess that there is such a bijection with a good or
even perfect approximation. However, I do not know if there is a fast algorithm
(O (n * log n)) for doing such a transformation.

If there *is* such a fast algorithm, maybe this could be incorporated into
jpegtran?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.