https://wiki.whatwg.org/api.php?action=feedcontributions&feedformat=atom&user=XidachenWHATWG Wiki - User contributions [en]2026-04-04T01:40:50ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=OffscreenCanvas&diff=10092OffscreenCanvas2016-09-07T15:36:20Z<p>Xidachen: /* Web IDL */</p>
<hr />
<div>:''Provides more control over how canvases are rendered. This is a follow-on to the [[WorkerCanvas]] proposal and will be merged once agreement is reached.''<br />
<br />
== Use Case Description ==<br />
<br />
Feedback from web application authors using canvases have shown the need for the following controls:<br />
<br />
* (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.<br />
* (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.<br />
* (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.<br />
* (From adopters of the Push API): need to be able to dynamically create images to use as notification icons, such as compositing avatars, or adding an unread count<br />
* (From the Google Docs team): need to be able to layout and render text from a worker using CanvasRenderingContext2D and display those results on the main thread.<br />
* (From the Google Slides team): want to layout and render the slide thumbnails from a worker. During initial load and heavy collaboration these update frequently, and currently cause slowdowns on the main thread.<br />
<br />
=== Current Limitations ===<br />
<br />
* [https://html.spec.whatwg.org/multipage/scripting.html#proxying-canvases-to-workers CanvasProxy] does not provide sufficient control to allow synchronization between workers' rendering and DOM updates on the main thread. Keeping this rendering in sync is a requirement from Google's Maps team.<br />
* [[CanvasInWorkers]] does not allow a worker to render directly into a canvas on the main thread without running code on the main thread. Allowing completely unsynchronized rendering is a requirement from Mozilla and users of Emscripten such as Epic Games and Unity, in which the desire is to execute all of the game's rendering on a worker thread.<br />
* [[WorkerCanvas]] mostly addresses these two use cases, but some implementers objected to the mechanism for displaying the rendering results in image elements. The specific objection was that image elements already have complex internal state (for example, the management of the image's "loaded" state), and this would make it more complex. It also did not precisely address the use case of producing new frames both on the main thread and in workers.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
[https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/ WebGL in Web Workers] details some work attempted in the Emscripten toolchain to address the lack of WebGL in workers. Due to the high volume of calls and large amount of data that is transferred to the graphics card in a typical high-end WebGL application, this approach is not sustainable. It's necessary for workers to be able to call the WebGL API directly, and present those results to the screen in a manner that does not introduce any copies of the rendering results.<br />
<br />
=== Benefits ===<br />
<br />
Making canvas rendering contexts available to workers will increase parallelism in web applications, leading to increased performance on multi-core systems.<br />
<br />
=== Requests for this Feature ===<br />
<br />
See the abovementioned use cases:<br />
<br />
* Google's Maps team<br />
* Emscripten users such as Epic Games and Unity<br />
* Many others<br />
<br />
== Web IDL ==<br />
<br />
typedef (OffscreenCanvasRenderingContext2D or<br />
WebGLRenderingContext or<br />
WebGL2RenderingContext) OffscreenRenderingContext;<br />
<br />
[Constructor(unsigned long width, unsigned long height),<br />
Exposed=(Window,Worker)]<br />
interface OffscreenCanvas {<br />
attribute unsigned long width;<br />
attribute unsigned long height;<br />
OffscreenRenderingContext? getContext(DOMString contextId, any... arguments); <br />
<br />
// OffscreenCanvas, like HTMLCanvasElement, maintains an origin-clean flag.<br />
// ImageBitmaps created by calling this method also have an<br />
// origin-clean flag which is set to the value of the OffscreenCanvas's<br />
// flag at the time of their construction. Uses of the ImageBitmap<br />
// in other APIs, such as CanvasRenderingContext2D or<br />
// WebGLRenderingContext, propagate this flag like other<br />
// CanvasImageSource types do, such as HTMLImageElement.<br />
ImageBitmap transferToImageBitmap();<br />
<br />
// Throws a SecurityError if the OffscreenCanvas's origin-clean flag<br />
// is set to false.<br />
Promise<Blob> convertToBlob(optional ImageEncodeOptions options); <br />
};<br />
<br />
dictionary ImageEncodeOptions {<br />
DOMString type = "image/png";<br />
unrestricted double quality = 1.0; // Defaults to 1.0 if value is outside 0:1 range<br />
};<br />
<br />
OffscreenCanvas implements Transferable;<br />
<br />
partial interface HTMLCanvasElement {<br />
OffscreenCanvas transferControlToOffscreen();<br />
};<br />
<br />
typedef (HTMLOrSVGImageElement or<br />
HTMLVideoElement or<br />
HTMLCanvasElement or<br />
ImageBitmap or<br />
OffscreenCanvas) CanvasImageSource;<br />
<br />
typedef (CanvasImageSource or<br />
Blob or<br />
ImageData or<br />
OffscreenCanvas) ImageBitmapSource;<br />
<br />
[Exposed=Window, Worker]<br />
interface OffscreenCanvasRenderingContext2D {<br />
// commit() can only be used when HTMLCanvasElement has transferred Control<br />
// to OffscreenCanvas. Otherwise, an InvalidStateError will be thrown.<br />
// commit() can be invoked on main thread or worker thread. When it is invoked,<br />
// it is expected to see the image drawn to OffscreenCanvasRenderingContext2D <br />
// be displayed in the associated HTMLCanvasElement.<br />
void commit();<br />
// back-reference to the canvas<br />
readonly attribute OffscreenCanvas canvas;<br />
};<br />
OffscreenCanvasRenderingContext2D implements CanvasState;<br />
OffscreenCanvasRenderingContext2D implements CanvasTransform;<br />
OffscreenCanvasRenderingContext2D implements CanvasCompositing;<br />
OffscreenCanvasRenderingContext2D implements CanvasImageSmoothing;<br />
OffscreenCanvasRenderingContext2D implements CanvasFillStrokeStyles;<br />
OffscreenCanvasRenderingContext2D implements CanvasShadowStyles;<br />
// Reference filters (e.g. 'url()') are not expected to work in Workers<br />
OffscreenCanvasRenderingContext2D implements CanvasFilters;<br />
OffscreenCanvasRenderingContext2D implements CanvasRect;<br />
OffscreenCanvasRenderingContext2D implements CanvasDrawPath;<br />
// Text support in workers poses very difficult technical challenges.<br />
// Open issue: should we forgo text support in OffscreenCanvas v1?<br />
OffscreenCanvasRenderingContext2D implements CanvasText;<br />
OffscreenCanvasRenderingContext2D implements CanvasDrawImage;<br />
OffscreenCanvasRenderingContext2D implements CanvasImageData;<br />
OffscreenCanvasRenderingContext2D implements CanvasPathDrawingStyles;<br />
OffscreenCanvasRenderingContext2D implements CanvasTextDrawingStyles;<br />
OffscreenCanvasRenderingContext2D implements CanvasPath; <br />
<br />
[Exposed=Window, Worker]<br />
Partial interface CanvasPattern {<br />
}<br />
<br />
[Exposed=Window, Worker]<br />
partial interface CanvasGradient {<br />
}<br />
<br />
partial interface WebGLRenderingContextBase {<br />
// back-reference to the canvas<br />
readonly attribute (HTMLCanvasElement or OffscreenCanvas) canvas;<br />
<br />
// If this context is associated with an OffscreenCanvas that was<br />
// created by HTMLCanvasElement's transferControlToOffscreen method,<br />
// causes this context's current rendering results to be pushed<br />
// to that canvas element. This has the same effect as returning<br />
// control to the main loop in a single-threaded application. Otherwise,<br />
// an InvalidStateError will be thrown.<br />
void commit();<br />
};<br />
<br />
== Proposed Solutions ==<br />
<br />
=== This Solution ===<br />
<br />
This proposed API can be used in several ways to satisfy the use cases described above:<br />
<br />
* It supports zero-copy transfer of canvases' rendering results between threads, for example from a worker to the main thread. In this model, the main thread controls when to display new frames produced by the worker, so synchronization with other DOM updates is achieved.<br />
<br />
* It supports fully asynchronous rendering by a worker into a canvas displayed on the main thread. This satisfies certain Emscripten developers' full-screen use cases.<br />
<br />
* It supports using a single WebGLRenderingContext or Canvas2DRenderingContext to efficiently render into multiple regions on the web page.<br />
<br />
* It introduces ImageBitmapRenderingContext, a new canvas context type whose sole purpose is to efficiently display ImageBitmaps. This supersedes the [[WorkerCanvas]] proposal's use of HTMLImageElement for this purpose.<br />
<br />
* It supports asynchronous encoding of OffscreenCanvases' rendering results into Blobs which can be consumed by various other web platform APIs.<br />
<br />
==== Processing Model ====<br />
<br />
This proposal introduces two primary processing models. The first involves ''synchronous'' display of new frames produced by the OffscreenCanvas. The application generates new frames using the RenderingContext obtained from the OffscreenCanvas. When the application is finished rendering each new frame, it calls transferToImageBitmap to "tear off" the most recently rendered image from the OffscreenCanvas -- like a Post-It note. The resulting ImageBitmap can then be used in any API receiving that data type; notably, it can be displayed in a second canvas without introducing a copy. An ImageBitmapRenderingContext is obtained from the second canvas by calling <code>getContext('bitmaprenderer')</code>. Each frame is displayed in the second canvas using the <code>transferImageBitmap</code> method on this rendering context. Note that the threads producing and consuming the frames may be the same, or they may be different. Note also that a single OffscreenCanvas may transfer frames into an arbitrary number of other ImageBitmapRenderingContexts.<br />
<br />
The second processing model involves ''asynchronous'' display of new frames produced by the OffscreenCanvas. The main thread instantiates an HTMLCanvasElement and calls <code>transferControlToOffscreeen</code>. <code>getContext</code> is used to obtain a rendering context for that OffscreenCanvas, either on the main thread, or on a worker. The application calls <code>commit</code> against that rendering context in order to push frames to the original HTMLCanvasElement. In this rendering model, it is not defined when those frames become visible in the original canvas element. However, if the following situations apply:<br />
<br />
* It is a worker thread which is calling commit(), and<br />
* The worker is calling commit() repeatedly against exactly one rendering context<br />
<br />
then it is required that the user agent synchronize the calls to commit() to the vsync interval. Calls to commit() conceptually enqueue frames for display, and after an implementation-defined number of frames have been enqueued, further calls to commit() will block until earlier frames have been presented to the screen. (This requirement allows porting of applications which drive their own main loop rather than using an event-driven loop.)<br />
<br />
==== Limitations ==== <br />
<br />
* A known good way to drive an animation loop from a worker is needed. requestAnimationFrame or a similar API needs to be defined on worker threads.<br />
* Some parts of the CanvasRenderingContext2D interface shall not be supported due OffscreenCanvas objects having no relation to the DOM or Frame: HitRegions, scrollPathIntoView, drawFocusIfNeeded.<br />
* Due to technical challenges, some implementors [https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29 (Google and Mozilla)] have expressed a desire to ship without initially supporting text rendering in 2D contexts. Open Issue: Should text support be formally excluded from the specification until implementors are prepared to ship it (or until a more feasible API is designed)?<br />
<br />
==== Implementation ==== <br />
<br />
This proposal has been vetted by developers of Apple's Safari, Google's Chrome, Microsoft's Internet Explorer, and Mozilla's Firefox browsers. All vendors agreed upon the basic form of the API, so it is likely it will be implemented widely and compatibly.<br />
<br />
==== Adoption ==== <br />
<br />
Web page authors have demanded increased parallelism support from the web platform for multiple years. If support for multithreaded rendering is added, it is likely it will be rapidly adopted.<br />
<br />
==== Example code ====<br />
<br />
Jeff Gilbert from Mozilla has crafted some example code utilizing this API:<br />
<br />
* [https://github.com/jdashg/snippets/tree/master/webgl-from-worker Rendering WebGL from a worker using the commit() API]<br />
* [https://github.com/jdashg/snippets/blob/master/webgl-one-to-many/index.html Using one WebGL context to render to many Canvas elements]<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10036ImageBitmap Options2016-02-10T20:42:37Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Web IDL ==<br />
<br />
enum ImageOrientation { "none", "flipY" };<br />
enum PremultiplyAlpha { "none", "premultiply", "default" };<br />
enum ColorspaceConversion { "none", "default" };<br />
dictionary ImageBitmapOptions {<br />
ImageOrientation imageOrientation = "none";<br />
PremultiplyAlpha premultiplyAlpha = "default";<br />
ColorspaceConversion colorspaceConversion = "default";<br />
};<br />
<br />
partial interface ImageBitmapFactories {<br />
Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image, optional ImageBitmapOptions options);<br />
Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image, long sx, long sy, long sw, long sh, optional ImageBitmapOptions options);<br />
};<br />
<br />
* Note: This IDL reflects the "Strongly desired options" below.<br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'premultiply': Image sources that have raw image data that is not premultiplied by alpha will have their color components multiplied by alpha and image sources that are premultiplied by alpha will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected. <blockquote><p>Note: this is a convenience feature. At this moment, using the process of XHR->Blob->ImageBitmap will achieve the same goal.</p></blockquote><br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10035ImageBitmap Options2016-02-10T20:12:21Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Web IDL ==<br />
<br />
enum ImageOrientation { "none", "flipY" };<br />
enum PremultiplyAlpha { "none", "premultiply", "default" };<br />
enum ColorspaceConversion { "none", "default" };<br />
dictionary ImageBitmapOptions {<br />
ImageOrientation imageOrientation = "none";<br />
PremultiplyAlpha premultiplyAlpha = "default";<br />
ColorspaceConversion colorspaceConversion = "default";<br />
};<br />
<br />
partial interface ImageBitmapFactories {<br />
Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image, ImageBitmapOptions options);<br />
Promise<ImageBitmap> createImageBitmap(ImageBitmapSource image, long sx, long sy, long sw, long sh, ImageBitmapOptions options);<br />
};<br />
<br />
* Note: This IDL reflects the "Strongly desired options" below.<br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'premultiply': Image sources that have raw image data that is not premultiplied by alpha will have their color components multiplied by alpha and image sources that are premultiplied by alpha will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected. <blockquote><p>Note: this is a convenience feature. At this moment, using the process of XHR->Blob->ImageBitmap will achieve the same goal.</p></blockquote><br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10034ImageBitmap Options2016-02-10T19:52:42Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'premultiply': Image sources that have raw image data that is not premultiplied by alpha will have their color components multiplied by alpha and image sources that are premultiplied by alpha will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected. <blockquote><p>Note: this is a convenience feature. At this moment, using the process of XHR->Blob->ImageBitmap will achieve the same goal.</p></blockquote><br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10033ImageBitmap Options2016-02-10T19:49:41Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'true': Image sources that have raw image data that is not premultiplied by alpha will have their color components multiplied by alpha and image sources that are premultiplied by alpha will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected. <blockquote><p>Note: this is a convenience feature. At this moment, using the process of XHR->Blob->ImageBitmap will achieve the same goal.</p></blockquote><br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10032ImageBitmap Options2016-02-09T15:46:48Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected. <blockquote><p>Note: this is a convenience feature. At this moment, using the process of XHR->Blob->ImageBitmap will achieve the same goal.</p></blockquote><br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10031ImageBitmap Options2016-02-08T21:31:47Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: 2D Canvases may or may not be stored in premultipled form, depending on the implementation.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10030ImageBitmap Options2016-02-08T20:47:44Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that have raw image data that is not premultiplied by alpha will be left untouched and image sources that are premultiplied by alpha will have their color components divided by alpha.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10029ImageBitmap Options2016-02-08T19:50:54Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>'none': Do not change orientation.</p><p>'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that are premultiplied by alpha will have their color components divided by alpha and image sources that are not premultiplied will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* enum imageOrientation, 'topLeft' and 'bottomLeft' <blockquote><p>'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p><blockquote> <br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10028ImageBitmap Options2016-02-05T19:40:26Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0114.html June 2013 whatwg thread]</cite><br />
* <cite>[https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0075.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>(Higher priority) 'none': Do not change orientation.</p><p>(Higher priority) 'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p><p>(Lower priority) 'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>(Lower priority) 'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that are premultiplied by alpha will have their color components divided by alpha and image sources that are not premultiplied will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10027ImageBitmap Options2016-02-04T15:47:06Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-June/039793.html June 2013 whatwg thread]</cite><br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/039983.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>(Higher priority) 'none': Do not change orientation.</p><p>(Higher priority) 'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p><p>(Lower priority) 'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>(Lower priority) 'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that are premultiplied by alpha will have their color components divided by alpha and image sources that are not premultiplied will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
* DOMString? crossOrigin: The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10026ImageBitmap Options2016-02-04T03:17:22Z<p>Xidachen: </p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-June/039793.html June 2013 whatwg thread]</cite><br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/039983.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>(Higher priority) 'none': Do not change orientation.</p><p>(Higher priority) 'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p><p>(Lower priority) 'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>(Lower priority) 'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p></blockquote><br />
* enum colorspaceConversion, default = 'default' <blockquote><p>'none': The ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p> <p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p></blockquote><br />
* enum premultiplyAlpha, default = 'default' <blockquote><p>'none': Image sources that are premultiplied by alpha will have their color components divided by alpha and image sources that are not premultiplied will be left untouched.</p><p>'default': Implementation-specific behavior, possibly optimized for the implementation's graphics framework.</p><p>When premultiplyAlpha is set to 'none', the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
* DOMString? crossOrigin, default = null <blockquote><p>The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.</p><p>Compared with the previous three options, this option has relatively lower priority.</p><br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: These options affect the internal color representation used to store the ImageBitmap's bitmap data. The only observable effects would be on color fidelity. There would be no re-interpretation of color values. This is important because treating unpremultiplied colors as premultiplied is evil. For example, in blink's implementation, setting both options to 'none' would have no side-effects on the graphical results of CanvasRenderingContext2D.drawImage(). The only difference would be that the color-space conversion and the multiplication by alpha would be deferred to drawImage(), instead of being applied during ImageBitmap creation. The usefulness of 'none' is strictly for preventing losses in precision and gamut that may result from dividing by alpha and/or reversing the default color-space conversion when using APIs that would require it (WebGL's UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameters)<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachenhttps://wiki.whatwg.org/index.php?title=ImageBitmap_Options&diff=10025ImageBitmap Options2016-02-04T02:36:13Z<p>Xidachen: First try on editing the imageOrientation option</p>
<hr />
<div><br />
This page is a Work in Progress<br />
<br />
<br />
'''Problem to be solved''': Loading and preparing image resources for rendering to 2D canvas contexts and WebGL contexts is often inefficient using existing APIs.<br />
<br />
== Use Case Description ==<br />
:WebGL applications often use image media for transferring non-image data (illumination maps, vector maps, etc.) For such applications the image data must usually be decoded without colorspace conversions and without alpha premultiplications.<br />
<br />
=== Current Usage and Workarounds ===<br />
<br />
:Currently, there are several ways to apply arbitrary transformations on the client side, many of which involve intermediate copies of the image data. Some solutions involve DataURLs, temporary canvases, or direct manipulation of image data arrays, which are inefficient. Preparing the resources asynchronously also presents an additional challenge to the web developer.<br />
<br />
:WebGL applications can request that colorspace conversions be skipped at texture upload time by specifying pixel storage parameters, but this currently causes a synchronous image decode, because it is not known in advance that the image will need to be decoded in a special way. This latency is a significant problem for applications that upload many images to the GPU, such as Google Maps.<br />
<br />
:ImageBitmap offers an opportunity to provide exactly the desired image decoding options when the image is fetched, so that when the ImageBitmap is ready, it is in exactly the desired form for upload to the GPU.<br />
<br />
=== Benefits ===<br />
<br />
:With the right API support, image resources can be prepared asynchronously and/or in advance to avoid rendering latency issues. Furthermore, the preparation steps could be performed by native code, and in many case they can be integrated directly into the image decoding step without any additional memory consumption and little or no additional computational burden.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-June/039793.html June 2013 whatwg thread]</cite><br />
* <cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/039983.html July 2013 whatwg thread]</cite><br />
<br />
== Proposed Solutions ==<br />
<br />
=== ImageBitmap Construction Options ===<br />
<br />
:Add an optional ''options'' argument to createImageBitmap to specify image treatments to be applied when creating the ImageBitmap object.<br />
<br />
==== Strongly desired options ====<br />
<br />
* enum imageOrientation, default = 'none' <blockquote><p>(Higher priority) 'none': Do not change orientation.</p><p>(Higher priority) 'flipY': Flip image vertically, disregarding image orientation meta data (EXIF or other), if any.</p><p>(Lower priority) 'topLeft': identify visual orientation from image media meta data and re-order data so top-down, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with bottomLeft orientation. If the image source holds no orientation information, the image orientation is not changed.</p><p>(Lower priority) 'bottomLeft': identify visual orientation from image media meta data and re-order data so bottom-up, left-to-right processing for display results in correct visual orientation. If the image source is an ImageBitmap, the image data will be flipped vertically if and only if the source was created with topLeft orientation. If the image source holds no orientation information, the image is flipped vertically.</p></blockquote><br />
* boolean colorspaceConversion, default = true <blockquote><p>If set to false, the ImageBitmap must be created by decoding the source image media without performing any colorspace conversions. This means that the image decoding algorithm must ignore color profile meta-data embedded in the image source as well as the display device color profile. colorspaceConversion only applies when creating ImageBitmaps from bitmap media data (i.e. blobs and image elements with non-vector images)</p></blockquote><br />
* boolean premultiplyAlpha, default = true <blockquote><p>If set to false, image sources that are premultiplied by alpha will have their color components divided by alpha and image sources that are not premultiplied will be left untouched.</p><p>If set to true, image sources that are not premultiplied by alpha will have their color components multiplied by alpha and image sources that are premultiplied will be left untouched.</p><p>When premultiplyAlpha is set to false, the division by alpha may result in loss of precision, which must be avoided whenever possible. For example, if the image source is a blob or an image element, the decoded image may already be available in premultipled form. Rather than divide the already decoded data, the user agent must re-decode the image without premultiplying, thus ensuring that the ImageBitmap is delivered with the highest quality data.</p><p>Image sources that do not have an alpha channel are not affected by this option.</p><p>Caution: Canvases are assumed to be premultiplied image sources, which may not always be accurate.</p><br />
</blockquote><br />
* DOMString? crossOrigin, default = null <blockquote><p>The crossOrigin option is a [[https://html.spec.whatwg.org/multipage/infrastructure.html#cors-settings-attribute CORS settings attribute]]. It is consulted when [[ImageBitmap Constructor taking URL|constructing an ImageBitmap from the URL of an image]]. Because ImageBitmaps can only be constructed from same-origin resources, in order to construct an ImageBitmap from the URL of a cross-origin image resource, the crossOrigin option must be specified, and the server must grant the request. Otherwise the Promise returned from createImageBitmap will be rejected.<br />
</blockquote><br />
<br />
==== Other potentially useful options ====<br />
<br />
* resizedWidth, resizedHeight: dimension to which the image should be resized. Could also be expressed using scale factors<br />
* resizeFilter: filtering method used for scaling the image (pixelated, low quality, high quality, etc.)<br />
* frameIndex: for creating an image bitmap from multi-frame image media<br />
* flipX: like flipY but horizontal<br />
* colorspace: to decode images to a colorspace other than the device colorspace (sRGB, Adobe RGB, YUV, YCbCr, etc.)<br />
* custom color tranforms: color matrix, 3D Look up tables, per component look up tables, bias, gain, ... <br />
<br />
==== Processing Model ====<br />
: TBD ''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''<br />
<br />
==== Limitations ==== <br />
: TBD ''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''<br />
<br />
==== Implementation ==== <br />
: TBD ''Description of how and why browser vendors would take advantage of this feature.''<br />
<br />
==== Adoption ==== <br />
* Easier to develop asychronous image resource loading and preparation<br />
* Better performance that what can be implemented using current APIs<br />
* Applications can rely on the browser resource management facilities for caching decoded image data with the desired options baked-in and for evicting pre-decoded resources in low memory conditions to avoid out-of-memory crashes.<br />
<br />
==== See Also ====<br />
<br />
Related is the [[ImageBitmap Constructor taking URL]].<br />
<br />
<br />
[[Category:Proposals]]</div>Xidachen