Guess I'll hang on to my Hasselblad V
Alan Browne
I'll hang on to it ...
http://www.dpreview.com/news/0907/09070301hasselbladcfv39.asp
Claims no cable is needed. (Many backs use the lens sync signal). Must
expose on detecting light? (brochure says sync cable is only needed for
long ( > 1 s) exposures.
I can't locate a price, but I'm guessing about $25 - $30K.
Rich
wrote:
I think for about $1000 you can adapt some older medium format film
cameras to existing 20-22 megapixel backs which sell used for around
$4000-$6000. I don't know if it can be done with the 500 C/M.
D. Peter Maus
That would be one toy I wouldn't even consider selling. Unless I
was in desperate need of a new liver, or penis transplant or I'd
booked a vacation getaway on Lauren Graham.
Q.G. de Bakker
> Claims no cable is needed. (Many backs use the lens sync signal). Must
> expose on detecting light? (brochure says sync cable is only needed for
> long ( > 1 s) exposures.
Nope.
The pusher rod, tripping the exposed signal in film magazines, is used to
tell the bakc an exposure is imminent.
> I can't locate a price, but I'm guessing about $25 - $30K.
Much, much less.
US$ 14k.
Stefan Patric
When they get the price down to about $1500US (or less) for a full-frame
6x6 back with an easily removable Bayer sensor for "true" b&w, I'll buy
one, but until then, guess I'm staying with film for the old 'Blad. Too
much wishful thinking?
But seriously, as far as I can tell the back only saves in Hasselbald 3F
RAW and TIFF. I'd like to see some JPEG options. At the very least, a
full resolution, high quality one embedded in the RAW file making the
images viewable in any file viewer for quick editing.
Stef
Alan Browne
> On Wed, 08 Jul 2009 17:04:35 +0200, Q.G. de Bakker wrote:
>
>> Alan Browne wrote:
>>
>>> Claims no cable is needed. (Many backs use the lens sync signal).
>>> Must expose on detecting light? (brochure says sync cable is only
>>> needed for long ( > 1 s) exposures.
>> Nope.
>> The pusher rod, tripping the exposed signal in film magazines, is used
>> to tell the bakc an exposure is imminent.
>>
>>> I can't locate a price, but I'm guessing about $25 - $30K.
>> Much, much less.
>> US$ 14k.
This is a new, 39 Mpix back, not the CFV or CFV II.
The current CF 39 back is about $28K (multiple camera types, incl.
Mamiya, Hasselblad, etc.).
>
> When they get the price down to about $1500US (or less) for a full-frame
> 6x6 back with an easily removable Bayer sensor for "true" b&w, I'll buy
> one, but until then, guess I'm staying with film for the old 'Blad. Too
> much wishful thinking?
Used 16 Mpix backs for the 'blad are going for $4 - $8K.
> But seriously, as far as I can tell the back only saves in Hasselbald 3F
> RAW and TIFF. I'd like to see some JPEG options. At the very least, a
DNG in the H2/H3 backs. This one too.
> full resolution, high quality one embedded in the RAW file making the
> images viewable in any file viewer for quick editing.
DNG is viewable in many viewers - embedded thumbnails are JPG (I believe).
Q.G. de Bakker
> This is a new, 39 Mpix back, not the CFV or CFV II.
This is the 'CFV III', called CFV 39.
Same line, current generation.
> The current CF 39 back is about $28K (multiple camera types, incl. Mamiya,
> Hasselblad, etc.).
Yes.
But this one (Hasselblad V-System, hence the "V" in "CFV 39") only is $14K.
Hasselblad is lowering prices. Haven't you noticed?
Yet the price for this next-generationCFV is nearly double that of the
previous one.
Wolfgang Weisselberg
> But seriously, as far as I can tell the back only saves in Hasselbald 3F
> RAW and TIFF. I'd like to see some JPEG options. At the very least, a
> full resolution, high quality one embedded in the RAW file making the
> images viewable in any file viewer for quick editing.
If you need a quick JPEG, it's easy enough to quickly batch
process your RAWs or TIFFs when you import them ...
-Wolfgang
Stefan Patric
Yes, I could, but it's the convenience of it. And if you're editing a
thousand images waiting for the conversion is very time consuming
particularly stressful when you have the art director and client
impatiently waiting, too. Time is money.
However, my guess is there is an embedded JPEG in the RAW, if only a low
res one, for quick image viewing on the digital back's LCD. I have an
old Canon D30 (not 30D) that does that, even though it makes no mention
of such in any official Canon literature.
Stef
Alan Browne
Again, the output of the hassy CFV-39 back (as described here) is
optionally DNG. This opens in most OS' folder displays as a large
thumbnail and of course in many viewers and editors.
Stefan Patric
As understand it, the back only outputs in 3F RAW and TIFF, but Photoshop
can read the 3F files and CONVERT them to DNG. It's the time-wasting
converting I would want to avoid.
I don't know why Hasselblad didn't have embedded JPEGs as an option just
like all other pro digitals do. Although, I would like the option of
having the JPEGs--at whatever resolution and compression I choose--saved
separately at the time the image is created, too. It's just much more
convenient than having to do it separately.
Stef
Alan Browne
Do it via Bridge and it's part of the transfer to the computer. Files
leave the memory card in raw (3F) and are stored as .DNG on the computer
- see below.
>
> I don't know why Hasselblad didn't have embedded JPEGs as an option just
> like all other pro digitals do. Although, I would like the option of
> having the JPEGs--at whatever resolution and compression I choose--saved
> separately at the time the image is created, too. It's just much more
> convenient than having to do it separately.
I read the brochures differently. But even if it is as you say, then
you can do as I do: load onto the computer via Bridge and use that to:
-rename the files (eg: IMG_8754 becomes: "Paris 20090622-0023")
-add some metadata (photographer, copyright, whatever)
-convert to DNG while storing (includes compressed/non-lossy or lossy;
embedded JPG, embedded raw, etc...)
This makes for a longer upload time than a straight file transfer (due
to processing) but everything ends up in a useful format, renamed and
browse-able in Bridge (etc)).
Stefan Patric
>> Stefan Patric wrote:
>>
>> As understand it, the back only outputs in 3F RAW and TIFF, but
>> Photoshop can read the 3F files and CONVERT them to DNG. It's the
>> time-wasting converting I would want to avoid.
>
> Do it via Bridge and it's part of the transfer to the computer. Files
> leave the memory card in raw (3F) and are stored as .DNG on the computer
> - see below.
>
> [snip]
>
> This makes for a longer upload time than a straight file transfer (due
> to processing) but everything ends up in a useful format, renamed and
> browse-able in Bridge (etc)).
You're failing to see my point: I don't want to waste the time
converting regardless of what image format it's converted to just to
decide which images to delete. Most of the time, I don't even have to do
anything else to the remaining RAW files, since that's all most ADs want
from me as final output anyway.
Besides, other medium format digital backs have the imbedded JPEG option,
among others. So, why not Hasselblads'? That's really my point. It
can't be for cost savings. A JPEG license isn't all that expensive.
Also, FWIW, DNG is of no use to me.
Stef
Alan Browne
> On Sat, 11 Jul 2009 15:06:43 -0400, Alan Browne wrote:
>
>>> Stefan Patric wrote:
>>>
>>> As understand it, the back only outputs in 3F RAW and TIFF, but
>>> Photoshop can read the 3F files and CONVERT them to DNG. It's the
>>> time-wasting converting I would want to avoid.
>> Do it via Bridge and it's part of the transfer to the computer. Files
>> leave the memory card in raw (3F) and are stored as .DNG on the computer
>> - see below.
>>
>> [snip]
>>
>> This makes for a longer upload time than a straight file transfer (due
>> to processing) but everything ends up in a useful format, renamed and
>> browse-able in Bridge (etc)).
>
> You're failing to see my point: I don't want to waste the time
> converting regardless of what image format it's converted to just to
> decide which images to delete. Most of the time, I don't even have to do
> anything else to the remaining RAW files, since that's all most ADs want
> from me as final output anyway.
Oh that. In Bridge you will see the images before importing them.
> Besides, other medium format digital backs have the imbedded JPEG option,
> among others. So, why not Hasselblads'? That's really my point. It
> can't be for cost savings. A JPEG license isn't all that expensive.
Free actually. JPEG is beyond patent.
>
> Also, FWIW, DNG is of no use to me.
It's just TIF in a wrapper.
Ray Fischer
> Alan Browne wrote:
>> Again, the output of the hassy CFV-39 back (as described here) is
>> optionally DNG. This opens in most OS' folder displays as a large
>> thumbnail and of course in many viewers and editors.
>
>As understand it, the back only outputs in 3F RAW and TIFF, but Photoshop
>can read the 3F files and CONVERT them to DNG. It's the time-wasting
>converting I would want to avoid.
Smirk. Is that really what's stopping you from buying that gear?
--
Ray Fischer
rfis...@sonic.net
Wolfgang Weisselberg
> On Fri, 10 Jul 2009 12:58:06 +0200, Wolfgang Weisselberg wrote:
>> If you need a quick JPEG, it's easy enough to quickly batch process your
>> RAWs or TIFFs when you import them ...
> Yes, I could, but it's the convenience of it.
You could (have someone) automate it, so it'd be as convenient.
> And if you're editing a
> thousand images waiting for the conversion is very time consuming
You often come back to the computer with new 1.000 images?
> particularly stressful when you have the art director and client
> impatiently waiting, too. Time is money.
... and have the art director and client waiting for you?
> However, my guess is there is an embedded JPEG in the RAW, if only a low
> res one, for quick image viewing on the digital back's LCD. I have an
> old Canon D30 (not 30D) that does that, even though it makes no mention
> of such in any official Canon literature.
How slow *is* dcraw -h for your RAWs?
And did you try dcraw -e yet?
-Wolfgang
Stefan Patric
No. There are others. But in general, if a product fails to meet basic
requirements, why would you buy it? Or, doesn't that make sense to you?
Stef
Stefan Patric
> Stefan Patric <n...@thisaddress.com> wrote:
>> On Fri, 10 Jul 2009 12:58:06 +0200, Wolfgang Weisselberg wrote:
>
>>> If you need a quick JPEG, it's easy enough to quickly batch process
>>> your RAWs or TIFFs when you import them ...
>
>> Yes, I could, but it's the convenience of it.
>
> You could (have someone) automate it, so it'd be as convenient.
Been there. Done that. Never, again.
Why do you think pro DSLRs have built-in the option for a high quality
JPEG in the RAW file or to be saved separately outside it? There must be
a reason, yes? It's to save time! And like they say, time is money.
>> And if you're editing a
>> thousand images waiting for the conversion is very time consuming
>
> You often come back to the computer with new 1.000 images?
Quite often.
Most people who have never shot full time, professionally don't realize
how much pros really shoot. For example, since 2006, for just one
client, I shot over 250,000 exposures, wore out two bodies (shutters
failed), and am on my third one. And I only averaged about 3 days a week
shooting for them 9 to 10 months a year.
>> particularly stressful when you have the art director and client
>> impatiently waiting, too. Time is money.
>
> ... and have the art director and client waiting for you?
Lots of times, they are with you at the shoot.
>> However, my guess is there is an embedded JPEG in the RAW, if only a
>> low res one, for quick image viewing on the digital back's LCD. I have
>> an old Canon D30 (not 30D) that does that, even though it makes no
>> mention of such in any official Canon literature.
>
> How slow *is* dcraw -h for your RAWs? And did you try dcraw -e yet?
As I said above: "Been there. Done that. Never, again."
Stef
Stefan Patric
> Stefan Patric wrote:
>> On Sat, 11 Jul 2009 15:06:43 -0400, Alan Browne wrote:
>>
>>>> Stefan Patric wrote:
>>>>
>>>> As understand it, the back only outputs in 3F RAW and TIFF, but
>>>> Photoshop can read the 3F files and CONVERT them to DNG. It's the
>>>> time-wasting converting I would want to avoid.
>>> Do it via Bridge and it's part of the transfer to the computer. Files
>>> leave the memory card in raw (3F) and are stored as .DNG on the
>>> computer - see below.
>>>
>>> [snip]
>>>
>>> This makes for a longer upload time than a straight file transfer (due
>>> to processing) but everything ends up in a useful format, renamed and
>>> browse-able in Bridge (etc)).
>>
>> You're failing to see my point: I don't want to waste the time
>> converting regardless of what image format it's converted to just to
>> decide which images to delete. Most of the time, I don't even have to
>> do anything else to the remaining RAW files, since that's all most ADs
>> want from me as final output anyway.
>
> Oh that. In Bridge you will see the images before importing them.
If you're seeing the images on the computer screen, they already have
been imported and converted for viewing, just not saved to the hard
drive. Right? No other way.
Besides, I'm a Unix/Linux/BSD, started-with-the-Amiga guy. Don't use
Photoshop (even if it were ported): more app than I will ever need.
Stef
Alan Browne
Whatever works for you is of course your affair. And you're right that
unless the Hassy back embeds a small JPG into the raw file Bridge import
won't preview it to you.
(Note: Mac OS X _is_ UNIX compliant and PS runs under Mac OS X without
the need for X11).
D. Peter Maus
>> And if you're editing a
>> thousand images waiting for the conversion is very time consuming
>
> You often come back to the computer with new 1.000 images?
>
I do. Did this weekend, as well.
I've got an industrial shoot in two locations in 3 weeks. 1000
images will be light.
Q.G. de Bakker
> I do. Did this weekend, as well.
>
> I've got an industrial shoot in two locations in 3 weeks. 1000 images
> will be light.
You keep on shooting until your confidence that something useable might be
among the many shots has grown enough that you dare to stop?
D. Peter Maus
I select my shots. But when I"m shooting industrial, or aerial,
I've got a lot of targets. And photo worthy moments develop VERY
fast. I get multiple interpretations of each target because I'm not
the one who's making the final selection of the images.
My industrials frequently have me shooting 200 or more targets. 4
different angles of each comes to a thousand images pretty quickly.
This coming shoot will be in two cities. The preliminary target
lists already exceed 350 targets. The last time I shot for this
company, there were that many targets in one city alone.
I shot power boat runs on Lake Michigan, last summer. 125 boats.
4 or 5 individual shots of each from various angles, performance
moments, or locations along the course, plus groups...that's more
than 700 alone. Not including unexpected spontaneously developing
photo worthy shots. Like the shots of the leading groups in an ad
hoc formation at high speed with two chase helicopters in frame. I
got several of those.
That shoot took most of the day, about 6 1/2 hours.
You don't want to know about the Motorcycle Ride I shot this weekend.
p
Lots of images. Several cards. Three batteries.
It was a big day. And a blast.
Stefan Patric
> Stefan Patric wrote:
My point. And that's for any viewer, regardless of OS.
My first DSLR was the Canon D30 (not 30D). It had a little 120 x 160
pixel jpeg embedded in its RAW file to view the image on the camera's
LCD; however, because of the image's small size, it was useless for
anything else. So, every time, before I could start my initial editing,
I had to convert every RAW file. What a pain in the butt! And on a 1
GHZ machine with 1.5g RAM, a fairly fast machine for the day, it would
take hours even though I had scripted the process. And the RAWs were
only 3 megs each.
> (Note: Mac OS X _is_ UNIX compliant and PS runs under Mac OS X without
> the need for X11).
Yes. Underneath that flashy Mac GUI with all the eye candy, you'll find
good 'ol NetBSD (http://www.netbsd.org/). And from what I've been told,
besides Mac apps, you can also run BSD and Linux apps, if you have the
appropriate libraries installed. But since I don't own a Mac, I've never
verified this.
Stef
Alan Browne
I think Mac OS X resemblance to BSD has been severely changed over the
years - the kernel is the Mach kernel which is said to replace the BSD
kernel. Many -NIX apps will run under Mac OS X, often with X11 as the
GUI (The Gimp for example).
Stefan Patric
> Stefan Patric wrote:
I don't even think the Mach kernel is still in development by the
originators. Apple, I've read, has taken it over for their own
purposes. Although, I'm sure Mach, in some form or other, is floating
around the open source development community. There are some, me
included, that prefer micro-kernels over Linux and BSD's standard
monolithic ones. They each have their advantages and disadvantages.
Stef
Alan Browne
> On Wed, 15 Jul 2009 16:56:51 -0400, Alan Browne wrote:
>
>> Stefan Patric wrote:
>
>>>> (Note: Mac OS X _is_ UNIX compliant and PS runs under Mac OS X without
>>>> the need for X11).
>>> Yes. Underneath that flashy Mac GUI with all the eye candy, you'll
>>> find good 'ol NetBSD (http://www.netbsd.org/). And from what I've been
>>> told, besides Mac apps, you can also run BSD and Linux apps, if you
>>> have the appropriate libraries installed. But since I don't own a Mac,
>>> I've never verified this.
>> I think Mac OS X resemblance to BSD has been severely changed over the
>> years - the kernel is the Mach kernel which is said to replace the BSD
>> kernel. Many -NIX apps will run under Mac OS X, often with X11 as the
>> GUI (The Gimp for example).
>
> I don't even think the Mach kernel is still in development by the
> originators. Apple, I've read, has taken it over for their own
> purposes.
It would appear. The claim that it is the Mach kernel is from Wikipedia
which is usually reliable for "nerd" input.
> Although, I'm sure Mach, in some form or other, is floating
> around the open source development community. There are some, me
> included, that prefer micro-kernels over Linux and BSD's standard
> monolithic ones. They each have their advantages and disadvantages.
At the level I use them, probably no difference. However one important
change to Mac OS X will come out in the 10.6 release this late summer.
Part of it is to get full benefit of 64 bit processors and the rest,
perhaps more important is for multi core / multi CPU environments. The
OS has changed how tasks are queued for execution in order that
resources be maximized without application programmers needing to worry
much about the target CPU architecture. More:
http://www.apple.com/macosx/technology/#grandcentral
as well as the use of the graphics processor as an additional CPU
(OpenCL) - requires Apps to be compiled for it however. (Same link
above). [Not sure if my machine will support that however].
Wolfgang Weisselberg
> On Mon, 13 Jul 2009 16:08:55 +0200, Wolfgang Weisselberg wrote:
>> You could (have someone) automate it, so it'd be as convenient.
> Been there. Done that. Never, again.
You probably should upgrade your old 386, then.
> Why do you think pro DSLRs have built-in the option for a high quality
> JPEG in the RAW file or to be saved separately outside it?
Because consumer DSLRs offer the same.
Because they already offer JPEG-only in various sizes and
compressions as output. (as do consumer DSLRs)
Because sports shooters can amass serious numbers of shots in
an hour or two and they must be sighted very fast.
> There must be a reason, yes?
Sure. It's called "sales".
> It's to save time! And like they say, time is money.
It's there not to hurt sales. And if you bought a backend that
doesn't support that, well, why did you? Didn't you know your
own needs?
>> You often come back to the computer with new 1.000 images?
> Quite often.
> Most people who have never shot full time, professionally don't realize
> how much pros really shoot.
That depends entirely on what the pros shoot --- I imagine
most of the many-images-per-day pros use DSLRs.
> For example, since 2006, for just one
> client, I shot over 250,000 exposures, wore out two bodies (shutters
> failed), and am on my third one. And I only averaged about 3 days a week
> shooting for them 9 to 10 months a year.
You probably should rethink whose bodies to buy if your shutters
fail that often. But then you are shooting more than a photograph
per minute all the time through if you do 8 hour days --- and
that's only ~500 shots/day.
>> ... and have the art director and client waiting for you?
> Lots of times, they are with you at the shoot.
So your computer is also at the shoot. How about
transferring the images *as they are shot*, using WiFi or
firewire or whatever technology and converting them as they
arrive? That way, no more waiting for slow card readers and
flash memory ... time is money.
Or maybe you should return to your computer more often than
every few days.
>>> However, my guess is there is an embedded JPEG in the RAW, if only a
>>> low res one, for quick image viewing on the digital back's LCD. I have
>>> an old Canon D30 (not 30D) that does that, even though it makes no
>>> mention of such in any official Canon literature.
>> How slow *is* dcraw -h for your RAWs? And did you try dcraw -e yet?
> As I said above: "Been there. Done that. Never, again."
You didn't even *try* to understand what dcraw -e does. Well,
your loss, if your knee jerk reaction forces you to buy a
different backend it's not my problem.
Of course, if you had a backend driven by open source, you
could have asked someone to implement a straight to JPEG
conversion, no problem.
-Wolfgang
D. Peter Maus
> And if you bought a backend that
> doesn't support that, well, why did you? Didn't you know your
> own needs?
That may be the $64,000 question.
Stefan Patric
>> Stefan Patric wrote:
>> I don't even think the Mach kernel is still in development by the
>> originators. Apple, I've read, has taken it over for their own
>> purposes.
>
> It would appear. The claim that it is the Mach kernel is from Wikipedia
> which is usually reliable for "nerd" input.
Apple took the Mach kernel and massaged it to suit its purposes for OS
X. I don't know if that code is available, but under the Open Source
license, it's suppose to be.
>> Although, I'm sure Mach, in some form or other, is floating
>> around the open source development community. There are some, me
>> included, that prefer micro-kernels over Linux and BSD's standard
>> monolithic ones. They each have their advantages and disadvantages.
>
> At the level I use them, probably no difference. However one important
> change to Mac OS X will come out in the 10.6 release this late summer.
Very generally, monolithic kernels work best with servers while micros
are more suitable for desktops.
> Part of it is to get full benefit of 64 bit processors and the rest,
> perhaps more important is for multi core / multi CPU environments. The
> OS has changed how tasks are queued for execution in order that
> resources be maximized without application programmers needing to worry
> much about the target CPU architecture. More:
> http://www.apple.com/macosx/technology/#grandcentral
Sounds like the way cluster supercomputer kernel-OSes work, so that how
the app is distributed and executed through the cluster is transparent to
the user, and doesn't require special compiling of the app itself.
> as well as the use of the graphics processor as an additional CPU
> (OpenCL) - requires Apps to be compiled for it however. (Same link
> above). [Not sure if my machine will support that however].
Don't know about the Mac, but I read a couple years ago, that some team
was working on a Linux kernel that would automatically distribute
execution of the OS, apps, etc. over multi-core/multi-cpus without the
need for custom compile of anything except the kernel.
Ain't progress grand?
Stef
nospam
<n...@thisaddress.com> wrote:
> >> I don't even think the Mach kernel is still in development by the
> >> originators. Apple, I've read, has taken it over for their own
> >> purposes.
> >
> > It would appear. The claim that it is the Mach kernel is from Wikipedia
> > which is usually reliable for "nerd" input.
>
> Apple took the Mach kernel and massaged it to suit its purposes for OS
> X.
actually next did for nextstep/openstep and apple inherited that.
> I don't know if that code is available, but under the Open Source
> license, it's suppose to be.
it's available.