dotnetimageprocessor Issue Tracker Rss Feed

Created Unassigned: ResizeMethod.AspectRatioFill issue [11036]

gelion — Wed, 22 May 2013 06:10:28 GMT

protected virtual Size GetNewSize(Image img, Size requestedSize, ResizeMethod method, out Size bitmapSize)
{
Size outputSize = new Size();

switch (method)
{
case ResizeMethod.AspectRatioFill:
{

float ratio = (float)img.Width / (float)img.Height;

float reqRatio = (float)requestedSize.Width / (float)requestedSize.Height;
if (ratio > reqRatio)
{
outputSize.Height = (int) ((float) requestedSize.Width/ratio);
outputSize.Width = requestedSize.Width;

}
else
{
outputSize.Width = (int)((float)requestedSize.Height * ratio);
outputSize.Height = requestedSize.Height;
}

} break;

Commented Feature: Add a flag to constrain to an axis when resizing [10444]

elkdanger — Tue, 21 Aug 2012 21:13:49 GMT

When resizing into a box size using ResizeMethod.KeepAspectRatio, the filter keeps the image within the maximum resolution specified, and resizes using the longest axis.

We would like to add a flag to change this behaviour so that the axis to be constrained can be specified.
Comments: Associated with changeset 79662.

Created Feature: Add a flag to constrain to an axis when resizing [10444]

elkdanger — Tue, 21 Aug 2012 21:02:24 GMT

Closed Issue: Square images when blown up are not filled out correctly [10041]

elkdanger — Sun, 29 Apr 2012 13:12:05 GMT

When a square image is resized up using AspectRatioFill, instead of filling out the extra space with colour, the image is cropped.

It should work so that the image is filled out with the background colour. This would happen if I chose a non-square image - it should also behave this way with a square image.
Comments: Resolved with changeset 77779.

Created Issue: Square images when blown up are not filled out correctly [10041]

elkdanger — Thu, 15 Mar 2012 10:09:09 GMT

Created Task: Add extensibility hooks into IImageProviderFactory to allow some customisation over the providers which get instantiated [9088]

elkdanger — Sun, 21 Aug 2011 23:00:30 GMT

Closed Task: Modular framework to support different read/write strategies per file type [9087]

elkdanger — Sun, 21 Aug 2011 22:54:50 GMT

This is proposed mainly for the multi-page TIFF support.
Comments: Resolved with changeset 69834.

Created Task: Modular framework to support different read/write strategies per file type [9087]

elkdanger — Sun, 21 Aug 2011 21:27:52 GMT

This is proposed mainly for the multi-page TIFF support.

Closed Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:59:09 GMT

The watermark filter should accept an image to overlay, or a piece of text. The text font, size and colour can be configured.

In both cases, the programmer should be able to set the opacity and anchor location for the watermark.
Comments:

Implemented in release 1.2

Commented Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:47:45 GMT

Commented Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:47:16 GMT

Commented Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:46:33 GMT

Commented Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:07:02 GMT

Commented Feature: Watermark filter [8932]

elkdanger — Sun, 07 Aug 2011 10:01:46 GMT

Commented Feature: Watermark filter [8932]

elkdanger — Sat, 06 Aug 2011 22:16:04 GMT

Commented Issue: Multi-tiff processing and conversion [8976]

elkdanger — Mon, 25 Jul 2011 10:06:28 GMT

multi paged tiffs are currently handled only by the active page. a concatenation of the pages into one file would be nice!
Comments: ** Comment from web user: elkdanger **

Sounds acceptable - I'll investigate

Created Issue: Multi-tiff processing and conversion [8976]

Madmardigan — Thu, 21 Jul 2011 09:14:04 GMT

multi paged tiffs are currently handled only by the active page. a concatenation of the pages into one file would be nice!

Created Feature: Accumulative and Non-accumulative processing [8935]

elkdanger — Wed, 13 Jul 2011 22:26:08 GMT

Currently, processing is done accumulatively - each filter in the pipeline takes the output from the last filter, processes the image and passes the results on. The image at the end is the result of having been passed through many filters.

I would like to add the ability to process images non-accumulatively in one pass, which basically means that each filter in the pipeline processes the image as if it was the only filter there. Therefore, each filter would produce a separate image.

The scenario I want to enable is this: if, for example, I have a full-size product image and I want to produce 5 thumbnails of varying sizes, I would currently have to run through a loop 5 times, creating a new instance of ImageProcessor, adding in a resize filter, process the image and then save the output.

Or, using this proposal, I can add 5 resize filters to the processor, each with the appropriate thumbnail size, set the process mode to "non-accumulative" and then call Process() once, and retrieve 5 different images.

The big design question I can't answer at the moment is: how do we determine the output filename/stream for each step?

Created Issue: Image pipeline for batch processing/multi-image filters [8934]

elkdanger — Wed, 13 Jul 2011 22:17:40 GMT

Filters such as watermarking and masking will need to access the other images in the pipleline.

Can either:
- Just set the watermark or mask image in the constructor of the filter
- Pass in the watermark image in a different 'channel' which can somehow be accessed by the filter

Will need the concept of channels for batch processing anyway, and we could extend this to include channels which are 'dumb' (no processing is done on images in these channels) or 'active' (full filter processing is done). This way, filters can use other images as part of their processing.

Created Feature: Image mask filter [8933]

elkdanger — Wed, 13 Jul 2011 22:10:07 GMT