15041 2011-12-02 11:25:10 +0000 Clarify dimensions of image returned by Canvas toDataURL 2013-03-11 23:49:21 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED FIXED P2 normal --- 1 jknotten silviapfeiffer1 cabanier eoconnor erika.doyle ian jackalmage mike plh public-html-admin public-html-wg-issue-tracking silviapfeiffer1 smfr public-html-bugzilla oldest_to_newest 60772 0 jknotten 2011-12-02 11:25:10 +0000 It seems suggested, but not explicitly stated, that the dimensions of the image produced by toDataURL will match that of the underlying image data, as returned by context.getImageData(). The dimensions of the produced image will, therefore, not necessarily be the same as width and height properties of the canvas. It would be great to clarify this point in the spec. Below are some related paragraphs in the spec: 4.8.11.1 "The toDataURL() method must not include color space information in the resource returned. Where the output format allows it, the color of pixels in resources created by toDataURL() must match those returned by the getImageData() method." ... "Thus, in the 2D context, calling the drawImage() method to render the output of the toDataURL() method to the canvas, given the appropriate dimensions, has no visible effect." 60777 1 jackalmage 2011-12-02 16:30:18 +0000 I disagree that toDataURL should have the same behavior as getImageData here. getImageData is sensitive to the backing-store resolution, and importantly, will correctly round-trip an image. toDataURL should be producing an image identical to what's displayed in the canvas. If it produces an image with one image pixel = one backing store pixel, then it won't roundtrip through canvas, which your spec quote implies should happen. toDataURL, thus, should use screen pixels, not backing store pixels. If an output format support sub-pixel information, then sure, include it. But for formats like JPEG and PNG, it shouldn't. 60826 2 smfr 2011-12-02 19:15:50 +0000 (In reply to comment #1) > toDataURL should be producing an image identical to what's displayed in the > canvas. If it produces an image with one image pixel = one backing store > pixel, then it won't roundtrip through canvas, which your spec quote implies > should happen. > > toDataURL, thus, should use screen pixels, not backing store pixels. These two statements are not logically consistent. If the canvas has 2x backing store, but toDataURL uses screen pixels, then the toDataURL image will look fuzzy compared to the canvas on a 2x display. 60830 3 jackalmage 2011-12-02 19:22:05 +0000 (In reply to comment #2) > (In reply to comment #1) > > > toDataURL should be producing an image identical to what's displayed in the > > canvas. If it produces an image with one image pixel = one backing store > > pixel, then it won't roundtrip through canvas, which your spec quote implies > > should happen. > > > > toDataURL, thus, should use screen pixels, not backing store pixels. > > These two statements are not logically consistent. If the canvas has 2x backing > store, but toDataURL uses screen pixels, then the toDataURL image will look > fuzzy compared to the canvas on a 2x display. But an image generated with 1 image pixel = 1 backing-store pixel will look double-size. So, we've gotta make some sacrifices somewhere. 60831 4 smfr 2011-12-02 19:23:20 +0000 (In reply to comment #3) > But an image generated with 1 image pixel = 1 backing-store pixel will look > double-size. > > So, we've gotta make some sacrifices somewhere. Right. So do you make things lossy but work for naive web developers, or non-lossy but require a bit more web author smarts? We went the latter route for getImageData(). 60832 5 jackalmage 2011-12-02 19:27:15 +0000 (In reply to comment #4) > (In reply to comment #3) > > But an image generated with 1 image pixel = 1 backing-store pixel will look > > double-size. > > > > So, we've gotta make some sacrifices somewhere. > > Right. So do you make things lossy but work for naive web developers, or > non-lossy but require a bit more web author smarts? We went the latter route > for getImageData(). Yes, and I think that was the right choice - when you're pulling out the image data explicitly, you generally actually want the real data. However, there's no way to express the dpi of an image in a way that a web browser will automatically pay attention to, unfortunately. 67294 6 ian 2012-05-03 16:48:16 +0000 We're likely to add an HD version of getImageData() that's defined as the current one is and redefine the current one to use CSS pixel resolution, so maybe we should do the same with toDataURL and have a toDataURLHD? 67296 7 eoconnor 2012-05-03 17:08:14 +0000 Sounds reasonable to me. 70418 8 contributor 2012-07-18 07:27:38 +0000 This bug was cloned to create bug 17978 as part of operation convergence. 72073 9 silviapfeiffer1 2012-08-11 05:55:47 +0000 Moved to canvas component. 72544 10 cabanier 2012-08-22 18:37:07 +0000 This is a new feature. Moving it to HTML.next This is also not part of the canvas 2D spec. Moving it to HTML 81709 11 robin 2013-01-21 15:59:12 +0000 Mass move to "HTML WG" 81827 12 robin 2013-01-21 16:01:58 +0000 Mass move to "HTML WG" 84273 13 erika.doyle 2013-03-11 23:49:21 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: None (already in the spec) Rationale: Since the filing of this bug, the W3C spec has incorporated the toDataURL, toDataURLHD, getImageData, and getImageDataHD definitions and clarifying text from the WHATWG spec: https://github.com/w3c/html/commit/857a787b304e602a1cb2fea21b6dbfcb29107a09