Activity for pfstools for HDR images
-
Rafal Mantiuk committed [c86069] on Code
Script fixed
-
Merge branch 'master' of ssh://git.code.sf.net/p/pfstools/git
-
Typos. Better handling of matlab paths.
-
Fixed typo
-
Andreas Metzler created ticket #55
Build error against ImageMagick 7
-
Fixed compilation issues.
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
Added: pfstmo_mantiuk08 added --tone-value option. Added: pfstmo_mantiuk08 pass --fps 0 to disable temporal filer
-
Rafal Mantiuk committed [11ff45] on Code
Trying to fix OpenEXR on OSX - it still does not work
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
changes to compile on OSX
-
Rafal Mantiuk committed [71ab24] on Code
Started work to make the code compile on the OSX 14
-
Path is now correctluy escaped
-
Updated doc
-
Fixed typo
-
Alternatively one can update the Cmake module from blender and add some minor changes for the buildsystem. That is what I did in Debian.
-
Fixed mex files compilation issues
-
Added white balance option
-
Fixed bug when using a different pfsin command
-
compilation issues and installation on Ubuntu 22.04 (jammy)
-
Fixed colour space
-
pfsinyuv/pfsoutyuv names of the arguments were changed for the consistency; pfsoutffmpeg updated to use pfsoutyuv. Added HDR presets. Now it is correctly installed.
-
2.1.0 Build error with parallel build
-
Patch applied. Compiles fine on my side.
-
Fixed: linkage issues with octave interface
-
Out-of-bounds access in pfsview_widget
-
Thank you for reporting those. Yes, the LUT had the wrong size and you are right about the condition in L496. This is a very old code so I was not sure why the condition was there in the first place. This should be fixed now.
-
Fixed: pfsview - fixed out-of-bounds errors (thanks to Stefan)
-
Stefan Brüns created ticket #54
FindOpenEXR.cmake incompatible with current OpenEXR
-
Proposed patch
-
Linking pfsglview fails with CMake >= 3.22
-
The following works, and is IMHO the correct way to specify the dependency:
-
https://sourceforge.net/p/pfstools/git/ci/master/tree/src/pfsview/pfsview_widget.cpp#l492 int p = binarySearchPixels( (*R)(index), lutPixFloor, lutSize ); pixel = lutPixel[p]; if( infNaNTreatment == INFNAN_MARK_AS_RED && (p == 0 || p == LUTSIZE+1)) As p converges to lutSize - 1 for large values, and lutSize = 257 * 2 + 1;, this is also an OOB access. So apparently float lutPixFloor[257 * 2 + 1] is correct. Also, p == LUTSIZE + 1 here (L494) should probably read p == lutSize - 1.
-
Out-of-bounds access in pfsview_widget
-
Added: pfsinffmpeg for reading regular and HDR video files
-
Fixed: improved handling of yuv files, pfsinyuv can now read from stdin
-
Updated instruction
-
Rafal Mantiuk committed [81f705]
Fixed: pfsin/outexr now compiles with C++11 as OpenEXR libraries fail with C++17
-
Please provide a point release with all fixes from GIT
-
pfstools 2.2.0 has been just released (long overdue).
-
pfstools 2.2.0 released
-
pfstools for HDR images released /pfstools/2.2.0/pfstools-2.2.0.tgz
-
-
Updated
-
Updated documentation
-
Prepared for release
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
Fixed compilation on Ubuntu 18.04
-
Updated the code and documentation for saturation_offset
-
Compilation fails with GCC11/std=c++17, duplicate "clamp" definition
-
Patched applied and pushed to the master branch. Thanks for the fix.
-
Fixed: compilation fails with GCC11/std=c++17, duplicate clamp definition (thanks to Stefan)
-
Please provide a point release with all fixes from GIT
-
The following patch fixes the issue:
-
Compilation fails with GCC11/std=c++17, duplicate "clamp" definition
-
Removed: pfsinjpeghdr, pfsoutjpeghdr (discontinued)
-
Fixed: pfstmo_durand02 - reversed the old fix that made images over-saturated. Now 99.5th percentile is mapped to white.
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
Eliminated CMake and compilation warnings
-
Fixed return code; removed a warning message.
-
Build failure against new octave 6.2 API
-
Thank you for the patch. It is now applied and merged with master.
-
Fixed: Octave interface upgraded to Octave-6 (thanks to Michal)
-
Michal Suchanek posted a comment on ticket #49
patch
-
Support for Canon RAW files
-
Attempting to transition to ImageMagick-7, incomplete
-
Set default value of saturation-offset
-
Orion Poplawski posted a comment on ticket #49
octave 6.1 has been released and I'm hoping to update it in Fedora. Any chance a patch could be developed soon? Thanks.
-
No, we do not have video tutorials, but you are welcome to contribute some. Best, Rafal
-
Alves R posted a comment on ticket #4
Thank you very much for your feedback. Rafal Mantiuk. My question was about video tutorials. Basic. But little by little I am adapting. Because I found out by researching on the sourceforge the existence of the project. What are the forms of contribution to the project? att, Renato Alves. Em seg., 28 de dez. de 2020 às 17:15, Rafal Mantiuk rafm@users.sourceforge.net escreveu: There are a few examples at: http://pfstools.sourceforge.net/examples.html If could let us know what kind of calibration/...
-
-
There are a few examples at: http://pfstools.sourceforge.net/examples.html If could let us know what kind of calibration/ HDR merging you need to do, we may be able to help.
-
-
-
Added a script to install pfsv
-
Updated instruction
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
Alex Shpilkin posted a comment on ticket #49
FWIW, octave_value::is_map() and similar methods have been deprecated since 4.4 and caused compilation warnings, so maybe the Octave people thought they had already given adequate notice. They were removed in Octave changeset f23f27e78aa2. The deprecation notices (which the changeset removes along with the methods themselves) do mention seemingly straighforward replacements (for is_map(), it’s isstruct()), but I’m not up to doing a patch today, sorry.
-
Tutorials pfscalibration
-
eatdirt created ticket #49
Build failure against new octave 6.2 API
-
Fixed typos; improved docs; removed debug info
-
Merge branch 'master' of ssh://git.code.sf.net/p/pfstools/git
-
Case insensitive when removing matlab from path
-
Merge branch 'master' of ssh://git.code.sf.net/p/pfstools/git
-
added an option to pass extra erguments to pfsin* command
-
Added support for gpuArrays
-
do not use temp so that the code works on cygwin
-
Merge branch 'master' of https://git.code.sf.net/p/pfstools/git
-
peter green posted a comment on ticket #48
Contary to the title I don't belive this is related to g++-10, I was able to reproduce it with g++-9 The issue is that Magick++.h (indirectly) includes assert.h inside a namespace. Note that generally only the first include of a header actually does anything due to the presense of include gaurds. Therefore if assert.h is included before Magick++.h then everything is fine, the symbols from assert.h are correctly included in the global namespace. OTOH if the first include of assert.h is the one from...
-
Param Hanji committed [e527fa]
Fixed saturation artifacts with HDR merging
-
Param Hanji committed [4a5efb]
Updated documentation and noise parameters
-
Param Hanji committed [3e59a0]
Added option to provide saturation offset. This is needed for some Sony cameras to prevent artifacts
-
build error with gcc-10
-
Added 'format' to pfs_automerge
-
Added Canon CR2; commented out debug info
-
Silenced error messages
-
Fixed search for Cygwin path
-
Fixed issues with the space in the path
-
Minor
