[hugin-ptx] Enfuse 4.1.1 CIECAM bug?

2013-10-07 Thread dkloi
I've been trying to track down a problem with enblended images suffering a 
lack of contrast with respect to the remapped images. It seems that I am 
not the only one experiencing this problem and it is due to the CIECAM 
blending default option for input images with colour profiles. 

Example: http://www.flickr.com/photos/48606216@N00/10135641463/ The area 
shown is not in an overlapping region so no blending should occur. The 
input image looks exactly like the right hand side when CIECAM blending 
mode is turned off. The left shows a lightening of the shadows with the 
default options. Enblend 4.1.1 Windows 64-bit version from Sourceforge. 
Windows 7 64 bit 16GB RAM, i7 3770. Lightroom 4.4 and PWP 6.0.10 64 bit.

Is the problem due to the forward and reverse mappings of the input colour 
space to CIECAM02 not being inverse? I would have expected that a 
non-overlapping region should be mapped in the output to exactly the same 
values as the input but this doesn't seem to be the case with the CIECAM 
blending mode.

Daniel.

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
hugin and other free panoramic software group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/05709ecf-3aa7-431d-b092-41e5f9f0f416%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [hugin-ptx] Enfuse 4.1.1 CIECAM bug?

2013-10-07 Thread Bruno Postle
On 7 October 2013 12:07, dkloi dkl...@googlemail.com wrote:


 Is the problem due to the forward and reverse mappings of the input colour
 space to CIECAM02 not being inverse? I would have expected that a
 non-overlapping region should be mapped in the output to exactly the same
 values as the input but this doesn't seem to be the case with the CIECAM
 blending mode.


I don't have an explanation for the difference, but enblend _will_ alter
values in non-overlapping areas - The width of the blend is determined by
the number of blending levels, so if you want to rule out the blending
itself as the source of the problem then you can temporarily set this to -l
1

-- 
Bruno

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
hugin and other free panoramic software group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZgoFjNDUABODjWMYozvpB3bOaFoEBQqzcRWUmGi%2Btuduw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [hugin-ptx] Re: Building with Windows

2013-10-07 Thread T. Modes

Hi Frederic,

Am Sonntag, 6. Oktober 2013 20:02:20 UTC+2 schrieb Frederic Da Vitoria:


 The SDK first refused to install, just like the first time it installed. 
 Like the first time, I had to remove the C++ 2010 redistributables in order 
 to reach the window where I could check which options were about to be 
 installed. When checking the compilers, I noted that the checkbox was not 
 working properly: it never unchecks itself. But I also noted that the 
 required space varied and I deduced that when the required space was larger 
 it meant the compilers would be installed. Anyhow, which ever option I 
 chose, this does not work, and opening the SDK prompt gives the message: 
 The x64 compilers are not currently installed. Please go to Add/Remove 
 Programs to update your installation. I googled this and found a solution  
 ( 
 http://connect.microsoft.com/VisualStudio/feedback/details/683852/fail-to-install-windows-sdk-to-add-x64-cross-compiler-to-visual-c-2010-express-running-on-x86-pc-based)
  telling me not to install the compilers with the SDK but install the 
 compiler SP after. This is what I did. I managed to compile STLport with no 
 error and 45 warnings. I now understand that I don't need this step, 
 Thomas, but that was a few days ago.


I installed the SDK and the compiler update some time ago and could not 
remember all details anymore.  (I found this: 
http://blogs.msdn.com/b/vcblog/archive/2011/03/31/10148110.aspx Don't know, 
if this helps. But I have also the compiler update installed.)


 Now I am stuck a little further down the road: I am at the lcms step (once 
 again, I now know this is not necessary, but I believe the issues I find 
 here will block me further anyhow). In Visual C++, I select lcms, 
 right-click and chose the properties. I can change the configuration to 
 Release but the only Platform offered is Win32. 

 This is relatively easy: in the platform dropdown select the configuration 
manager (I have only a German version, I'm not sure about the English 
words). Under active platform select new and there then x64.
Close the dialog. Now open the properties of each project (right mouse 
button) and change the platform toolset (under General) to Windows SDK 
7.1. This must be done for all projects in the project map. This is some 
work, but needs to be done only once. (For other libs some more changes are 
necessary.).

Thomas
 

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
hugin and other free panoramic software group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/3c83413b-6e66-4502-8789-29744f932ae1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [hugin-ptx] Enfuse 4.1.1 CIECAM bug?

2013-10-07 Thread dkloi
Thanks for the tip about the blending levels. However, even with only a 
single blending level I get the same lightening of the shadows with the 
default options. I found a previous 
post https://groups.google.com/d/msg/hugin-ptx/354rmYe12fA/4cLfTrny11kJ 
that indicates that the problem could lie with LCMS.

Just noticed 4.1.2 on Sourceforge. Just tried it but it looks like it 
behaves the same as 4.1.1.

On Monday, October 7, 2013 1:45:05 PM UTC+1, Bruno Postle wrote:

 On 7 October 2013 12:07, dkloi dkl...@googlemail.com javascript:wrote:


 Is the problem due to the forward and reverse mappings of the input 
 colour space to CIECAM02 not being inverse? I would have expected that a 
 non-overlapping region should be mapped in the output to exactly the same 
 values as the input but this doesn't seem to be the case with the CIECAM 
 blending mode.


 I don't have an explanation for the difference, but enblend _will_ alter 
 values in non-overlapping areas - The width of the blend is determined by 
 the number of blending levels, so if you want to rule out the blending 
 itself as the source of the problem then you can temporarily set this to -l 
 1 

 -- 
 Bruno 


-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
hugin and other free panoramic software group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/118b8c56-4a33-41fc-8d5c-72a44038b69b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [hugin-ptx] Re: Possible Hugin bug in control points tab

2013-10-07 Thread Thomas Pryds
Den 07/10/2013 18.19 skrev T. Modes thomas.mo...@gmx.de:
 These are 2 different repository. It is not only a different address for
the same repository.
 After the update of sourceforge I assumed that the old repo is read only.
But it is still writeable, and there were an accidental push to the old
repo.

In another project that I'm following, they handled a similar repo change
by removing all files in the old repo, replacing them with a single README,
briefly explaining about the new location of the repo. Given the nature of
mercurial/hg, the old chances will not be lost.

Thomas P

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
hugin and other free panoramic software group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAOC2i36oKRgv3MQ55NKzP55Yh44D%2BryLZGj3TimDXiaEpnsyvw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.