Don said:
No, because "lossless" refers to the fact that no information is lost.
Therefore, there is nothing to "reverse".
The only way not to lose information (in the sense you use this term!)
would be not to change the input at all.
What you're getting at is that if you have a *lossy* operation which
is reversible then the *end result* is lossless, but that's a stretch.
A lossy operation can't be reversible.
Can you name a "lossless" operation (i.e. where "no information is
lost"), which doesn't need to be reversed to get back the input?
The only one I can think is the null operation.
You don't destroy pixels when you apply LZW otherwise you would not be
able to get them back.
Cool. So, I don't destroy pixels when I apply my noise addition,
otherwise I would not be able to get them back.
And I do get them back. Try and see! Where *is* the difference between
this and LZW? They both get back *exactly the same input image with no
changes at all*, so why is my noise addition "destroying data" while LZW
is not?
You simply encode or compress them, but no
information is lost or destroyed.
Nor is information destroyed with my noise addition.
You're focusing in to narrowly and literally on what bytes are
actually in the file but that's not important in this context. It's
the concept which is the key.
Uh?!
No, it means no information is lost. It's all really semantics...
Well, no information is lost.
You have a set A of data, and you transform it to a set B of data by
applying an operation O. If there exists an operation O' that can take B
as input and give back A, then O was lossless/reversible.
I still can't understand *where* you disagree with this concept.
(My noise addition operation is obviously only lossless when the
histogram of the original image "A" is considered part of the output
"B", but I've made that clear multiple times. This is the only caveat I
can see, though)
The problem is that's impossible because the number of pixels in an
image is fixed.
That's why I said "even if you could". What I wanted to say is that the
point is moot, since under your definition, it wouldn't be lossles *even
if* this could be done.
You can't! That was exactly my point.
But I can. Just run the program. You'll see that you'll get back your
original input every time, save bugs (i.e. "maintain reversibility"),
and yet, noise will have been added in the output.
That's different. Now you're getting into what JPG or MP3 do i.e.
ranks information and removes marginal data. But that is lossy by
definition.
Yes, it is lossy by definition.
But no, that's not what I'm doing.
I'm not removing marginal data; I'm removing *no* data.
Answer this please: if you taken an image.tif, then compress it to an
image.jpeg, then convert image.jpeg to image2.tif, will
image.tif=image2.tif ever hold true?
I bet it never will. Precisely because JPEG is lossy.
On the other hand, if you take an image.tif, apply noise with my program
and get an image_noise.tif, then use my program to remove the noise and
get an image_denoised.tif, it will be true that
image.tif=image_denoised.tif (though, again, you must feed my program
the histogram of image.tif as well).
[snip]
Now, if there is perceptible posterization, then again don't get
fixated by the gaps (or the histogram for that matter) but focus on
how best to remove this posterization. Given the right process the
histogram will fix itself. You use the histogram, of course, to check
the process but don't let the histogram drive your process if the
result of that is neglecting the goal.
This may be sound advice, but it's not the point.
I'm not trying to demonstrate that my program is the best way to remove
posterization, but only that it performs a lossless operation.
One example of this is the application of random noise which, as you
yourself say, looks "terrible" but it "fixes" the histogram. Well,
that's a case of "throwing out the baby with the bath water" as we
say. Or "The operation was a success but the patient died"! ;o)
I think the program can be improved to make the image look less
terrible, hopefully to a point where the result will look better than
the original posterization.
But, for the moment, I realize perfectly that the patient died; I still
think I can show that the operation was a success.
The reason I said "corrupt" is because the data you are trying to
recover not only exists but you can obtain it easily (simply use
16-bit depth and then reduce).
The data does not exist *in the input*! Obviously, I'm talking about the
input to my noise adder, that is the original scan.
If the scan was made in 8-bit, then the data does not exist in it.
If you scan at 16-bit, it's all different. And, granted, scanning at
16-bit is the best way to go in many cases.
However, you chose not to do that (for whatever reasons) and are now
trying to recover this missing data from an 8-bit image. That data
will never be as genuine as the original data in a 16-bit file.
Of course! but as you say, "for whatever reasons" we have an 8-bit file.
Clearly, all the arguments about reversibility and lossless operations
must be about *that* file.
Otherwise, it's like saying, "no, LZW isn't lossless because you could
have gotten a more genuine image using a better scanner [or scanning in
16-bit]". Half of this sentence is true, but the other half doesn't make
any sense. Guess which is which?
Therefore, anything you do to the 8-bit file is "corruption" in regard
to the actual 16-bit data you're trying to recreate.
"Recreate"? I've never claimed I can "recreate" useful 16-bit channels
from a single scan of 8-bit channels.
(That is, of course, unless the scanner *really* only outputs 8
meaningful bit; but you said that even a low-end scanner has meaningful
data beyond the 8th bit, and I'll take your word for it)
In regard to the actual 16-bit data, *the* 8-bit file itself is
corruption! But that wasn't the point of the current discussion, having
nothing to do with "information", "corruption" and "lossless/reversible
operations" relative to *the data you have*.
If you can get better data by sampling the target picture again, that's
another matter.
But we do! Simply use 16-bit depth and reduce. That way you will get
exactly the data you are missing in the 8-bit domain.
Sure. Please don't get the impression that I'm rejecting this possibility.
I currently scan at 8-bit mainly because of file size and bus speed, but
I'm absolutely not trying to claim that scanning at 16-bit is worthless.
The case is simply: you have a posterized image, and you can't or won't
scan it again at a higher bit depth. What can be said about such an
image? What reversible operations can be applied on it? Is artificial
noise perceptually better than posterization? etc.
[snip]
Last example: take an image that is all black on the left and all white
on the right, with no grays - again like your own example.
If you know that this is not a faithful reproduction of the original
picture, but rather a result of posterization/quantization, then you may
suppose that the original picture could have been a continuous shade of
gray... or something else, you can't really know.
Actually you do know that there is a threshold which made one side
black and the other side white. What you don't know is how solid each
side is and how wide the transition.
Yes. By "something else" I didn't mean "anything else"... but there is a
wide range of possibilities; all involve a transition, sure.
But you haven't gained anything either. You ended up adding "grain" to
an otherwise "clean" image.
Exactly! I've gained nothing, as far as information theory is concerned.
But, let me stress once again that I've also lost nothing.
So, what's the purpose in adding grain to a clean (but posterized) image?
Well, if a purpose there is, it is perceptual. I think the human eye
simply likes noise more than posterization; after all, the concept of
quantization is probably unused in our brain, while noise is very
present on the other hand.
So, if we have an excessively low-bit-depth image (which is essentially
what a posterized image is), I think our eyes prefers it displayed with
noise in the (otherwise empty) lower bits, than with the lower bits at zero.
This is essentially the whole point of my test program. If fills the
lower bits with random data, when these lower bits would otherwise be
consistenly at zero.
(In reality, it's a little more complicated than just "filling in the
lower bits", as the gaps in the histogram might not be uniformely
spaced, in which case the situation can't be precisely compared with a
low bit depth condition; but the overall concept keeps working).
[snip]
In general, I would always focus on solving the root problem rather
than trying to fix the consequences afterwards. In my experience, when
you try to fix the consequence in only generates more problems than it
solves. Usually you then have to "fix the fix" and so on. It just
never ends...
Amen!
But this doesn't always make it useless to discuss "fixing the
consequences". If you can, you solve the root problem, but if for some
reason you can't, it can be helpful.
You know, you can't just solve everything with "go take a better scan".
The software tricks are useful sometimes.
by LjL
(e-mail address removed)