OASIS Static Analysis Results Interchange Format (SARIF) TC

We got tied up in knots this morning discussing how to draw rectangles on files like PDF and SVG. But PDF is not an image format . If a SARIF producer wants to draw rectangles on a PDF, it can take a screenshot, or use a PDF-to-JPEG converter. Likewise, SVG (although unquestionably an image format) is a text representation. A SARIF producer could specify a region containing the XML elements of interest, and a viewer that knows how to render SVG could add the necessary decorations to highlight the area. Or again, the producer could convert to a pixel-based image file.   We can certainly continue to talk about improvements to image-like attachments, but I propose we limit “rectangle” support to pixel-based image files, and suggest “take a screenshot” or “convert to JPEG or PNG” for anything else. After all, the original motivation for what became generic image support was precisely that: screenshots.   Larry

Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels).
 
In hindsight, I personally regret my contributions to this discussion.

Thanks Michael. That raises a procedural issue: according to the minutes, the TC approved #137 with certain changes. Most of them are still good, but this part of this one is not:   Jim: make values float and change pixels to units appropriate for format   I will merge the changes as we’ve discussed here: supporting only raster-based formats and requiring units of pixels (although they are float values, and can be signed).   Then I will add an item to the agenda for the next TC meeting to ratify this decision.   Larry   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Wednesday, May 2, 2018 5:18 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels).   In hindsight, I personally regret my contributions to this discussion.

FYI, here’s the relevant text in the provisional draft: 3.14.5 [attachment.]rectangles property If the attachment is a raster-based image file (for example .png , .jpg , .gif , or .bmp ), an attachment object MAY contain a property named rectangles whose value is an array of one or more unique (§3.6.2) rectangle objects (§3.23), each of which specifies an area of interest within the image. These rectangle objects SHOULD contain a message property (§3.23.3) so a user can understand their relevance. If the attachment is not a raster-based image file, rectangles SHALL be absent. NOTE: If a SARIF producer wished to highlight areas in a non-raster based image file such as .svg , or a non-image file such as .pdf , it might export the file to a raster-based image format, attach the exported image file, and specify the rectangles on that image. …   3.23.2 [rectangle.]top, left, bottom, and right properties A rectangle object SHALL contain properties named top , left , bottom , and right , each of which contains a number (as defined by [ JSCHEMA01 ]) specifying one of the coordinates of the rectangle within the image. These properties SHALL be measured in pixels . Pixel values SHALL increase from left to right and from top to bottom . Pixel values MAY be positive of negative , depending on the natural coordinate system of the image. NOTE: A number in JSON schema can take a variety of forms, including simple integers ( 42 ) and floating point numbers ( 3.14 ).   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Thursday, May 3, 2018 1:28 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Thanks Michael. That raises a procedural issue: according to the minutes, the TC approved #137 with certain changes. Most of them are still good, but this part of this one is not:   Jim: make values float and change pixels to units appropriate for format   I will merge the changes as we’ve discussed here: supporting only raster-based formats and requiring units of pixels (although they are float values, and can be signed).   Then I will add an item to the agenda for the next TC meeting to ratify this decision.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, May 2, 2018 5:18 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels).   In hindsight, I personally regret my contributions to this discussion.

Thanks Larry. I am not a raster image format expert. Is there, in fact, a pixel-based image format that supports negative (and/or non-integral) pixel values?
 
“Pixel values MAY be positive of negative , depending on the natural coordinate system of the image”
 


From: Larry Golding (Comcast) <larrygolding@comcast.net>

Sent: Thursday, May 3, 2018 2:27 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Image files: wait just a minute here!


 
FYI, here’s the relevant text in the provisional draft:
3.14.5 [attachment.]rectangles property
If the attachment is a
raster-based image file (for example .png ,
.jpg ,
.gif , or
.bmp ), an
attachment object
MAY contain a property named rectangles
whose value is an array of one or more unique (§3.6.2)
rectangle objects (§3.23), each of which specifies an area of interest within the image. These
rectangle objects
SHOULD contain a message property (§3.23.3) so a user can understand their relevance.
If the attachment is not a raster-based image file,
rectangles
SHALL be absent.
NOTE: If a SARIF producer wished to highlight areas
in a non-raster based image file such as
.svg , or a non-image file such as
.pdf , it might export the file to a raster-based image format, attach the exported image file, and specify the rectangles on that image.
…
 
3.23.2 [rectangle.]top, left, bottom, and right properties
A rectangle object SHALL contain properties named
top ,
left , bottom , and
right , each of which contains
a number (as defined by [ JSCHEMA01 ]) specifying one of the coordinates of the rectangle within the image. These properties
SHALL be measured in pixels . Pixel values
SHALL increase from left to right and from top to bottom . Pixel values
MAY be positive of negative , depending on the natural coordinate system of the image.
NOTE: A number in JSON schema can take a variety of forms, including simple integers ( 42 ) and floating point numbers ( 3.14 ).
 
Larry
 


From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
On Behalf Of Larry Golding (Comcast)
Sent: Thursday, May 3, 2018 1:28 PM
To: 'Michael Fanning' < Michael.Fanning@microsoft.com >;
sarif@lists.oasis-open.org
Subject: RE: [sarif] Image files: wait just a minute here!


 
Thanks Michael. That raises a procedural issue: according to the minutes, the TC approved #137 with certain changes. Most of them are still good, but
this part of this one is not:
 
Jim: make values float and
change pixels to units appropriate for format
 
I will merge the changes as we’ve discussed here: supporting only raster-based formats and requiring units of pixels (although they are float values, and can be signed).
 
Then I will add an item to the agenda for the next TC meeting to ratify this decision.
 
Larry
 


From: Michael Fanning < Michael.Fanning@microsoft.com >

Sent: Wednesday, May 2, 2018 5:18 PM
To: Larry Golding (Comcast) < larrygolding@comcast.net >;
sarif@lists.oasis-open.org
Subject: RE: [sarif] Image files: wait just a minute here!


 
Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels).
 
In hindsight, I personally regret my contributions to this discussion.

I don’t know. Jim , is it possible that now that we’ve restricted ourselves to raster-based image formats, that we can restrict the coordinates to non-negative integers?   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Thursday, May 3, 2018 2:57 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Thanks Larry. I am not a raster image format expert. Is there, in fact, a pixel-based image format that supports negative (and/or non-integral) pixel values?   “Pixel values MAY be positive of negative , depending on the natural coordinate system of the image”   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Thursday, May 3, 2018 2:27 PM To: Michael Fanning < Michael.Fanning@microsoft.com >; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   FYI, here’s the relevant text in the provisional draft: 3.14.5 [attachment.]rectangles property If the attachment is a raster-based image file (for example .png , .jpg , .gif , or .bmp ), an attachment object MAY contain a property named rectangles whose value is an array of one or more unique (§3.6.2) rectangle objects (§3.23), each of which specifies an area of interest within the image. These rectangle objects SHOULD contain a message property (§3.23.3) so a user can understand their relevance. If the attachment is not a raster-based image file, rectangles SHALL be absent. NOTE: If a SARIF producer wished to highlight areas in a non-raster based image file such as .svg , or a non-image file such as .pdf , it might export the file to a raster-based image format, attach the exported image file, and specify the rectangles on that image. …   3.23.2 [rectangle.]top, left, bottom, and right properties A rectangle object SHALL contain properties named top , left , bottom , and right , each of which contains a number (as defined by [ JSCHEMA01 ]) specifying one of the coordinates of the rectangle within the image. These properties SHALL be measured in pixels . Pixel values SHALL increase from left to right and from top to bottom . Pixel values MAY be positive of negative , depending on the natural coordinate system of the image. NOTE: A number in JSON schema can take a variety of forms, including simple integers ( 42 ) and floating point numbers ( 3.14 ).   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Thursday, May 3, 2018 1:28 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com >; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Thanks Michael. That raises a procedural issue: according to the minutes, the TC approved #137 with certain changes. Most of them are still good, but this part of this one is not:   Jim: make values float and change pixels to units appropriate for format   I will merge the changes as we’ve discussed here: supporting only raster-based formats and requiring units of pixels (although they are float values, and can be signed).   Then I will add an item to the agenda for the next TC meeting to ratify this decision.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Wednesday, May 2, 2018 5:18 PM To: Larry Golding (Comcast) < larrygolding@comcast.net >; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here!   Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels).   In hindsight, I personally regret my contributions to this discussion.

If images are restricted to a raster image, then it seems that all the formats I looked at use positive integer coordinate values, where the top, left value has the coordinate (0, 0). This is not true for vector graphics formats, where negative and decimal values are allowed. I do not see a reason to restrict images to raster formats only. Jim On 05/03/2018 05:21 PM, Larry Golding (Comcast) wrote: I don’t know. *Jim*, is it possible that now that we’ve restricted ourselves to raster-based image formats, that we can restrict the coordinates to non-negative integers? *From:* Michael Fanning <Michael.Fanning@microsoft.com> *Sent:* Thursday, May 3, 2018 2:57 PM *To:* Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org *Subject:* RE: [sarif] Image files: wait just a minute here! Thanks Larry. I am not a raster image format expert. Is there, in fact, a pixel-based image format that supports negative (and/or non-integral) pixel values? “Pixel values *MAY*be positive of negative, depending on the natural coordinate system of the image” *From:* Larry Golding (Comcast) <larrygolding@comcast.net < mailto:larrygolding@comcast.net >> *Sent:* Thursday, May 3, 2018 2:27 PM *To:* Michael Fanning <Michael.Fanning@microsoft.com < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > *Subject:* RE: [sarif] Image files: wait just a minute here! FYI, here’s the relevant text in the provisional draft: *3.14.5 [attachment.]rectangles property* If the attachment is a raster-based image file (for example .png, .jpg, .gif, or .bmp), an attachment object *MAY* contain a property namedrectangles whose value is an array of one or more unique (§3.6.2) rectangle objects (§3.23), each of which specifies an area of interest within the image. These rectangle objects *SHOULD* contain a message property (§3.23.3) so a user can understand their relevance. If the attachment is not a raster-based image file, rectangles *SHALL* be absent. NOTE: If a SARIF producer wished to highlight areas in a non-raster based image file such as .svg, or a non-image file such as .pdf, it might export the file to a raster-based image format, attach the exported image file, and specify the rectangles on that image. … *3.23.2 [rectangle.]top, left, bottom, and right properties* A rectangle object *SHALL* contain properties named top, left, bottom, and right, each of which contains a number (as defined by [JSCHEMA01 <#JSCHEMA01>]) specifying one of the coordinates of the rectangle within the image. These properties *SHALL*be measured in pixels. Pixel values *SHALL*increase from left to right and from top to bottom. Pixel values *MAY*be positive of negative, depending on the natural coordinate system of the image. NOTE: A number in JSON schema can take a variety of forms, including simple integers (42) and floating point numbers (3.14). Larry *From:* sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > <sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org >> *On Behalf Of *Larry Golding (Comcast) *Sent:* Thursday, May 3, 2018 1:28 PM *To:* 'Michael Fanning' <Michael.Fanning@microsoft.com < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > *Subject:* RE: [sarif] Image files: wait just a minute here! Thanks Michael. That raises a procedural issue: according to the minutes, the TC approved #137 with certain changes. Most of them are still good, but *this part* of this one is not: Jim: make values float and *change pixels to units appropriate for format* I will merge the changes as we’ve discussed here: supporting only raster-based formats and requiring units of pixels (although they are float values, and can be signed). Then I will add an item to the agenda for the next TC meeting to ratify this decision. Larry *From:* Michael Fanning <Michael.Fanning@microsoft.com < mailto:Michael.Fanning@microsoft.com >> *Sent:* Wednesday, May 2, 2018 5:18 PM *To:* Larry Golding (Comcast) <larrygolding@comcast.net < mailto:larrygolding@comcast.net >>; sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > *Subject:* RE: [sarif] Image files: wait just a minute here! Ok, so we might indeed have really tied ourselves into knots. Your original text, perhaps with the addition of emphasizing that this construct is relevant for raster image formats only, was right (including the use of the term pixels). In hindsight, I personally regret my contributions to this discussion.

Based on this (Larry, sorry!), we would return to Larry's original text. For raster images, rect values are >=0 integral values, where top/left has the coordinate 0,0. For vector images, the rect properties represent top, left, right, bottom values. A consumer will need to use this information to drive whatever line/polyline primitives will render the bounding rectangle. Jim, does that sound right? Do we need language that says, you need to interpret this data, for vector formats, according to the expected coordinate system of the format? Do we need to explicitly note we support only 2D coordinate system (no 3d bounding rectangle for us)?
Original Message----- From: James A. Kupsch <kupsch@cs.wisc.edu> Sent: Friday, May 4, 2018 11:13 AM To: Larry Golding (Comcast) <larrygolding@comcast.net>; Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org Subject: Re: [sarif] Image files: wait just a minute here! If images are restricted to a raster image, then it seems that all the formats I looked at use positive integer coordinate values, where the top, left value has the coordinate (0, 0). This is not true for vector graphics formats, where negative and decimal values are allowed. I do not see a reason to restrict images to raster formats only. Jim On 05/03/2018 05:21 PM, Larry Golding (Comcast) wrote: > I don’t know. *Jim*, is it possible that now that we’ve restricted > ourselves to raster-based image formats, that we can restrict the > coordinates to non-negative integers? > > *From:* Michael Fanning <Michael.Fanning@microsoft.com> > *Sent:* Thursday, May 3, 2018 2:57 PM > *To:* Larry Golding (Comcast) <larrygolding@comcast.net>; > sarif@lists.oasis-open.org > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Thanks Larry. I am not a raster image format expert. Is there, in > fact, a pixel-based image format that supports negative (and/or > non-integral) pixel values? > > “Pixel values *MAY*be positive of negative, depending on the natural > coordinate system of the image” > > *From:* Larry Golding (Comcast) <larrygolding@comcast.net > < mailto:larrygolding@comcast.net >> > *Sent:* Thursday, May 3, 2018 2:27 PM > *To:* Michael Fanning <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > FYI, here’s the relevant text in the provisional draft: > > > *3.14.5 [attachment.]rectangles property* > > If the attachment is a raster-based image file (for example .png, > .jpg, .gif, or .bmp), an attachment object *MAY* contain a property > namedrectangles whose value is an array of one or more unique (§3.6.2) > rectangle objects (§3.23), each of which specifies an area of interest > within the image. These rectangle objects *SHOULD* contain a message > property (§3.23.3) so a user can understand their relevance. > > If the attachment is not a raster-based image file, rectangles *SHALL* > be absent. > > NOTE: If a SARIF producer wished to highlight areas in a non-raster > based image file such as .svg, or a non-image file such as .pdf, it > might export the file to a raster-based image format, attach the > exported image file, and specify the rectangles on that image. > > … > > > *3.23.2 [rectangle.]top, left, bottom, and right properties* > > A rectangle object *SHALL* contain properties named top, left, bottom, > and right, each of which contains a number (as defined by [JSCHEMA01 > <#JSCHEMA01>]) specifying one of the coordinates of the rectangle > within the image. These properties *SHALL*be measured in pixels. Pixel > values *SHALL*increase from left to right and from top to bottom. > Pixel values *MAY*be positive of negative, depending on the natural > coordinate system of the image. > > NOTE: A number in JSON schema can take a variety of forms, including > simple integers (42) and floating point numbers (3.14). > > Larry > > *From:* sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > > <sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org >> *On > Behalf Of *Larry Golding (Comcast) > *Sent:* Thursday, May 3, 2018 1:28 PM > *To:* 'Michael Fanning' <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Thanks Michael. That raises a procedural issue: according to the > minutes, the TC approved #137 with certain changes. Most of them are > still good, but *this part* of this one is not: > > Jim: make values float and *change pixels to units appropriate for > format* > > I will merge the changes as we’ve discussed here: supporting only > raster-based formats and requiring units of pixels (although they are > float values, and can be signed). > > Then I will add an item to the agenda for the next TC meeting to > ratify this decision. > > Larry > > *From:* Michael Fanning <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >> > *Sent:* Wednesday, May 2, 2018 5:18 PM > *To:* Larry Golding (Comcast) <larrygolding@comcast.net > < mailto:larrygolding@comcast.net >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Ok, so we might indeed have really tied ourselves into knots. Your > original text, perhaps with the addition of emphasizing that this > construct is relevant for raster image formats only, was right > (including the use of the term pixels). > > In hindsight, I personally regret my contributions to this discussion. > >

Michael, I agree with what you say, _if_ we restrict to raster images. Jim asked why we should restrict to raster images. My reason was that we got hung up attempting to define a useful set of units for non-raster images. Jim, is there a simple way to do this? Remember, the original motivation for this was screenshots. From my standpoint, generalizing to raster images is just gravy -- it falls out easily. Incorporating non-raster images and IMO is not worth the trouble (we could add them in a future SARIF as a non-breaking change). (Michael, remember we've come to a meeting of the minds on the acceptability of a SARIF 2.1 that incorporates _only_ additive, non-breaking changes.)
Original Message----- From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Friday, May 4, 2018 11:29 AM To: James A. Kupsch <kupsch@cs.wisc.edu>; Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org Subject: RE: [sarif] Image files: wait just a minute here! Based on this (Larry, sorry!), we would return to Larry's original text. For raster images, rect values are >=0 integral values, where top/left has the coordinate 0,0. For vector images, the rect properties represent top, left, right, bottom values. A consumer will need to use this information to drive whatever line/polyline primitives will render the bounding rectangle. Jim, does that sound right? Do we need language that says, you need to interpret this data, for vector formats, according to the expected coordinate system of the format? Do we need to explicitly note we support only 2D coordinate system (no 3d bounding rectangle for us)?
Original Message----- From: James A. Kupsch <kupsch@cs.wisc.edu> Sent: Friday, May 4, 2018 11:13 AM To: Larry Golding (Comcast) <larrygolding@comcast.net>; Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org Subject: Re: [sarif] Image files: wait just a minute here! If images are restricted to a raster image, then it seems that all the formats I looked at use positive integer coordinate values, where the top, left value has the coordinate (0, 0). This is not true for vector graphics formats, where negative and decimal values are allowed. I do not see a reason to restrict images to raster formats only. Jim On 05/03/2018 05:21 PM, Larry Golding (Comcast) wrote: > I don’t know. *Jim*, is it possible that now that we’ve restricted > ourselves to raster-based image formats, that we can restrict the > coordinates to non-negative integers? > > *From:* Michael Fanning <Michael.Fanning@microsoft.com> > *Sent:* Thursday, May 3, 2018 2:57 PM > *To:* Larry Golding (Comcast) <larrygolding@comcast.net>; > sarif@lists.oasis-open.org > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Thanks Larry. I am not a raster image format expert. Is there, in > fact, a pixel-based image format that supports negative (and/or > non-integral) pixel values? > > “Pixel values *MAY*be positive of negative, depending on the natural > coordinate system of the image” > > *From:* Larry Golding (Comcast) <larrygolding@comcast.net > < mailto:larrygolding@comcast.net >> > *Sent:* Thursday, May 3, 2018 2:27 PM > *To:* Michael Fanning <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > FYI, here’s the relevant text in the provisional draft: > > > *3.14.5 [attachment.]rectangles property* > > If the attachment is a raster-based image file (for example .png, > .jpg, .gif, or .bmp), an attachment object *MAY* contain a property > namedrectangles whose value is an array of one or more unique (§3.6.2) > rectangle objects (§3.23), each of which specifies an area of interest > within the image. These rectangle objects *SHOULD* contain a message > property (§3.23.3) so a user can understand their relevance. > > If the attachment is not a raster-based image file, rectangles *SHALL* > be absent. > > NOTE: If a SARIF producer wished to highlight areas in a non-raster > based image file such as .svg, or a non-image file such as .pdf, it > might export the file to a raster-based image format, attach the > exported image file, and specify the rectangles on that image. > > … > > > *3.23.2 [rectangle.]top, left, bottom, and right properties* > > A rectangle object *SHALL* contain properties named top, left, bottom, > and right, each of which contains a number (as defined by [JSCHEMA01 > <#JSCHEMA01>]) specifying one of the coordinates of the rectangle > within the image. These properties *SHALL*be measured in pixels. Pixel > values *SHALL*increase from left to right and from top to bottom. > Pixel values *MAY*be positive of negative, depending on the natural > coordinate system of the image. > > NOTE: A number in JSON schema can take a variety of forms, including > simple integers (42) and floating point numbers (3.14). > > Larry > > *From:* sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org > > <sarif@lists.oasis-open.org < mailto:sarif@lists.oasis-open.org >> *On > Behalf Of *Larry Golding (Comcast) > *Sent:* Thursday, May 3, 2018 1:28 PM > *To:* 'Michael Fanning' <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Thanks Michael. That raises a procedural issue: according to the > minutes, the TC approved #137 with certain changes. Most of them are > still good, but *this part* of this one is not: > > Jim: make values float and *change pixels to units appropriate for > format* > > I will merge the changes as we’ve discussed here: supporting only > raster-based formats and requiring units of pixels (although they are > float values, and can be signed). > > Then I will add an item to the agenda for the next TC meeting to > ratify this decision. > > Larry > > *From:* Michael Fanning <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@microsoft.com >> > *Sent:* Wednesday, May 2, 2018 5:18 PM > *To:* Larry Golding (Comcast) <larrygolding@comcast.net > < mailto:larrygolding@comcast.net >>; sarif@lists.oasis-open.org > < mailto:sarif@lists.oasis-open.org > > *Subject:* RE: [sarif] Image files: wait just a minute here! > > Ok, so we might indeed have really tied ourselves into knots. Your > original text, perhaps with the addition of emphasizing that this > construct is relevant for raster image formats only, was right > (including the use of the term pixels). > > In hindsight, I personally regret my contributions to this discussion. > >