Possible to extract high resolution b/w from a raw file?

In article ,
lid says...

In article , Mxsmanic
wrote:

actually, it's not that simple. one major advantage for 64 bit are the
additional cpu registers which allow for code optimizations, and that
can help regardless of how much memory there is. another benefit is
being able to directly address huge amounts of memory. there are also
situations where 64 bit may be slower.

Sixty-four bit architecture simply concerns the direct addressing space. It
does not necessarily imply any other optimizations of the processor
architecture, such as the width of data paths or the use of internal processor
components.

however, on intel it does mean that, and since you think windows is the
only operating system to use, you *are* running on intel.

Or DEC Alpha or MIPs or PowerPC or . . .


however, 64 bit photoshop & lightroom *are* faster (and this is trivial
to test) unless the images are small, in which case adjustments are
going to be instant so it won't matter either way. on the other hand,
if the images are large, there can be a significant performance
improvements with 64 bit, in some cases 10x or more.

In general, anything that reduces disk I/O results in a performance
improvement.

only if disk i/o is the bottleneck. many times, it isn't.

On 5/29/2011 4:50 PM, Mxsmanic wrote:
nospam writes:

wrong. if the bottleneck was i/o then a faster computer wouldn't make
much of a difference, and it does.

No, it doesn't. Many applications take almost exactly the same time to open on
a fast computer as they do on a slow computer, and that's because almost all
the delay is disk I/O.

In fact, one of the consistent disappointments of getting a faster computer is
that things really don't run that much faster, if they do any kind of disk
I/O. And today's bloated software does huge amounts of disk I/O. I've seen
browsers do thousands of disk I/Os before they even create their first visible
window.

also wrong.

I've measured it.

A faster bus and memory contribute much to processing speed.

--
Peter

On 5/30/2011 7:59 AM, Mxsmanic wrote:
PeterN writes:

A faster bus and memory contribute much to processing speed.

Yes, but that has nothing to do with the size of the address space.

I never said it did. But any time we have I/O a slow bus will act as a
bottleneck
BTW taken in context of my comment before you snipped the context, that
meaning is clear.

--
Peter

On 5/30/2011 1:34 PM, Mxsmanic wrote:
PeterN writes:

I never said it did. But any time we have I/O a slow bus will act as a
bottleneck ...

Not true. The bottleneck for disk I/O is in access times, not transfer rates.
Processor speeds have increased by orders of magnitude, and memory speeds
nearly as much, along with bus speeds. Transfer rates for disks have increased
a lot as well. But access times have only slightly improved in the past half
century or so, and now they are the leading bottleneck in most computer
systems, along with network delays.

Things like RAID have only slightly improved performance. The access times are
still huge compared to all other performance factors. Likewise, disk cache has
only slightly helped: unfortunately, disk cache only works if there is
significantly locality in disk access, and often there is none, meaning that
wanted pages are almost never in cache. Write-into cache has also had only a
moderate effect, since you still have to physically write promptly, and this
still requires a very slow disk access.

So you are saying that a machine with a 1,200 front side bus won't be
any faster than the identical machine with a 400 front side bus.
(both machines theoretical, of course.)

--
Peter

nospam wrote:
In article , Ray Fischer
wrote:

Set up a script to run through several steps. Use the exact same
hardware. Run the test in a 32-bit OS and then a 64-bit OS.

the os is 64 bit. the apps can be either 32 or 64 bit, toggled by a
single mouse click.

And that's supposed to be the same as a 32-bit OS running a 32-bit
app?

the only difference is the app. everything else is the same.

Except that one OS is 64-bit and the other is 32-bit.

THAT's the test I'll accept.

it's been done,

Where?

adobe, intel, and by many many users.

Bull****ting isn't evidence.

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal

Mxsmanic wrote:
Ray Fischer writes:

Mxsmanic wrote:
Ray Fischer writes:

Whether an OS is UNIX is determined by it's performance with
tests and not by some arbitrary rules made up by you.

Mac OS is Unix according to the authority.

These two statements conflict with each other.

No they don't.

One says that a real UNIX is identified by tests, the other says that it's
identified by an arbitary authority. Both statements cannot be simultaneously
true.

Since the authority (which is not arbitrary) decides the tests that
determine whether an OS is UNIX, the two statements are equivalent and
not at all contradictory.

You don't know what Unix means.

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal

In article , Ray Fischer
wrote:

Set up a script to run through several steps. Use the exact same
hardware. Run the test in a 32-bit OS and then a 64-bit OS.

the os is 64 bit. the apps can be either 32 or 64 bit, toggled by a
single mouse click.

And that's supposed to be the same as a 32-bit OS running a 32-bit
app?

the only difference is the app. everything else is the same.

Except that one OS is 64-bit and the other is 32-bit.

except it's the same os, and it runs both 32 and 64 bit apps the same
time.

THAT's the test I'll accept.

it's been done,

Where?

adobe, intel, and by many many users.

Bull****ting isn't evidence.

i know what i and others have seen and your telling me otherwise is
bull****.

On 5/30/2011 11:07 PM, Mxsmanic wrote:
PeterN writes:

So you are saying that a machine with a 1,200 front side bus won't be
any faster than the identical machine with a 400 front side bus.
(both machines theoretical, of course.)

It depends on what it's doing. If it's constrained by the access time of disk
devices, as is often the case for real-world desktop computers (and most other
computers), the bus speed really isn't going to make any significant
difference.

If you watch the behavior of a typical desktop, you see that it's doing a
tremendous number of small I/Os to relatively random locations. This means
that access time is the main bottleneck. High transfer speeds don't help if
the transfer is only 500 bytes. Ten thousand I/Os of 500 bytes are going to be
very slow, no matter what the bus speed might be, because that's ten thousand
times the (extremely slow) access time, if access is random.

Ordering I/Os to minimize access time is difficult in a multiprocessing system
and is also very device-dependent, so that generally doesn't work.

Cache can help, but only if accesses are highly localized so as to raise the
probability of finding the data in cache. If they are completely random and
the cache is small in relation to the database, cache may not make any
difference at all. This reduces the utility of large amounts of RAM, since
excess RAM is often used for disk cache.

Amazing. You won't even admit that the bus can be a choke point. Yes
disk I/O and memory swap can also be choke points.

--
Peter

On 5/28/11 PDT 3:49 PM, Savageduck wrote:
On 2011-05-28 13:31:13 -0700, (Ray Fischer) said:

Savageduck wrote:
On 2011-05-28 11:56:19 -0700, John McWilliams said

On my Mac with 8GB RAM and 5.2GB allocated to CS5, and on my MacBook
Pro with 4GB and a 2.7GB CS5 RAM allocation I have experienced a
considerable speed up of all 64 bit CS5 processes vs. 32 bit.

But those aren't equal comparisons. You're using very large image
files that requite a lot of memory and stating that more memory lets
Photoshop run faster. That's not the same as 32-bit vs. 64-bit.

Actually the image files are all D300s NEF's which remain in the
18.5-20.5 MB range.

I have provided my machines with 8GB & 4GB of RAM respectively for my
iMac & MacBook Pro, allocating 73% of available RAM to Photoshop. Prior
to upgrading to 64 bit CS5, I was running a 32 bit CS version with the
same 73% RAM allocation, processing the same size NEF files.
My workflow remains the same and I am quite able to make an evaluation
of the process performance improvement between the two versions of CS
installed on each of my computers.

...and yes, more free RAM does help improve the performance of any
version of Photoshop by reducing writing to, and reading from the
scratch disc. Just try working with a large number of layers with
minimum RAM. With minimum RAM any version of CS, 32 or 64 bit will grind
away using I/O to the scratch disc with even just a few layers in use.

Of course. But there is some breakeven point of RAM in a given machine
where 32 bit will run a bit better than 64. You are well above such a
point, and I suspect said point is now..................


pointless.

On 2011-05-31 20:04:58 -0700, John McWilliams said:

On 5/28/11 PDT 3:49 PM, Savageduck wrote:
On 2011-05-28 13:31:13 -0700, (Ray Fischer) said:

Savageduck wrote:
On 2011-05-28 11:56:19 -0700, John McWilliams said

On my Mac with 8GB RAM and 5.2GB allocated to CS5, and on my MacBook
Pro with 4GB and a 2.7GB CS5 RAM allocation I have experienced a
considerable speed up of all 64 bit CS5 processes vs. 32 bit.

But those aren't equal comparisons. You're using very large image
files that requite a lot of memory and stating that more memory lets
Photoshop run faster. That's not the same as 32-bit vs. 64-bit.

Actually the image files are all D300s NEF's which remain in the
18.5-20.5 MB range.

I have provided my machines with 8GB & 4GB of RAM respectively for my
iMac & MacBook Pro, allocating 73% of available RAM to Photoshop. Prior
to upgrading to 64 bit CS5, I was running a 32 bit CS version with the
same 73% RAM allocation, processing the same size NEF files.
My workflow remains the same and I am quite able to make an evaluation
of the process performance improvement between the two versions of CS
installed on each of my computers.

...and yes, more free RAM does help improve the performance of any
version of Photoshop by reducing writing to, and reading from the
scratch disc. Just try working with a large number of layers with
minimum RAM. With minimum RAM any version of CS, 32 or 64 bit will grind
away using I/O to the scratch disc with even just a few layers in use.

Of course. But there is some breakeven point of RAM in a given machine
where 32 bit will run a bit better than 64. You are well above such a
point, and I suspect said point is now..................


pointless.

So I guess I don't really need to concern myself with this debate any
more, as I find myself beyond this "break even point" and the virtual
line drawn in the processor sand. So I can just sit back and enjoy the
performance benefit of having plentiful RAM and CS5 in 64 bit mode
running on a 64bit system.
I am certainly experiencing better performance with the 64 bit mode CS
vs. the 32 bit version on my set up.


--
Regards,

Savageduck