I use Akeneo 2.1.9 EE version.
I wrote a configuration file to generate asset variation for a specific channel, which sets width and length to 750px
asset_channel_configurations:
ecommerce:
configuration:
resize:
width: 750
height: 750
But then when I generate variations for a rectangular image, it doesn't change to a square and keeps proportions with the width or height at 750px.
Why do I get this behavior ? Isn't resize supposed to not keep proportions ?
Thanks
Akeneo is using ImageMagick for asset variations. By default, the resize command does keep proportions. It is possible to force Imagemagick to ignore it. In this case you will have a square image, regardless of the original ratio. That means it would be distorted to fit the square aspect ratio, if the input was not square.
However, this is not possible in Akeneo. So you have two solutions:
- you can either add a new transformation that will resize without respecting the image ratio
- or you can override the existing Akeneo resize implementation (it is in the class Akeneo\Component\FileTransformer\Transformation\Image\Resize, in Enterprise Edition only) so it always ignores the ratio.
Related
I am trying to overlay a part of one image on top of another image on .net core (code needs to be cross platform).
I considered using ImageSharp since it supports win,mac and linux.
But i couldn't find pixel blending on their features list, although i saw that you can access an individual pixel.
So the use case would be, i have two 4k Png images and i want a small part of the first image (roughly 10% square of the overall image) to be overlayed on top of the second image (but not the whole image just the same 10% space) and get the area where the merging happened as a new Jpeg image.
(the source PNGs have some degree of transparancy).
I considered cropping out the two parts i want to merge from the two 4k images and then blending them to get the final image, but that is slow for the needs of the project I'm working on.
ImageSharp does support pixel blending, you can specify the pixel blending mode during Draw/Fill operations by passing in an GraphicsOptions parameter and setting its BlenderMode and BlendPercentage(defaults to 100%) properties.
Currently ImageSharp has implementations for the following blending modes:
Normal
Multiply
Add
Substract
Screen
Darken
Lighten
Overlay
HardLight
Src
Atop
Over
In
Out
Dest
DestAtop
DestOver
DestIn
DestOut
Clear
Xor
I have a webview in my Windows 8 (Metro) app that I will use to display much of my content. The webview automatically scales any CSS dimensions to 100%, 140%, and 180%. This means that when I specify:
#square {
width:100px;
height:100px;
background-color:white;
}
...we get a nice square that is 100, 140, or 180 device pixels, depending on the display. So far, so good.
Further, if I supply an image that is 100px square, the OS correctly scales it to 140 and 180 as appropriate on higher density screens.
Further still, if I supply versions of the image that are 100px, 140px, and 180px, and I indicate the size as 100px in the CSS, like this:
#my_image {
width:100px;
height:100px;
}
The OS uses an area that is 100 dp square (that is to say, 100, 140, or 180 device pixels square as appropriate) and automatically selects the right image. So far, still good.
The problem occurs when I try to use images with density qualifiers without naming a literal size in CSS. Why would I want to do this? I have lots of images with variable sizes. I'd prefer to just allow the webview to infer the appropriate size based on the dimensions of the images.
So I expect that if I supply 100, 140, and 180 versions of an image, the OS will be smart enough to say, "Ah, this is a 100-dp image that happens to have additional versions available."
What actually happens, however, is this.
I supply images:
square.scale-100.png
square.scale-140.png
square.scale-180.png
The OS picks the appropriate one. On a 180% screen, it picks the version that is 180 device pixels square. Recall, however, that we made it 180 device pixels because it was the 180% version of the 100 dp image. We want it to actually take up only 100x100 dp of space.
However, the OS takes 180 as the size in DP. So it scales it by 180% again.
How can I avoid this double-scaling? Any pointers would be awesome!
We've figured out a solution to this that I'm sharing in case it helps anyone else.
The solution is to include dynamically written CSS that zooms images using a factor that is the inverse of the current scale factor.
The current scale factor is available to app code, but not to Javascript running in a WebView. From the point of view of such Javascript, all dimensions are already scaled. So, for example, window.devicePixelRatio is no good -- it always returns 1.
You can obtain the current scale factor in app code like so:
ResolutionScale scale = DisplayInformation.GetForCurrentView().ResolutionScale;
From this, you can derive a zoom factor like this:
float imageZoomFactor = 1.0F;
switch (DisplayInformation.GetForCurrentView().ResolutionScale)
{
case ResolutionScale.Scale140Percent:
imageZoomFactor = (1.0F / 1.4);
break;
// etc
}
You can pass this into your Javascript in one of several ways. Since we were reading HTML from the app bundle and using WebView.NavigateToString, we created a placeholder in the Javascript that we replace in the string. The Javascript looks like this:
<!-- Scale images so that their sizes map 1:1 to device pixels -->
<script type="text/javascript" language="javascript">
document.write('<style type="text/css">img {zoom:' + HOSTING_CODE_SUPPLIED_ZOOM_FACTOR + ';}</style>');
</script>
Now when you use an image tag without specifying explicit dimensions, it works properly. For example, an image that is 180px x 180px, created for the purpose of being displayed at 100dp x 100dp in 180% mode, is displayed correctly using 180 device pixels.
One caveat is that if you have CSS that explicitly sizes an image, you need to cancel the zoom. So, for example:
#my_explicit_image {
width:200px;
height:200px;
zoom:normal; /* cancel the zoom on img since we're being explicit */
}
If you don't include the last line, the zoom specified on img will apply to the dimensions you specify here.
Hope this helps someone out there!
I'm working with documents, so maintaining the the original image dimensions and subsequent dpi is important.
The aspect ratio is always maintained so the automatic fill modes and alike don't seem to have any effect.
Say I have a 300 dpi document and the user want to clear an inch border around the image. So I need an inch cropped from the image but the result needs to be the original image dimensions (2550x3300).
I have been able to achieve this effect with...
...&crop=300,300,-300,-300&margin=300,300,300,300
This works, but seems more than a little clunky. I've tried a lot of other combinations but they all seem to enlarge or reduce the image size which is undesirable in my case.
So does someone know a simpler syntax to achieve the desired result, or do I need to re-size the image then calculate and fill with a margin as I'm doing now.
Thanks
It turns out that my example requests the image in it's full size which turns out to be a special case. When I introduce a width or height into the command line things don't work very well since crop size is in respect to the original image dimensions and margin size is in respect to the result image.
Thinking about it more I abandoned the crop approach. What I really needed was a way to introduce a clipping region into the result bitmap. So I built an extension to do just that. It works well as it doesn't interfere with any of Resizer's layout calculations and the size of the returned image is whatever the height or width were specified as. Which is just what I needed. The Faces plugin has an example of introducing a clipping region.
Karlton
Cropping and re-adding 300px on each edge is best accomplished exactly the way you're doing it:
&crop=300,300,-300,-300&margin=300
What kind of improved syntax would you expect? This isn't a common operation.
I'm trying to do a image resizing operation where:
Image stock is at 2x dimension (for Retina)
If device detected is low resolution (standard), reduce image by 50% back to 1x (i.e. zoom=0.5)
If device max resolution is 800, set the image not going over 800 (i.e. maxwidth=800)
However, when I combine the two operations (i.e. zoom=0.5&maxwidth=800), it basically give me an image that is 800 x 50% = 400. But I would like to have the image first reduced by 50% (e.g. if image was 2000w x 1000h, reduce it to 1000w x 500h), then make sure width does not go over 800 (i.e. 800w x 400h).
Is there any way to approach this?
Thanks in advance!
Stephen
Zoom operates after all other sizing operations, such as width/height/maxwidth/maxheight. This ensures that you can add 'zoom' to any image command set and zoom the result.
I.e, Zoom multiplies the 'result' size, not the source size.
If you're doing responsive images, you should consider trying slimmage.js. It's rather ideal if you want to handle both pixel densities and CSS viewport or element rules effectively together.
If you really need to build your own solution, you'll need to do the math either client side (and set maxwidth alone) or server side (and add a command that applies your custom rules).
Full disclosure: I wrote Slimmage, so I personally think it's the best all-around solution, of course :)
I want to intercept the imageresizing.net pipeline to conditionally resize an image. The scenario is this.
Any image 600px or larger should be resized down to 600px wide
if an image is 300-> 599px it should be resized to 300px wide
if its less than 150px it should be padded with whitespace to 300px wide.
I know i can achieve each of the above using the library but i don't know in advance of making the call the size of the source image. Is there an entry point where i can intercept the original image size and adjust the resize criteria as above?
I did find this but I'm not certain exactly how to implement it. How to avoid imageresizing if width and height is same as original?
To accomplish this in an efficient manner, you would have to store the source file width/height somewhere fast. Opening the source file each time isn't acceptable.