• Make "Simplex" the default tonemapper (because of computational requirements of "Compressor").

• Save file dialog: delete file name when closing the project.
• Tone Mapping: modified the value range of Black and White Point sliders in order to avoid possible display problems.
• OS X: Tone Mapping: locking problem caused crashes when handling curve points.
• Application could crash when pressing the main window "Close" button while processing is going on.
• Disable curve control function to change axis ranges via first/last curve point. While this functionality is handy it puts restrictions to the first/last curve points.
  

• Windows OS: http://fdrtools.com/FDRToolsAdvanced240beta6.msi
• OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced240beta6_i386.dmg
• OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced240beta6_PPC.dmg
  

• Integrate HDR and LDR save dialogs.
• Create replacement for former HDR Inspector view. Consider HDR as a special case of tone mapping, i.e. identity mapping.
• Augment curve control capabilities by allowing to change y-axis range interactively.
• Add new controls to tone mapping dialogs (Exposure, Dynamic Range, Black Point, White Point).
• Add possibility to modify "image resolution" metadata fields prior to saving the resulting image.
• Color space of HDR image is now configurable.
• Preview zoom range extended to 400%.
• Module xDOF temporarily removed. xDOF makes real sense only with comprehensive image alignment which is not there yet. I'm sorry.
  

• Zoomed view could crash when dragging the scrollbars (related to multi threading changes).
• Make controls in alignment and HDR creation modules responsive.
• Remove blockade between push and drag events in curve widgets.
• Pink highlight problem of some Canon 50D cameras fixed.
• Problem reading project files of future FDRTools versions fixed.
• Program crashed when pressing the Close button of the main window during a computation.
• Various issues of the White Balance tool solved. The issues are mostly related to multithreading support introduced with v2.4.0.
  

• Integration of former 'Navigator' and 'Preview' windows.
• Integration of former 'Progress' window with the Main window.
• Make controls "responsive". E.g. when dragging a slider the screen is updated without the need to release the slider.
• Performance: reduced memory usage, especially when working with many source images.
• Performance: optimisations in tone mapping modules.
  

• Reading 16 bit TIFF images could crash the program.
• Memory leaks fixed.
• Fixed potential crash situations caused by introducing multithreading.
  

• Performance: several optimizations in order to speed up algorithmic calculations and image loading.
• Preferences: added feature to detect system display profile. If enabled the detected profile is used instead of the manually configured profile.
  

• "Out of memory" message close button showed no reaction hence application couldn't terminate.
• Quick repeated use of the white balance tool pipette freezes the program.
• Receptor tone mapper had a bug introduced in the course of the modifications for v2.4.0.
• Projects: added missing parameters and repaired unsaved check.
• Switching among HDR generators could cause a crash in certain situations.
  

• Program crashed when trying to read project files from versions earlier than 2.3
• Once in a while crash on cancelling project changes.
• Coordinates and RGB value within Preview were not displayed correctly.
• Resulting images of integer formats were always scaled to the maximum integer value thereby foiling deliberate downscaling by the user.
• Images were not correctly "prepared". When reading prepared images histograms were missing alongside other side effects.
• Histograms were not always drawn correctly - missing histograms or flickering.
• Redraw behaviour of Preview had a few shortcomings.
• Drawing of tabs has been slightly modified.
• "Color Plus" button was activated when pressing "Defaults" with only one image loaded.
  

• Ability to process large images.
• Support for multicore processors / multiprocessor systems.
• New controls broaden the tone mapping options and allow for more precise adjustments.

• Reading project files of future FDRTools versions (e.g. the 2.4.0 Beta versions) crashes the program.

• Windows OS: http://fdrtools.com/FDRToolsAdvanced233.msi
• OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced233_i386.dmg
• OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced233_PPC.dmg
  

Is there a way to maintain existing file names on import to the projects?

When rendering a batch of projects what are the edit settings and can these be
adjusted or saved?

Thank you,
Steven Poe

What do you mean with "maintain"? If you mean that the default project
name should be derived from the image names somehow the answer is no -
not yet, but it is on the todo list. The same does apply to the default
name for saving the result.

When you create a project it gets the default settings. By editing a
newly created project you can find out what this means. If you modify
parameter settings the modifications are saved to the project when you
leave the editor. If you want to apply identical settings to several
projects you can create project "templates" with the settings you like
and then apply them to a selection of projects.

Regards,
Andreas Schömann

Andreas,

Thanks. Yes, that what I meant by the file name. Can't wait for the update for
this.

One more question. I'm importing from two sources. DNG's from a Nikon D3 with no
issues. DNG's from a Nikon D3x won't import and result in "?" in the project
thumbnails. Are there some DNG setting not supported?

Thank you,
Steven Poe



--- In fdrtools@yahoogroups.com, Andreas Schömann <kontakt@...> wrote:
>
> What do you mean with "maintain"? If you mean that the default project
> name should be derived from the image names somehow the answer is no -
> not yet, but it is on the todo list. The same does apply to the default
> name for saving the result.
>
> When you create a project it gets the default settings. By editing a
> newly created project you can find out what this means. If you modify
> parameter settings the modifications are saved to the project when you
> leave the editor. If you want to apply identical settings to several
> projects you can create project "templates" with the settings you like
> and then apply them to a selection of projects.
>
> Regards,
> Andreas Schömann
>

 

Andreas,

Thanks. Yes, that what I meant by the file name. Can't wait for the update for this.

One more question. I'm importing from two sources. DNG's from a Nikon D3 with no issues. DNG's from a Nikon D3x won't import and result in "?" in the project thumbnails. Are there some DNG setting not supported?

• Tone Mapping: added slider "Color Contrast" to the Compressor module. Color Contrast allows to adapt the contrast of colored regions.

• OS X: Navigator/Preview: scrolling the image in Preview mode can crash the program.
• Navigator/Preview: dragging the image in Preview mode is sluggish.
• Navigator/Preview: correct Preview scale slider range so that zoom value increases from left to right.
  
• Projects: exiting FDRTools after modifying the project name without leaving the name text field looses the modifications.
• Tone Mapping: curve control has a problem drawing first and last knot under certain conditions.
• Tone Mapping: correct Receptor Compression range.
• Gui: opening the Save Image dialog via the "Images->Save as..." menu entry crashes the program.
  

• Windows OS: http://fdrtools.com/FDRToolsAdvanced240.msi
• OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced240_i386.dmg
• OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced240_PPC.dmg
  

• Make "Simplex" the default tonemapper (because of computational requirements of "Compressor").

• Save file dialog: delete file name when closing the project.
• Tone Mapping: modified the value range of Black and White Point sliders in order to avoid possible display problems.
• OS X: Tone Mapping: locking problem caused crashes when handling curve points.
• Application could crash when pressing the main window "Close" button while processing is going on.
• Disable curve control function to change axis ranges via first/last curve point. While this functionality is handy it puts restrictions to the first/last curve points.
  

• Integrate HDR and LDR save dialogs.
• Create replacement for former HDR Inspector view. Consider HDR as a special case of tone mapping, i.e. identity mapping.
• Augment curve control capabilities by allowing to change y-axis range interactively.
• Add new controls to tone mapping dialogs (Exposure, Dynamic Range, Black Point, White Point).
• Add possibility to modify "image resolution" metadata fields prior to saving the resulting image.
• Color space of HDR image is now configurable.
• Preview zoom range extended to 400%.
• Module xDOF temporarily removed. xDOF makes real sense only with comprehensive image alignment which is not there yet. I'm sorry.
  

• Zoomed view could crash when dragging the scrollbars (related to multi threading changes).
• Make controls in alignment and HDR creation modules responsive.
• Remove blockade between push and drag events in curve widgets.
• Pink highlight problem of some Canon 50D cameras fixed.
• Problem reading project files of future FDRTools versions fixed.
• Program crashed when pressing the Close button of the main window during a computation.
• Various issues of the White Balance tool solved. The issues are mostly related to multithreading support introduced with v2.4.0.
  

• Integration of former 'Navigator' and 'Preview' windows.
• Integration of former 'Progress' window with the Main window.
• Make controls "responsive". E.g. when dragging a slider the screen is updated without the need to release the slider.
• Performance: reduced memory usage, especially when working with many source images.
• Performance: optimisations in tone mapping modules.
  

• Reading 16 bit TIFF images could crash the program.
• Memory leaks fixed.
• Fixed potential crash situations caused by introducing multithreading.
  

• Performance: several optimizations in order to speed up algorithmic calculations and image loading.
• Preferences: added feature to detect system display profile. If enabled the detected profile is used instead of the manually configured profile.
  

• "Out of memory" message close button showed no reaction hence application couldn't terminate.
• Quick repeated use of the white balance tool pipette freezes the program.
• Receptor tone mapper had a bug introduced in the course of the modifications for v2.4.0.
• Projects: added missing parameters and repaired unsaved check.
• Switching among HDR generators could cause a crash in certain situations.
  

• Program crashed when trying to read project files from versions earlier than 2.3
• Once in a while crash on cancelling project changes.
• Coordinates and RGB value within Preview were not displayed correctly.
• Resulting images of integer formats were always scaled to the maximum integer value thereby foiling deliberate downscaling by the user.
• Images were not correctly "prepared". When reading prepared images histograms were missing alongside other side effects.
• Histograms were not always drawn correctly - missing histograms or flickering.
• Redraw behaviour of Preview had a few shortcomings.
• Drawing of tabs has been slightly modified.
• "Color Plus" button was activated when pressing "Defaults" with only one image loaded.
  

• Ability to process large images.
• Support for multicore processors / multiprocessor systems.
• New controls broaden the tone mapping options and allow for more precise adjustments.

Am 24.01.2011 17:23, schrieb Andreas Schömann:
> # Windows OS: http://fdrtools.com/FDRToolsAdvanced240.msi
> # OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced240_i386.dmg
> # OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced240_PPC.dmg

These URLs are correct, but the links point to the beta6 versions, which
give a 404 error...

(disadvantage of HTML posts ;-)

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

Am 24.01.2011 20:20, schrieb Erik Krause:
> Am 24.01.2011 17:23, schrieb Andreas Schömann:
>> # Windows OS: http://fdrtools.com/FDRToolsAdvanced240.msi
>> # OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced240_i386.dmg
>> # OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced240_PPC.dmg
> These URLs are correct, but the links point to the beta6 versions, which
> give a 404 error...
>
> (disadvantage of HTML posts ;-)
>


I'm sorry. Will do better next time.

Regards,
Andreas Schömann

Hi Andreas,

using 2.4.0 I have just had a crash as follows:

Process:         FDRTools [2356]
Path:            /Applications/FDRTools Advanced-2.4.0
release/FDRTools.app/Contents/MacOS/FDRTools
Identifier:      com.fdrtools.fdrgui
Version:         ??? (2.4.0)
Code Type:       X86 (Native)
Parent Process:  launchd [138]

Date/Time:       2011-01-26 20:59:58.996 +0000
OS Version:      Mac OS X 10.6.6 (10J567)
Report Version:  6

Interval Since Last Report:          358559 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  3534 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      BB912A8B-9FCB-46F8-A009-88A41843C936

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000017
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.fdrtools.fdrgui            0x0030f9c2 std::_Rb_tree<Channel,
std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const,
double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> >
>::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 114
1   com.fdrtools.fdrgui            0x0030fa04 std::_Rb_tree<Channel,
std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const,
double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> >
>::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180
2   com.fdrtools.fdrgui            0x0030fa04 std::_Rb_tree<Channel,
std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const,
double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> >
>::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180
3   com.fdrtools.fdrgui            0x0030fa04 std::_Rb_tree<Channel,
std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const,
double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> >
>::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180

This happened after trying to quit the Save dialogue (saved once but the save
dialogue didn't go away).

Kind regards

Roger
On 24 Jan 2011, at 21:04, Andreas Schömann wrote:

> Am 24.01.2011 20:20, schrieb Erik Krause:
>> Am 24.01.2011 17:23, schrieb Andreas Schömann:
>>> # Windows OS: http://fdrtools.com/FDRToolsAdvanced240.msi
>>> # OS X, Mac Intel: http://fdrtools.com/FDRToolsAdvanced240_i386.dmg
>>> # OS X, Mac PowerPC: http://fdrtools.com/FDRToolsAdvanced240_PPC.dmg
>> These URLs are correct, but the links point to the beta6 versions, which
>> give a 404 error...
>>
>> (disadvantage of HTML posts ;-)
>>
>
>
> I'm sorry. Will do better next time.
>
> Regards,
> Andreas Schömann
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

 

Hi Andreas,

using 2.4.0 I have just had a crash as follows:

Process: FDRTools [2356]
Path: /Applications/FDRTools Advanced-2.4.0 release/FDRTools.app/Contents/MacOS/FDRTools
Identifier: com.fdrtools.fdrgui
Version: ??? (2.4.0)
Code Type: X86 (Native)
Parent Process: launchd [138]

Date/Time: 2011-01-26 20:59:58.996 +0000
OS Version: Mac OS X 10.6.6 (10J567)
Report Version: 6

Interval Since Last Report: 358559 sec
Crashes Since Last Report: 1
Per-App Interval Since Last Report: 3534 sec
Per-App Crashes Since Last Report: 1
Anonymous UUID: BB912A8B-9FCB-46F8-A009-88A41843C936

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000017
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.fdrtools.fdrgui 0x0030f9c2 std::_Rb_tree<Channel, std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const, double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> > >::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 114
1 com.fdrtools.fdrgui 0x0030fa04 std::_Rb_tree<Channel, std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const, double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> > >::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180
2 com.fdrtools.fdrgui 0x0030fa04 std::_Rb_tree<Channel, std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const, double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> > >::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180
3 com.fdrtools.fdrgui 0x0030fa04 std::_Rb_tree<Channel, std::pair<Channel const, double>, std::_Select1st<std::pair<Channel const, double> >, std::less<Channel>, std::allocator<std::pair<Channel const, double> > >::_M_erase(std::_Rb_tree_node<std::pair<Channel const, double> >*) + 180

This happened after trying to quit the Save dialogue (saved once but the save dialogue didn't go away).

Kind regards

Roger.

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
>