put the shrink line cache back
so we can use THINSTRIP for the vips_shrink() operation
This commit is contained in:
parent
f07fb25ab5
commit
7061f0f00b
@ -322,15 +322,12 @@ vips_shrink_build( VipsObject *object )
|
||||
if( vips_image_copy_fields( resample->out, resample->in ) )
|
||||
return( -1 );
|
||||
|
||||
/* We want to be able to work with sequential sources. THINSTRIP would
|
||||
* be OK, but FATSTRIP would be a disaster: thread 2 would be given a
|
||||
* strip some way down the output, which would be a huge distance down
|
||||
* the input.
|
||||
*
|
||||
* Make sure we always work by insisting on SMALLTILE.
|
||||
/* THINSTRIP will work, FATSTRIP will break seq mode. If you combine
|
||||
* shrink with conv you'll need to use a line cache to maintain
|
||||
* sequentiality.
|
||||
*/
|
||||
vips_demand_hint( resample->out,
|
||||
VIPS_DEMAND_STYLE_SMALLTILE, resample->in, NULL );
|
||||
VIPS_DEMAND_STYLE_THINSTRIP, resample->in, NULL );
|
||||
|
||||
/* Size output. Note: we round the output width down!
|
||||
*/
|
||||
|
@ -162,8 +162,19 @@ shrink_factor( IMAGE *in, IMAGE *out,
|
||||
}
|
||||
|
||||
/* Shrink!
|
||||
*
|
||||
* We want to make sure we read the image sequentially.
|
||||
* However, the convolution we may be doing later will force us
|
||||
* into SMALLTILE or maybe FATSTRIP mode and that will break
|
||||
* sequentiallity.
|
||||
*
|
||||
* So ... read into a cache where tiles are scanlines, and make sure
|
||||
* we keep enough scanlines to be able to serve a line of tiles.
|
||||
*/
|
||||
if( im_shrink( x, t[3], shrink, shrink ) ||
|
||||
if( im_shrink( x, t[2], shrink, shrink ) ||
|
||||
im_tile_cache( t[2], t[3],
|
||||
t[2]->Xsize, 1,
|
||||
VIPS__TILE_HEIGHT * 2 ) ||
|
||||
im_affinei_all( t[3], t[4],
|
||||
interp, residual, 0, 0, residual, 0, 0 ) )
|
||||
return( -1 );
|
||||
|
Loading…
Reference in New Issue
Block a user