After a short test of the 2.4beta6 I have loaded the final 2.4.

I have 2 projects that I am working on, one using Canon RAW files the other
using 16 TIF.

With the Canon RAW I have had the program crash twice saying out of memory. 
This did not happen with the beta version on the same images.

With the Tiff files although they are numbered XX-a.tif to XX-e in ascending
order of exposure they were derived from a single RAW file.  They do not sort
into exposure or file name order and so do not get into the correct position in
the stack of images for editing.  Also if I try to use the Tone Mapping
Compressor the program stops.  Task manager shows no activity.

My system is AMD quad core in Gigabyte motherboard with 4GB RAM running XP SP3
with all updates.  There are 4 hard disks each with a minimum 60GB free space

Is there any information that I can gather from my system that will help you
debug the problems?
Is there a limit on the size of TIF files?

 

Is there any information that I can gather from my system that will help you debug the problems?

Is there a limit on the size of TIF files?

 

Am 01.02.2011 13:26, schrieb p_cutland:

 

Is there any information that I can gather from my system that will help you debug the problems?

No. Just make me one of your RAW files available please - or at least give me the dimensions of the image. And tell me how many images you tried to process. Then I will try to reproduce it here.

Is there a limit on the size of TIF files?

Sure. FDRTools is still a 32 bit application hence can't address more than 4GB memory on 32 bit OS X. 32 bit Windows is even more restrictive, normally an application can address just 2GB, with the so called "3GB switch" enabled about 3GB - is this switch enabled in your system?

This means: there is limit on the size of a single image, say an HDR panorama. There is a limit also on the number of RAW files of an exposure series that can be processed, depending on the sensor size of the camera. This is because loaded images are kept in memory and additional memory is required to produce the intermediate and final results.

When FDRTools can't allocate enough memory the result will be an error message. This is not a crash. However, there must be an explanation for your problem.

Regards,
Andreas Schömann

PS: I'm currently working on a version for 64 bit operating systems which will solve (most of) these memory problems.

Thank you. I've tested your images on my machine (Vista 64, 8GB).
Measuring the memory requirements I found a maximum of about 2.0 GB.
This is not a problem on my machine but probably is the reason why it
fails on yours.

When viewing the image in Preview mode at 100% about 1.2 GB memory is
used. If you zoom out the program allocates additional memory. I've
measured about 2 GB at 33%. This is caused by the increased precision in
the calculation of the image preview which I have introduced with
version 2.4.0. This is probably the reason why FDRTools runs out of
memory on your machine. The memory consumption is specific to the
Compressor tone mapper.

(Note: in case you want to use more RAWs you should calculate with about
180 MB memory additionaly required per RAW image given the 20 MPixel
image size.)

Things you can do:
- Use the Preview at 100% zoom value. Don't go below. If you need to see
the overview switch to the Navigator.
- If you want/need to stay with XP then activate the 3GB switch.
- Otherwise upgrade to Win7. If you are willing to do this then go for
the 64 bit version. Later on you should add more RAM. The more RAM the
better. This is a general advice but especially important when editing
images.

Regards,
Andreas Schömann

 

Thank you. I've tested your images on my machine (Vista 64, 8GB).
Measuring the memory requirements I found a maximum of about 2.0 GB.
This is not a problem on my machine but probably is the reason why it
fails on yours.

When viewing the image in Preview mode at 100% about 1.2 GB memory is
used. If you zoom out the program allocates additional memory. I've
measured about 2 GB at 33%. This is caused by the increased precision in
the calculation of the image preview which I have introduced with
version 2.4.0. This is probably the reason why FDRTools runs out of
memory on your machine. The memory consumption is specific to the
Compressor tone mapper.

(Note: in case you want to use more RAWs you should calculate with about
180 MB memory additionaly required per RAW image given the 20 MPixel
image size.)

Things you can do:
- Use the Preview at 100% zoom value. Don't go below. If you need to see
the overview switch to the Navigator.
- If you want/need to stay with XP then activate the 3GB switch.
- Otherwise upgrade to Win7. If you are willing to do this then go for
the 64 bit version. Later on you should add more RAM. The more RAM the
better. This is a general advice but especially important when editing
images.

Regards,
Andreas Schömann

 

Andreas,

Thank you.  I tried the 3GB switch but could not get the system to start in that mode.  I have now got my Windows 7 64 bit working, and now have NO problems with crashes or not responding.

  I will now look at installing more RAM to try to get the speed up.

The HDR output from FDRT is a different file dimension than the original camera
RAW files. Is there a setting to keep the pixel dimensions the same as the input
files?

I output 16bit TIF from the render tab and get about 8 to 10 pixels different on
the HDR.

Nikon D3 5120 X 3407 / FDR 5120 X 3399

Nikon D3x 5120 X 3413 / FDR 5120 X 3405


Thanks for your help...
Steven Poe

Normally I don't reply to my own message. I just noticed in the FDR EXIF  window
that it sees a Nikon D3 native file dimension as 4284 X 2844, and every other
pieces of software I have sees the same file as 4256 X 2832.

I assume that is where the issue is, although not sure how to get non-FDR file
to align properly.


--- In fdrtools@yahoogroups.com, "chimpoez" <steven@...> wrote:
>
> The HDR output from FDRT is a different file dimension than the original
camera RAW files. Is there a setting to keep the pixel dimensions the same as
the input files?
>
> I output 16bit TIF from the render tab and get about 8 to 10 pixels different
on the HDR.
>
> Nikon D3 5120 X 3407 / FDR 5120 X 3399
>
> Nikon D3x 5120 X 3413 / FDR 5120 X 3405
>
>
> Thanks for your help...
> Steven Poe
>

 

Normally I don't reply to my own message. I just noticed in the FDR EXIF window that it sees a Nikon D3 native file dimension as 4284 X 2844, and every other pieces of software I have sees the same file as 4256 X 2832.

I assume that is where the issue is, although not sure how to get non-FDR file to align properly.

--- In fdrtools@yahoogroups.com, "chimpoez" <steven@...> wrote:
>
> The HDR output from FDRT is a different file dimension than the original camera RAW files. Is there a setting to keep the pixel dimensions the same as the input files?
>
> I output 16bit TIF from the render tab and get about 8 to 10 pixels different on the HDR.
>
> Nikon D3 5120 X 3407 / FDR 5120 X 3399
>
> Nikon D3x 5120 X 3413 / FDR 5120 X 3405
>
>
> Thanks for your help...
> Steven Poe
>

Yes, there is an alignment problem, because the TIF output from FDR is a
different file dimension than the camera RAW files opened through ACR.


--- In fdrtools@yahoogroups.com, Andreas Schömann <kontakt@...> wrote:
>
> FDRTools utilizes dcraw (http://www.cybercom.net/~dcoffin/dcraw/) to
> develop RAW images and hence can not influence the dimensions of the
> developed image.
>
> The question "Why are dcraw output images larger than camera JPEGs?" is
> answered on Dave Coffin's site. I suppose the same reasoning applies to
> other RAW development software, especially for the camera makers own
> software. Probably they want to comply to the in-camera algorithms and
> drop edge pixels or they think that edge pixels are not usable for other
> reasons.
>
> I have a Nikon D3X RAW file here that results in a developed image of
> 6080x4044 pixels.
>
> The size of the developed image does not influence image alignment
> results. What makes you think so? Do you have a specific alignment problem?
>
> Regards,
> Andreas Schömann
>
>
> Am 09.02.2011 09:06, schrieb chimpoez:
> >
> > Normally I don't reply to my own message. I just noticed in the FDR
> > EXIF window that it sees a Nikon D3 native file dimension as 4284 X
> > 2844, and every other pieces of software I have sees the same file as
> > 4256 X 2832.
> >
> > I assume that is where the issue is, although not sure how to get
> > non-FDR file to align properly.
> >
> > --- In fdrtools@yahoogroups.com <mailto:fdrtools%40yahoogroups.com>,
> > "chimpoez" <steven@> wrote:
> > >
> > > The HDR output from FDRT is a different file dimension than the
> > original camera RAW files. Is there a setting to keep the pixel
> > dimensions the same as the input files?
> > >
> > > I output 16bit TIF from the render tab and get about 8 to 10 pixels
> > different on the HDR.
> > >
> > > Nikon D3 5120 X 3407 / FDR 5120 X 3399
> > >
> > > Nikon D3x 5120 X 3413 / FDR 5120 X 3405
> > >
> > >
> > > Thanks for your help...
> > > Steven Poe
> > >
> >
>

 

Yes, there is an alignment problem, because the TIF output from FDR is a different file dimension than the camera RAW files opened through ACR.

--- In fdrtools@yahoogroups.com, Andreas Schömann <kontakt@...> wrote:
>
> FDRTools utilizes dcraw (http://www.cybercom.net/~dcoffin/dcraw/) to
> develop RAW images and hence can not influence the dimensions of the
> developed image.
>
> The question "Why are dcraw output images larger than camera JPEGs?" is
> answered on Dave Coffin's site. I suppose the same reasoning applies to
> other RAW development software, especially for the camera makers own
> software. Probably they want to comply to the in-camera algorithms and
> drop edge pixels or they think that edge pixels are not usable for other
> reasons.
>
> I have a Nikon D3X RAW file here that results in a developed image of
> 6080x4044 pixels.
>
> The size of the developed image does not influence image alignment
> results. What makes you think so? Do you have a specific alignment problem?
>
> Regards,
> Andreas Schömann

Yes, thats what we are doing now as a make shift bandaid to the problem, and its
not exact.

Even though you have my highest compliments for the delivering the best HDR
image rendering application yet, this could be a deal breaker for a high volume
production line.

Can you help me understand how FDR and ACR (Adobe Camera Raw) output the same
DNG file at different sizes?

Thank you,
Steven Poe




--- In fdrtools@yahoogroups.com, Andreas Schömann <kontakt@...> wrote:
>
> In Photoshop this should be easy to handle using "Auto-Align Layers",
> see
>
http://help.adobe.com/en_US/Photoshop/11.0/WS9ADF1895-A714-4f73-B91C-3A83ED225A7\
7a.html.
>
> An other solution would be to create an action that creates a layered
> document from the two images and shifts one layer by the appropriate
> number of pixels in horizontal and vertical direction.
>
> Does this make sense?
>
> Regards,
> Andreas Schömann
>
>
> Am 09.02.2011 16:17, schrieb chimpoez:
> >
> > Yes, there is an alignment problem, because the TIF output from FDR is
> > a different file dimension than the camera RAW files opened through ACR.
> >
> > --- In fdrtools@yahoogroups.com <mailto:fdrtools%40yahoogroups.com>,
> > Andreas Schömann <kontakt@> wrote:
> > >
> > > FDRTools utilizes dcraw (http://www.cybercom.net/~dcoffin/dcraw/
> > <http://www.cybercom.net/%7Edcoffin/dcraw/>) to
> > > develop RAW images and hence can not influence the dimensions of the
> > > developed image.
> > >
> > > The question "Why are dcraw output images larger than camera JPEGs?" is
> > > answered on Dave Coffin's site. I suppose the same reasoning applies to
> > > other RAW development software, especially for the camera makers own
> > > software. Probably they want to comply to the in-camera algorithms and
> > > drop edge pixels or they think that edge pixels are not usable for
> > other
> > > reasons.
> > >
> > > I have a Nikon D3X RAW file here that results in a developed image of
> > > 6080x4044 pixels.
> > >
> > > The size of the developed image does not influence image alignment
> > > results. What makes you think so? Do you have a specific alignment
> > problem?
> > >
> > > Regards,
> > > Andreas Schömann
> >
>

 

Yes, thats what we are doing now as a make shift bandaid to the problem, and its not exact.

Am 10.02.2011 11:29, schrieb Andreas Schömann:
> It should be exact. I've just tried it with a D3X .dng of a car (it was
> you who send me this image, right?). I developed the RAW with ACR (CS5)
> and with FDR. Then loaded the tone mapped FDR version (size 6080 x 4040)
> into Photoshop, pasted it over the ACR version and shifted the layer 15
> pixels to the left and 6 pixels up. The match is perfect.

There is a program that enables the excessive pixels for ACR as well:
http://www.luminous-landscape.com/contents/DNG-Recover-Edges.shtml

However, I didn't test whether it delivers exactly the same framing as
dcraw.

--
Erik Krause
http://www.erik-krause.de

It seems this tool vanished from the site. Can't find it anymore.

Regards,
Andreas Schömann

Thanks for the tip Erik.

Yes, the LL link is dead. I did find someone who sent me a WIN version of the
DNG Recover Edges app, which we'll test. Although I'm still looking for the Mac
version.

Steven Poe


--- In fdrtools@yahoogroups.com, Andreas Schömann <kontakt@...> wrote:
>
> It seems this tool vanished from the site. Can't find it anymore.
>
> Regards,
> Andreas Schömann
>

Am 12.02.2011 19:43, schrieb chimpoez:
> Although I'm still looking for the Mac version.

->
http://www.luminous-landscape.com/recover_edges/DNG%20Recover%20Edges%20Mac.dmg
short: http://tinyurl.com/4bokngm

download seems to work. Same as

->
http://www.luminous-landscape.com/recover_edges/DNG%20Recover%20Edges%20Win.zip
short: http://tinyurl.com/4wx54rg

for windows.

--
Erik Krause
http://www.erik-krause.de

Thank you Erik. Both of these work and the problem is solved.

Steven Poe


--- In fdrtools@yahoogroups.com, Erik Krause <erik.krause@...> wrote:
>
> Am 12.02.2011 19:43, schrieb chimpoez:
> > Although I'm still looking for the Mac version.
>
> ->
>
http://www.luminous-landscape.com/recover_edges/DNG%20Recover%20Edges%20Mac.dmg
> short: http://tinyurl.com/4bokngm
>
> download seems to work. Same as
>
> ->
>
http://www.luminous-landscape.com/recover_edges/DNG%20Recover%20Edges%20Win.zip
> short: http://tinyurl.com/4wx54rg
>
> for windows.
>
> --
> Erik Krause
> http://www.erik-krause.de
>

hi,

how can i save (and load) compressor or any other settings to apply it on
different projects?

thanks
adsy

 

hi,

how can i save (and load) compressor or any other settings to apply it on different projects?

thanks, andreas. already tried it. but it always starts with the default setup,
so i have to do all the compressor (or other) settings again. even with saved
projects. i write the settings down though, what's actually not a good workflow.
but perhaps i've overlooked something.

regards
adsy

--- In fdrtools@yahoogroups.com, Andreas Sch�mann <kontakt@...> wrote:
>
> Am 18.02.2011 08:37, schrieb adsy_b:
> >
> > hi,
> >
> > how can i save (and load) compressor or any other settings to apply it
> > on different projects?
> >
>
>
> Currently you can not save settings of a module, say Compressor. This
> will be possible with the next version.
>
> What you do can now is create a Template project and copy (all of) its
> settings to other projects. To do this start FDRTools, choose the
> "Templates" tab, create a project, edit and save. Now switch to the
> "Projects" tab, create a project, select it with a left-click, open the
> context menu with a right-click, choose "Copy Template settings to
> selected" and then the name of the template.
>
> Regards,
> Andreas Sch�mann
>

 

thanks, andreas. already tried it. but it always starts with the default setup, so i have to do all the compressor (or other) settings again. even with saved projects.

i write the settings down though, what's actually not a good workflow.
but perhaps i've overlooked something.

regards
adsy

• Detection of installed Photoshop versions does not recognize the latest Photoshop version CS5.

• Windows OS: http://fdrtools.com/FDRCompressorPI303.msi

I suppose you are talking about the 64 bit plug-in version because you have
replied to the "FDRCompressor Plug-In 3.0.3 released" message!? (I'm asking
because replies to previous messages should refer to the topic dicussed in the
thread. If there is no reference please create a new topic.)

Regarding 64 bit versions: there is neither one for the plug-in nor for
FDRTools. The problem is that one external library that both the plug-in and
FDRTools depend upon is not yet available for 64 bit Windows (though it is for
64 bit OS X). I can't help it, just wait for the library people to fix the
problem. I know they are working on it but (as usual) they can't give a release
date. I'm not happy with the situation but try to make the best out of it: while
waiting for the library I'm implementing other stuff that is on the todo list.
I'm sorry I have no better news.



--- In fdrtools@yahoogroups.com, "Geoff Burton" <grb@...> wrote:
>
> Hi
>
>
>
> I'm wondering if there's a 64-bit version of FDRtools in development. Mine
> keeps crashing because it's hitting the 32-bit memory limit.
>
>
>
> Cheers,
>
>
>
> Geoff.
>

Hey guys,

Was wondering if it is possible to run these tools entirely from the command
line?

Michael

Hi Michael,

full control over the functionality from the command line is not
possible. You can only call FDRTools from the command line with a series
of images as parameters. This allows imaging applications to start
FDRTools as an external editor.

Regards,
Andreas Schömann

I have seen some queries in the past.  Is there now or will there soon be a
64-bit plug-in?  Photomatix has had one for a long time now. Would be convenient
to be able to use FDR Tools in my CS5.

Hi,

there is a hurdle in the way to a 64 bit plug-in: FDRTools depends on
several external libraries and one of those libraries is not available
as 64 bit version on the Windows platform.

I can not remove this hurdle easily by myself. My hope was that the
manufacturers of the library would fill the gap and release the 64 bit
version, but nothing so far. The only way to escape this dilemma by
myself would be to drop the library altogether and replace it with
something else. But that would hit me hard: I haven't analysed yet but
it would probably take months to get that job done. So I'm still hesitating.

It would be possible to build a 64 bit OS X plug-in but I don't want to
release something exclusively for one operating system.

So that's the current situation. Currently I'm preparing the next
FDRTools version 2.5.0 (also 32 bit for the same reason). Once this
release is out I will analyse the approximate time and effort for
replacing the mentioned library. Then I will decide what to do.

Regards,
Andreas Schömann

• Tone Mapping: Compressor: "History" resp. "Undo/Redo" functionality added.
• Tone Mapping: Compressor: "Save/Load module state" feature added, also known as "Save/Load settings".
• GUI: improve responsiveness of scrolling in Preview mode.
• GUI: the Preview can now be zoomed via the mousewheel.
• GUI: make selection in the "small" Navigator within Preview moveable by dragging via left mouse button.
• GUI: hide (evtl. visible) Preview when closing a project.
• Projects: derive project name and output file name from input images.
• Preferences: option to configure the program language added.
• Preferences: add "output color space" parameter to "Raw Conversion" tab.
• System: add entry to the Windows registry so that FDRTools executable can be found from other applications.
• External software: "dcraw" updated to v9.10 and "ExifTool" updated to v8.65.

• HDR Creation: Separation: strange colors may occur in regions with moving objects (multithreading related).
• HDR Creation: Separation: color shifts can occur when switching from Exif to Auto and back to Exif.
• HDR Creation: Separation: choosing all color channels as separators causes grain in regions with strong colors.
• HDR Creation: Separation: pressing the 'Defaults' button does not switch off separation mask and does not deselect layers.
• HDR Creation: Separation: with active Separation module the program could crash during image saving.
• HDR Creation: Separation: active separation mask caused crash when switching between tonemapping modules.
• Projects: thumbnails from .dng's were not recognized.
• Projects: project settings are lost if the "Save" dialog is active while the project settings are being saved.
• Tone Mapping: Compressor: Postprocessing curve: changing dynamic range and collapsing the curve caused problems.
• Tone Mapping: Compressor: the label text of slider "Smoothing" is not always redrawn if the tooltip of the "Compressor" slider is being displayed.
• GUI: improve behaviour of the main window Close button.

• GUI: label translations are missing.
• Documentation is missing.

• Windows OS: http://fdrtools.com/FDRToolsAdvanced250beta1.msi
• OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced250beta1.dmg