Topic: std::image
Author: apegomp2@gmail.com
Date: Sat, 7 Jul 2018 07:38:36 -0700 (PDT)
Raw View
------=_Part_49500_842617923.1530974316496
Content-Type: multipart/alternative;
boundary="----=_Part_49501_969000541.1530974316496"
------=_Part_49501_969000541.1530974316496
Content-Type: text/plain; charset="UTF-8"
reddit.com/r/cpp/comments/89we31/2d_graphics_a_more_modest_proposal
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3eec0595-2d31-4b05-9228-86060ff44f10%40isocpp.org.
------=_Part_49501_969000541.1530974316496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><a href=3D"http://reddit.com/r/cpp/comments/89we31/2d=
_graphics_a_more_modest_proposal">reddit.com/r/cpp/comments/89we31/2d_graph=
ics_a_more_modest_proposal</a><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3eec0595-2d31-4b05-9228-86060ff44f10%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3eec0595-2d31-4b05-9228-86060ff44f10=
%40isocpp.org</a>.<br />
------=_Part_49501_969000541.1530974316496--
------=_Part_49500_842617923.1530974316496--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 10 Jul 2018 12:57:10 -0400
Raw View
On 2018-07-07 10:38, apegomp2@gmail.com wrote:
> reddit.com/r/cpp/comments/89we31/2d_graphics_a_more_modest_proposal
> It would support uint8 and float32 data types with n channels.
For me, no uint16 support is a non-starter. Images aren't just about
on-screen graphics, and my line of work often deals with 16-bit image
data. (I suppose the counter-argument here would be that you can
losslessly cram uint16 into float32, but I'm sure someone is going to
squawk about a) having to do that conversion, and b) the space overhead.)
> Pixel storage
I would strongly encourage ability to specify strides.
I think this could be useful, but I would *strongly* recommend referring
to prior art, such as the image classes in Qt, VTK, OpenCV, VXL, and KWIVER.
> What about 10 bit images? No special effort to deal with odd integer
> formats.
Indeed; use uint16. I don't think I've ever seen an in-memory
representation that doesn't use a hardware-native type for storage.
> Maybe somebody could talk me into the importance of 16 or 32 bit
> integer storage, but it'd frankly be a fairly uncommon use case to
> require integer storage of many bits. I know it's not unheard of, but
> I think there's logic in covering the 90% use case as easily as
> possible, rather than making things harder on the 90% for the sake
> of some use cases that will be rare.
The thing is, once you support more than one type *at all*, you've
already done most of the work to add support for any number of types.
And uint16 is not that uncommon, at least in non-display contexts.
One of the advantages to having a common image type is that it isn't
*limited* to use in display contexts. One of the major problems with
Graphics is that it created a whole bunch of types that were tightly
coupled to a display API, that would have been much more useful as
*generic* types. If anything becomes of this proposal, I could see it as
a great opportunity to avoid making that same mistake.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd37616e-52e5-8cb5-f4e4-e265393e05f0%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 10 Jul 2018 13:27:32 -0700 (PDT)
Raw View
------=_Part_26405_2033773305.1531254452388
Content-Type: multipart/alternative;
boundary="----=_Part_26406_1702351855.1531254452388"
------=_Part_26406_1702351855.1531254452388
Content-Type: text/plain; charset="UTF-8"
On the subject of formats, the Khronos Group publishes a pretty
comprehensive specification on data formats
<https://www.khronos.org/registry/DataFormat/>. I'm not saying that such an
image tool needs to handle all of these. Indeed, the more edge cases you
support, the more likelihood someone will come along and say, "but what
about my cases." If you allow 16-bit normalized unsigned integers, I can
easily say "why not 16-bit *signed* normalized integers? A lot of my images
are normals rather than pictures." And if we can have that, why not YUV in
some form; that's pretty common for video work. And on and on and on;
nothing will ever get done in that case.
This is why a focus on 2D graphics kept feature creep out: because the
types it was creating were specific to that use case and no others. Once
you decide that you're just making an "image" type, such a thing now
invites usage from everyone for many purposes.
This kind of unbounded scope is precisely why these things *should not be*
in the standard library at all. There are just too many disparate needs.
Plus, one of the main purposes of putting something in the standard library
is interoperability: I can write an API that uses `std::optional<T>`, and
odds are good you won't mind, not merely because it's available to you, but
because you probably use it yourself.
If I am writing a tool for dealing with Vulkan, and someone else is writing
a tool for dealing with non-display contexts, odds are good that we don't
need to interoperate. I don't need to be able to pass my image types to
him, and vice versa. And even if we could, we're probably talking about
incompatible constructs in some way.
No single "image" type can service the needs of all users of images. It is
exceedingly difficult to say where the line should be drawn however.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1d0a41d2-e7cf-4503-a0d8-c98b2748c7eb%40isocpp.org.
------=_Part_26406_1702351855.1531254452388
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On the subject of formats, the Khronos Group publishe=
s a <a href=3D"https://www.khronos.org/registry/DataFormat/">pretty compreh=
ensive specification on data formats</a>. I'm not saying that such an i=
mage tool needs to handle all of these. Indeed, the more edge cases you sup=
port, the more likelihood someone will come along and say, "but what a=
bout my cases." If you allow 16-bit normalized unsigned integers, I ca=
n easily say "why not 16-bit <i>signed</i> normalized integers? A lot =
of my images are normals rather than pictures." And if we can have tha=
t, why not YUV in some form; that's pretty common for video work. And o=
n and on and on; nothing will ever get done in that case.<br></div><div><br=
></div><div>This is why a focus on 2D graphics kept feature creep out: beca=
use the types it was creating were specific to that use case and no others.=
Once you decide that you're just making an "image" type, suc=
h a thing now invites usage from everyone for many purposes.</div><div><br>=
</div><div>This kind of unbounded scope is precisely why these things <i>sh=
ould not be</i> in the standard library at all. There are just too many dis=
parate needs.</div><div><br></div><div>Plus, one of the main purposes of pu=
tting something in the standard library is interoperability: I can write an=
API that uses `std::optional<T>`, and odds are good you won't mi=
nd, not merely because it's available to you, but because you probably =
use it yourself.</div><div><br></div><div>If I am writing a tool for dealin=
g with Vulkan, and someone else is writing a tool for dealing with non-disp=
lay contexts, odds are good that we don't need to interoperate. I don&#=
39;t need to be able to pass my image types to him, and vice versa. And eve=
n if we could, we're probably talking about incompatible constructs in =
some way.</div><div><br></div><div>No single "image" type can ser=
vice the needs of all users of images. It is exceedingly difficult to say w=
here the line should be drawn however.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1d0a41d2-e7cf-4503-a0d8-c98b2748c7eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d0a41d2-e7cf-4503-a0d8-c98b2748c7eb=
%40isocpp.org</a>.<br />
------=_Part_26406_1702351855.1531254452388--
------=_Part_26405_2033773305.1531254452388--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 11 Jul 2018 12:51:36 -0400
Raw View
On 2018-07-10 16:27, Nicol Bolas wrote:
> The more edge cases you support, the more likelihood someone will
> come along and say, "but what about my cases." If you allow 16-bit
> normalized unsigned integers, I can easily say "why not 16-bit
> *signed* normalized integers? A lot of my images are normals rather
> than pictures."
Normals should probably use float16 or float32, but I don't see a
problem also supporting signed types.
> And if we can have that, why not YUV in some form; that's pretty
> common for video work.
Actually, the original proposal talked about how YUV would be
"supported". The short version is that color spaces don't affect the
type representation. The only variables are pixel scalar type and three
dimensions (height, width, channels/planes).
> And on and on and on; nothing will ever get done in that case.
Er... no. See last paragraph in this message.
> This is why a focus on 2D graphics kept feature creep out: because the
> types it was creating were specific to that use case and no others. Once
> you decide that you're just making an "image" type, such a thing now
> invites usage from everyone for many purposes.
>
> This kind of unbounded scope is precisely why these things *should not be*
> in the standard library at all. There are just too many disparate needs.
There, I have to disagree; one of my main objections to the failed
graphics proposal was that it *was* very narrow in focus. It was useful
if you wanted to do *exactly* what it was designed to let you do, and
nothing else. If you wanted to do something even *slightly* different,
it was an enormous pile of useless baggage.
Compare that to something like std::vector, which is tremendously useful
*because* it is so general-purpose. That is the sort of thing we
*should* be standardizing.
In particular, the creation of linear algebra types that were not
general purpose was probably my single biggest objection to P0267. A
decent suite of *standardized* linear algebra types would be every bit
as useful as std::unordered_map. Standardizing them as specific to 2D
graphics in a way that makes them non-useful for general purpose use
would be a huge mistake.
> Plus, one of the main purposes of putting something in the standard library
> is interoperability: I can write an API that uses `std::optional<T>`, and
> odds are good you won't mind, not merely because it's available to you, but
> because you probably use it yourself.
....and that's exactly why we *do* need a general-purpose type! I should
be able to use a std::image for both graphics and computational
purposes, without having to convert between disparate formats for each
of those tasks. If we don't achieve that, we've explicitly failed to
achieve interoperability.
> If I am writing a tool for dealing with Vulkan, and someone else is writing
> a tool for dealing with non-display contexts, odds are good that we don't
> need to interoperate.
I don't know what world *you* live in, but obviously it is very, very
different from mine. Practically the entire VTK suite, and dozens of
projects built on it, are all about those worlds intersecting and
needing to interoperate. There are entire *industries* built on the
intersection of display and computational imagery.
> No single "image" type can service the needs of all users of images. It is
> exceedingly difficult to say where the line should be drawn however.
Sorry, but this assertion is patently false. Such a type can most
certainly exist, as evidenced by (at least) OpenCV, VXL, VTK and KWIVER
all *already having such a type*. Now, I'm not saying that any single
one of those libraries' image types is *perfect*, but they're generally
good enough to soundly debunk any claim that it's "impossible".
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4bf2521e-c22f-fd0d-2d6b-9ea0160696c4%40gmail.com.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Jul 2018 14:17:22 -0400
Raw View
--0000000000000e87b20570bd42d5
Content-Type: text/plain; charset="UTF-8"
Here's my thoughts.
Background: I've spent 25+ years doing pixel++.
This is all "off the top of my head", but I've seen it (and helped it be)
done a number of times.
What is an image? You need some basis, else you are defining nothing.
An image is more than a 2D vector.
A 2D vector is a worthwhile type (I think the latest proposal is "mdspan" -
md for multi-dimensional), but that's not an image.
An image holds *pixels* (or is able to give/take pixels, whether it
actually holds them)
So we need to define pixels.
If we don't define pixels (and color spaces), QImage can't take a
std::image and do anything with it, etc.
A pixel is colour + alpha. You can claim that alpha is "extra" channel
info, and if you allow alpha, why not 3D depth, etc? Maybe.
(So have a way to expose extra channels, but most code will probably ignore
anything beyond colour and alpha)
Back to image:
For performance, you need a type templated on the pixel type.
Then I can write specialized algorithms for composite() or whatever.
*And* generic (unspecialized) algorithms can also be compiled into faster
code.
template<typename Pixel, typename Pixel>
ImageT<Pixel> composite(ImageT<Pixel> top, ImageT<Pixel> bottom)
{
ImageT<Pixel> dest(union_size(top, bottom));
for (auto & [d, t, b] : intersect_zip(dest, union_zip(top, bottom)))
d = composite_pixel(t, b);
return dest;
}
ImageT<RGBA32> composite(ImageT<RGBA32> top, ImageT<RGBA32> bottom)
{
ImageT<RGBA32> dest;
asm {
....
}
return dest;
}
Then you need an Image (non template) class that has the pixel type decided
at runtime.
Image composite(Image top, Image bottom)
{
Image dest;
if (top.pixelType == bottom.pixelType)
switch (top.pixelType)
{
case PixelType::RGBA32
dest = composite(top.to<RGBA32>(), bottom.to<RGBA32());
break;
case PixelType::Etc
}
else if ... // can add common mixes here
else
// fall back to HiFiPixel, see below
return dest;
}
Here's an important part:
you need a common "base" hi-fidelity pixel type. HiFiPixel. Say RGBA 32bit
floats. Or whatever is enough.
Whenever types don't match, you need to be able to convert every pixel to
this hi-fidelity type.
Every ImageT<T> needs, at minimum, to be able to convert pixels to/from
HiFiPixel.
You can store the pixels however you like CMYK, YUV, whatever, but unless
it converts to HiFiPixel, it can't be used by anyone.
This conversion to HiFi also needs to take into account colourspaces, etc.
And linear vs nonlinear. HiFi needs to be well defined.
So now all Image types
- can interoperate
- can be fast when the types "know each other"
Also, you probably want scan-line based, or chunk-based, not pixel based.
Image::accessLine(...)
ie convert a chunk at a time to HiFiPixel, etc.
Again, specializing cases where possible to avoid unnecessary copies.
Basically, you want convert per pixel on the fly, but not if that is a
virtual function per pixel!
There's probably more, much more, but that's it for now.
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivhZO3dE6aA0%2BuBF%3Ddz%2BPLNG1B74WuWbofMZeT2%3DJg_4Q%40mail.gmail.com.
--0000000000000e87b20570bd42d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div><br></div><div>Here's my thoughts.=
</div><div>Background: I've spent 25+ years doing pixel++.</div><div>Th=
is is all "off the top of my head", but I've seen it (and hel=
ped it be) done a number of times.</div><div><br></div><div><br></div><div>=
What is an image?=C2=A0 You need some basis, else you are defining nothing.=
</div><div>An image is more than a 2D vector.</div><div>A 2D vector is a wo=
rthwhile type (I think the latest proposal is "mdspan" - md for m=
ulti-dimensional), but that's not an image.<br></div><div></div><div>An=
image holds *pixels* (or is able to give/take pixels, whether it actually =
holds them)</div><div>So we need to define pixels.<br></div><div><br></div>=
<div>If we don't define pixels (and color spaces), QImage can't tak=
e a std::image and do anything with it, etc.</div><div><br></div><div><br><=
/div><div>A pixel is colour + alpha.=C2=A0 You can claim that alpha is &quo=
t;extra" channel info, and if you allow alpha, why not 3D depth, etc?=
=C2=A0 Maybe.</div><div>(So have a way to expose extra channels, but most c=
ode will probably ignore anything beyond colour and alpha)<br></div><div><b=
r></div><div>Back to image:<br></div><div><br></div><div>For performance, y=
ou need a type templated on the pixel type.</div><div>Then I can write spec=
ialized algorithms for composite() or whatever.</div><div>*And* generic (un=
specialized) algorithms can also be compiled into faster code.</div><div><b=
r></div><div>template<typename Pixel, typename Pixel><br></div><div>I=
mageT<Pixel> composite(ImageT<Pixel> top, ImageT<Pixel> b=
ottom)</div><div>{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 ImageT<Pixel> d=
est(union_size(top, bottom));</div><div><br></div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0 for (auto & [d, t, b] : intersect_zip(dest, union_zip(top, botto=
m)))</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d =3D compo=
site_pixel(t, b);</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 return dest;<=
br></div><div>}</div><div><br></div><div>ImageT<RGBA32> composite(Ima=
geT<RGBA32> top, ImageT<RGBA32> bottom)</div><div>{</div><div>=
=C2=A0=C2=A0=C2=A0 ImageT<RGBA32> dest;</div><div>=C2=A0=C2=A0=C2=A0 =
asm {</div><div>=C2=A0=C2=A0=C2=A0 ....</div><div>=C2=A0=C2=A0=C2=A0 }</div=
><div>=C2=A0=C2=A0=C2=A0 return dest;<br></div><div>}</div><div><br></div><=
div>Then you need an Image (non template) class that has the pixel type dec=
ided at runtime.</div><div><br></div><div>
<div>Image composite(Image top, Image bottom)</div><div>{</div><div>=C2=A0=
=C2=A0=C2=A0 Image dest;</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 if (to=
p.pixelType =3D=3D bottom.pixelType)<br></div><div>=C2=A0 =C2=A0=C2=A0 =C2=
=A0=C2=A0 switch (top.pixelType)</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=
{</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 case PixelType::RGBA32</div><=
div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dest =3D compo=
site(<a href=3D"http://top.to">top.to</a><RGBA32>(), <a href=3D"http:=
//bottom.to">bottom.to</a><RGBA32());</div><div>=C2=A0 =C2=A0=C2=A0 =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;</div><div>=C2=A0 =C2=A0=C2=A0 =C2=
=A0=C2=A0 case PixelType::Etc</div><div>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 }<=
/div><div>=C2=A0=C2=A0=C2=A0 else if ... // can add common mixes here</div>=
<div>=C2=A0=C2=A0=C2=A0 else <br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 // fall back to HiFiPixel, see below</div><div><br></div>=C2=A0=C2=
=A0=C2=A0 return dest;<br><div>}</div><div><br></div><div>Here's an imp=
ortant part:</div><div>you need a common "base" hi-fidelity pixel=
type.=C2=A0 HiFiPixel. Say RGBA 32bit floats. Or whatever is enough.<br></=
div><div>Whenever types don't match, you need to be able to convert eve=
ry pixel to this hi-fidelity type.</div><div>Every ImageT<T> needs, a=
t minimum, to be able to convert pixels to/from HiFiPixel.</div><div>You ca=
n store the pixels however you like CMYK, YUV, whatever, but unless it conv=
erts to HiFiPixel, it can't be used by anyone.</div><div>This conversio=
n to HiFi also needs to take into account colourspaces, etc.=C2=A0 And line=
ar vs nonlinear.=C2=A0 HiFi needs to be well defined.<br></div><div><br></d=
iv><div>So now all Image types</div><div>- can interoperate</div><div>- can=
be fast when the types "know each other"</div><div><br></div><di=
v>Also, you probably want scan-line based, or chunk-based, not pixel based.=
<br></div>
Image::accessLine(...)</div><div>ie convert a chunk at a time to HiFiPixel,=
etc.</div><div>Again, specializing cases where possible to avoid unnecessa=
ry copies.<br></div><div>Basically, you want convert per pixel on the fly, =
but not if that is a virtual function per pixel!<br></div><div><br></div><d=
iv>There's probably more, much more, but that's it for now.<br></di=
v><div class=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></di=
v>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbivhZO3dE6aA0%2BuBF%3Ddz%2BPLNG1=
B74WuWbofMZeT2%3DJg_4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivh=
ZO3dE6aA0%2BuBF%3Ddz%2BPLNG1B74WuWbofMZeT2%3DJg_4Q%40mail.gmail.com</a>.<br=
/>
--0000000000000e87b20570bd42d5--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 11 Jul 2018 15:03:26 -0400
Raw View
On 2018-07-11 14:17, Tony V E wrote:
> A pixel is colour + alpha. You can claim that alpha is "extra" channel
> info, and if you allow alpha, why not 3D depth, etc? Maybe.
A "pixel" is a vector of scalars, where the vector indices have specific
meaning. Often those meanings are "RGB" or "RGBA", but as you're clearly
aware, they need not be. RGB are basically radiation intensity in
particular EM bands, but I've seen plenty of TIFF files, not even in the
realm of astronomy, that use different bands. Alpha, depth, and so forth
aren't even "radiation intensity", but they're certainly useful.
The thing is... I'm not aware of any good reason why we should require
that an image container be limited to "RGB" and "RGBA". (Don't forget
about "BGRA", either...)
I think the original proposal had the right idea here; provide some very
generic mechanism for specifying what the channels mean (the OP
suggested a string), but don't try to standardize it. As others have
said, that way lies madness. Instead, leave it to the application if it
needs to deal with that *at all*. Often, the application can just assume
that 3/4 channels are RGB/RGBA, and things will work out. Either the
provider of the image can provide the mechanism to convert to RGB, if
that's what the consumer wants, or you're dealing with something
sufficiently specialized that trying to standardize the conversion is
impractical.
> (So have a way to expose extra channels, but most code will probably ignore
> anything beyond colour and alpha)
....which IMO is best done by an "image" being a *3* dimensional array.
Preferably with strides, so that users aren't locked into a particular
memory layout.
> For performance, you need a type templated on the pixel type.
Yup.
> Then you need an Image (non template) class that has the pixel type decided
> at runtime.
Sure. Provide a pointer to the raw memory block and maybe an accessor to
a specific pixel.
There is prior art for all of this, and it generally works acceptably.
> Here's an important part:
> you need a common "base" hi-fidelity pixel type. HiFiPixel. Say RGBA 32bit
> floats. Or whatever is enough.
> Whenever types don't match, you need to be able to convert every pixel to
> this hi-fidelity type.
> Every ImageT<T> needs, at minimum, to be able to convert pixels to/from
> HiFiPixel.
> You can store the pixels however you like CMYK, YUV, whatever, but unless
> it converts to HiFiPixel, it can't be used by anyone.
> This conversion to HiFi also needs to take into account colourspaces, etc.
> And linear vs nonlinear. HiFi needs to be well defined.
I can't say I agree in practice. Converting to/from different scalar
types is useful, but colorspace conversion is hard. Converting between
sRGB and display, for instance, requires run-time knowledge of the
properties of the display in question. Again, from my experience with
real, existing applications working with images, this is usually either
unnecessary or is most appropriately provided by whatever produced the
image in the first place.
Now, it may be worth exploring this at some point in the future, but I
think it's something that can be added later, especially if we've made
some provision for recording the colorspace information already. Worst
case, as a subclass that adds additional information about color spaces.
> Again, specializing cases where possible to avoid unnecessary copies.
Actually, that's where I'd argue for a) layout independence, and b)
ability to take ownership of an existing data buffer, possibly by means
of having a templated custom deleter (not on the specific function, but
on e.g. `void(*)(void*)` vs. the std::function equivalent, though the
overhead of std::function might not justify that optimization).
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fbbef7bd-f024-538e-2302-6b4656e35d3e%40gmail.com.
.
Author: "oliviersohn via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 20 Jul 2018 15:04:07 -0700 (PDT)
Raw View
------=_Part_6460_24212769.1532124248035
Content-Type: multipart/alternative;
boundary="----=_Part_6461_2077129305.1532124248035"
------=_Part_6461_2077129305.1532124248035
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The JuicyPixels library in Haskell=20
(https://hackage.haskell.org/package/JuicyPixels-3.3) handles colorspaces=
=20
conversions=20
: https://hackage.haskell.org/package/JuicyPixels-3.3/docs/Codec-Picture-Ty=
pes.html#t:ColorSpaceConvertible
I think an equivalent feature should be part of std::image, as colorspaces=
=20
are quite central to anything graphic-related.
Le samedi 7 juillet 2018 16:38:36 UTC+2, apeg...@gmail.com a =C3=A9crit :
>
> reddit.com/r/cpp/comments/89we31/2d_graphics_a_more_modest_proposal
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/033056a0-568e-4716-b7b1-71859b350530%40isocpp.or=
g.
------=_Part_6461_2077129305.1532124248035
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The JuicyPixels library in Haskell (https://hackage.haskel=
l.org/package/JuicyPixels-3.3) handles colorspaces conversions :=C2=A0https=
://hackage.haskell.org/package/JuicyPixels-3.3/docs/Codec-Picture-Types.htm=
l#t:ColorSpaceConvertible<div><br></div><div>I think an equivalent feature =
should be part of std::image, as colorspaces are quite central to anything =
graphic-related.</div><div><br></div><div><br>Le samedi 7 juillet 2018 16:3=
8:36 UTC+2, apeg...@gmail.com a =C3=A9crit=C2=A0:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><a href=3D"http://reddit.com/r/cpp=
/comments/89we31/2d_graphics_a_more_modest_proposal" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Freddit.com%2Fr%2Fcpp%2Fcomments%2F89we31%2F2d_graphics_a_mor=
e_modest_proposal\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF1lgfaqgaYXbRqnKR=
lDuyn1zZESQ';return true;" onclick=3D"this.href=3D'http://www.googl=
e.com/url?q\x3dhttp%3A%2F%2Freddit.com%2Fr%2Fcpp%2Fcomments%2F89we31%2F2d_g=
raphics_a_more_modest_proposal\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF1lg=
faqgaYXbRqnKRlDuyn1zZESQ';return true;">reddit.com/r/cpp/comments/<wbr>=
89we31/2d_graphics_a_more_<wbr>modest_proposal</a><br></div></div></blockqu=
ote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/033056a0-568e-4716-b7b1-71859b350530%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/033056a0-568e-4716-b7b1-71859b350530=
%40isocpp.org</a>.<br />
------=_Part_6461_2077129305.1532124248035--
------=_Part_6460_24212769.1532124248035--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 23 Jul 2018 13:00:05 -0400
Raw View
On 2018-07-20 18:04, oliviersohn via ISO C++ Standard - Future Proposals
wrote:
> The JuicyPixels library in Haskell
> (https://hackage.haskell.org/package/JuicyPixels-3.3) handles colorspaces
> conversions
> : https://hackage.haskell.org/package/JuicyPixels-3.3/docs/Codec-Picture-Types.html#t:ColorSpaceConvertible
>
> I think an equivalent feature should be part of std::image, as colorspaces
> are quite central to anything graphic-related.
Colorspaces are to images as text codecs are to strings.
Considering how long std::string has existed, and how much trouble
trying to get any sort of Unicode support functions into the standard
has been, I think it would be very, very wise to look at any proposed
std::image as the equivalent of having std::string with no text codec
conversions.
That is, even as just a "bag of bytes" with users that need them
required to implement their own codec conversions, std::string is very
useful. Similarly, std::image can be very useful with no colorspace
support, while trying to make that a "requirement" for the type is
likely to kill any proposal, or at least bog it down for the next decade
or so.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f606072f-b279-3f07-a66b-f8303684ef6d%40gmail.com.
.
Author: "'Olivier Sohn' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 23 Jul 2018 17:14:42 +0000 (UTC)
Raw View
------=_Part_1054294_1620766621.1532366082176
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
But why call it std::image when there is no tool to interpret pixel colors=
?
It feels like it's an std::matrix where the dimension is 2, but not std::im=
age.
Le lundi 23 juillet 2018 =C3=A0 19:00:10 UTC+2, Matthew Woehlke <mwoehl=
ke.floss@gmail.com> a =C3=A9crit : =20
=20
On 2018-07-20 18:04, oliviersohn via ISO C++ Standard - Future Proposals
wrote:
> The JuicyPixels library in Haskell=20
> (https://hackage.haskell.org/package/JuicyPixels-3.3) handles colorspaces=
=20
> conversions=20
> : https://hackage.haskell.org/package/JuicyPixels-3.3/docs/Codec-Picture-=
Types.html#t:ColorSpaceConvertible
>=20
> I think an equivalent feature should be part of std::image, as colorspace=
s=20
> are quite central to anything graphic-related.
Colorspaces are to images as text codecs are to strings.
Considering how long std::string has existed, and how much trouble
trying to get any sort of Unicode support functions into the standard
has been, I think it would be very, very wise to look at any proposed
std::image as the equivalent of having std::string with no text codec
conversions.
That is, even as just a "bag of bytes" with users that need them
required to implement their own codec conversions, std::string is very
useful. Similarly, std::image can be very useful with no colorspace
support, while trying to make that a "requirement" for the type is
likely to kill any proposal, or at least bog it down for the next decade
or so.
--=20
Matthew
--=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/2R6jiK_kkqw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f606072f-b279-3f07-a66b-f8303684ef6d%40gmail.com=
..
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/482841376.1054295.1532366082178%40mail.yahoo.com=
..
------=_Part_1054294_1620766621.1532366082176
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div style=3D"font-family:Helvetica Neue, Helvetic=
a, Arial, sans-serif;font-size:13px;"><div style=3D"font-family:Helvetica N=
eue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div>But why call it std::image when there is no tool to interpret =
pixel colors?<br></div><div><br></div><div><span><div style=3D"color: rgb(0=
, 0, 0); font-family: "Helvetica Neue", Helvetica, Arial, sans-se=
rif;">It feels like it's an std::matrix where the dimension is 2, but not s=
td::image.</div><div><br></div></span></div><div><br></div>
=20
</div><div id=3D"ydp5f615d74yahoo_quoted_2663603022" class=3D"ydp5f=
615d74yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
Le lundi 23 juillet 2018 =C3=A0 19:00:10 UTC+2, Matthew=
Woehlke <mwoehlke.floss@gmail.com> a =C3=A9crit :
</div>
<div><br></div>
<div><br></div>
<div><div dir=3D"ltr">On 2018-07-20 18:04, oliviersohn via =
ISO C++ Standard - Future Proposals<br clear=3D"none">wrote:<br clear=3D"no=
ne">> The JuicyPixels library in Haskell <br clear=3D"none">> (<a sha=
pe=3D"rect" href=3D"https://hackage.haskell.org/package/JuicyPixels-3.3" re=
l=3D"nofollow" target=3D"_blank">https://hackage.haskell.org/package/JuicyP=
ixels-3.3</a>) handles colorspaces <br clear=3D"none">> conversions <br =
clear=3D"none">> : <a shape=3D"rect" href=3D"https://hackage.haskell.org=
/package/JuicyPixels-3.3/docs/Codec-Picture-Types.html#t:ColorSpaceConverti=
ble" rel=3D"nofollow" target=3D"_blank">https://hackage.haskell.org/package=
/JuicyPixels-3.3/docs/Codec-Picture-Types.html#t:ColorSpaceConvertible</a><=
br clear=3D"none">> <br clear=3D"none">> I think an equivalent featur=
e should be part of std::image, as colorspaces <br clear=3D"none">> are =
quite central to anything graphic-related.<br clear=3D"none"><br clear=3D"n=
one">Colorspaces are to images as text codecs are to strings.<br clear=3D"n=
one"><br clear=3D"none">Considering how long std::string has existed, and h=
ow much trouble<br clear=3D"none">trying to get any sort of Unicode support=
functions into the standard<br clear=3D"none">has been, I think it would b=
e very, very wise to look at any proposed<br clear=3D"none">std::image as t=
he equivalent of having std::string with no text codec<br clear=3D"none">co=
nversions.<br clear=3D"none"><br clear=3D"none">That is, even as just a "ba=
g of bytes" with users that need them<br clear=3D"none">required to impleme=
nt their own codec conversions, std::string is very<br clear=3D"none">usefu=
l. Similarly, std::image can be very useful with no colorspace<br clear=3D"=
none">support, while trying to make that a "requirement" for the type is<br=
clear=3D"none">likely to kill any proposal, or at least bog it down for th=
e next decade<br clear=3D"none">or so.<br clear=3D"none"><br clear=3D"none"=
>-- <br clear=3D"none">Matthew<div class=3D"ydp5f615d74yqt0952222436" id=3D=
"ydp5f615d74yqtfd01486"><br clear=3D"none"><br clear=3D"none">-- <br clear=
=3D"none">You received this message because you are subscribed to a topic i=
n the Google Groups "ISO C++ Standard - Future Proposals" group.<br clear=
=3D"none">To unsubscribe from this topic, visit https://groups.google.com/a=
/isocpp.org/d/topic/std-proposals/2R6jiK_kkqw/unsubscribe.<br clear=3D"none=
">To unsubscribe from this group and all its topics, send an email to std-p=
roposals+<a shape=3D"rect" href=3D"mailto:unsubscribe@isocpp.org." rel=3D"n=
ofollow" target=3D"_blank">unsubscribe@isocpp.org.</a><br clear=3D"none">To=
post to this group, send email to <a shape=3D"rect" href=3D"mailto:std-pro=
posals@isocpp.org." rel=3D"nofollow" target=3D"_blank">std-proposals@isocpp=
..org.</a></div><br clear=3D"none">To view this discussion on the web visit =
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f606072f-b279-=
3f07-a66b-f8303684ef6d%40gmail.com.<div class=3D"ydp5f615d74yqt0952222436" =
id=3D"ydp5f615d74yqtfd53888"><br clear=3D"none"></div></div></div>
</div>
</div></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/482841376.1054295.1532366082178%40mai=
l.yahoo.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/482841376.1054295.1532366082178%40mai=
l.yahoo.com</a>.<br />
------=_Part_1054294_1620766621.1532366082176--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Jul 2018 10:37:42 -0700 (PDT)
Raw View
------=_Part_8495_1084515192.1532367462887
Content-Type: multipart/alternative;
boundary="----=_Part_8496_51013484.1532367462887"
------=_Part_8496_51013484.1532367462887
Content-Type: text/plain; charset="UTF-8"
On Monday, July 23, 2018 at 1:00:08 PM UTC-4, Matthew Woehlke wrote:
>
> On 2018-07-20 18:04, oliviersohn via ISO C++ Standard - Future Proposals
> wrote:
> > The JuicyPixels library in Haskell
> > (https://hackage.haskell.org/package/JuicyPixels-3.3) handles
> colorspaces
> > conversions
> > :
> https://hackage.haskell.org/package/JuicyPixels-3.3/docs/Codec-Picture-Types.html#t:ColorSpaceConvertible
> >
> > I think an equivalent feature should be part of std::image, as
> colorspaces
> > are quite central to anything graphic-related.
>
> Colorspaces are to images as text codecs are to strings.
>
> Considering how long std::string has existed, and how much trouble
> trying to get any sort of Unicode support functions into the standard
> has been, I think it would be very, very wise to look at any proposed
> std::image as the equivalent of having std::string with no text codec
> conversions.
>
But that's widely recognized as the biggest *problem* with `std::string`:
that there is no encoding attached in either a static or dynamic way.
There's not even a standard way of interpreting a string with a particular
encoding. This is one of the biggest reasons why people don't use
`std::string`. C++'s "standard" string class is basically a laughing stock
among its competing languages because of this; practically every other
language has a more usable string class than us.
There's a saying about those who don't remember history...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/565e1765-e23c-4cd0-a47d-dbf0a19afb8f%40isocpp.org.
------=_Part_8496_51013484.1532367462887
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, July 23, 2018 at 1:00:08 PM UTC-4, Matt=
hew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-07-2=
0 18:04, oliviersohn via ISO C++ Standard - Future Proposals
<br>wrote:
<br>> The JuicyPixels library in Haskell=20
<br>> (<a href=3D"https://hackage.haskell.org/package/JuicyPixels-3.3" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fhackage.haskell.org%2Fpackage%2FJuicyP=
ixels-3.3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdGnLqU-ZAUEMD3pFbkeF9AxB=
Ycw';return true;" onclick=3D"this.href=3D'https://www.google.com/u=
rl?q\x3dhttps%3A%2F%2Fhackage.haskell.org%2Fpackage%2FJuicyPixels-3.3\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFdGnLqU-ZAUEMD3pFbkeF9AxBYcw';return=
true;">https://hackage.haskell.org/<wbr>package/JuicyPixels-3.3</a>) handl=
es colorspaces=20
<br>> conversions=20
<br>> : <a href=3D"https://hackage.haskell.org/package/JuicyPixels-3.3/d=
ocs/Codec-Picture-Types.html#t:ColorSpaceConvertible" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fhackage.haskell.org%2Fpackage%2FJuicyPixels-3.3%2Fdocs%2FC=
odec-Picture-Types.html%23t%3AColorSpaceConvertible\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGGE9K58K0kHkIaujZ4bY6G4JNv6A';return true;" onclick=3D=
"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fhackage.has=
kell.org%2Fpackage%2FJuicyPixels-3.3%2Fdocs%2FCodec-Picture-Types.html%23t%=
3AColorSpaceConvertible\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGE9K58K0kH=
kIaujZ4bY6G4JNv6A';return true;">https://hackage.haskell.org/<wbr>packa=
ge/JuicyPixels-3.3/docs/<wbr>Codec-Picture-Types.html#t:<wbr>ColorSpaceConv=
ertible</a>
<br>>=20
<br>> I think an equivalent feature should be part of std::image, as col=
orspaces=20
<br>> are quite central to anything graphic-related.
<br>
<br>Colorspaces are to images as text codecs are to strings.
<br>
<br>Considering how long std::string has existed, and how much trouble
<br>trying to get any sort of Unicode support functions into the standard
<br>has been, I think it would be very, very wise to look at any proposed
<br>std::image as the equivalent of having std::string with no text codec
<br>conversions.<br></blockquote><div><br></div><div>But that's widely =
recognized as the biggest <i>problem</i> with `std::string`: that there is =
no encoding attached in either a static or dynamic way. There's not eve=
n a standard way of interpreting a string with a particular encoding. This =
is one of the biggest reasons why people don't use `std::string`. C++&#=
39;s "standard" string class is basically a laughing stock among =
its competing languages because of this; practically every other language h=
as a more usable string class than us.<br></div><div><br></div><div>There&#=
39;s a saying about those who don't remember history...</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/565e1765-e23c-4cd0-a47d-dbf0a19afb8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/565e1765-e23c-4cd0-a47d-dbf0a19afb8f=
%40isocpp.org</a>.<br />
------=_Part_8496_51013484.1532367462887--
------=_Part_8495_1084515192.1532367462887--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 23 Jul 2018 14:10:05 -0400
Raw View
On 2018-07-23 13:14, Olivier Sohn wrote:
> But why call it std::image when there is no tool to interpret pixel colors?
>
> It feels like it's an std::matrix where the dimension is 2, but not std::image.
I assume you meant 3, not 2. Even so, you have a rather special case
where the third dimension is not spatial, whereas the first two are.
(Also, what's a std::matrix? ;-) We don't *have* those (yet), and I
would really, *really* hope that we'd get at least basic linear algebra
with them, which we don't need for std::image.)
But to answer the question... why call it std::string when there is no
tool to interpret character codepoints? Why not call it std::vector<char>?
Besides, the OP *did* suggest having a string member that "describes"
the color space. I think that's a good idea. I'm just saying that
deciding that we can't have std::image (std::string) without colorspace
conversion (text codec conversion) is a great way to kill the proposal.
Maybe I'm wrong, and someone can write a brilliant proposal that solves
all colorspace conversion problems on their first attempt. However, I
have very low expectations in that respect. My point is that I feel
pretty strongly that lack of colorspace conversion is *not* a "must
have" in order to have a useful std::image.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/330e9aaf-d837-4f93-2bc5-ae44c6574bd2%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 23 Jul 2018 14:22:30 -0400
Raw View
On 2018-07-23 13:37, Nicol Bolas wrote:
>> Considering how long std::string has existed, and how much trouble
>> trying to get any sort of Unicode support functions into the standard
>> has been, I think it would be very, very wise to look at any proposed
>> std::image as the equivalent of having std::string with no text codec
>> conversions.
>
> But that's widely recognized as the biggest *problem* with `std::string`:
> that there is no encoding attached in either a static or dynamic way.
> There's not even a standard way of interpreting a string with a particular
> encoding. This is one of the biggest reasons why people don't use
> `std::string`.
And yet, many people *do* use std::string. Just as people use image
containers in applications that possess very rudimentary, if any,
colorspace handling.
First, please note that I'm not saying that colorspace conversion has no
place in standard C++. If we get std::image, then clearly, colorspace
conversion seems useful also. All I'm saying is that I don't think we
should make colorspace conversion a precondition of a *basic* container
for "pixels".
Second, remember that the OP *did* include a field for specifying
colorspace; just no specification of how to *interpret* that field.
The point is to keep in mind that "perfect is the enemy of good", and to
avoid getting so bogged down in wanting something "perfect" that we wind
up with nothing at all.
The whole origin of the original proposal, after all, was to try to
learn from the mistakes of 2D Graphics.
> C++'s "standard" string class is basically a laughing stock
> among its competing languages because of this; practically every other
> language has a more usable string class than us.
Would I rather use e.g. QString? Probably. *Can* I use std::string?
Sure. The reality is that many applications *don't actually care* about
text encoding. As long as you always deal with text in the active
runtime encoding, std::string is just fine.
Many potential users of std::image are in the much same boat; they just
assume that no colorspace conversion is necessary... and in many cases,
*in real, existing practice*, this works just fine.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/611f8a13-2733-fcd3-83c2-33ca5558fc5e%40gmail.com.
.
Author: "oliviersohn via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 23 Jul 2018 11:26:14 -0700 (PDT)
Raw View
------=_Part_8414_1171601842.1532370374778
Content-Type: multipart/alternative;
boundary="----=_Part_8415_1324066380.1532370374778"
------=_Part_8415_1324066380.1532370374778
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le lundi 23 juillet 2018 20:10:07 UTC+2, Matthew Woehlke a =C3=A9crit :
>
> On 2018-07-23 13:14, Olivier Sohn wrote:=20
> > But why call it std::image when there is no tool to interpret pixel=20
> colors?=20
> >=20
> > It feels like it's an std::matrix where the dimension is 2, but not=20
> std::image.=20
>
> I assume you meant 3, not 2.
I meant 2, where each dimension is one of the screen axis. For example, an=
=20
image could be represented as a std::vector<std::vector<Pixel>>.
(Also, what's a std::matrix? ;-) We don't *have* those (yet), and I=20
> would really, *really* hope that we'd get at least basic linear algebra=
=20
> with them, which we don't need for std::image.)=20
>
Yes we don't have those, but if we had a std::matrix we could represent an=
=20
image with it.
=20
>
> But to answer the question... why call it std::string when there is no=20
> tool to interpret character codepoints? Why not call it std::vector<char>=
?=20
>
>
Yes, you're right, but we don't have to repeat the same design mistake.
=20
> Besides, the OP *did* suggest having a string member that "describes"=20
> the color space. I think that's a good idea.
I don't think it's a good idea since there is no specification of what that=
=20
string really means and how to convert between colorspaces.
=20
> I'm just saying that=20
> deciding that we can't have std::image (std::string) without colorspace=
=20
> conversion (text codec conversion) is a great way to kill the proposal.=
=20
>
>
Yeah I feel the proposal will never make it through without colorspaces.=20
However, a std::matrix proposal is maybe easier to do.
For example : std::matrix<size_t N_DIMENSIONS, typename T>
and a matrix<2,...> can then be used to store 2d images.
=20
> Maybe I'm wrong, and someone can write a brilliant proposal that solves=
=20
> all colorspace conversion problems on their first attempt. However, I=20
> have very low expectations in that respect. My point is that I feel=20
> pretty strongly that lack of colorspace conversion is *not* a "must=20
> have" in order to have a useful std::image.=20
>
> --=20
> Matthew=20
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a6dd6d39-39ff-4448-8e3f-b8358b0645b5%40isocpp.or=
g.
------=_Part_8415_1324066380.1532370374778
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le lundi 23 juillet 2018 20:10:07 UTC+2, Matthew W=
oehlke a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2=
018-07-23 13:14, Olivier Sohn wrote:
<br>> =C2=A0But why call it std::image when there is no tool to interpre=
t pixel colors?
<br>>=20
<br>> It feels like it's an std::matrix where the dimension is 2, bu=
t not std::image.
<br>
<br>I assume you meant 3, not 2.</blockquote><div><br></div><div>I meant 2,=
where each dimension is one of the screen axis. For example, an image coul=
d be represented as a std::vector<std::vector<Pixel>>.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(Also, what's =
a std::matrix? ;-) We don't *have* those (yet), and I
<br>would really, *really* hope that we'd get at least basic linear alg=
ebra
<br>with them, which we don't need for std::image.)
<br></blockquote><div><br></div><div>Yes we don't have those, but if we=
had a std::matrix we could represent an image with it.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
<br>But to answer the question... why call it std::string when there is no
<br>tool to interpret character codepoints? Why not call it std::vector<=
char>?
<br>
<br></blockquote><div><br></div><div>Yes, you're right, but we don'=
t have to repeat the same design mistake.</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">Besides, the OP *did* suggest having a st=
ring member that "describes"
<br>the color space. I think that's a good idea.</blockquote><div><br><=
/div><div>I don't think it's a good idea since there is no specific=
ation of what that string really means and how to convert between colorspac=
es.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I=
9;m just saying that
<br>deciding that we can't have std::image (std::string) without colors=
pace
<br>conversion (text codec conversion) is a great way to kill the proposal.
<br>
<br></blockquote><div><br></div><div>Yeah I feel the proposal will never ma=
ke it through without colorspaces. However, a std::matrix proposal is maybe=
easier to do.</div><div><br></div><div>For example : std::matrix<size_t=
N_DIMENSIONS, typename T></div><div><br></div><div>and a matrix<2,..=
..> can then be used to store 2d images.</div><div><br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Maybe I'm wrong, and =
someone can write a brilliant proposal that solves
<br>all colorspace conversion problems on their first attempt. However, I
<br>have very low expectations in that respect. My point is that I feel
<br>pretty strongly that lack of colorspace conversion is *not* a "mus=
t
<br>have" in order to have a useful std::image.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6dd6d39-39ff-4448-8e3f-b8358b0645b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6dd6d39-39ff-4448-8e3f-b8358b0645b5=
%40isocpp.org</a>.<br />
------=_Part_8415_1324066380.1532370374778--
------=_Part_8414_1171601842.1532370374778--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 23 Jul 2018 14:50:44 -0400
Raw View
On 2018-07-23 14:26, oliviersohn wrote:
> Le lundi 23 juillet 2018 20:10:07 UTC+2, Matthew Woehlke a =C3=A9crit :
>> On 2018-07-23 13:14, Olivier Sohn wrote:=20
>>> But why call it std::image when there is no tool to interpret pixel=20
>>> colors?=20
>>>
>>> It feels like it's an std::matrix where the dimension is 2, but not=20
>>> std::image.=20
>>
>> I assume you meant 3, not 2.
>=20
> I meant 2, where each dimension is one of the screen axis. For example, a=
n=20
> image could be represented as a std::vector<std::vector<Pixel>>.
I will oppose any such proposal. Besides my previously expressed
feelings on the dubious wisdom of creating another template type to
express "a pixel", as opposed to allowing direct access to the channel
scalars, this would necessarily impose a particular packing order, which
is inefficient for some applications. Packing order should be
*communicated*, not *coerced*.
>> But to answer the question... why call it std::string when there is no=
=20
>> tool to interpret character codepoints? Why not call it std::vector<char=
>?=20
>
> Yes, you're right, but we don't have to repeat the same design mistake.
Failing to provide a mechanism to specify encoding was probably a
mistake. I'm *not* proposing to repeat that.
Failing to provide text codec conversions is... unfortunate, but not
unsurprising, because not only is it *really hard* (not to mention
something of a moving target), it's not *universally necessary*. Plenty
of applications manage to use std::string effectively. Many of them
don't even *need* codec conversion.
In my experience, all of the above is equally true for image colorspace
conversion.
>> Besides, the OP *did* suggest having a string member that "describes"=20
>> the color space. I think that's a good idea.
>=20
> I don't think it's a good idea since there is no specification of what th=
at=20
> string really means and how to convert between colorspaces.
Sigh. As I said in my reply to Nicol, "perfect is the enemy of good". I
can virtually guarantee you that if you refuse to support an image type
without a fully featured colorspace conversion library, the result will
be... no image type at all.
Feel free to write a proposal and prove me wrong. I, however, will
adamantly support the position that a std::image with no colorspace
conversion library is still useful.
Keep in mind that an acceptable colorspace proposal must support
user-defined color spaces with the ability to register user-supplied
conversion functions, and that the set of colorspaces isn't just an
enumeration; some of them involve one or more scalar parameters (gamma
being the most obvious, but I wouldn't bet on that being the *only* such
parameter).
>> I'm just saying that deciding that we can't have std::image
>> (std::string) without colorspace conversion (text codec conversion)
>> is a great way to kill the proposal.
>
> Yeah I feel the proposal will never make it through without colorspaces.=
=20
Well, then, I expect it will never make it through, period. Too bad.
> However, a std::matrix proposal is maybe easier to do.
....but that's of limited use without std::pixel. If we get matrices but
no std::image, we will be even worse off, because then people will start
using 3-dimensional matrices (or worse, a plethora of non-compatible
"pixel" types) for images, and we'll have only perpetuated the
incompatibility problems we have now.
Don't get me wrong; I'd be *thrilled* to get std::matrix. Matrices have
*tons* of uses, and having decent linear algebra support in the standard
library would *rock*. I just don't see std::matrix solving the problem
that std::image could solve.
I also don't think std::matrix would be easier to get than std::image
*without* colorspace conversion.
--=20
Matthew
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/15029eed-5a70-2fb1-6216-a8d6d46d1176%40gmail.com=
..
.
Author: apegomp2@gmail.com
Date: Mon, 23 Jul 2018 17:02:49 -0700 (PDT)
Raw View
------=_Part_8561_919422098.1532390569707
Content-Type: multipart/alternative;
boundary="----=_Part_8562_2108212800.1532390569707"
------=_Part_8562_2108212800.1532390569707
Content-Type: text/plain; charset="UTF-8"
2D Graphics Is Everywhere . .
You See It When You Turn On Your Computer .
std::image
* 32-bit // RED GREEN BLUE + ALPHA
* PNG // most common image format widely used
What Standardization Means:
* Slower // Alpha is slower. But modern computers are fast.
* OMG NO .HIV .bmp support? // we want normal people to use .png
Modern computers are fast and
memory and storage is cheap
Internet is lightspeed due
to optical computing (fibre)
We want people
TO USE ONLY 1 IMAGE FORMAT (PNG)
This will create a nice standard
1 IMAGE FORMAT
TO RULE THEM ALL
<https://lh3.googleusercontent.com/-MPfN-JGPnPE/W1Zazylz38I/AAAAAAAABCs/EnAzgxXMbmc0GjpkcmocvlN0SMypo17bwCLcBGAs/s1600/matrix.png>
<https://lh3.googleusercontent.com/-MPfN-JGPnPE/W1Zazylz38I/AAAAAAAABCs/EnAzgxXMbmc0GjpkcmocvlN0SMypo17bwCLcBGAs/s1600/matrix.png>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62c48922-0415-464d-b25a-7f327faa7c48%40isocpp.org.
------=_Part_8562_2108212800.1532390569707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"color: rgb(0, 255, 0); font-family: &q=
uot;courier new", monospace; font-size: large; background-color: rgb(0=
, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span><font style=3D"background-color: rg=
b(0, 0, 0);" color=3D"#00ff00" face=3D"courier new, monospace" size=3D"4"><=
br></font></div><font style=3D"background-color: rgb(0, 0, 0);" color=3D"#0=
0ff00" face=3D"courier new, monospace" size=3D"4">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 2D Graphics Is Everywhere=C2=A0.=C2=A0.=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0</font><div><span style=3D"color: rgb(0, 255, 0); font-family: "=
courier new", monospace; font-size: large; background-color: rgb(0, 0,=
0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0=C2=A0</span><font color=3D"#00ff00" face=3D"courier ne=
w, monospace" size=3D"4"><br></font><div><font style=3D"background-color: r=
gb(0, 0, 0);" color=3D"#00ff00" face=3D"courier new, monospace" size=3D"4">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 You See It When You Turn O=
n Your Computer=C2=A0.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</font></div=
><div><span style=3D"color: rgb(0, 255, 0); font-family: "courier new&=
quot;, monospace; font-size: large; background-color: rgb(0, 0, 0);">=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0=C2=A0</span></div></div><p class=3D"separator" style=3D"text-ali=
gn: center; clear: both;"></p><div style=3D"text-align: left;"><span style=
=3D"background-color: rgb(0, 0, 0);"><img src=3D"https://lh3.googleusercont=
ent.com/-MPfN-JGPnPE/W1Zazylz38I/AAAAAAAABCs/EnAzgxXMbmc0GjpkcmocvlN0SMypo1=
7bwCLcBGAs/s1600/matrix.png" border=3D"0" style=3D""></span></div><div styl=
e=3D"text-align: left;"><span style=3D"background-color: rgb(0, 0, 0); colo=
r: rgb(0, 255, 0); font-family: "courier new", monospace; font-si=
ze: large;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><p></p><div><font color=3D"#0=
0ff00" face=3D"courier new, monospace" size=3D"4" style=3D"background-color=
: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::image=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0</font><div><span style=3D"color: rgb(0, 255, 0); font-fam=
ily: "courier new", monospace; font-size: large; background-color=
: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</span><span style=3D"background-color: rgb(0, 0, 0); color: rgb(=
0, 255, 0); font-family: "courier new", monospace; font-size: lar=
ge;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><div><span style=3D"color: rgb(0, =
255, 0); font-family: "courier new", monospace; font-size: large;=
background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div></div></=
div><div><span style=3D"color: rgb(0, 255, 0); font-family: "courier n=
ew", monospace; font-size: large; background-color: rgb(0, 0, 0);">=C2=
=A0 =C2=A0 * 32-bit=C2=A0 // RED GREEN BLUE=C2=A0 +=C2=A0 ALPHA=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span></div><div><span style=3D"color: rgb(0, 255, 0); font-f=
amily: "courier new", monospace; font-size: large; background-col=
or: rgb(0, 0, 0);">=C2=A0 =C2=A0 * PNG=C2=A0 =C2=A0 =C2=A0// most common im=
age format=C2=A0widely used=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0</span></div><div><span style=3D"color: rgb(0, 255, 0); font-family:=
"courier new", monospace; font-size: large; background-color: rg=
b(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><div><span style=3D"color: rg=
b(0, 255, 0); font-family: "courier new", monospace; font-size: l=
arge; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><=
div><span style=3D"color: rgb(0, 255, 0); font-family: "courier new&qu=
ot;, monospace; font-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =
=C2=A0 What Standardization Means:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 255, 0); font-family: =
"courier new", monospace; font-size: large; background-color: rgb=
(0, 0, 0);"><br></span></div><div><span style=3D"color: rgb(0, 255, 0); fon=
t-family: "courier new", monospace; font-size: large; background-=
color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><div><span style=
=3D"color: rgb(0, 255, 0); font-family: "courier new", monospace;=
font-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 * Slower=
=C2=A0 //=C2=A0Alpha is slower. But modern computers are fast.=C2=A0 =C2=A0=
=C2=A0</span><span style=3D"color: rgb(0, 255, 0); font-family: "couri=
er new", monospace; font-size: large; background-color: rgb(0, 0, 0);"=
><br></span></div><div><span style=3D"color: rgb(0, 255, 0); font-family: &=
quot;courier new", monospace; font-size: large; background-color: rgb(=
0, 0, 0);">=C2=A0 =C2=A0 * OMG NO .HIV .bmp support? // we want normal peop=
le to use .png</span><span style=3D"color: rgb(0, 255, 0); font-family: &qu=
ot;courier new", monospace; font-size: large; background-color: rgb(0,=
0, 0);"><br></span></div><div><span style=3D"color: rgb(0, 255, 0); font-f=
amily: "courier new", monospace; font-size: large; background-col=
or: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Modern=
computers are fast and=C2=A0 =C2=A0=C2=A0</span><span style=3D"color: rgb(=
0, 255, 0); font-family: "courier new", monospace; font-size: lar=
ge; background-color: rgb(0, 0, 0);"><br></span></div><div><span style=3D"c=
olor: rgb(0, 255, 0); font-family: "courier new", monospace; font=
-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0memory and storage is cheap=C2=A0 =C2=A0 =C2=A0=C2=
=A0</span><span style=3D"color: rgb(0, 255, 0); font-family: "courier =
new", monospace; font-size: large; background-color: rgb(0, 0, 0);"><b=
r></span></div><div><span style=3D"color: rgb(0, 255, 0); font-family: &quo=
t;courier new", monospace; font-size: large; background-color: rgb(0, =
0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Internet is ligh=
tspeed due=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 25=
5, 0); font-family: "courier new", monospace; font-size: large; b=
ackground-color: rgb(0, 0, 0);"><br></span></div><div><span style=3D"color:=
rgb(0, 255, 0); font-family: "courier new", monospace; font-size=
: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0to optical computing=C2=A0(fibre)=C2=A0 =C2=A0 =C2=A0</=
span></div><div><span style=3D"color: rgb(0, 255, 0); font-family: "co=
urier new", monospace; font-size: large; background-color: rgb(0, 0, 0=
);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><div><span style=3D"color: rgb(0, 25=
5, 0); font-family: "courier new", monospace; font-size: large; b=
ackground-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0We want people=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span></div><div><span style=3D"color: rgb(0, 255, 0);=
font-family: "courier new", monospace; font-size: large; backgro=
und-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0TO USE ONLY 1 IMAGE FORMAT (PNG)=C2=A0</span></div><div><span style=3D"c=
olor: rgb(0, 255, 0); font-family: "courier new", monospace; font=
-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span>=
</div><div><span style=3D"color: rgb(0, 255, 0); font-family: "courier=
new", monospace; font-size: large; background-color: rgb(0, 0, 0);">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This will create a nice=
standard=C2=A0</span></div><div><span style=3D"color: rgb(0, 255, 0); font=
-family: "courier new", monospace; font-size: large; background-c=
olor: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><div><span style=
=3D"color: rgb(0, 255, 0); font-family: "courier new", monospace;=
font-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 IMAGE FORMAT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span></div><div><span style=3D"c=
olor: rgb(0, 255, 0); font-family: "courier new", monospace; font=
-size: large; background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TO RULE THEM ALL=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0</span></div><div><span style=3D"color: rgb(0, 2=
55, 0); font-family: "courier new", monospace; font-size: large; =
background-color: rgb(0, 0, 0);">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</span></div><div><sp=
an style=3D"color: rgb(0, 255, 0); font-family: "courier new", mo=
nospace; font-size: large; background-color: rgb(0, 0, 0);"><br></span></di=
v><p class=3D"separator" style=3D"text-align: center; clear: both;"></p><di=
v style=3D"text-align: left;"><br></div><a imageanchor=3D"1" href=3D"https:=
//lh3.googleusercontent.com/-MPfN-JGPnPE/W1Zazylz38I/AAAAAAAABCs/EnAzgxXMbm=
c0GjpkcmocvlN0SMypo17bwCLcBGAs/s1600/matrix.png" style=3D"clear: left; marg=
in-bottom: 1em; float: left; margin-right: 1em;"><br></a><br><a imageanchor=
=3D"1" href=3D"https://lh3.googleusercontent.com/-MPfN-JGPnPE/W1Zazylz38I/A=
AAAAAAABCs/EnAzgxXMbmc0GjpkcmocvlN0SMypo17bwCLcBGAs/s1600/matrix.png" style=
=3D"clear: left; margin-bottom: 1em; float: left; margin-right: 1em;"><br><=
/a><p></p></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/62c48922-0415-464d-b25a-7f327faa7c48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62c48922-0415-464d-b25a-7f327faa7c48=
%40isocpp.org</a>.<br />
------=_Part_8562_2108212800.1532390569707--
------=_Part_8561_919422098.1532390569707--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Jul 2018 17:18:56 -0700 (PDT)
Raw View
------=_Part_8761_799441717.1532391536609
Content-Type: multipart/alternative;
boundary="----=_Part_8762_61815932.1532391536609"
------=_Part_8762_61815932.1532391536609
Content-Type: text/plain; charset="UTF-8"
On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:
>
> On 2018-07-23 13:37, Nicol Bolas wrote:
> >> Considering how long std::string has existed, and how much trouble
> >> trying to get any sort of Unicode support functions into the standard
> >> has been, I think it would be very, very wise to look at any proposed
> >> std::image as the equivalent of having std::string with no text codec
> >> conversions.
> >
> > But that's widely recognized as the biggest *problem* with
> `std::string`:
> > that there is no encoding attached in either a static or dynamic way.
> > There's not even a standard way of interpreting a string with a
> particular
> > encoding. This is one of the biggest reasons why people don't use
> > `std::string`.
>
> And yet, many people *do* use std::string.
A standard library tool's successfulness can be measured based on what
percentage of the userbase is able to use that tool to solve problems in
that tool's domain, relative to having to get another one/write their own.
`vector` is a very successful tool by that metric; `basic_string` is
decidedly less so.
Even better, you can see how successful it is based on the nature of the
alternatives people write for them. `vector` alternatives are primarily for
corner-cases. They provide very specific optimizations in certain
workloads: small buffer storage, etc. Basically, these alternatives exist
because there cannot be a one-size-fits-all dynamic array.
By contrast, alternative string types are written/used because of a lack of
*functionality* in the standard library version. That is, a lot of people
write string types, not because they are trying to improve performance or
reduce memory consumption; they're merely trying to make their program
*work*.
That is a sign of a deficient tool. And deficient standard tools lead to
workarounds. If `std::image` cannot do what many people need to do with
images, then they won't use it. And thus, image types will continue to
proliferate and interoperation will not be achieved.
Just as people use image
> containers in applications that possess very rudimentary, if any,
> colorspace handling.
>
> First, please note that I'm not saying that colorspace conversion has no
> place in standard C++. If we get std::image, then clearly, colorspace
> conversion seems useful also. All I'm saying is that I don't think we
> should make colorspace conversion a precondition of a *basic* container
> for "pixels".
>
Alright, let's talk scope, because nobody has actually sat down and tried
to draw out the borders of this functionality. Oh yes, the initial proposal
says "X formats, Y features, etc." But there's no specific "here's the use
cases for this feature" set down.
So, what exactly is the image-specific stuff that this "basic container for
pixels" will provide? What is this type going to give me that `vector` with
a couple of helper function cannot?
If the thing can't handle fundamental image concepts like colorspaces,
image formats beyond the trivial, and the like, what exactly *does* it
handle? Blitting? Accessing a pixel through two dimensional coordinates? Do
we really need a whole type just for that?
Second, remember that the OP *did* include a field for specifying
> colorspace; just no specification of how to *interpret* that field.
>
> The point is to keep in mind that "perfect is the enemy of good", and to
> avoid getting so bogged down in wanting something "perfect" that we wind
> up with nothing at all.
>
Is having "nothing at all" ultimately so different from having "nothing
that I can actually use"? It's easy to declare "perfect is the enemy of
good" for features that you don't need.
I do not feel comfortable telling other people that their use cases aren't
important enough to warrant being in the standard library image class.
Especially when the best argument against them is nothing more than "it'd
take *time* to actually do."
If standardizing this thing is important, then it's probably important
enough to take some time.
The whole origin of the original proposal, after all, was to try to
> learn from the mistakes of 2D Graphics.
>
That all rather depends on what you feel the mistakes of the 2D graphics
proposal actually were.
> C++'s "standard" string class is basically a laughing stock
> > among its competing languages because of this; practically every other
> > language has a more usable string class than us.
>
> Would I rather use e.g. QString? Probably. *Can* I use std::string?
> Sure. The reality is that many applications *don't actually care* about
> text encoding. As long as you always deal with text in the active
> runtime encoding, std::string is just fine.
>
> Many potential users of std::image are in the much same boat; they just
> assume that no colorspace conversion is necessary... and in many cases,
> *in real, existing practice*, this works just fine.
>
> --
> Matthew
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9638334d-1d8e-4313-b811-df48ef5c7056%40isocpp.org.
------=_Part_8762_61815932.1532391536609
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-07-23 13:37,=
Nicol Bolas wrote:
<br>>> Considering how long std::string has existed, and how much tro=
uble=20
<br>>> trying to get any sort of Unicode support functions into the s=
tandard=20
<br>>> has been, I think it would be very, very wise to look at any p=
roposed=20
<br>>> std::image as the equivalent of having std::string with no tex=
t codec=20
<br>>> conversions.
<br>>=20
<br>> But that's widely recognized as the biggest *problem* with `st=
d::string`:=20
<br>> that there is no encoding attached in either a static or dynamic w=
ay.=20
<br>> There's not even a standard way of interpreting a string with =
a particular=20
<br>> encoding. This is one of the biggest reasons why people don't =
use=20
<br>> `std::string`.
<br>
<br>And yet, many people *do* use std::string.</blockquote><div><br></div><=
div>A standard library tool's successfulness can be measured based on w=
hat percentage of the userbase is able to use that tool to solve problems i=
n that tool's domain, relative to having to get another one/write their=
own. `vector` is a very successful tool by that metric; `basic_string` is =
decidedly less so.</div><div><br></div><div>Even better, you can see how su=
ccessful it is based on the nature of the alternatives people write for the=
m. `vector` alternatives are primarily for corner-cases. They provide very =
specific optimizations in certain workloads: small buffer storage, etc. Bas=
ically, these alternatives exist because there cannot be a one-size-fits-al=
l dynamic array.</div><div><br></div><div>By contrast, alternative string t=
ypes are written/used because of a lack of <i>functionality</i> in the stan=
dard library version. That is, a lot of people write string types, not beca=
use they are trying to improve performance or reduce memory consumption; th=
ey're merely trying to make their program <i>work</i>.</div><div><br></=
div><div>That is a sign of a deficient tool. And deficient standard tools l=
ead to workarounds. If `std::image` cannot do what many people need to do w=
ith images, then they won't use it. And thus, image types will continue=
to proliferate and interoperation will not be achieved.<br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Just as people use image
<br>containers in applications that possess very rudimentary, if any,
<br>colorspace handling.
<br>
<br>First, please note that I'm not saying that colorspace conversion h=
as no
<br>place in standard C++. If we get std::image, then clearly, colorspace
<br>conversion seems useful also. All I'm saying is that I don't th=
ink we
<br>should make colorspace conversion a precondition of a *basic* container
<br>for "pixels".<br></blockquote><div><br></div><div>Alright, le=
t's talk scope, because nobody has actually sat down and tried to draw =
out the borders of this functionality. Oh yes, the initial proposal says &q=
uot;X formats, Y features, etc." But there's no specific "her=
e's the use cases for this feature" set down.</div><div><br></div>=
<div>So, what exactly is the image-specific stuff that this "basic con=
tainer for pixels" will provide? What is this type going to give me th=
at `vector` with a couple of helper function cannot?</div><div><br></div><d=
iv>If the thing can't handle fundamental image concepts like colorspace=
s, image formats beyond the trivial, and the like, what exactly <i>does</i>=
it handle? Blitting? Accessing a pixel through two dimensional coordinates=
? Do we really need a whole type just for that?<br></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
Second, remember that the OP *did* include a field for specifying
<br>colorspace; just no specification of how to *interpret* that field.
<br>
<br>The point is to keep in mind that "perfect is the enemy of good&qu=
ot;, and to
<br>avoid getting so bogged down in wanting something "perfect" t=
hat we wind
<br>up with nothing at all.<br></blockquote><div><br></div><div>Is having &=
quot;nothing at all" ultimately so different from having "nothing=
that I can actually use"? It's easy to declare "perfect is t=
he enemy of good" for features that you don't need.</div><div><br>=
</div><div>I do not feel comfortable telling other people that their use ca=
ses aren't important enough to warrant being in the standard library im=
age class. Especially when the best argument against them is nothing more t=
han "it'd take <i>time</i> to actually do."</div><div><br></d=
iv><div>If standardizing this thing is important, then it's probably im=
portant enough to take some time.<br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
The whole origin of the original proposal, after all, was to try to
<br>learn from the mistakes of 2D Graphics.<br></blockquote><div><br></div>=
<div>That all rather depends on what you feel the mistakes of the 2D graphi=
cs proposal actually were.<br></div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
> C++'s "standard" string class is basically a laughing st=
ock=20
<br>> among its competing languages because of this; practically every o=
ther=20
<br>> language has a more usable string class than us.
<br>
<br>Would I rather use e.g. QString? Probably. *Can* I use std::string?
<br>Sure. The reality is that many applications *don't actually care* a=
bout
<br>text encoding. As long as you always deal with text in the active
<br>runtime encoding, std::string is just fine.
<br>
<br>Many potential users of std::image are in the much same boat; they just
<br>assume that no colorspace conversion is necessary... and in many cases,
<br>*in real, existing practice*, this works just fine.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9638334d-1d8e-4313-b811-df48ef5c7056%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9638334d-1d8e-4313-b811-df48ef5c7056=
%40isocpp.org</a>.<br />
------=_Part_8762_61815932.1532391536609--
------=_Part_8761_799441717.1532391536609--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 24 Jul 2018 11:33:34 -0400
Raw View
On 2018-07-23 20:18, Nicol Bolas wrote:
> A standard library tool's successfulness can be measured based on what
> percentage of the userbase is able to use that tool to solve problems in
> that tool's domain, relative to having to get another one/write their own.
> `vector` is a very successful tool by that metric; `basic_string` is
> decidedly less so.
By that metric, I predict that the "success" of a std::image with *no*
colorspace information at all, let alone a conversion library, would be
about 70%.
That's from my own experience, which in fairness is most likely biased.
However, it *is* from *direct, first-hand experience*. Can your claims
that colorspace conversion is "absolutely vital" say the same?
> Even better, you can see how successful it is based on the nature of the
> alternatives people write for them. `vector` alternatives are primarily for
> corner-cases. They provide very specific optimizations in certain
> workloads: small buffer storage, etc. Basically, these alternatives exist
> because there cannot be a one-size-fits-all dynamic array.
>
> By contrast, alternative string types are written/used because of a lack of
> *functionality* in the standard library version. That is, a lot of people
> write string types, not because they are trying to improve performance or
> reduce memory consumption; they're merely trying to make their program
> *work*.
But... your argument here doesn't follow. The proposed std::image *does*
carry colorspace information. Granted, not in a standardized format
(even so, no one is saying we can't or shouldn't have *guidelines* as to
what strings to use), but then, someone's one-off replacement will
hardly be "standardized" either. Given that, why would someone *not* use
std::image? In what way can a custom format improve? (Why would you not,
at the very least, create a wrapper over std::image that uses some other
mechanism to carry colorspace information, but still uses std::image as
the underlying memory container?)
> That is a sign of a deficient tool. And deficient standard tools lead to
> workarounds. If `std::image` cannot do what many people need to do with
> images, then they won't use it. And thus, image types will continue to
> proliferate and interoperation will not be achieved.
Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I've
already named several libraries for which a std::image without even
colorspace information *is* sufficient. If you're going to insist
otherwise, despite evidence to the contrary, you need to back that up.
> On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:
>> First, please note that I'm not saying that colorspace conversion has no
>> place in standard C++. If we get std::image, then clearly, colorspace
>> conversion seems useful also. All I'm saying is that I don't think we
>> should make colorspace conversion a precondition of a *basic* container
>> for "pixels".
>
> Alright, let's talk scope, because nobody has actually sat down and tried
> to draw out the borders of this functionality. Oh yes, the initial proposal
> says "X formats, Y features, etc." But there's no specific "here's the use
> cases for this feature" set down.
My specific use cases are the various, *existing* libraries that need
pixel containers. I have *personally* written one such container, and
been at least somewhat involved in the development of a second. I've
written or been involved with code that uses five.
> So, what exactly is the image-specific stuff that this "basic container for
> pixels" will provide? What is this type going to give me that `vector` with
> a couple of helper function cannot?
The only *critical* feature that comes to mind would be ability to
assume a foreign memory block. Sure, you *could* build the rest into a
helper class that stores e.g. stride information while using std::vector
as underlying storage, but even if that's all you're doing, the fact
that libraries are *already* doing that sort of thing suggests that a
std::image would still be helpful.
Again, this is like asking "why do we need std::string when we have
vector<char>?". Or, why do we need std::matrix when we have std::vector?
I would argue that a standard type to carry the information that
describes the layout of the underlying bag of bytes is important.
An even better example would be a flat_map. Granted, we don't have one
of those (yet), but plenty of people think we should, even though it's
nothing but some helper functions over a std::vector. I rather think the
main reason we *don't* have such a critter is because it is "too niche".
> If the thing can't handle fundamental image concepts like colorspaces,
> image formats beyond the trivial, and the like, what exactly *does* it
> handle? Blitting? Accessing a pixel through two dimensional coordinates? Do
> we really need a whole type just for that?
Asking whether we "need" a type like that is, IMO, disingenuous.
Existing practice is that people *will* create that type if it isn't
provided for them.
Besides, part of the point is to avoid making the mistakes of 2D
Graphics, by building up capabilities from the ground up, rather than
from the top down. Today, std::image. Tomorrow, colorspace conversion,
or blitting, or image I/O, or...
The point is to give these features a common type language, rather than
having to invent their own types, as 2D Graphics did for linear algebra
types. Also, so that libraries implementing these sorts of things have a
standard type to use for their basic primitives, in order to facilitate
interoperability.
The standard library is successful because it doesn't try to be the
be-all, end-all of programming in C++, but rather, to provide *low
level* types that higher level algorithms can build upon, in order to
facilitate interoperability. Going back to your earlier point, the
higher up the stack you move, the less chance you have of producing
something that is useful to a majority of people. (Another reason 2D
Graphics failed...)
>> The point is to keep in mind that "perfect is the enemy of good", and to
>> avoid getting so bogged down in wanting something "perfect" that we wind
>> up with nothing at all.
>
> Is having "nothing at all" ultimately so different from having "nothing
> that I can actually use"? It's easy to declare "perfect is the enemy of
> good" for features that you don't need.
Aaaaand... I *don't* need colorspace conversion. At least, not always,
and more critically, I *can* use a std::image that doesn't have it.
This goes back to your *false* assertion that a std::image without
colorspace conversion is not useful. *Actual experience* says otherwise.
Therefore, you can mutter all you want about "having 'nothing that I can
actually use'", but that claim is wrong.
*Existing usage* clearly demonstrates that a std::image, with or without
colorspace conversion (or even any colorspace information!) would be
useful to real world code.
> I do not feel comfortable telling other people that their use cases aren't
> important enough to warrant being in the standard library image class.
And I'm *not* saying that. If someone can present a usable proposal for
colorspace conversion... great! I will be *ecstatic*! (I'm not going to
hold my breath waiting for it, though, especially when there is no
standard image container on which it might operate.)
Meanwhile, I note that you're perfectly comfortable telling me that
these as-yet-hypothetical "other people" are sufficiently important that
*my* use cases should be deprived of a standard library type.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-ba84-22cd51a8a125%40gmail.com.
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Wed, 25 Jul 2018 10:35:42 +0200
Raw View
--000000000000a3a6050571cec366
Content-Type: text/plain; charset="UTF-8"
Take look at boost::gil.
Then already poses containers with so many capabilities.
std::image must must be at least like that.
I see that as minimum.
On Tue, Jul 24, 2018 at 5:33 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2018-07-23 20:18, Nicol Bolas wrote:
> > A standard library tool's successfulness can be measured based on what
> > percentage of the userbase is able to use that tool to solve problems in
> > that tool's domain, relative to having to get another one/write their
> own.
> > `vector` is a very successful tool by that metric; `basic_string` is
> > decidedly less so.
>
> By that metric, I predict that the "success" of a std::image with *no*
> colorspace information at all, let alone a conversion library, would be
> about 70%.
>
> That's from my own experience, which in fairness is most likely biased.
> However, it *is* from *direct, first-hand experience*. Can your claims
> that colorspace conversion is "absolutely vital" say the same?
>
> > Even better, you can see how successful it is based on the nature of the
> > alternatives people write for them. `vector` alternatives are primarily
> for
> > corner-cases. They provide very specific optimizations in certain
> > workloads: small buffer storage, etc. Basically, these alternatives
> exist
> > because there cannot be a one-size-fits-all dynamic array.
> >
> > By contrast, alternative string types are written/used because of a lack
> of
> > *functionality* in the standard library version. That is, a lot of
> people
> > write string types, not because they are trying to improve performance
> or
> > reduce memory consumption; they're merely trying to make their program
> > *work*.
>
> But... your argument here doesn't follow. The proposed std::image *does*
> carry colorspace information. Granted, not in a standardized format
> (even so, no one is saying we can't or shouldn't have *guidelines* as to
> what strings to use), but then, someone's one-off replacement will
> hardly be "standardized" either. Given that, why would someone *not* use
> std::image? In what way can a custom format improve? (Why would you not,
> at the very least, create a wrapper over std::image that uses some other
> mechanism to carry colorspace information, but still uses std::image as
> the underlying memory container?)
>
> > That is a sign of a deficient tool. And deficient standard tools lead to
> > workarounds. If `std::image` cannot do what many people need to do with
> > images, then they won't use it. And thus, image types will continue to
> > proliferate and interoperation will not be achieved.
>
> Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I've
> already named several libraries for which a std::image without even
> colorspace information *is* sufficient. If you're going to insist
> otherwise, despite evidence to the contrary, you need to back that up.
>
> > On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:
> >> First, please note that I'm not saying that colorspace conversion has
> no
> >> place in standard C++. If we get std::image, then clearly, colorspace
> >> conversion seems useful also. All I'm saying is that I don't think we
> >> should make colorspace conversion a precondition of a *basic* container
> >> for "pixels".
> >
> > Alright, let's talk scope, because nobody has actually sat down and
> tried
> > to draw out the borders of this functionality. Oh yes, the initial
> proposal
> > says "X formats, Y features, etc." But there's no specific "here's the
> use
> > cases for this feature" set down.
>
> My specific use cases are the various, *existing* libraries that need
> pixel containers. I have *personally* written one such container, and
> been at least somewhat involved in the development of a second. I've
> written or been involved with code that uses five.
>
> > So, what exactly is the image-specific stuff that this "basic container
> for
> > pixels" will provide? What is this type going to give me that `vector`
> with
> > a couple of helper function cannot?
>
> The only *critical* feature that comes to mind would be ability to
> assume a foreign memory block. Sure, you *could* build the rest into a
> helper class that stores e.g. stride information while using std::vector
> as underlying storage, but even if that's all you're doing, the fact
> that libraries are *already* doing that sort of thing suggests that a
> std::image would still be helpful.
>
> Again, this is like asking "why do we need std::string when we have
> vector<char>?". Or, why do we need std::matrix when we have std::vector?
> I would argue that a standard type to carry the information that
> describes the layout of the underlying bag of bytes is important.
>
> An even better example would be a flat_map. Granted, we don't have one
> of those (yet), but plenty of people think we should, even though it's
> nothing but some helper functions over a std::vector. I rather think the
> main reason we *don't* have such a critter is because it is "too niche".
>
> > If the thing can't handle fundamental image concepts like colorspaces,
> > image formats beyond the trivial, and the like, what exactly *does* it
> > handle? Blitting? Accessing a pixel through two dimensional coordinates?
> Do
> > we really need a whole type just for that?
>
> Asking whether we "need" a type like that is, IMO, disingenuous.
> Existing practice is that people *will* create that type if it isn't
> provided for them.
>
> Besides, part of the point is to avoid making the mistakes of 2D
> Graphics, by building up capabilities from the ground up, rather than
> from the top down. Today, std::image. Tomorrow, colorspace conversion,
> or blitting, or image I/O, or...
>
> The point is to give these features a common type language, rather than
> having to invent their own types, as 2D Graphics did for linear algebra
> types. Also, so that libraries implementing these sorts of things have a
> standard type to use for their basic primitives, in order to facilitate
> interoperability.
>
> The standard library is successful because it doesn't try to be the
> be-all, end-all of programming in C++, but rather, to provide *low
> level* types that higher level algorithms can build upon, in order to
> facilitate interoperability. Going back to your earlier point, the
> higher up the stack you move, the less chance you have of producing
> something that is useful to a majority of people. (Another reason 2D
> Graphics failed...)
>
> >> The point is to keep in mind that "perfect is the enemy of good", and
> to
> >> avoid getting so bogged down in wanting something "perfect" that we
> wind
> >> up with nothing at all.
> >
> > Is having "nothing at all" ultimately so different from having "nothing
> > that I can actually use"? It's easy to declare "perfect is the enemy of
> > good" for features that you don't need.
>
> Aaaaand... I *don't* need colorspace conversion. At least, not always,
> and more critically, I *can* use a std::image that doesn't have it.
>
> This goes back to your *false* assertion that a std::image without
> colorspace conversion is not useful. *Actual experience* says otherwise.
> Therefore, you can mutter all you want about "having 'nothing that I can
> actually use'", but that claim is wrong.
>
> *Existing usage* clearly demonstrates that a std::image, with or without
> colorspace conversion (or even any colorspace information!) would be
> useful to real world code.
>
> > I do not feel comfortable telling other people that their use cases
> aren't
> > important enough to warrant being in the standard library image class.
>
> And I'm *not* saying that. If someone can present a usable proposal for
> colorspace conversion... great! I will be *ecstatic*! (I'm not going to
> hold my breath waiting for it, though, especially when there is no
> standard image container on which it might operate.)
>
> Meanwhile, I note that you're perfectly comfortable telling me that
> these as-yet-hypothetical "other people" are sufficiently important that
> *my* use cases should be deprived of a standard library type.
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-
> ba84-22cd51a8a125%40gmail.com.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ8%2BssP0k%2B-TSiZZycxRZ3%2B4X4HG3i1zopH2SPu8uw%40mail.gmail.com.
--000000000000a3a6050571cec366
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br>Take look at boost::gil.<br>Then already poses co=
ntainers with so many capabilities.<br>std::image must must be at least lik=
e that.</div><div>I see that as minimum.</div><div><br></div><div><br></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Ju=
l 24, 2018 at 5:33 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=3D"mai=
lto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-07-23 20:18, =
Nicol Bolas wrote:<br>
> A standard library tool's successfulness can be measured based on =
what <br>
> percentage of the userbase is able to use that tool to solve problems =
in <br>
> that tool's domain, relative to having to get another one/write th=
eir own. <br>
> `vector` is a very successful tool by that metric; `basic_string` is <=
br>
> decidedly less so.<br>
<br>
By that metric, I predict that the "success" of a std::image with=
*no*<br>
colorspace information at all, let alone a conversion library, would be<br>
about 70%.<br>
<br>
That's from my own experience, which in fairness is most likely biased.=
<br>
However, it *is* from *direct, first-hand experience*. Can your claims<br>
that colorspace conversion is "absolutely vital" say the same?<br=
>
<br>
> Even better, you can see how successful it is based on the nature of t=
he <br>
> alternatives people write for them. `vector` alternatives are primaril=
y for <br>
> corner-cases. They provide very specific optimizations in certain <br>
> workloads: small buffer storage, etc. Basically, these alternatives ex=
ist <br>
> because there cannot be a one-size-fits-all dynamic array.<br>
> <br>
> By contrast, alternative string types are written/used because of a la=
ck of <br>
> *functionality* in the standard library version. That is, a lot of peo=
ple <br>
> write string types, not because they are trying to improve performance=
or <br>
> reduce memory consumption; they're merely trying to make their pro=
gram <br>
> *work*.<br>
<br>
But... your argument here doesn't follow. The proposed std::image *does=
*<br>
carry colorspace information. Granted, not in a standardized format<br>
(even so, no one is saying we can't or shouldn't have *guidelines* =
as to<br>
what strings to use), but then, someone's one-off replacement will<br>
hardly be "standardized" either. Given that, why would someone *n=
ot* use<br>
std::image? In what way can a custom format improve? (Why would you not,<br=
>
at the very least, create a wrapper over std::image that uses some other<br=
>
mechanism to carry colorspace information, but still uses std::image as<br>
the underlying memory container?)<br>
<br>
> That is a sign of a deficient tool. And deficient standard tools lead =
to <br>
> workarounds. If `std::image` cannot do what many people need to do wit=
h <br>
> images, then they won't use it. And thus, image types will continu=
e to <br>
> proliferate and interoperation will not be achieved.<br>
<br>
Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I&#=
39;ve<br>
already named several libraries for which a std::image without even<br>
colorspace information *is* sufficient. If you're going to insist<br>
otherwise, despite evidence to the contrary, you need to back that up.<br>
<br>
> On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:<b=
r>
>> First, please note that I'm not saying that colorspace convers=
ion has no <br>
>> place in standard C++. If we get std::image, then clearly, colorsp=
ace <br>
>> conversion seems useful also. All I'm saying is that I don'=
;t think we <br>
>> should make colorspace conversion a precondition of a *basic* cont=
ainer <br>
>> for "pixels".<br>
> <br>
> Alright, let's talk scope, because nobody has actually sat down an=
d tried <br>
> to draw out the borders of this functionality. Oh yes, the initial pro=
posal <br>
> says "X formats, Y features, etc." But there's no specif=
ic "here's the use <br>
> cases for this feature" set down.<br>
<br>
My specific use cases are the various, *existing* libraries that need<br>
pixel containers. I have *personally* written one such container, and<br>
been at least somewhat involved in the development of a second. I've<br=
>
written or been involved with code that uses five.<br>
<br>
> So, what exactly is the image-specific stuff that this "basic con=
tainer for <br>
> pixels" will provide? What is this type going to give me that `ve=
ctor` with <br>
> a couple of helper function cannot?<br>
<br>
The only *critical* feature that comes to mind would be ability to<br>
assume a foreign memory block. Sure, you *could* build the rest into a<br>
helper class that stores e.g. stride information while using std::vector<br=
>
as underlying storage, but even if that's all you're doing, the fac=
t<br>
that libraries are *already* doing that sort of thing suggests that a<br>
std::image would still be helpful.<br>
<br>
Again, this is like asking "why do we need std::string when we have<br=
>
vector<char>?". Or, why do we need std::matrix when we have std:=
:vector?<br>
I would argue that a standard type to carry the information that<br>
describes the layout of the underlying bag of bytes is important.<br>
<br>
An even better example would be a flat_map. Granted, we don't have one<=
br>
of those (yet), but plenty of people think we should, even though it's<=
br>
nothing but some helper functions over a std::vector. I rather think the<br=
>
main reason we *don't* have such a critter is because it is "too n=
iche".<br>
<br>
> If the thing can't handle fundamental image concepts like colorspa=
ces, <br>
> image formats beyond the trivial, and the like, what exactly *does* it=
<br>
> handle? Blitting? Accessing a pixel through two dimensional coordinate=
s? Do <br>
> we really need a whole type just for that?<br>
<br>
Asking whether we "need" a type like that is, IMO, disingenuous.<=
br>
Existing practice is that people *will* create that type if it isn't<br=
>
provided for them.<br>
<br>
Besides, part of the point is to avoid making the mistakes of 2D<br>
Graphics, by building up capabilities from the ground up, rather than<br>
from the top down. Today, std::image. Tomorrow, colorspace conversion,<br>
or blitting, or image I/O, or...<br>
<br>
The point is to give these features a common type language, rather than<br>
having to invent their own types, as 2D Graphics did for linear algebra<br>
types. Also, so that libraries implementing these sorts of things have a<br=
>
standard type to use for their basic primitives, in order to facilitate<br>
interoperability.<br>
<br>
The standard library is successful because it doesn't try to be the<br>
be-all, end-all of programming in C++, but rather, to provide *low<br>
level* types that higher level algorithms can build upon, in order to<br>
facilitate interoperability. Going back to your earlier point, the<br>
higher up the stack you move, the less chance you have of producing<br>
something that is useful to a majority of people. (Another reason 2D<br>
Graphics failed...)<br>
<br>
>> The point is to keep in mind that "perfect is the enemy of go=
od", and to <br>
>> avoid getting so bogged down in wanting something "perfect&qu=
ot; that we wind <br>
>> up with nothing at all.<br>
> <br>
> Is having "nothing at all" ultimately so different from havi=
ng "nothing <br>
> that I can actually use"? It's easy to declare "perfect =
is the enemy of <br>
> good" for features that you don't need.<br>
<br>
Aaaaand... I *don't* need colorspace conversion. At least, not always,<=
br>
and more critically, I *can* use a std::image that doesn't have it.<br>
<br>
This goes back to your *false* assertion that a std::image without<br>
colorspace conversion is not useful. *Actual experience* says otherwise.<br=
>
Therefore, you can mutter all you want about "having 'nothing that=
I can<br>
actually use'", but that claim is wrong.<br>
<br>
*Existing usage* clearly demonstrates that a std::image, with or without<br=
>
colorspace conversion (or even any colorspace information!) would be<br>
useful to real world code.<br>
<br>
> I do not feel comfortable telling other people that their use cases ar=
en't <br>
> important enough to warrant being in the standard library image class.=
<br>
<br>
And I'm *not* saying that. If someone can present a usable proposal for=
<br>
colorspace conversion... great! I will be *ecstatic*! (I'm not going to=
<br>
hold my breath waiting for it, though, especially when there is no<br>
standard image container on which it might operate.)<br>
<br>
Meanwhile, I note that you're perfectly comfortable telling me that<br>
these as-yet-hypothetical "other people" are sufficiently importa=
nt that<br>
*my* use cases should be deprived of a standard library type.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-ba84-22cd51a8a125%=
40gmail.com" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/91292cdd-f72b-d867-<wbr>ba84-=
22cd51a8a125%40gmail.com</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ8%2BssP0k%2B-TSiZZycxRZ3%2=
B4X4HG3i1zopH2SPu8uw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ=
8%2BssP0k%2B-TSiZZycxRZ3%2B4X4HG3i1zopH2SPu8uw%40mail.gmail.com</a>.<br />
--000000000000a3a6050571cec366--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 26 Jul 2018 21:55:52 -0400
Raw View
--000000000000618ab50571f16995
Content-Type: text/plain; charset="UTF-8"
Let's step back a bit.
The original idea, IIUC, had a string not just for colourspace, but for
even just format.
That is the main part I'd like to tackle - if you can't at least agree on a
canonical/interchange form of a pixel (ie CIE XYZ or something), then you
aren't really standardizing anything. You just have an array of bytes.
You have just a de facto standard, with QImage internals checking for
hardcoded strings like "RGBA", and libpng checking for "ARGB" instead.
If I need to google for extra information (ie for the de facto parts), and
can't code anything useful directly from the standard, it just really isn't
a standard.
From there we can argue whether the conversion to interchange-pixel needs
to be hi-fidelity or not. Maybe that's just QoI.
On Tue, Jul 24, 2018 at 11:33 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2018-07-23 20:18, Nicol Bolas wrote:
> > A standard library tool's successfulness can be measured based on what
> > percentage of the userbase is able to use that tool to solve problems in
> > that tool's domain, relative to having to get another one/write their
> own.
> > `vector` is a very successful tool by that metric; `basic_string` is
> > decidedly less so.
>
> By that metric, I predict that the "success" of a std::image with *no*
> colorspace information at all, let alone a conversion library, would be
> about 70%.
>
> That's from my own experience, which in fairness is most likely biased.
> However, it *is* from *direct, first-hand experience*. Can your claims
> that colorspace conversion is "absolutely vital" say the same?
>
> > Even better, you can see how successful it is based on the nature of the
> > alternatives people write for them. `vector` alternatives are primarily
> for
> > corner-cases. They provide very specific optimizations in certain
> > workloads: small buffer storage, etc. Basically, these alternatives
> exist
> > because there cannot be a one-size-fits-all dynamic array.
> >
> > By contrast, alternative string types are written/used because of a lack
> of
> > *functionality* in the standard library version. That is, a lot of
> people
> > write string types, not because they are trying to improve performance
> or
> > reduce memory consumption; they're merely trying to make their program
> > *work*.
>
> But... your argument here doesn't follow. The proposed std::image *does*
> carry colorspace information. Granted, not in a standardized format
> (even so, no one is saying we can't or shouldn't have *guidelines* as to
> what strings to use), but then, someone's one-off replacement will
> hardly be "standardized" either. Given that, why would someone *not* use
> std::image? In what way can a custom format improve? (Why would you not,
> at the very least, create a wrapper over std::image that uses some other
> mechanism to carry colorspace information, but still uses std::image as
> the underlying memory container?)
>
> > That is a sign of a deficient tool. And deficient standard tools lead to
> > workarounds. If `std::image` cannot do what many people need to do with
> > images, then they won't use it. And thus, image types will continue to
> > proliferate and interoperation will not be achieved.
>
> Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I've
> already named several libraries for which a std::image without even
> colorspace information *is* sufficient. If you're going to insist
> otherwise, despite evidence to the contrary, you need to back that up.
>
> > On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:
> >> First, please note that I'm not saying that colorspace conversion has
> no
> >> place in standard C++. If we get std::image, then clearly, colorspace
> >> conversion seems useful also. All I'm saying is that I don't think we
> >> should make colorspace conversion a precondition of a *basic* container
> >> for "pixels".
> >
> > Alright, let's talk scope, because nobody has actually sat down and
> tried
> > to draw out the borders of this functionality. Oh yes, the initial
> proposal
> > says "X formats, Y features, etc." But there's no specific "here's the
> use
> > cases for this feature" set down.
>
> My specific use cases are the various, *existing* libraries that need
> pixel containers. I have *personally* written one such container, and
> been at least somewhat involved in the development of a second. I've
> written or been involved with code that uses five.
>
> > So, what exactly is the image-specific stuff that this "basic container
> for
> > pixels" will provide? What is this type going to give me that `vector`
> with
> > a couple of helper function cannot?
>
> The only *critical* feature that comes to mind would be ability to
> assume a foreign memory block. Sure, you *could* build the rest into a
> helper class that stores e.g. stride information while using std::vector
> as underlying storage, but even if that's all you're doing, the fact
> that libraries are *already* doing that sort of thing suggests that a
> std::image would still be helpful.
>
> Again, this is like asking "why do we need std::string when we have
> vector<char>?". Or, why do we need std::matrix when we have std::vector?
> I would argue that a standard type to carry the information that
> describes the layout of the underlying bag of bytes is important.
>
> An even better example would be a flat_map. Granted, we don't have one
> of those (yet), but plenty of people think we should, even though it's
> nothing but some helper functions over a std::vector. I rather think the
> main reason we *don't* have such a critter is because it is "too niche".
>
> > If the thing can't handle fundamental image concepts like colorspaces,
> > image formats beyond the trivial, and the like, what exactly *does* it
> > handle? Blitting? Accessing a pixel through two dimensional coordinates?
> Do
> > we really need a whole type just for that?
>
> Asking whether we "need" a type like that is, IMO, disingenuous.
> Existing practice is that people *will* create that type if it isn't
> provided for them.
>
> Besides, part of the point is to avoid making the mistakes of 2D
> Graphics, by building up capabilities from the ground up, rather than
> from the top down. Today, std::image. Tomorrow, colorspace conversion,
> or blitting, or image I/O, or...
>
> The point is to give these features a common type language, rather than
> having to invent their own types, as 2D Graphics did for linear algebra
> types. Also, so that libraries implementing these sorts of things have a
> standard type to use for their basic primitives, in order to facilitate
> interoperability.
>
> The standard library is successful because it doesn't try to be the
> be-all, end-all of programming in C++, but rather, to provide *low
> level* types that higher level algorithms can build upon, in order to
> facilitate interoperability. Going back to your earlier point, the
> higher up the stack you move, the less chance you have of producing
> something that is useful to a majority of people. (Another reason 2D
> Graphics failed...)
>
> >> The point is to keep in mind that "perfect is the enemy of good", and
> to
> >> avoid getting so bogged down in wanting something "perfect" that we
> wind
> >> up with nothing at all.
> >
> > Is having "nothing at all" ultimately so different from having "nothing
> > that I can actually use"? It's easy to declare "perfect is the enemy of
> > good" for features that you don't need.
>
> Aaaaand... I *don't* need colorspace conversion. At least, not always,
> and more critically, I *can* use a std::image that doesn't have it.
>
> This goes back to your *false* assertion that a std::image without
> colorspace conversion is not useful. *Actual experience* says otherwise.
> Therefore, you can mutter all you want about "having 'nothing that I can
> actually use'", but that claim is wrong.
>
> *Existing usage* clearly demonstrates that a std::image, with or without
> colorspace conversion (or even any colorspace information!) would be
> useful to real world code.
>
> > I do not feel comfortable telling other people that their use cases
> aren't
> > important enough to warrant being in the standard library image class.
>
> And I'm *not* saying that. If someone can present a usable proposal for
> colorspace conversion... great! I will be *ecstatic*! (I'm not going to
> hold my breath waiting for it, though, especially when there is no
> standard image container on which it might operate.)
>
> Meanwhile, I note that you're perfectly comfortable telling me that
> these as-yet-hypothetical "other people" are sufficiently important that
> *my* use cases should be deprived of a standard library type.
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-
> ba84-22cd51a8a125%40gmail.com.
>
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGoi_oBFc3UQoQt13jEY39oH_pNCyqiFd9bTkq-ieMjA%40mail.gmail.com.
--000000000000618ab50571f16995
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Let's step back a bit.</div><div><br></div><div>T=
he original idea, IIUC, had a string not just for colourspace, but for even=
just format.<br></div><div><br></div><div>That is the main part I'd li=
ke to tackle - if you can't at least agree on a canonical/interchange f=
orm of a pixel (ie CIE XYZ or something), then you aren't really standa=
rdizing anything.=C2=A0 You just have an array of bytes.=C2=A0 You have jus=
t a de facto standard, with QImage internals checking for hardcoded strings=
like "RGBA", and libpng checking for "ARGB" instead.</=
div><div><br></div><div>If I need to google for extra information (ie for t=
he de facto parts), and can't code anything useful directly from the st=
andard, it just really isn't a standard.<br></div><div><br></div><div>F=
rom there we can argue whether the conversion to interchange-pixel needs to=
be hi-fidelity or not.=C2=A0 Maybe that's just QoI.<br></div><div><br>=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tu=
e, Jul 24, 2018 at 11:33 AM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On 2018-07-23 20:18, Nicol Bolas wrote:<br>
> A standard library tool's successfulness can be measured based on =
what <br>
> percentage of the userbase is able to use that tool to solve problems =
in <br>
> that tool's domain, relative to having to get another one/write th=
eir own. <br>
> `vector` is a very successful tool by that metric; `basic_string` is <=
br>
> decidedly less so.<br>
<br>
</span>By that metric, I predict that the "success" of a std::ima=
ge with *no*<br>
colorspace information at all, let alone a conversion library, would be<br>
about 70%.<br>
<br>
That's from my own experience, which in fairness is most likely biased.=
<br>
However, it *is* from *direct, first-hand experience*. Can your claims<br>
that colorspace conversion is "absolutely vital" say the same?<br=
>
<span class=3D""><br>
> Even better, you can see how successful it is based on the nature of t=
he <br>
> alternatives people write for them. `vector` alternatives are primaril=
y for <br>
> corner-cases. They provide very specific optimizations in certain <br>
> workloads: small buffer storage, etc. Basically, these alternatives ex=
ist <br>
> because there cannot be a one-size-fits-all dynamic array.<br>
> <br>
> By contrast, alternative string types are written/used because of a la=
ck of <br>
</span>> *functionality* in the standard library version. That is, a lot=
of people <br>
<span class=3D"">> write string types, not because they are trying to im=
prove performance or <br>
> reduce memory consumption; they're merely trying to make their pro=
gram <br>
</span>> *work*.<br>
<br>
But... your argument here doesn't follow. The proposed std::image *does=
*<br>
carry colorspace information. Granted, not in a standardized format<br>
(even so, no one is saying we can't or shouldn't have *guidelines* =
as to<br>
what strings to use), but then, someone's one-off replacement will<br>
hardly be "standardized" either. Given that, why would someone *n=
ot* use<br>
std::image? In what way can a custom format improve? (Why would you not,<br=
>
at the very least, create a wrapper over std::image that uses some other<br=
>
mechanism to carry colorspace information, but still uses std::image as<br>
the underlying memory container?)<br>
<span class=3D""><br>
> That is a sign of a deficient tool. And deficient standard tools lead =
to <br>
> workarounds. If `std::image` cannot do what many people need to do wit=
h <br>
> images, then they won't use it. And thus, image types will continu=
e to <br>
> proliferate and interoperation will not be achieved.<br>
<br>
</span>Again, here's my problem. Please *SHOW EVIDENCE* of this asserti=
on. I've<br>
already named several libraries for which a std::image without even<br>
colorspace information *is* sufficient. If you're going to insist<br>
otherwise, despite evidence to the contrary, you need to back that up.<br>
<span class=3D""><br>
> On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:<b=
r>
</span><span class=3D"">>> First, please note that I'm not saying=
that colorspace conversion has no <br>
>> place in standard C++. If we get std::image, then clearly, colorsp=
ace <br>
>> conversion seems useful also. All I'm saying is that I don'=
;t think we <br>
>> should make colorspace conversion a precondition of a *basic* cont=
ainer <br>
>> for "pixels".<br>
> <br>
> Alright, let's talk scope, because nobody has actually sat down an=
d tried <br>
> to draw out the borders of this functionality. Oh yes, the initial pro=
posal <br>
> says "X formats, Y features, etc." But there's no specif=
ic "here's the use <br>
> cases for this feature" set down.<br>
<br>
</span>My specific use cases are the various, *existing* libraries that nee=
d<br>
pixel containers. I have *personally* written one such container, and<br>
been at least somewhat involved in the development of a second. I've<br=
>
written or been involved with code that uses five.<br>
<span class=3D""><br>
> So, what exactly is the image-specific stuff that this "basic con=
tainer for <br>
> pixels" will provide? What is this type going to give me that `ve=
ctor` with <br>
> a couple of helper function cannot?<br>
<br>
</span>The only *critical* feature that comes to mind would be ability to<b=
r>
assume a foreign memory block. Sure, you *could* build the rest into a<br>
helper class that stores e.g. stride information while using std::vector<br=
>
as underlying storage, but even if that's all you're doing, the fac=
t<br>
that libraries are *already* doing that sort of thing suggests that a<br>
std::image would still be helpful.<br>
<br>
Again, this is like asking "why do we need std::string when we have<br=
>
vector<char>?". Or, why do we need std::matrix when we have std:=
:vector?<br>
I would argue that a standard type to carry the information that<br>
describes the layout of the underlying bag of bytes is important.<br>
<br>
An even better example would be a flat_map. Granted, we don't have one<=
br>
of those (yet), but plenty of people think we should, even though it's<=
br>
nothing but some helper functions over a std::vector. I rather think the<br=
>
main reason we *don't* have such a critter is because it is "too n=
iche".<br>
<span class=3D""><br>
> If the thing can't handle fundamental image concepts like colorspa=
ces, <br>
</span>> image formats beyond the trivial, and the like, what exactly *d=
oes* it <br>
<span class=3D"">> handle? Blitting? Accessing a pixel through two dimen=
sional coordinates? Do <br>
> we really need a whole type just for that?<br>
<br>
</span>Asking whether we "need" a type like that is, IMO, disinge=
nuous.<br>
Existing practice is that people *will* create that type if it isn't<br=
>
provided for them.<br>
<br>
Besides, part of the point is to avoid making the mistakes of 2D<br>
Graphics, by building up capabilities from the ground up, rather than<br>
from the top down. Today, std::image. Tomorrow, colorspace conversion,<br>
or blitting, or image I/O, or...<br>
<br>
The point is to give these features a common type language, rather than<br>
having to invent their own types, as 2D Graphics did for linear algebra<br>
types. Also, so that libraries implementing these sorts of things have a<br=
>
standard type to use for their basic primitives, in order to facilitate<br>
interoperability.<br>
<br>
The standard library is successful because it doesn't try to be the<br>
be-all, end-all of programming in C++, but rather, to provide *low<br>
level* types that higher level algorithms can build upon, in order to<br>
facilitate interoperability. Going back to your earlier point, the<br>
higher up the stack you move, the less chance you have of producing<br>
something that is useful to a majority of people. (Another reason 2D<br>
Graphics failed...)<br>
<span class=3D""><br>
>> The point is to keep in mind that "perfect is the enemy of go=
od", and to <br>
>> avoid getting so bogged down in wanting something "perfect&qu=
ot; that we wind <br>
>> up with nothing at all.<br>
> <br>
> Is having "nothing at all" ultimately so different from havi=
ng "nothing <br>
> that I can actually use"? It's easy to declare "perfect =
is the enemy of <br>
> good" for features that you don't need.<br>
<br>
</span>Aaaaand... I *don't* need colorspace conversion. At least, not a=
lways,<br>
and more critically, I *can* use a std::image that doesn't have it.<br>
<br>
This goes back to your *false* assertion that a std::image without<br>
colorspace conversion is not useful. *Actual experience* says otherwise.<br=
>
Therefore, you can mutter all you want about "having 'nothing that=
I can<br>
actually use'", but that claim is wrong.<br>
<br>
*Existing usage* clearly demonstrates that a std::image, with or without<br=
>
colorspace conversion (or even any colorspace information!) would be<br>
useful to real world code.<br>
<span class=3D""><br>
> I do not feel comfortable telling other people that their use cases ar=
en't <br>
> important enough to warrant being in the standard library image class.=
<br>
<br>
</span>And I'm *not* saying that. If someone can present a usable propo=
sal for<br>
colorspace conversion... great! I will be *ecstatic*! (I'm not going to=
<br>
hold my breath waiting for it, though, especially when there is no<br>
standard image container on which it might operate.)<br>
<br>
Meanwhile, I note that you're perfectly comfortable telling me that<br>
these as-yet-hypothetical "other people" are sufficiently importa=
nt that<br>
*my* use cases should be deprived of a standard library type.<br>
<span class=3D""><br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-ba84-22cd51=
a8a125%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.goo=
gle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/91292cdd-f72b-d867-<wb=
r>ba84-22cd51a8a125%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGoi_oBFc3UQoQt13jEY39oH_pNCyq=
iFd9bTkq-ieMjA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGoi_oBFc3=
UQoQt13jEY39oH_pNCyqiFd9bTkq-ieMjA%40mail.gmail.com</a>.<br />
--000000000000618ab50571f16995--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 26 Jul 2018 22:14:11 -0400
Raw View
--000000000000ea8e9f0571f1aa93
Content-Type: text/plain; charset="UTF-8"
Definitely.
If someone does make a proposal, you have two choices:
- look at gil and explain, in the proposal, why it is not the right thing
- look at gil and use it or ideas from it (particularly since boost has
such a good track record for landing in std)
Note that _not_ looking at gil really isn't an option. Someone in LEWG
*will* ask if it was considered, and if you can't give a detailed answer,
your odds of success are greatly diminished.
Same goes for considering other applicable libraries, not just boost. But
boost is an obvious one.
On Wed, Jul 25, 2018 at 4:35 AM, Dejan Milosavljevic <dmilos@gmail.com>
wrote:
>
> Take look at boost::gil.
> Then already poses containers with so many capabilities.
> std::image must must be at least like that.
> I see that as minimum.
>
>
>
> On Tue, Jul 24, 2018 at 5:33 PM, Matthew Woehlke <mwoehlke.floss@gmail.com
> > wrote:
>
>> On 2018-07-23 20:18, Nicol Bolas wrote:
>> > A standard library tool's successfulness can be measured based on what
>> > percentage of the userbase is able to use that tool to solve problems
>> in
>> > that tool's domain, relative to having to get another one/write their
>> own.
>> > `vector` is a very successful tool by that metric; `basic_string` is
>> > decidedly less so.
>>
>> By that metric, I predict that the "success" of a std::image with *no*
>> colorspace information at all, let alone a conversion library, would be
>> about 70%.
>>
>> That's from my own experience, which in fairness is most likely biased.
>> However, it *is* from *direct, first-hand experience*. Can your claims
>> that colorspace conversion is "absolutely vital" say the same?
>>
>> > Even better, you can see how successful it is based on the nature of
>> the
>> > alternatives people write for them. `vector` alternatives are primarily
>> for
>> > corner-cases. They provide very specific optimizations in certain
>> > workloads: small buffer storage, etc. Basically, these alternatives
>> exist
>> > because there cannot be a one-size-fits-all dynamic array.
>> >
>> > By contrast, alternative string types are written/used because of a
>> lack of
>> > *functionality* in the standard library version. That is, a lot of
>> people
>> > write string types, not because they are trying to improve performance
>> or
>> > reduce memory consumption; they're merely trying to make their program
>> > *work*.
>>
>> But... your argument here doesn't follow. The proposed std::image *does*
>> carry colorspace information. Granted, not in a standardized format
>> (even so, no one is saying we can't or shouldn't have *guidelines* as to
>> what strings to use), but then, someone's one-off replacement will
>> hardly be "standardized" either. Given that, why would someone *not* use
>> std::image? In what way can a custom format improve? (Why would you not,
>> at the very least, create a wrapper over std::image that uses some other
>> mechanism to carry colorspace information, but still uses std::image as
>> the underlying memory container?)
>>
>> > That is a sign of a deficient tool. And deficient standard tools lead
>> to
>> > workarounds. If `std::image` cannot do what many people need to do with
>> > images, then they won't use it. And thus, image types will continue to
>> > proliferate and interoperation will not be achieved.
>>
>> Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I've
>> already named several libraries for which a std::image without even
>> colorspace information *is* sufficient. If you're going to insist
>> otherwise, despite evidence to the contrary, you need to back that up.
>>
>> > On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:
>> >> First, please note that I'm not saying that colorspace conversion has
>> no
>> >> place in standard C++. If we get std::image, then clearly, colorspace
>> >> conversion seems useful also. All I'm saying is that I don't think we
>> >> should make colorspace conversion a precondition of a *basic*
>> container
>> >> for "pixels".
>> >
>> > Alright, let's talk scope, because nobody has actually sat down and
>> tried
>> > to draw out the borders of this functionality. Oh yes, the initial
>> proposal
>> > says "X formats, Y features, etc." But there's no specific "here's the
>> use
>> > cases for this feature" set down.
>>
>> My specific use cases are the various, *existing* libraries that need
>> pixel containers. I have *personally* written one such container, and
>> been at least somewhat involved in the development of a second. I've
>> written or been involved with code that uses five.
>>
>> > So, what exactly is the image-specific stuff that this "basic container
>> for
>> > pixels" will provide? What is this type going to give me that `vector`
>> with
>> > a couple of helper function cannot?
>>
>> The only *critical* feature that comes to mind would be ability to
>> assume a foreign memory block. Sure, you *could* build the rest into a
>> helper class that stores e.g. stride information while using std::vector
>> as underlying storage, but even if that's all you're doing, the fact
>> that libraries are *already* doing that sort of thing suggests that a
>> std::image would still be helpful.
>>
>> Again, this is like asking "why do we need std::string when we have
>> vector<char>?". Or, why do we need std::matrix when we have std::vector?
>> I would argue that a standard type to carry the information that
>> describes the layout of the underlying bag of bytes is important.
>>
>> An even better example would be a flat_map. Granted, we don't have one
>> of those (yet), but plenty of people think we should, even though it's
>> nothing but some helper functions over a std::vector. I rather think the
>> main reason we *don't* have such a critter is because it is "too niche".
>>
>> > If the thing can't handle fundamental image concepts like colorspaces,
>> > image formats beyond the trivial, and the like, what exactly *does* it
>> > handle? Blitting? Accessing a pixel through two dimensional
>> coordinates? Do
>> > we really need a whole type just for that?
>>
>> Asking whether we "need" a type like that is, IMO, disingenuous.
>> Existing practice is that people *will* create that type if it isn't
>> provided for them.
>>
>> Besides, part of the point is to avoid making the mistakes of 2D
>> Graphics, by building up capabilities from the ground up, rather than
>> from the top down. Today, std::image. Tomorrow, colorspace conversion,
>> or blitting, or image I/O, or...
>>
>> The point is to give these features a common type language, rather than
>> having to invent their own types, as 2D Graphics did for linear algebra
>> types. Also, so that libraries implementing these sorts of things have a
>> standard type to use for their basic primitives, in order to facilitate
>> interoperability.
>>
>> The standard library is successful because it doesn't try to be the
>> be-all, end-all of programming in C++, but rather, to provide *low
>> level* types that higher level algorithms can build upon, in order to
>> facilitate interoperability. Going back to your earlier point, the
>> higher up the stack you move, the less chance you have of producing
>> something that is useful to a majority of people. (Another reason 2D
>> Graphics failed...)
>>
>> >> The point is to keep in mind that "perfect is the enemy of good", and
>> to
>> >> avoid getting so bogged down in wanting something "perfect" that we
>> wind
>> >> up with nothing at all.
>> >
>> > Is having "nothing at all" ultimately so different from having "nothing
>> > that I can actually use"? It's easy to declare "perfect is the enemy of
>> > good" for features that you don't need.
>>
>> Aaaaand... I *don't* need colorspace conversion. At least, not always,
>> and more critically, I *can* use a std::image that doesn't have it.
>>
>> This goes back to your *false* assertion that a std::image without
>> colorspace conversion is not useful. *Actual experience* says otherwise.
>> Therefore, you can mutter all you want about "having 'nothing that I can
>> actually use'", but that claim is wrong.
>>
>> *Existing usage* clearly demonstrates that a std::image, with or without
>> colorspace conversion (or even any colorspace information!) would be
>> useful to real world code.
>>
>> > I do not feel comfortable telling other people that their use cases
>> aren't
>> > important enough to warrant being in the standard library image class.
>>
>> And I'm *not* saying that. If someone can present a usable proposal for
>> colorspace conversion... great! I will be *ecstatic*! (I'm not going to
>> hold my breath waiting for it, though, especially when there is no
>> standard image container on which it might operate.)
>>
>> Meanwhile, I note that you're perfectly comfortable telling me that
>> these as-yet-hypothetical "other people" are sufficiently important that
>> *my* use cases should be deprived of a standard library type.
>>
>> --
>> Matthew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/is
>> ocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-ba84-
>> 22cd51a8a125%40gmail.com.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ8%2BssP0k%2B-TSiZZycxRZ3%
> 2B4X4HG3i1zopH2SPu8uw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ8%2BssP0k%2B-TSiZZycxRZ3%2B4X4HG3i1zopH2SPu8uw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbithQSdYKtPdVsZdd%2BEeH1qBvHh_w0LX-x2bu8GceAVeKQ%40mail.gmail.com.
--000000000000ea8e9f0571f1aa93
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Definitely.</div><div><br></div><div>If someone does =
make a proposal, you have two choices:</div><div><br></div><div>- look at g=
il and explain, in the proposal, why it is not the right thing</div><div>- =
look at gil and use it or ideas from it (particularly since boost has such =
a good track record for landing in std)</div><div><br></div><div>Note that =
_not_ looking at gil really isn't an option.=C2=A0 Someone in LEWG *wil=
l* ask if it was considered, and if you can't give a detailed answer, y=
our odds of success are greatly diminished.</div><div><br></div><div>Same g=
oes for considering other applicable libraries, not just boost.=C2=A0 But b=
oost is an obvious one.</div><div><br></div><div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Wed, Jul 25, 2018 at 4:35 AM, Dejan Milo=
savljevic <span dir=3D"ltr"><<a href=3D"mailto:dmilos@gmail.com" target=
=3D"_blank">dmilos@gmail.com</a>></span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><br>Take look at boost::gil.<br>Then alread=
y poses containers with so many capabilities.<br>std::image must must be at=
least like that.</div><div>I see that as minimum.</div><div><br></div><div=
><br></div></div><div><div class=3D"h5"><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Tue, Jul 24, 2018 at 5:33 PM, Matthew Woehlke <sp=
an dir=3D"ltr"><<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_b=
lank">mwoehlke.floss@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2018-07-23 20:18, Nicol Bolas wrote:<br>
> A standard library tool's successfulness can be measured based on =
what <br>
> percentage of the userbase is able to use that tool to solve problems =
in <br>
> that tool's domain, relative to having to get another one/write th=
eir own. <br>
> `vector` is a very successful tool by that metric; `basic_string` is <=
br>
> decidedly less so.<br>
<br>
By that metric, I predict that the "success" of a std::image with=
*no*<br>
colorspace information at all, let alone a conversion library, would be<br>
about 70%.<br>
<br>
That's from my own experience, which in fairness is most likely biased.=
<br>
However, it *is* from *direct, first-hand experience*. Can your claims<br>
that colorspace conversion is "absolutely vital" say the same?<br=
>
<br>
> Even better, you can see how successful it is based on the nature of t=
he <br>
> alternatives people write for them. `vector` alternatives are primaril=
y for <br>
> corner-cases. They provide very specific optimizations in certain <br>
> workloads: small buffer storage, etc. Basically, these alternatives ex=
ist <br>
> because there cannot be a one-size-fits-all dynamic array.<br>
> <br>
> By contrast, alternative string types are written/used because of a la=
ck of <br>
> *functionality* in the standard library version. That is, a lot of peo=
ple <br>
> write string types, not because they are trying to improve performance=
or <br>
> reduce memory consumption; they're merely trying to make their pro=
gram <br>
> *work*.<br>
<br>
But... your argument here doesn't follow. The proposed std::image *does=
*<br>
carry colorspace information. Granted, not in a standardized format<br>
(even so, no one is saying we can't or shouldn't have *guidelines* =
as to<br>
what strings to use), but then, someone's one-off replacement will<br>
hardly be "standardized" either. Given that, why would someone *n=
ot* use<br>
std::image? In what way can a custom format improve? (Why would you not,<br=
>
at the very least, create a wrapper over std::image that uses some other<br=
>
mechanism to carry colorspace information, but still uses std::image as<br>
the underlying memory container?)<br>
<br>
> That is a sign of a deficient tool. And deficient standard tools lead =
to <br>
> workarounds. If `std::image` cannot do what many people need to do wit=
h <br>
> images, then they won't use it. And thus, image types will continu=
e to <br>
> proliferate and interoperation will not be achieved.<br>
<br>
Again, here's my problem. Please *SHOW EVIDENCE* of this assertion. I&#=
39;ve<br>
already named several libraries for which a std::image without even<br>
colorspace information *is* sufficient. If you're going to insist<br>
otherwise, despite evidence to the contrary, you need to back that up.<br>
<br>
> On Monday, July 23, 2018 at 2:22:33 PM UTC-4, Matthew Woehlke wrote:<b=
r>
>> First, please note that I'm not saying that colorspace convers=
ion has no <br>
>> place in standard C++. If we get std::image, then clearly, colorsp=
ace <br>
>> conversion seems useful also. All I'm saying is that I don'=
;t think we <br>
>> should make colorspace conversion a precondition of a *basic* cont=
ainer <br>
>> for "pixels".<br>
> <br>
> Alright, let's talk scope, because nobody has actually sat down an=
d tried <br>
> to draw out the borders of this functionality. Oh yes, the initial pro=
posal <br>
> says "X formats, Y features, etc." But there's no specif=
ic "here's the use <br>
> cases for this feature" set down.<br>
<br>
My specific use cases are the various, *existing* libraries that need<br>
pixel containers. I have *personally* written one such container, and<br>
been at least somewhat involved in the development of a second. I've<br=
>
written or been involved with code that uses five.<br>
<br>
> So, what exactly is the image-specific stuff that this "basic con=
tainer for <br>
> pixels" will provide? What is this type going to give me that `ve=
ctor` with <br>
> a couple of helper function cannot?<br>
<br>
The only *critical* feature that comes to mind would be ability to<br>
assume a foreign memory block. Sure, you *could* build the rest into a<br>
helper class that stores e.g. stride information while using std::vector<br=
>
as underlying storage, but even if that's all you're doing, the fac=
t<br>
that libraries are *already* doing that sort of thing suggests that a<br>
std::image would still be helpful.<br>
<br>
Again, this is like asking "why do we need std::string when we have<br=
>
vector<char>?". Or, why do we need std::matrix when we have std:=
:vector?<br>
I would argue that a standard type to carry the information that<br>
describes the layout of the underlying bag of bytes is important.<br>
<br>
An even better example would be a flat_map. Granted, we don't have one<=
br>
of those (yet), but plenty of people think we should, even though it's<=
br>
nothing but some helper functions over a std::vector. I rather think the<br=
>
main reason we *don't* have such a critter is because it is "too n=
iche".<br>
<br>
> If the thing can't handle fundamental image concepts like colorspa=
ces, <br>
> image formats beyond the trivial, and the like, what exactly *does* it=
<br>
> handle? Blitting? Accessing a pixel through two dimensional coordinate=
s? Do <br>
> we really need a whole type just for that?<br>
<br>
Asking whether we "need" a type like that is, IMO, disingenuous.<=
br>
Existing practice is that people *will* create that type if it isn't<br=
>
provided for them.<br>
<br>
Besides, part of the point is to avoid making the mistakes of 2D<br>
Graphics, by building up capabilities from the ground up, rather than<br>
from the top down. Today, std::image. Tomorrow, colorspace conversion,<br>
or blitting, or image I/O, or...<br>
<br>
The point is to give these features a common type language, rather than<br>
having to invent their own types, as 2D Graphics did for linear algebra<br>
types. Also, so that libraries implementing these sorts of things have a<br=
>
standard type to use for their basic primitives, in order to facilitate<br>
interoperability.<br>
<br>
The standard library is successful because it doesn't try to be the<br>
be-all, end-all of programming in C++, but rather, to provide *low<br>
level* types that higher level algorithms can build upon, in order to<br>
facilitate interoperability. Going back to your earlier point, the<br>
higher up the stack you move, the less chance you have of producing<br>
something that is useful to a majority of people. (Another reason 2D<br>
Graphics failed...)<br>
<br>
>> The point is to keep in mind that "perfect is the enemy of go=
od", and to <br>
>> avoid getting so bogged down in wanting something "perfect&qu=
ot; that we wind <br>
>> up with nothing at all.<br>
> <br>
> Is having "nothing at all" ultimately so different from havi=
ng "nothing <br>
> that I can actually use"? It's easy to declare "perfect =
is the enemy of <br>
> good" for features that you don't need.<br>
<br>
Aaaaand... I *don't* need colorspace conversion. At least, not always,<=
br>
and more critically, I *can* use a std::image that doesn't have it.<br>
<br>
This goes back to your *false* assertion that a std::image without<br>
colorspace conversion is not useful. *Actual experience* says otherwise.<br=
>
Therefore, you can mutter all you want about "having 'nothing that=
I can<br>
actually use'", but that claim is wrong.<br>
<br>
*Existing usage* clearly demonstrates that a std::image, with or without<br=
>
colorspace conversion (or even any colorspace information!) would be<br>
useful to real world code.<br>
<br>
> I do not feel comfortable telling other people that their use cases ar=
en't <br>
> important enough to warrant being in the standard library image class.=
<br>
<br>
And I'm *not* saying that. If someone can present a usable proposal for=
<br>
colorspace conversion... great! I will be *ecstatic*! (I'm not going to=
<br>
hold my breath waiting for it, though, especially when there is no<br>
standard image container on which it might operate.)<br>
<br>
Meanwhile, I note that you're perfectly comfortable telling me that<br>
these as-yet-hypothetical "other people" are sufficiently importa=
nt that<br>
*my* use cases should be deprived of a standard library type.<br>
<span class=3D"m_6479164254317827509HOEnZb"><font color=3D"#888888"><br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/91292cdd-f72b-d867-ba84-22cd51a8a125%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/91292cdd-f72b-d867-ba84-<wbr>=
22cd51a8a125%40gmail.com</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwXwJ8%2BssP0k%2B-TSiZZycxRZ3%2=
B4X4HG3i1zopH2SPu8uw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAEfefmwXwJ8%<wbr>2BssP0k%2B-TSiZZycxRZ3%<wbr>2B4X4HG3=
i1zopH2SPu8uw%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbithQSdYKtPdVsZdd%2BEeH1qBvHh_w0=
LX-x2bu8GceAVeKQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbithQSdYKt=
PdVsZdd%2BEeH1qBvHh_w0LX-x2bu8GceAVeKQ%40mail.gmail.com</a>.<br />
--000000000000ea8e9f0571f1aa93--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 27 Jul 2018 10:21:00 -0400
Raw View
On 2018-07-26 21:55, Tony V E wrote:
> That is the main part I'd like to tackle - if you can't at least agree on a
> canonical/interchange form of a pixel (ie CIE XYZ or something), then you
> aren't really standardizing anything. You just have an array of bytes.
....which experience says is still useful.
Oh, sure, I agree it would be good to have some guidance behind what
goes in the format string, so that there is at least a chance that user
A will be able to understand a string produces by library B.
I'm *not* convinced we need a full-fledged library for color
conversions. Or I/O.
> You have just a de facto standard, with QImage internals checking for
> hardcoded strings like "RGBA", and libpng checking for "ARGB" instead.
....except that AFAIK libpng doesn't have a C++ interface :-).
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/31858346-e2be-88fa-fb06-0d74e9ba520e%40gmail.com.
.