J
Jens-Michael Gross
Kennedy said:
Why am I not surprised to read this kind of statement from you? Well,
must have been predictable - even for a 'kid' like me.
Grossibaer
Why am I not surprised to read this kind of statement from you? Well,
must have been predictable - even for a 'kid' like me.
Grossibaer
J
Jens-Michael Gross
Kennedy said:
indeed there are 65536 states and I never denied that. But your
arguments contained the VALUE 65536 as part of the mathematical proof of
your concept. While using the zero as a VALUE in this 'proof' at the
same time.
Either your calculations may not be zero based or you may never think of
a number of 65536 in the same formula (but you were not the only one
mixing both value ranges in the same argument).
If I always use the range 0..65535 then I do not ignore the zero state
and also do not use any different number than 65536 states, as the rang
0..65535 includes the zero as well as the 65535 and all 65534 values in
between.
You're even ripping apart logical statements combined with an AND
operator. Okay, it's completely fruitless to further answer any of your
posts.
Indeed. It not only requires language other than mathematics but also
requires understanding other than mathematics. And there you seem to
lack a whole bit.
I never denied that dividing a 16 bit value by 256 (shifting it left 8
bit) gives mathematically valid mapping of 16->8 bit. But it does no
justice to the task of mapping a 16 bit brightness level to an 8 bit
brightness level.
No, as part of the mathematical proof of your concept - in a formula
that works zero-based. That's a difference and that's invalid.
Okay, I'm gone now. Do what you want and get what you desire. And enjoy
a happy smile on your face that you 'obviously must have defeated me'
since I'm not answering anymore.
My life expands beyond and above this newsgroup and there are other and
way more profiting things than arguing with someone who wouldn't accept
the reality even if it woul bite him into the face.
'don't come with facts - I have my prejudice' seems to be your concept.
Be happy with it and enjoy mathematics. I wish you it will not fail you
someday when it is really important.
Grossibaer
J
Jens-Michael Gross
Kennedy said:
It's not the output, it's the INPUT you're working with.
And here we got the cause of your problems to understand the concept.
We're not discussing mapping output levels of a video card, we were
discussing converting an INPUT value from a sensor to a different value
range. And that's a big difference. maybe too big for you.
Oh, no, I surely had to calibrate the gamme for original image and every
convterted image differently?
No ... wait ... sounds stupid ... IS stupid!
What a difference makes the gamma or any other calibration if I present
original image data and onverted image data on the same device?
If I would compare the image on screen with the photographed object in
my hands, then it would of course make a difference, but when I just
compare the quality of one conversion and another conversion with the
original image on the same screen, it is completely unimportant.
Oh, well, with 16 bit per color channel, you have actually NEVER SEEN
the original 48 bit scan on your display. Or does your monitor do
48/64bit color depth? And when you calibrated your monitor to give best
results of the result of your conversion, it's obvious that your
conversion gives best results.
Never trust a statistic you didn't cheat yourself.
Neither was I the one who has thrown in the average or total error into
discussion nor did I calculate it on a mathematical way in any of my
posts (I was just using the - correct - values someone else posted
before). I rather explained more than once what happens with the
brightness levels one and the other way. But it seems this slipped your
attention (along other things).
And a histogram isn't something else than a visible representation of a
mathematical result.
Oh, you used your calculater to count to 9? Well, then... I'm speechless
about your mathematical skills.
I just wanted to give you justice and read (and answer) all of the posts
you wrote even if I originally wanted to stop with my last answer to one
of your others posts, but as I wrote there: it's fruitless.
And I have better things to do than wasting hours with this discussion,
since I already know that my opinion has been seconded by all people I
asked to judge my results, and knowing that you will never change your
mind.
After all, the purpose of this whole thread was not to change your mind
(or mine) but to asnwer someones questions which agorithm woudl be best
for a conversion. There have been enough answers, simple and
complicated, good and bad (not 'correct' and 'wrong') so I think this is
really the point where no further reply is needed.
I bet you cannot resist replying anyway. But chances are I won't read
it.
Grossibaer
J
Jens-Michael Gross
SJS said:
You exactly got my thoughts when working on the problem _without_ any
other input.
(besides it is -8 to +8 since the ranges except black and white are 17
and not 16, with zero error in the middle, but that's inimportant to the
concept)
The question is how you think the 0x08 value should be shown. As pitch
black or dark gray. And should 0x0f be shown as pitch black or rather as
dark gray (which would be the result for 0x10 in both methods).
And I found that the +8/17 mehtod gives the better results.
Of course the difference is much less visible when it comes to 16 to 8
bit conversion.
Get a 4 bit grayscale image and save it as true color image. Then look
at the color values.
If Photoshop would use *16 for this job, you'll never see an 255 color
value in the resulting image. if you see, it's definitely not using /16
and *16 for the conversion. (or it uses different algorithms for both
directions)
As I already stated several times: what gives the better result is the
better solution.
And after conversion you end up with an image that has certain data and
is shown in a certain way,. And if this image pleases you, then it is
completely unimportant how you got it. If you only make it to an image
that pleases you.
And if Photoshop and all other programs would scramble your image to
unusable crap, and no program would provide any 'working' solution,
well, you would get the best you can get and you had to be content with
the result. Even if there COULD be a better solution.
Both methods produce a valid 8 bit (per color) image which would show up
identically on any software capable of handling 8 bit depth per color
(in the limitations of the used output device). Only the content of the
image would differ a bit. So the important standard is the format of the
resulting image, not the conversion method.
Maybe, I only remember that I wasn't - even if I could easily jump in
with the experiences I made jsut a few months ago when writing code for
exactly this problem.
Aren't algorithms claimed intellectual property? AFAIK the USA (driven
by the large companies) try to make algorithms patentable.
I guess, nobody will tell teh 'inner secrets' of their software and
whether they use a shifht right by 8 bit or make a more complicated
division.
Grossibaer
K
Kennedy McEwen
Jens-Michael Gross said:
Where? You have stated this allegations on several occasions, but have
not once identified the statement in my argument where both *values* of
0 and 65536 are used. The divisor is determined by the ratio of the
number of states. There are 65536 states in the original format
(whether that ranges from 0 to 65535 positive binary, -32768 to +32767
twos complement or any other 16bit coding scheme is irrelevant).
Similarly there are 256 states in the output format (and again, whether
that 8 bit range is 0 to 255 positive binary, -128 to +127 two's
complement or any other format is equally irrelevant). Photoshop, for
example, uses integer maths for 16-bit computation, so the range is
-32768 to +32767, hence previous comments that PS only really supports a
15-bit range.
Using *only* the number of states in each range we can determine the
ratio between them, and thus the divisor of the conversion, to be
65536/256 = 256.
Please state *exactly* where in the above deduction I use both 0 and
65536 in the same range - otherwise apologise for your repetitive and
unfounded allegation.
The argument is stated completely above - show where *both* 0 and 65536
are used in defining the number of states in the range. If both states
existed then there would be a total of 65537 states - I have not used
that number in any part of the discussion.
However you have not used the number of states in the range in your
conversion, but the peak value - which you assume to be 65535 (even
though in 16bit integers that is +32767).
Actually, yes - see your statement which you repeated yet again n the
3ed paragraph quoted above. This is a clear, although totally
unjustified, statement that you have repeatedly made that I use *both* 0
and 65536 values in the same range, but not once have you specified
where that has occurred in my argument. In fact, I have been at pains
to point out that the ratio between the two ranges, and thus the divisor
in any conversion, is completely independent of the max and min values
in the range, merely on the number of states within it.
J
Jens-Michael Gross
Don said:
Indeed. If I have 65536 equidistant values and map them to 256 values by
any non-linear 'adaptive' algorithm, then the result aren't 256
equidistant values (or you could dump the 'adaptive' algorithm). And if
they are not equidistant, You'll need a lookup table for the brightness
distance between the values. Anything else is clearly beyond my grasp
(and beyond what any currently used reproduction device or imaging
software would handle).
Except you really want the image to be altered in a way that you get a
linear histogram. Wouldn't look much like the original, but if it
pleases you...
See above.
Wait, I have an idea... are you using one of these experimental
computers where you can store more than one mathematical bit in every
physical bit by using different voltage levels when writing to ram? Then
perhaps it might work. I thought these devices have all been dumped when
ram started to get cheaper.
Unfortunatly would it require some equally specialized storage media to
let the result survive the next power-down. Or a specialized file format
with, say, 16 bit per 8 'bit' value.
I wonder where there would be the advantage over sticking with the
original 16 bit data?
Grossibaer
K
Kennedy McEwen
I suggest that you read the subject line of the thread!Jens-Michael Gross said:
These are OUTPUT levels from the scanner - the input is a photon flux
level which is generally measured in the range of many tens of billions
of photons per second per square metre per steradian, and cannot be
described in either 8 or 16-bit integers.
Exactly! And this is the very reason that the discussion diverted to
comparing 8 and 4 bit ranges such that the difference is visible!
Irrelevant, you chose to use that calculation of error as part of your
argument. In doing so you implicitly supported it and all of its
derivation. Blaming the calculation on someone else merely undermines
your entire argument since you now have no evidence to support your
position.
No, it is a visible representation of the luminance output which is
*independent* of the data range used to produce those luminance levels.
You have already demonstrated that your brain is incapable of
calculating, consistently.
D
Don
Yeah. Just ignore him. I mean, ignore "it"... ;o)
Don.
K
Kennedy McEwen
Photoshop (v7.1) doesn't actually support 4 bit images internally (theJens-Michael Gross said:
first operation it makes on opening a 4-bit image is to convert it to
8-bit indexed colour mode) so the data is assigns to the nominal levels
after that conversion is irrelevant. Furthermore, as Wayne pointed out
in an earlier post, you are now converting from a 4-bit image luminance
descriptor to an 8-bit descriptor - completely the opposite function of
that being addressed in the subject line of the thread!
Photoshop will, however, convert an 8-bit full range image to any number
of levels you chose, using the Posterise function, but retain the data
in 8-bit format. So, create an 8-bit greyscale image with 256 pixels
wide, linearly ramping from 0 to 255 across the image. Do not rely on
the Photoshop gradient tool for this, which introduces a dither to the
data, but, if necessary, create a file directly with a hex editor to be
sure that the numbers are a precise linear ramp with each level
represented by a single pixel width. Select the
Image|Adjustment|Posterise and input 16 as the number of discrete levels
required (ie. a 4-bit range). Please explain why Photoshop then
produces a 16 level ramp with equal widths for all of the 16 levels.
From the original 256 equispaced levels, the lower 16 (neither 8 nor 9!)
are converted to black, the upper 16 (neither 8 nor 9!) are converted to
white, and every level in between is sourced from 16 levels (not 17!) in
the original 8-bit range. In short, in determining which levels of the
0..255 range are being mapped to the 16 level range Photoshop *is*
simply truncating the data.
Same thing happens if you take a 16-bit greyscale image that is 256
pixels wide and create a linear ramp from 0 to 255, then convert that
image to 8-bit greyscale. The resulting linear ramp is again equispaced
indicating that Photoshop has implemented the conversion from 16-bit
data to 8-bit by truncation. (In spite of Chris Cox's comments earlier
in this thread!)
Similarly, Paintshop Pro, which does support 4-bit graphic images
directly will reduce an 256 colour, 8-bit, image to 16 colours (4-bits)
directly. Guess what, that does the same! (Select Colors|Decrease Color
Depth| 16 colors (4-bit)|Optimised Octree - Nearest Color).
Now, just because Photoshop and Paintshop Pro do it that way does not
make it right - there have been numerous bugs and errors in both of
those applications over the years of their development to rely on either
using a "correct" algorithm - however it does put the lie to your
argument that all programs implement the conversion using your preferred
method. Clearly the two most popular image processing packages on the
PC and Mac platforms use a shift right to reduce the number of bits
representing images.
S
SJS
On Wed, 30 Jun 2004 01:55:03 +0100, Kennedy McEwen
[snip]
Hi Kennedy,
Thanks for answering my question and all your input and well-researched
info in this thread.
-- Steven
[snip]
Hi Kennedy,
Thanks for answering my question and all your input and well-researched
info in this thread.
-- Steven