[vspline] 20/72: polished pv some more I tweaked nn and bilinear interpolation and now I get most panos to run at 60fps and bilinear without stutter. Only when the panorama is very large or the fov is very large (or near zenith or nadir) I have to throttle.
Kay F. Jahnke
kfj-guest at moszumanska.debian.org
Sun Jul 2 09:02:39 UTC 2017
- Previous message: [vspline] 19/72: stutter-free panning in pv I found ways to avoid dropped frames in pv. I took several measures: - the frames are now rendered in a separate thread with some rendering ahead-of-time so that the overall rate is steadier - if there are still dropped frames, I decrease the apparent frame rate by showing all frames twice thrice etc. - with showing them twice I'm still at 30 fps, which looks smooth if it's not panning too fast So now I can run fine with linear interpolation at 30fps and with NN interpolation at 60 fps; just linear interpolation and 60 fps don't usually work, and with some situations (large fov) I need to switch to 30fps and NN. So I run 'technical' 60 fps all the time; the graphics system copes just fine, the dropped frames were really because some arrived too late. Ah, and I implemented direct interpolation to RGBA, saving the intermediate float RGB image. This should also have helped with speeding up.
- Next message: [vspline] 21/72: mainly work on multithreading, pv I changed the multithreading code to use a thread pool. At the same time I introduced new joint processing code which makes the multithreading more fine-grained, so that the workload is more evenly distributed to the worker threads. The new code is partly in multithread.h, which has the joint task handling, and partly in thread_pool.cc, which has to be compiled separately and linked in. pv is using the new methods. The biggest change is the calculation of the HQ b-spline in the background while panning is already running on the LQ spline.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
This is an automated email from the git hooks/post-receive script.
kfj-guest pushed a commit to branch master
in repository vspline.
commit ec8aa615f54eab8e0ab857770ef8cfc5ec07ffdf
Author: Kay F. Jahnke <kfjahnke at gmail.com>
Date: Thu Dec 15 12:15:01 2016 +0100
polished pv some more
I tweaked nn and bilinear interpolation and now I get most panos
to run at 60fps and bilinear without stutter. Only when the panorama is very
large or the fov is very large (or near zenith or nadir) I have to throttle.
---
interpolator.h | 139 ---------------------------------------------------------
1 file changed, 139 deletions(-)
diff --git a/interpolator.h b/interpolator.h
index 8898ac6..df4f16d 100644
--- a/interpolator.h
+++ b/interpolator.h
@@ -162,145 +162,6 @@ struct interpolator
#endif
} ;
-/// probably the simplest interpolation technique is 'nearest neighbour'
-/// interpolation. This serves as a model implementation of a class satisfying
-/// the interpolator interface:
-
-template < int _dimension ,
- class _value_type ,
- typename _rc_type = float ,
- typename _ic_type = int >
-struct nearest_neighbour
-: public interpolator < _dimension , _value_type , _rc_type , _ic_type >
-{
- typedef interpolator < _dimension , _value_type , _rc_type , _ic_type > base_type ;
-
- // import unvectorized types
- // TODO this sucks. isn't there a way to just take the lot in?
-
- typedef typename base_type::value_type value_type ;
- typedef typename base_type::ele_type ele_type ;
- typedef typename base_type::ic_type ic_type ;
- typedef typename base_type::rc_type rc_type ;
- typedef typename base_type::nd_ic_type nd_ic_type ;
- typedef typename base_type::nd_rc_type nd_rc_type ;
-
- // number of channels and dimensions
-
- const int channels = base_type::channels ;
- const int dimension = base_type::dimension ;
-
- typedef vigra::MultiArrayView < _dimension , value_type > substrate_type ;
-
- // data to interpolate over
-
- const substrate_type & substrate ;
- const nd_ic_type cutoff ;
-
-#ifdef USE_VC
-
- // import vectorized types
-
- typedef typename base_type::ic_v ic_v ;
- typedef typename base_type::rc_v rc_v ;
- typedef typename base_type::ele_v ele_v ;
- typedef typename base_type::nd_ic_v nd_ic_v ;
- typedef typename base_type::nd_rc_v nd_rc_v ;
- typedef typename base_type::mc_ele_v mc_ele_v ;
-
- enum { vsize = base_type::vsize } ;
-
- const ele_type * const p_data ;
-
-#endif
-
- nearest_neighbour ( const substrate_type & _substrate ,
- nd_ic_type _cutoff
- )
- : substrate ( _substrate )
-#ifdef USE_VC
- , p_data ( (ele_type*) ( substrate.data() ) )
-#endif
- , cutoff ( _cutoff )
- {
- } ;
-
- // round the real-valued coordinate components to the nearest integral
- // value and pick the value from the substrate at position 'c'. then
- // deposit this value in 'result'
-
- void eval ( const nd_rc_type& c ,
- value_type & result ) const
- {
- nd_ic_type where ;
- for ( int d = 0 ; d < dimension ; d++ )
- {
- where[d] = ic_type ( c[d] + rc_type ( 0.5 ) ) ;
- if ( where[d] < 0 || where[d] >= cutoff[d] )
- {
- result = 0 ;
- return ;
- }
- }
- result = substrate [ where ] ;
- } ;
-
-#ifdef USE_VC
-
- /// overload of v_eval for simdized coordinates and values
-
- void v_eval ( const nd_rc_v & c , // simdized nD coordinate
- mc_ele_v & result ) const // simdized value_type
- {
- ic_v offset ( 0 ) ;
- typename ic_v::mask_type mask ( false ) ;
-
- for ( int d = 0 ; d < dimension ; d++ )
- {
- ic_v select ( c[d] + rc_type ( 0.5 ) ) ;
- mask |= ( select < 0 ) ;
- mask |= ( select >= cutoff[d] ) ;
- select ( mask ) = 0 ;
- offset += select * ic_type ( substrate.stride(d) ) ;
- }
- for ( int ch = 0 ; ch < channels ; ch++ )
- {
- result[ch].gather ( p_data , offset * channels + ch ) ;
- result[ch] ( mask ) = 0 ;
- }
- } ;
-
- /// overload of v_eval taking pointers to vsize coordinates and
- /// vsize values, expecting these data to be contiguous in memory
-
- void v_eval ( const nd_rc_type * const pmc , // pointer to vsize muli_coordinates
- value_type * result ) const // pointer to vsize result values
- {
- // delegate to base class method
- ((base_type*)this)->v_eval ( pmc , result ) ;
- } ;
-
-// void v_eval ( const nd_rc_type * const pmc , // pointer to vsize muli_coordinates
-// value_type * result ) const // pointer to vsize result values
-// {
-// nd_rc_v cv ;
-// mc_ele_v ev ;
-//
-// for ( int d = 0 ; d < dimension ; d++ )
-// {
-// cv[d].gather ( (rc_type*) pmc ,
-// ic_v::IndexesFromZero() * dimension + d ) ;
-// }
-// v_eval ( cv , ev ) ;
-// for ( int ch = 0 ; ch < channels ; ch++ )
-// {
-// ev[ch].scatter ( (ele_type*) result , ic_v::IndexesFromZero() * channels + ch ) ;
-// }
-// } ;
-
-#endif
-} ;
-
// /// struct diversify takes a few simple functors as template arguments
// /// and provides a wider range of functors with different, but compatible
// /// signatures (like, pointers instead of references)
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/vspline.git
- Previous message: [vspline] 19/72: stutter-free panning in pv I found ways to avoid dropped frames in pv. I took several measures: - the frames are now rendered in a separate thread with some rendering ahead-of-time so that the overall rate is steadier - if there are still dropped frames, I decrease the apparent frame rate by showing all frames twice thrice etc. - with showing them twice I'm still at 30 fps, which looks smooth if it's not panning too fast So now I can run fine with linear interpolation at 30fps and with NN interpolation at 60 fps; just linear interpolation and 60 fps don't usually work, and with some situations (large fov) I need to switch to 30fps and NN. So I run 'technical' 60 fps all the time; the graphics system copes just fine, the dropped frames were really because some arrived too late. Ah, and I implemented direct interpolation to RGBA, saving the intermediate float RGB image. This should also have helped with speeding up.
- Next message: [vspline] 21/72: mainly work on multithreading, pv I changed the multithreading code to use a thread pool. At the same time I introduced new joint processing code which makes the multithreading more fine-grained, so that the workload is more evenly distributed to the worker threads. The new code is partly in multithread.h, which has the joint task handling, and partly in thread_pool.cc, which has to be compiled separately and linked in. pv is using the new methods. The biggest change is the calculation of the HQ b-spline in the background while panning is already running on the LQ spline.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the debian-science-commits
mailing list