6x6 = 180 Megapixel camera?

In article ,
Neil Gould wrote:

Why not take your own advice, and not snip relevent portions that you then
make comments about?

There is no point in addressing nonsequiturs. My point was very simple and
uncontentious. It has nothing to do with colour depth, whether disk counts
as "physical memory", the non-existence of 64 bit per channel digital
cameras, or pretty much anything else you seem to have randomly plucked out
of the air.

Case in point, in the above comment, you snipped the
portion that directly addressed your current criticism;

But what you go on to write doesn't address *anything*. It's just
technobabble:

"...Furthermore,
the filters you've described -- editing curves, hue/saturation
(shadow/highlight is a little different, but the point will still
apply) -- are redundant routines that are not all that large as programs
go." In other words, they spend their time executing a relatively small
loop on the same sized segments of a file (determined by format), ergo, no
particular speed up is likely attributable to address space.

That reads like the sort of filler you'd expect to hear on "Star Trek".
Nothing you've said there is making any specific point at all, it reads like
random use of terminology, perhaps in some sort of attempt to make yourself
sound authoritative - a "cargo cult" aping of academic debate, which looks
impressive as long as the reader doesn't realise that it's just babble.

Here's mo

You haven't provided one reason why one *must* load the entire image
to process it.

Because the sort of machines that run Photoshop don't perform
arithmetic operations on disk files.

Who said that is a requirement under any circumstances?
Multithreaded operation makes such an approach completely absurd.

That makes no sense at all - it's just more technobabble.

In your previous reply, when I tried to explain the very straightforward
difference between address values and datavalues by suggesting that, if you
knew C, it was the difference between sizeof(void*) and sizeof(int), you
came back with some nonsense about how "sizeof() defines datastructures", or
some such. Problem is, sizeof() doesn't define anything, it's an operator,
just like addition and subtraction. You could have just said, "I don't know
C, so your example doesn't mean anything to me", but instead you responded
with more technobabble.

So either you're trolling, or you're genuinely of the belief that you are
making some sort of valid technical point which has something remotely to do
with what I was talking to JJS about, and are just horribly confused, but
either way, you are wasting my time. Good day.

Recently, Chris Brown posted:

Neil Gould wrote:

Why not take your own advice, and not snip relevent portions that
you then make comments about?

There is no point in addressing nonsequiturs. My point was very
simple and uncontentious.

?

But what you go on to write doesn't address *anything*. It's just
technobabble:

"...Furthermore,
the filters you've described -- editing curves, hue/saturation
(shadow/highlight is a little different, but the point will still
apply) -- are redundant routines that are not all that large as
programs go." In other words, they spend their time executing a
relatively small loop on the same sized segments of a file
(determined by format), ergo, no particular speed up is likely
attributable to address space.

That reads like the sort of filler you'd expect to hear on "Star
Trek". Nothing you've said there is making any specific point at all,

Well, your insults aside, my comment addresses an aspect of performance --
how long an operation takes to execute. And, the salient point is that
nature of these operations on existing file structures may not change
significantly by only altering the address space. Since you're the one
that introduced these operations as an issue, you may wish to counter the
assertion with some facts to support your claims rather than just issuing
another ad hominem attack on me.

Here's mo

You haven't provided one reason why one *must* load the entire
image to process it.

Because the sort of machines that run Photoshop don't perform
arithmetic operations on disk files.

Who said that is a requirement under any circumstances?
Multithreaded operation makes such an approach completely absurd.

That makes no sense at all - it's just more technobabble.

What is it that you don't understand about that comment? Your assertion is
that the methods that I described must perform arithmetic operations on
disc files. I know of no such requirement. File read/write operations are
independent of the editing functions' arithmetic operations, and needn't
have a significant impact on the execution time of those editing
functions, especially in the context of multithreaded operations. Do you
REALLY disagree with this?

In your previous reply, when I tried to explain the very
straightforward difference between address values and datavalues by
suggesting that, if you knew C, it was the difference between
sizeof(void*) and sizeof(int), you came back with some nonsense about
how "sizeof() defines datastructures", or some such.

Here's the "some such":
"Well, I think this comment is going astray, as (sizeof()) has the
flexibility to define address data structures as required. In short, those
data structures are defined in the image file, not the image editor, and
the editor must deal with whatever it's presented with in that regard."

Well, I could have put that better. ;-) No problem (the way it turned
out was actually the result of over-agressive editing of my comment on my
part). Your use of (void*) as a data object within the sizeof operator is
also ambiguous. None the less, I took the gist of what you wrote to make
my comment, and the salient point I was making is that such data object
definitions appear in the data file, not the editing application... etc.
Do you REALLY disagree with this? If not, I presumed that you'd understand
the implications of this withiin the context of the point I *think* you
were trying to make.

Again, you present a string of personal attacks with nothing substantive
about *why* you think there would be a performance gain associated with
merely increasing the address space while operating on current image file
formats. At least I'm making an attempt to support my opinions to the
contrary with specific examples which you haven't refuted with any facts.

Regards,

Neil

"Neil Gould" wrote in message
m...
Recently, Chris Brown posted:

Neil Gould wrote:

Aw you guys. Will ya take it to email? Yer both making me feel stupid.

My appraisal of a machine is to load a 3gb file and see how it works.
Simple. So far, I'm pretty damned unhappy.

"jjs" john@xstafford.net wrote in message
...
"Neil Gould" wrote in message
m...
Recently, Chris Brown posted:

Neil Gould wrote:

Aw you guys. Will ya take it to email? Yer both making me feel stupid.

Not to worry. A larger physical address spaces makes it easier to use larger
amounts of RAM, and that makes it easier to manipulate larger files with
less pain. As long as you perform more than one operation on an image before
saving it to disk, doing it in RAM will be faster.

You can also do heroic things to break up files into chunks handled by
multiple processes or threads, but that assumes that the CPU itself can
address more than 4GB of RAM. Memory management units that handle more RAM
than the nominal address space of the CPU are not unknown, but that doesn't
seem to be being done.

So if you want more RAM, you aren't going to get it without wider addresses.
So wider addresses are needed.

My appraisal of a machine is to load a 3gb file and see how it works.
Simple. So far, I'm pretty damned unhappy.

As I've said before, you need an amount of RAM that slightly exceeds the sum
of the active OS and program code plus _twice_ the in-RAM size of the image
file. Even then that only allows simple transformations. I don't know what
the math looks like for layers operations.

David J. Littleboy
Tokyo, Japan

Here are some interesting discussions.

http://medfmt.8k.com/mf/filmwins.html

rafe bustin wrote:

On Fri, 11 Feb 2005 01:45:00 -0500, Stacey wrote:

rafe bustin wrote:

I haven't seen a slide projector in use for
a few years now. The last time was at some
geezer's 80th birthday and half the audience
was asleep after midway through the second
or third carousel.

If you fall asleep looking at your own work.....


No, silly.

My point was, you DO look at your own work don't you? If so a slide show is
a very nice way to look at what you've shot. Hard to beat a 4X8 foot
iluminated display..
--

Stacey

That reminds me..... If you could convert digital images to slides I
wonder how well they would compare to slides shot by a film camera when
using a projector.

Recently, RolandRB posted:

That reminds me..... If you could convert digital images to slides I
wonder how well they would compare to slides shot by a film camera
when using a projector.

Well, one *can* convert digital images to slides. I've been doing that for
a couple of decades now to create trade show displays. The results are
dependent on the resolution of the film recorder and the resolution of the
digital file. One can get some pretty impressive results from a high-res
file to create an 8x10 slide or negative to use as a master for creating
10x20' images.

Regards,

On Wed, 16 Feb 2005 00:36:54 -0500, Stacey wrote:

rafe bustin wrote:

On Fri, 11 Feb 2005 01:45:00 -0500, Stacey wrote:

rafe bustin wrote:

I haven't seen a slide projector in use for
a few years now. The last time was at some
geezer's 80th birthday and half the audience
was asleep after midway through the second
or third carousel.

If you fall asleep looking at your own work.....


No, silly.

My point was, you DO look at your own work don't you?

Only to a point. I've seen some of these images
too often and for too long. I can see small
versions of most of my best just by going to
my website. (Though the site is in serious
need of updating and pruning.)

If so a slide show is
a very nice way to look at what you've shot. Hard to beat a 4X8 foot
iluminated display..


Like I say... it's been a while. Hard to
beat a 21" LCD too. grin


rafe b.
http://www.terrapinphoto.com

So far the main limitation to physical memory is the address space on the
memory controller on the motherboard. This is smaller than the CPU
address space. X86 chips have more than 32 bits of addressing
for some time now. The change to 64 bits would be of no value to the
the photo editor from an address space perspective.

An additional limiitation if the max file size of the OS. This is also not
limited
by the address space of the CPU.

Best wishes.