Textract results on recognizing basic arithmetic seems to degrade with color
This series of images show Textract failing unusually in all cases except the one where the image has been both grayscale and brightness/contrast (50/50 and 25/25)
unedited image from the camera FAIL
brightness contrast applied without grayscale FAIL
grayscale FAIL
grayscale with brightness contrast finally!
Is one supposed to grayscale the image before sending to textract? Should one also apply brightness/contrast?
I assume Textract was trained with grayscale images - so should the service automatically convert the input images to grayscale?
Related
I have a div that uses:
-webkit-clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);
clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);
And there is an image inside this div inside another div. Is there a reason why this specific code causes chrome performance to drop - scrolling becomes choppy too. In Firefox everything looks normal.
Strangely enough, it only affects scrolling when view is on that element, once you scroll past it looks fine again
Clip-Path GPU Rendering
clip-path uses the GPU for rendering, so it is likely to be a graphics card/driver issue or that your system was out of resources and unable to render it effectively.
Try viewing on other machines to see if the same problem exists.
To understand the performance issues and how to debug them these articles will help
Debugging a Canvas Element
Chrome allows you to profile and debug canvas elements from the
Developer Tools. It can be used for both 2D and WebGL canvas projects.
To be able to do this, you need to have enabled the "Experiments" tab.
If you haven't already, navigate to chrome://flags and enable the
option marked "Enable Developer Tools experiments". You'll need to
press "Relaunch Now" button at the bottom of the page to apply your
changes. Go to the Settings panel of Chrome Developer Tools by
clicking the cog on the bottom right. Click the "Experiments" tab and
check the option "Canvas inspection".
Now visit the "Profile" tab and you will see an option called "Capture
Canvas Frame". The Developer Tools may ask you to Reload the page to
use the canvas. Pressing "Start" captures a single frame of the canvas
application. Alternatively, you can click the box below to switch to
"Consecutive Frames" which allows for capture of multiple frames.
Chrome creates a log of each call to canvas, providing a list of each
call to the context and a screenshot. You can click one of the log
items to replay the frame in the Developer Tools and see which
commands were called in the order they were called and from which
line.
Firefox has Canvas and WebGL Shader debugger, giving you features to
inspect frames, fps, modify shaders and more.
In order to enable these tools, go to Devtools settings (the cog icon
in devtools) and check "Canvas" and "Shader Editor".
Picking Your Properties
Animation is not selecting a syntax, it’s designing the animation for
fast rendering. The difference between a smooth, life-like animation
and a janky, stuttery one is rarely as simple as CSS versus
JavaScript. Instead, it’s often determined by which properties or
attributes you animate, on which elements.
Regardless of whether you’re changing a style property with CSS or
with SMIL or with JavaScript, the browser needs to determine which
pixels on the screen need to be updated, and how.
If the DOM and style computation steps determine that no styles or SVG
rendering attributes have changed for any elements, the browser can
stop right there.
If the changed styles don’t affect layout (only painting), or if
layout has changed for some elements but not for others, the browser
has to determine which parts it needs to repaint. This region is known
as the “dirty” rectangle of the screen. Elements elsewhere on the
screen can be skipped, their pixels unchanged for this update.
The changed element usually needs to be repainted, but also maybe
others. Did the changed element overlap another element, which is now
revealed? If so, the browser may need to redraw that background
element.
But maybe not.
It depends on whether the browser has the original pixel data for the
background saved in memory. The graphical processing units (GPU) in
most modern computers and smartphones can keep a certain number of
rendering layers in memory, not just the final version that appears on
screen. The main browser program may also save partial images in
memory.
Much of browser rendering optimization comes down to how it selects
which parts of the rendered document to divide into separately cached
(saved) layers.
GPUs can perform certain operations on the cached rendering layers,
and are highly optimized for the limited number of operations they can
do.
If browsers know that an element is going to change in a way that can
be efficiently calculated by the GPU, they can save that image’s pixel
data in a different GPU layer from its background (or foreground). The
animated changes can therefore be applied by sending new instructions
to the GPU for how to combine the saved pixels, instead of by
calculating new pixel values in the main processor.
Tip Most browser Dev Tools now have options to highlight the “dirty”
paint rectangles whenever they are updated. If your animation is being
GPU-optimized, you won’t see any colored rectangles flashing when you
run this Dev Tools mode.
Of course, all GPU-optimized pathways are conditional on having a
compatible GPU available—and on the browser knowing how to use it,
which may depend on the operating system. So browser performance, and
sometimes even browser bugs, will depend not just on the browser
version but also on the OS and hardware.
Most GPUs can adjust opacity of the saved layers, and translate them
to different relative positions before combining them. They can also
perform image scaling, usually including 3D perspective scaling—but
the scaling is calculated on a pixel level, not a vector level, and
can cause a visible loss in resolution. More advanced GPUs can
calculate some filter operations and blend modes, and masking of one
image layer with an alpha mask layer.
Some GPUs also have optimized vector rasterization, which can
calculate high-resolution vector shapes for use as clipping paths of
other vector levels. These “clipping paths” aren’t only used for
clip-path effects, though. Filling and stroking a shape is clipping
the paint image layer to the fill-region or stroke-region vector
outline. Similarly, CSS border-radius effects are vector clipping
paths on the content and background image layers.
But you currently can’t rely on your end users having these optimized
pathways.
The best performance, across a wide range of browsers and hardwares,
comes from animations that can be broken into layers (of elements,
groups, or individual graphics) that are animated in the
following ways:
opacity changes
translational and rotational transformations
Warning Currently, Chrome never divides an SVG graphic into different
GPU layers (although they do other optimizations).
To create a fully GPU-optimized animation in Chrome, you can sometimes
position separate inline elements over top of each other,
creating your own layers.
If you can’t define your animation entirely in translation and opacity
layers, consider the following guidelines:
Minimize the size of the “dirty” rectangle at each frame.
Solid-color objects are better than semi-transparent ones, since the
browser doesn’t need to calculate pixel updates for shapes that can’t
be seen behind a solid object. (Although this may not apply if the
browser is using GPU layers for optimization.)
Moving elements around is more efficient than changing what they look
like. (Although it depends on the browser whether “moving around” only
applies to transform movements or also to other absolute position
changes.)
Changing fill and stroke is more efficient than changing shapes and
sizes.
Scaling transformations are better than changing the underlying
geometry; browsers may be able to use GPU image scaling for an
animated scale effect, instead of recalculating the vector image at
the correct resolution at each frame.
Clipping is usually more efficient than masking.
Avoid rescaling gradient and pattern layers; this could mean using
user-space effects instead of bounding-box effects, if the bounding
box is changing.
Avoid any changes that require a filter to be recalculated. That
includes any change to the filtered element or its child content.
I use QPainter and the function drawImage to draw an airplane on a map. The image and redrawn each time the position of the airplane changes. The problem is, after some time, the image becomes extremely pixelated. I have tried to use a high quality .svg and that did not help either.
Below is my code. Can somebody spot where the error is or what has caused the image to be so pixelated?
// Load .svg image
airplane->load("AirplaneTopDown.svg");
// Downsize image
airplaneSmall = airplane->scaled(120, 120,Qt::KeepAspectRatio);
// Rotate image by trans
airplaneSmall = airplaneSmall.transformed(trans);
// Draw image and center at a certain screen position
painter.drawImage(airplaneX-airplaneSmall.width()/2,airplaneY-airplaneSmall.height()/2,airplaneSmall);
Below are the images of the drawn airplanes. One taken as screenshot at the beginning of the program runtime another one taken after a couple of minutes.
Airplane
Airplane-pixelated
One of your problems is that you first rescale the image and then rotate it.
The rotation needs to interpolate new pixels from the old ones. The higher the resolution of the input, the better the quality of the interpolation. The quality of your SVG is completely lost after the rescale operation.
The second problem you are facing is that you use the "fast" (default) transformation method. This method does not antialias. So instead of interpolating from several input pixels, it will only take one best fit. Calling transformed() with the second argument Qt::SmoothTransformation and scaled() with the sceond argument Qt::SmoothTransformation |Qt::KeepAspectRatio` will greatly improve your results.
However it is also slower, as is performing the rotation on the image in its original, higher resolution.
The arguably best solution to your problem is to take on a different approach. Instead of loading the SVG into a QImage, which is a raster-based image, you should work with the vector graphics. So the SVG is rendered in the right orientation and scale in the first place. A good starting point is the SVG Viewer Example: http://doc.qt.io/qt-5/qtsvg-svgviewer-example.html
I'm adding CSS to a Bootstrap-based web app, to match a PDF from a designer. There's a button image, whose background color Seashore reports as rgb(0,186,158) aka hsl(171,100,36%). So I set the background colour of the button to match the image:
background-image: url('images/elements/small-search-button-up.png');
background-color: hsl(171,100%,36%);
Only...it doesn't.
Subtracting 3% from the luminosity fixes it:
I'd love to know why. I can't see any obvious causes in all of the other CSS styles applied. This happens in both Chrome and Firefox, on OS X Snow Leopard.
I'm seeing something similar with certain fonts (comparing the web rendered output with a provided PDF), but that cause could be different.
EDIT
Here's the original image. Hopefully SO doesn't process it.
EDIT2
Why use PNG? That's how the designer provided the images. I wasn't aware that there was a trade-off with color space information. Also, I would have thought that PNGs are better for glyphs needing flat backgrounds and crisp edges (compared to JPEGs), no?
It's most likely the color of the PNG image that is not displayed consistently.
A PNG image doesn't have color space information, instead it has a gamma value, and there is a problem to interpret that value to determine a color space. You will probably see that there is a color difference between different browsers, so if you adjust the color for how one browser displays the PNG, it won't match in other browsers.
Use a different file format if you need the color match other elements, or make the background of the PNG transparent instead of green.
Rendering text is a different matter. There will always be slight differences in how browsers renders different fonts, depending on the rendering method used, which fonts are installed, and system/user settings. You simply can't expect exactly the same result in different browsers.
I have a large png image (950x500px) which I have been scaling down using CSS to 500px wide (and 263 high). Before putting this webpage online I decided to scale the image using GIMP as scaling images with CSS is bad practice. However there is a noticeable reduction in image quality when I scale the image using GIMP rather than CSS in Google Chrome even though both images are png and have identical dimensions. I have tried using all four compression methods offered by GIMP (None, Linear, Cubic and Sinc (Lanczos3)) and none of them match the image quality given by Google Chrome.
What compression method does Google Chrome use to give such high-quality image scaling and how can I achieve this offline?
You may get the answer to your question here: How web browsers resize images
Chrome seems to be using several algorithms depending on the scaling factor:
With a very slight downscale (557 to 555 pixels), Chrome uses the same
linear interpolation as when upscaling. (The fact that this graph is
disconnected is an artifact of the way ResampleScope works, and has
nothing to do with Chrome.)
But look what happens if we downscale just a bit more, to 543 pixels:
[…] We get a completely different result: clearly a 3-lobed Lanczos
filter. Chrome’s strategy may be to use Lanczos when reducing an image
by more than 2.5%.
If you have to do it yourself (to get more control on the result), Cubic is usually the best bet scaling up and Sinc (Lanczos3) for scaling down.
If you scale the image yourself, you know how it will look on all browsers.
Note: There are more and more computers equipped with high resolution displays (around 4 times the pixel density of a classic display). You may want to check how images look on those computers. There is a high chance they are scaled up by the browser.
This is a very old question, but I was struggling with an image resize in Gimp yesterday. When I compared the image resized in Gimp with the image automatically resized in Chrome (and Safari), there was a visible difference.
I was resizing a PNG logo from 89x127 to 69x101 and the text blurred after the resize in Gimp no matter which interpolation I chose.
Thanks to the comment above saying that ImageMagick gave a better result when resizing an image, I found this article: Efficient Image Resizing With ImageMagick
The command from the article, despite its claims to be indistinguishable from Photoshop, did not produce a result that matched Chrome, however one of the commenters added a command that did create an image that produced the closest result (barring the resize my friend did in Photoshop):
convert SOURCE_IMAGE -resize OUTPUT_WIDTH -quality 90 -unsharp 0x0.55+0.55+0.008 OUTPUT_IMAGE
I think the trick lies mainly in the sharpening. I've tried different settings and can't exactly match Chrome, but this came pretty darn close.
For completeness, here is the command from the article. Please read the article for a full explanation of how it works:
mogrify -path OUTPUT_PATH -filter Triangle -define filter:support=2 -thumbnail OUTPUT_WIDTH -unsharp 0.25x0.25+8+0.065 -dither None -posterize 136 -quality 82 -define jpeg:fancy-upsampling=off -define png:compression-filter=5 -define png:compression-level=9 -define png:compression-strategy=1 -define png:exclude-chunk=all -interlace none -colorspace sRGB -strip INPUT_PATH
Overview
I'm looking for advice / solutions on standardizing color profiles on comps so colors of HTML/CSS gradients/blends match effects achieved in a comp. I often get PSDs using the sRGB color profile so when I color pick something to recreate a gradient / icon / or background the HEX color and resulting CSS/HTML gradient does not match the original sRGB gradient provided in the comp. Typically I just discard the embedded color profile for a Monitor RGB color profile that better matches PSD colors to end result CSS colors. Here's an example showing differences between color profiles.
Details
So here's the predicament: A designer wants to standardize PSDs to use an embedded sRGB color profile because exported images (JPEG / PNG) retain that sRGB color profile to display correctly when loaded in a browser. So photos / textures / things that I can't recreate in CSS will export as JPEG/PNG with the better sRGB profile (which is an understandable request).
As a front-end developer I often recreate elements displayed in a comp using CSS and HTML (no images) and this requires me to match HEX colors properly between what's in the PSD and what's rendered on the website. So, I would prefer to standardize with a Monitor RGB color profile so that everyone uses something closer to what's actually rendered in the browser.
Just curious how everyone else approaches this problem? There's often cases where I use a mixture of CSS and PNGs to achieve an effect (especially effects that need to change dynamically (size/hue/shading...) so exporting an image with sRGB and overlaying it with CSS gradients / shadows ends up being a mixture of sRGB / Monitor RBG and hence subtly different from the comp.
Answer Format
Hopefully I've properly asked this question - suitable answers would just give a perspective on how you deal with the problem - OR (better) if theres an SCSS sRGB() function or some other algorithm to convert an RGB / HEX color to sRGB then I will throw it into a SASS mixin.
Here's how we ensure color consistency in Photoshop: correct color-picking and consistency in saved-for-web images.
Setting Up Photoshop Color Space
The first thing we all have to do is to ensure we are working under the correct color profiles. To do this follow these steps:
Go to Edit > Color Settings or Shift + Command + K or Shift + Control + K in windows.
From the Settings drop down select North America Web/Internet
Commit your changes by hitting OK.
Go to View > Proof Setup and select Internet Standard RGB (sRGB)
Hit Command + Y or Control + Y in windows to enable Proof Colors, alternatively you can just go to View > Proof Colors
Exporting (Save for Web)
When exporting via Save for Web ensure that Convert to sRGB is checked.
You are done, you should now enjoy color accuracy across all of your files and in HTML and images will be ensured to display consistently across devices and browsers.