Drawing with the draw tool over the image with big size (e.g. 3000 x 2500) result in loss of quality.

Workaround: In the DrawCommand use the following method to create a BitmapSource which should be used for creating a RadBitmapImage.

public RadBitmap Execute(RadBitmap source, object context)
{
   ...
   ...
   ...
   BitmapSource bitmapSource = GetBitmapSource(source.Width, source.Height, canvas);
   return new RadBitmap(bitmapSource);
}
private BitmapSource GetBitmapSource(int width, int height, Canvas surface)
{
    Size size = new Size(width, height);

    surface.Measure(size);
    surface.Arrange(new Rect(size));

    // Create a render bitmap and push the surface to it
    RenderTargetBitmap renderBitmap =
        new RenderTargetBitmap(
        (int) size.Width,
        (int) size.Height,
        96d,
        96d,
        PixelFormats.Pbgra32);
    renderBitmap.Render(surface);

    return renderBitmap;
}

1. RadImageEditor with ZoomToCursor enable.

2.Apply ZoomOut function until render width/height less than view width/height

result => Image zoom at center of viewport, not zoom at cursor position.

The RadImageEditorUI's tools (selection, shape, text, etc.) have different UI element representing their settings. Those are hosted in a settings panel. In case there are many options that cannot fit in the vertical size of the control, a scrollbar should get displayed. One example of this is the SelectionTool.

In the Office2019 and VisualStudio2019 themes, the vertical scrollbar doesn't get displayed.

To work this around, extract the ControlTemplate of SettingsPanel control. Then find the first RowDefinition of the root Grid panel and change its Height from Auto to star ( * ).

<Style TargetType="telerik:ToolSettingsPanel">	
	<Setter Property="Template">
		<Setter.Value>
			<ControlTemplate TargetType="telerik:ToolSettingsPanel">
				<Grid Background="{TemplateBinding Background}">
					<Grid.RowDefinitions>
						<RowDefinition Height="*"/>
						<RowDefinition Height="Auto"/>
					</Grid.RowDefinitions>
<!-- other xaml here -->

In the Shape Tool - Line Shape -> lock ratio, this currently constrains the lines to be diagonal.

IMHO it'd be a more common use case that users would want to constrain a line to be horizontal or vertical.

I would suggest changing the default behaviour of the ratio lock for line shapes to be horizontal/vertical and not diagonal.

You could leave the Ctrl key modifier to still constrain diagonally, but add a Shift key modifier so that holding shift constrains the line vertically / horizontally (this would coincide with Photoshop behaviour).

I know it's not a great idea to change behaviour on published code, so could consider adding a LockRatioMode property to the shape tool that defaults to Diagonal, and allow coders to set it to HorizontalVertical to implement the new behaviour.

Thanks

I just requested similar functionality for the Shape tool when drawing lines, and thought it would also be useful to have something similar in the Draw tool. I've raised a separate feature request because this one is for a different tool.

It would be good in the draw tool if holding the Shift key while drawing constrained the line to be horizontal or vertical.

In my use case people will load images and might want to underline things on the image.

Currently there is no way I can see to draw a perfectly horizontal line.

If in the draw tool you could hold shift and draw a perfectly horizontal line it would make this really easy and intuitive for the end user.

PS. To make the functionality more consistent with the Shape line tool, you could also add Ctrl as a modifier to the Draw tool to constrain the line diagonally.

The user should create a custom tool if they need to change the default settings of the DrawTextTool. It would be nice to provide an easier way for achieving this.

Using the built in OpenImageCommand functionality of telerik:RadImageEditorUI, you can detect the OpenImageCommand has been executed via the CommandExecuted event.

However there is no way to determine whether an image was loaded or not.

The Dialog Result is silently consumed by the OpenImageCommand class so if the user clicks the cancel button on the open file dialogue you have no way of knowing.

It would be good to have a means to determine the dialog result, either via a property on the command, by an additional property in the CommandExecuted event args, or even an event that is raised when an image is loaded or the dialog is cancelled.

To achieve this functionality I had to implement code like the following:

        public bool IsNewImage { get; set; }

        private void ImageEditor_CommandExecuting(object sender, ImageCommandExecutingEventArgs e)
        {
            if (e.Command is OpenImageCommand)
            {
                IsNewImage = false;
            }
        }

        private void HistoryOnCurrentImageChanged(object sender, EventArgs e)
        {
            var history = (ImageHistory)sender;

            IsNewImage = (!history.CanRedo && !history.CanUndo);
        }

        private void ImageEditor_CommandExecuted(object sender, ImageCommandExecutedEventArgs e)
        {
            if (e.Command is OpenImageCommand)
            {
                if (IsNewImage)
                {
                    // Deal with new image...
                }
            }
        }

It'd be so much easier to have the following:

        private void ImageEditor_CommandExecuted(object sender, ImageCommandExecutedEventArgs e)
        {
            if (e.Command is OpenImageCommand)
            {
                if (!e.CommandCancelled)
                {
                    // Deal with new image...
                }
            }
        }

Thanks 👍

Currently there isn't a way to determine if an image in the Image Editor has any changes.

There is a HistoryOnCurrentImageChanged() event which goes some way to providing the functionality, but this doesn't fire until a tool is committed.

For example, if you load an image, and select the Hue tool, and then drag the hue slider and change the image, this won't trigger the HistoryOnCurrentImageChanged() event until the user commits the tool e.g. clicks another tool or clicks off the image...

What would be perfect would be to have a HasChanges() property on the image editor that gets set to true when any aspect of the image is edited e.g. a tool slider is moved and the changes are not yet committed.

This would allow things like being able to have the the Save button disabled until the image is edited. Or being able to warn a user they are about to lose their changes if they have edited (say) the hue but have not yet committed the tool.

See also - https://www.telerik.com/forums/detecting-change 

Thanks

Please add a property to disable the zoom witch CTRL+MouseWheel. Maybe something like IsMouseWheelZoomEnabled with a defaut value of true.

There are already other properties like IsPanningEnabled or ZoomToCursor.

The currently known solution is:

private void imageEditor_PreviewMouseWheel(object sender, MouseWheelEventArgs e)
        {
            if (Keyboard.IsKeyDown(Key.LeftCtrl) || Keyboard.IsKeyDown(Key.RightCtrl))
            {
                e.Handled = true;
            }
        }

If an image with dpi different than 96 (for example 300dpi) is imported and then some operations are made on it, the exported image is with 96dpi.

When Depth property is set it is expected that the undo stack would not keep more items than the depth value. However, this behaviour is not working in ImageHistory class and could lead to OutOfMemoryException when the stack gets full of ImageHistoryItem instances.

Steps to reproduce:
1. Open ImageEditor and load some image.
2. Set ImageEditor.History.Depth = 1.
3. Make a few rotations.
Expected: When making Undo you should be able to undo only the last rotation.
Actual: You can Undo all the rotations meaning that Depth property is not respected.

Currently, on each change of the image, a new instance of the image is stored in the undo/redo stack. This means that the memory grows very fast. Especially, in a scenario with big images.

Create a smarter undo/redo mechanisms that saves only the applied change in the image.

The setting should be available in the settings UI, the DrawTextCommandContext and it should be respected in the DrawText command's Execute method.

Scheduled for: 
The feature will be available in R1 2019, scheduled for the mid of January 2019. 

Multiple operations applied on a big RadBitmap can cause OutOfMemoryException because of used and not disposed unmanaged resources in a WriteableBitmap object.

Steps to reproduce:
- Execute multiple times the Rotate tool
Observe: The memory goes up and retains such.
Expected: The unmanaged memory is cleared.

Findings: the memory leak is related to the WPF class WriteableBitmap which is internally used by the RadBitmap. Attached is a sample project illustrating the problem using only WPF classes.
Note: At this point, we are not aware of a possible fix.