From: DanP on

> Here's a fun link to browse some of the more popular CHDK P&S-camera photo
> examples <http://fiveprime.org/hivemind/Tags/chdk> The lightning and bird
> shots are particularly interesting, taken with the 45ms-fast
> motion-detection capability of CHDK.- Hide quoted text -

45ms motion detection means nothing when you cannot take more than 1.3
fps.
I am better off taking continuos shots with my DSLR at 3fps. The best
DSLR can achieve up to 10. That is 1 frame nearly every 2*45ms.
Then pick the best shot.

Follow the link above, scroll to the 5th row, click on the last photo,
lightpaint of the guy on the bench with the ball (http://
www.flickr.com/photos/36774021(a)N08/3739744960) and read on what the
guy using CHDK has to say:
"Not perfect but oh well, I'll post it anyway. I'll take all this more
seriously when I get a DSLR, but for now I'm just having fun and
trying stuff."

DanP
From: NameHere on
On Thu, 4 Feb 2010 15:23:39 -0800 (PST), DanP <dan.petre(a)gmail.com> wrote:

>
>> Here's a fun link to browse some of the more popular CHDK P&S-camera photo
>> examples <http://fiveprime.org/hivemind/Tags/chdk> The lightning and bird
>> shots are particularly interesting, taken with the 45ms-fast
>> motion-detection capability of CHDK.- Hide quoted text -
>
>45ms motion detection means nothing when you cannot take more than 1.3
>fps.
>I am better off taking continuos shots with my DSLR at 3fps. The best
>DSLR can achieve up to 10. That is 1 frame nearly every 2*45ms.
>Then pick the best shot.

P&S can attain 10 fps too. That's not the issue here. How many photos are
you going to waste at 10 fps waiting for a decent lightning strike when a
P&S camera can do it without error on the first shot every time. Lightning
strike shots can even be taken in daylight hand-held with a CHDK camera.
Something that is impossible for you to accomplish with any DSLR.

>
>Follow the link above, scroll to the 5th row, click on the last photo,
>lightpaint of the guy on the bench with the ball (http://
>www.flickr.com/photos/36774021(a)N08/3739744960) and read on what the
>guy using CHDK has to say:
>"Not perfect but oh well, I'll post it anyway. I'll take all this more
>seriously when I get a DSLR, but for now I'm just having fun and
>trying stuff."
>
>DanP

Oh wait, let me browse the net and find a post where someone is giving up
on the frailties, dust problems, cost, lost shots from changing lenses, and
weight of their DSLRs, on ad-infinauseum ... Damn, there's so many I can't
decide which of the hundreds of thousands are worth posting here.

You're a troll and a fool. One who has now proved in the worldwide arena
that you can't even use a simple P&S camera properly.

Thanks for playing.



From: Ray Fischer on
LOL! <lol(a)lol.org> wrote:
>On Thu, 04 Feb 2010 14:14:45 +0000, bugbear
><bugbear(a)trim_papermule.co.uk_trim> wrote:
>
>>NameHere wrote:
>>> On Thu, 04 Feb 2010 11:38:59 +0000, bugbear
>>> <bugbear(a)trim_papermule.co.uk_trim> wrote:
>>>
>>
>>> They also do a fine job of
>>> retaining the full dynamic range of the sensor in the JPG file to begin
>>> with.
>>
>>This is trivial; here an alogorithm:
>>
>>RAW 0 -> JEPG 0
>>RAW MAX -> JPEG MAX
>>
>>You speak as if this is some kind of achievment.
>
>Ask any DSLR owner who worships RAW and you'll find out that

.... that you're a lying troll.

--
Ray Fischer
rfischer(a)sonic.net

From: bugbear on
LOL! wrote:
> On Thu, 04 Feb 2010 14:14:45 +0000, bugbear
> <bugbear(a)trim_papermule.co.uk_trim> wrote:
>
>> NameHere wrote:
>>> On Thu, 04 Feb 2010 11:38:59 +0000, bugbear
>>> <bugbear(a)trim_papermule.co.uk_trim> wrote:
>>>
>>> They also do a fine job of
>>> retaining the full dynamic range of the sensor in the JPG file to begin
>>> with.
>> This is trivial; here an alogorithm:
>>
>> RAW 0 -> JEPG 0
>> RAW MAX -> JPEG MAX
>>
>> You speak as if this is some kind of achievment.
>
> Ask any DSLR owner who worships RAW and you'll find out that it is very
> much some kind of major achievement. Apparently none of their cameras are
> capable of something so simple. They're always clamouring how they get two
> or more stops of dynamic range out of the RAW data compared to the JPG file
> their camera can produce. Go ahead, ask them. They're even stupidly willing
> to spend an extra $100-$200 for the required software needed to repair what
> their camera's firmware failed to do correctly in the first place. Then on
> top of that they waste even more valuable hours of their life trying to
> correct all the errors from their camera's firmware on every snapshot they
> take.
>
> LOL!

You've address none of th points I raised,
choosing to attack a group who aren't even
in this thread.

You clearly just want to rant, despite my attempt
to discuss matters of genuine interest.

<END THREAD>
From: NameHere on
On Thu, 04 Feb 2010 14:14:45 +0000, bugbear
<bugbear(a)trim_papermule.co.uk_trim> wrote:

>
>CMYK is a redundant colour space. It's equivalent (pace gamut concerns)
>to RGB.

Wherever did you read this? Must have been one of those "net-truths" that
are so popular. The "net-truths" that float to the top of a Google search
because it's the most plausible and popular, but wrong, explanation for
those who can't think very clearly. The vast majority that don't want to
try to understand nor take the time to educate themselves on anything more
complex. This comprises the majority of all Google search-hits within the
first 3 pages of them which are offered. Someone's feeding you some pretty
good manure and keeping you in the dark. Do you feel like a fungus yet?

When converting my images to CMYK from their RGB sources it's easy to see
how many of the colors are not a match and get shifted. The reverse also
true. Have you never done this in any editor with even something as simple
as a Granger Calibration Chart? The shifts and obvious gaps between the two
color-spaces are astounding.

Here's an example to show you, starting with a 3000x3000 16-bit RGB Granger
Chart as the source. Sorry, I don't have a CMYK Granger-like chart handy to
show you the reverse. It can only be approximated in CMYK anyway. And I've
already wasted far too much of my valuable time trying to educate you to
begin with. Any CMYK to RGB conversion of anything would, of course, show
far less disastrous results. Though, come to think of it, the CMYK to RGB
is already implied in the right-panel because the CMYK space has to be
converted back again to JPG's RGB and your monitor. This would explain the
serious gaps in the colors re-presented.

http://farm5.static.flickr.com/4071/4332259033_c0dced9de7_o.jpg


3 discreet units of information vs. 4 discreet units of information. There
can only be a rough approximation between the two. And you want to argue
about 8 vs. 10 vs. 12 senosr bit-depths while ignoring something even more
simple for an example? Trying to go from RGB to CMYK is like trying to go
from RGB to reconstruct Bayer's RGGB. Though I'll admit, with slightly
less difficulty. Have someone explain to you why you can't reconstruct the
sensor's RGGB data from the resulting RGB file and you'll start to
comprehend why CMYK and RGB are not equivalent. I can't be bothered with
trying to educate someone on something so rudimentary. I've tried that in
the past and it was a painstaking task not unlike trying to teach a worm
how to flip a light switch.

I wasn't going to address the rest of your comments because I was trying to
spare you the embarrassment. So I'll just address this one to show you why
I didn't bother. You can thank me for not addressing the rest of your post.