Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > My afternoon

Reply
Thread Tools

My afternoon

 
 
PeterN
Guest
Posts: n/a
 
      05-25-2013
On 5/25/2013 3:08 PM, Floyd L. Davidson wrote:
> PeterN <(E-Mail Removed)> wrote:
>> On 5/25/2013 2:38 PM, Savageduck wrote:
>>> On 2013-05-25 01:01:33 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (Floyd L. Davidson) said:
>>>
>>>> Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:
>>>>> On 2013-05-24 16:27:06 -0700, (E-Mail Removed) (Floyd L. Davidson) said:
>>>>>
>>>>>> Tony Cooper <(E-Mail Removed)> wrote:
>>>>>>>
>>>>>>> Well, you certainly did a good job of making those dust spots
>>>>>>> (primarily at almost 3 o'clock, but also in other places) much sharper
>>>>>>> and more apparent.
>>>>>>
>>>>>> Another less than astute observer told Peter there were
>>>>>> dust spots, and Peter correctly stated, "After reading your
>>>>>> post I looked, and there is no dust on the sensor."
>>>>>>
>>>>>> If you actually do think you see dust spots, feel free
>>>>>> to download the image and draw a circle around a couple
>>>>>> of these spots before reposting, and I or someone will
>>>>>> be happy to explain what you are seeing.
>>>>>>
>>>>>>> A few more "improvements" and the image will be completely trashed.
>>>>>>
>>>>>> Are the "dust spots" merely the shades of jealousy that
>>>>>> cloud your eyes so often.
>>>>>
>>>>> I found four questionable spots, whether it was dust, or
>>>>> the infamous D800 oil/metal/plastics shavings issue or
>>>>> not, it was well outside the crop area the three of us
>>>>> used to work on our versions.
>>>>> < https://dl.dropbox.com/u/1295663/Fil...326-spotsw.jpg >
>>>>
>>>> Those are in fact "dust spots". They are easy enough to
>>>> clone out, and will probably go away if the camera is
>>>> configured to do a "sensor cleaning" routine every time
>>>> it is turned on, though perhaps not.
>>>>
>>>> Regardless, none are "at almost 3 o'clock" even in the
>>>> original, much less in the cropped version that I
>>>> posted.
>>>>
>>>> We have a couple people that can't be serious because
>>>> they don't have anything to contribute but have to say
>>>> something about anything.
>>>
>>> As I said none of the spots, dust or otherwise, were in the cropped area
>>> we worked on.
>>>

>>
>> I am quite concerned if they are dust spots, which is
>> why I posted the immediately proceeding frame.

>
> What's to be concerned about? Dust happens.
>
> Configure your D800 to automatically clean the sensor
> when it is turned on or off. See page 396 of the
> printed manual.
>


It has been that way since day 1. As is my D300.


--
PeterN
 
Reply With Quote
 
 
 
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-25-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>Floyd L. Davidson <(E-Mail Removed)> wrote:


>>> The UNIX kernel and the various UNIX filesystems have
>>> *never* disallowed characters such as quotes and spaces.
>>> The only two characters that are (and always were)
>>> disallowed are a NUL character and the backslash.


>>$ touch example\\file
>>$ ls exa*
>>example\file
>>$


>>Care to try again?


> I'm sorry that you can't read through the rather obvious
> typo. It isn't a backslash, it's the forward slash,
> that is not allowed.


I'm sorry you still are wrong. The various UNIX filesystems
don't disallow the forward slash:

$ mkdir test/
$ touch test/file
$ ls test/file
test/file
$

Care to try again?

-Wolfgang
 
Reply With Quote
 
 
 
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-25-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:

> And the noise that is visible in the sky is Photon
> Noise.


If photon noise comes in 8x8 blocks, then yes.

> It is to some small degree made worse by using a
> higher ISO, but the significance is very slight,


So you're saying photon noise does not change significantly
if you collect 16 times more photons (i.e. ISO 100 instead of
ISO 1600)?

Wanna try again?

-Wolfgang
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      05-26-2013
In article <(E-Mail Removed)>, Floyd L. Davidson
<(E-Mail Removed)> wrote:

> >> It isn't correct to say that "unix" treats spaces as a
> >> delimiter. The UNIX kernel (and UNIX filesystems) do
> >> not.

> >
> >this isn't about the kernel.

>
> It's about the filesystem as well.


no it isn't. it's about the user deciding whether or not to use a space
in a file name.

> Note that any given command line shell you choose to use
> on Linux, UNIX or whatever is also available for Windows
> and Mac platforms too, and will have *exactly* the same
> quoting requirements under every OS.


mac and windows users don't normally use a command line.

unix users frequently do.

> >as far as the user is concerned, which is the only thing that matters
> >when naming a file, spaces are delimiters in unix, which is why they
> >have to be escaped.

>
> The user is not the only thing that matters when naming
> a file.


the user is the *only* thing that matters.

they're the ones who decides what to name a file and having to deal
with escaping spaces in unix.

what goes on under the hood does not matter to the user.

> Many files are created by programs without any
> assist from a user.


so what? this isn't about what name a program decides to use, possibly
for a file the user might never even see.

> . Spaces are not delimiters in
> "unix".


they most certainly are. the following have different results:

the classic example is:
rm foo *
rm foo*

another:
rm abd def
rm "abc def"
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      05-26-2013
In article <(E-Mail Removed)>, J. Clarke
<(E-Mail Removed)> wrote:

> > Note that any given command line shell you choose to use
> > on Linux, UNIX or whatever is also available for Windows
> > and Mac platforms too, and will have *exactly* the same
> > quoting requirements under every OS.

>
> OSX is a shell on top of of a BSD port, so it runs Unix code natively.


os x is *much* more than a shell on top of a bsd port, but it can run
unix code natively.

however, most mac users don't care about unix code (nor should they).
they run mac apps which use mac apis. they probably don't even know
what unix *is*, let alone run unix programs.

> Windows uses "\" instead of "/" as the file system delimeter, and most
> attempts at porting shells from Unix to Windows do not deal with this in
> any kind of graceful manner--they either translate the "\" to "/" which
> plays Hell when they try to pass a path to a native application, or they
> keep it as is which breaks existing scripts. It doesn't help that in
> *nix the "\" is an escape character which has special meaning in most
> shells.


mac actually uses : as the file system delimiter, which originated on
the very first mac. it is the *only* character that is disallowed in
the file system, even on os x.

unix uses / so there's a conversion between / and : under the hood,
depending on which api is used to access files. this is all done deep
within the system and works very well.

> While there are Windows ports of the major *nix shells, to say they
> "will have *exactly* the same quoting requirements" is questionable.


unless it's part of the system itself, it's going to have issues.
 
Reply With Quote
 
nospam
Guest
Posts: n/a
 
      05-26-2013
In article <(E-Mail Removed)>, Floyd L. Davidson
<(E-Mail Removed)> wrote:

> >Windows uses "\" instead of "/" as the file system delimeter, and most
> >attempts at porting shells from Unix to Windows do not deal with this in
> >any kind of graceful manner--they either translate the "\" to "/" which
> >plays Hell when they try to pass a path to a native application, or they
> >keep it as is which breaks existing scripts. It doesn't help that in
> >*nix the "\" is an escape character which has special meaning in most
> >shells.
> >
> >While there are Windows ports of the major *nix shells, to say they
> >"will have *exactly* the same quoting requirements" is questionable.

>
> They have *exactly* the same quoting requirements!


except that mac and windows users don't use shells and do not have to
quote *anything* when accessing files.

when an app puts up a file open dialogue, the user types in a file
name, with or without spaces, and it just works.

> The quoting requirements are not related to characters
> reserved by either the kernel or the filesystem, but are
> instead ways to pass characters *reserved* *by* *the*
> *shell* on to the kernel. Those reserved characters
> have nothing to do with the underlying platform the
> shell is running on.


mac and windows users don't use a shell. they use mac and windows apps.

unix users almost always have a window with a shell and are therefore
subject to its limitations because there's always the chance a space
will cause an issue.

this is never the case on a mac, unless you drop to the unix layer,
which is then subject to all of the limitations of unix.

> Different platforms might very well have different
> delimiters (other than the UNIX NUL and slash
> character), but the shell has no need to quote/escape
> those characters unless they also happen to be reserved
> by the shell for its use to begin with. Notice that on
> Linux and other unixen there is no requirement to escape
> a NUL or a slash to put them into a filename... instead
> it is simply impossible to do, escaped or otherwise.


rm foo*
rm foo *

one of those is going to cause a whole lot more problems than the other.
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-28-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> nospam <(E-Mail Removed)> wrote:
>>In article <(E-Mail Removed)>, Floyd L. Davidson
>><(E-Mail Removed)> wrote:



>>> Note that any given command line shell you choose to use
>>> on Linux, UNIX or whatever is also available for Windows
>>> and Mac platforms too, and will have *exactly* the same
>>> quoting requirements under every OS.


>>mac and windows users don't normally use a command line.


>>unix users frequently do.


> So what? In fact, the exact same significance applies to them
> all.


The significance is that entering a filename with
tab-autocomplete (and having to escape spaces) is a
completely different thing from scrolling through a list and
pointing to one file name, user experience wise.


>>> >as far as the user is concerned, which is the only thing that matters
>>> >when naming a file, spaces are delimiters in unix, which is why they
>>> >have to be escaped.


>>> The user is not the only thing that matters when naming
>>> a file.


>>the user is the *only* thing that matters.


> Once again: that just is not true.


What else matters?


-Wolfgang
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-28-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>Floyd L. Davidson <(E-Mail Removed)> wrote:
>>> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>>>Floyd L. Davidson <(E-Mail Removed)> wrote:


>>>>> The UNIX kernel and the various UNIX filesystems have
>>>>> *never* disallowed characters such as quotes and spaces.
>>>>> The only two characters that are (and always were)
>>>>> disallowed are a NUL character and the backslash.


>>>>$ touch example\\file
>>>>$ ls exa*
>>>>example\file
>>>>$


>>>>Care to try again?


>>> I'm sorry that you can't read through the rather obvious
>>> typo. It isn't a backslash, it's the forward slash,
>>> that is not allowed.


>>I'm sorry you still are wrong. The various UNIX filesystems
>>don't disallow the forward slash:


>>$ mkdir test/
>>$ touch test/file
>>$ ls test/file
>>test/file
>>$


>>Care to try again?


> Are you actually that stupid?


Yes, I am actually that stupid to believe that UNIX filesystems
do have directories.
I am also actually that stupid to read what you actually
did write: Re: "the various UNIX filesystems": "The only two
characters that are (and always were) isallowed are a NUL
character and the backslash." Which is wrong, of course.

Care to try again?

-Wolfgang
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-29-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>Floyd L. Davidson <(E-Mail Removed)> wrote:
>>> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>>>Floyd L. Davidson <(E-Mail Removed)> wrote:


>>>>> And the noise that is visible in the sky is Photon
>>>>> Noise.


>>>>If photon noise comes in 8x8 blocks, then yes.


>>> The noise is not in 8x8 blocks, so no.


>>You are looking at
>> https://dl.dropboxusercontent.com/u/...h%20flying.jpg
>>?


> He provided the NEF file.


And from that you can see that the mottled sky (of 8x8
blocks) as visible in
https://dl.dropboxusercontent.com/u/...h%20flying.jpg
comes from the photon noise?

>>If no, please do.
>>If yes, you need new eyes and a guide dog, new glasses won't
>>help anymore.


> Kinda lost, aren't you...


Oh, I landed a solid hit on you.


>>>>> It is to some small degree made worse by using a
>>>>> higher ISO, but the significance is very slight,


>>>>So you're saying photon noise does not change significantly
>>>>if you collect 16 times more photons (i.e. ISO 100 instead of
>>>>ISO 1600)?


>>>>Wanna try again?


>>> In the particular circumstance, the significance is very
>>> slight.


>>> That should be rather obvious, as the noise is not particularly
>>> a problem. Insignificant noise that is reduced is only a slight
>>> improvement.


>>I can only conclude you're looking at something completely
>>different or have gone bonkers: the mottled sky (according to
>>you) is photon noise, is a particular problem and needs to be
>>reduced drastically for the image to be acceptable for more
>>than a 'that's what I have seen'.


So what is it?

-Wolfgang
 
Reply With Quote
 
Wolfgang Weisselberg
Guest
Posts: n/a
 
      05-29-2013
Floyd L. Davidson <(E-Mail Removed)> wrote:
> Wolfgang Weisselberg <(E-Mail Removed)> wrote:
>>Floyd L. Davidson <(E-Mail Removed)> wrote:
>>> nospam <(E-Mail Removed)> wrote:
>>>>In article <(E-Mail Removed)>, Floyd L. Davidson
>>>><(E-Mail Removed)> wrote:


>>>>> Note that any given command line shell you choose to use
>>>>> on Linux, UNIX or whatever is also available for Windows
>>>>> and Mac platforms too, and will have *exactly* the same
>>>>> quoting requirements under every OS.


>>>>mac and windows users don't normally use a command line.


>>>>unix users frequently do.


>>> So what? In fact, the exact same significance applies to them
>>> all.


>>The significance is that entering a filename with
>>tab-autocomplete (and having to escape spaces) is a
>>completely different thing from scrolling through a list and
>>pointing to one file name, user experience wise.


> Boy is that true! But since both are common for either
> situation, that is a non-sequitur.


"mac and windows users don't normally use a command line" =>
tab-autocomplete is not common for Mac/Windows.

With UNIX it depends on stuff like "is there even a GUI".

So "both are common for either situation" is obviously wrong!


>>>>> >as far as the user is concerned, which is the only thing that matters
>>>>> >when naming a file, spaces are delimiters in unix, which is why they
>>>>> >have to be escaped.


>>>>> The user is not the only thing that matters when naming
>>>>> a file.


>>>>the user is the *only* thing that matters.


>>> Once again: that just is not true.


>>What else matters?


Well?

-Wolfgang
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hello and good afternoon. nevillenevilleson Computer Support 76 07-08-2005 02:36 PM
good afternoon neville nevilleson snr Computer Support 1 06-07-2005 04:23 PM
good afternoon neville Computer Support 10 05-24-2005 10:19 PM
good afternoon neville Computer Support 7 05-24-2005 07:01 PM
OT: Friday afternoon PEBCAK Briscobar MCSE 0 03-11-2005 10:13 PM



Advertisments