length, SI, font size, EM, pixels

[takev]

I am trying to use mp-units in a GUI library, I need a few more units that I am trying to design, but I am bit stuck.

I added a new type pixel which is a length. Then I added a ppi (pixels per inch) type as: pixel / international::inch. This was easy, works perfectly, if my CSS file has a size in SI or international units, I can multiply it with ppi to get the size in pixels.

Now the next one is the one I get confused by: The CSS file may also list a length in em-quad this a length in multiples of the font-size (also read from the CSS file).

The font-size is normally described in SI/international units, like 12pt. So if I want to convert a quantity in em-quad to international units I need to multiply em-quad with the font-size, but that can only work if em-quad is a unitless quantity, but it is still a length at the same time.

We could also describe font-size as: international::point / em-quad. This would be weird, because font-sizes are normally described only in points.

Is there something in mp-units to solve this?

[mpusz]

Hi @takev, thanks for trying the library! 😃

Generally, it is easier for us to discuss such use cases if you could share a Compiler Explorer link with us. With that we can better understand your use case and propose some solutions as well.

Said that, I am not sure if pixels should be an isq::length? Maybe it should be some special quantity type? It could be either:

• a dimensionless quantity/count set as a kind,
• new separate quantity type like screen_coordinate,
• a special quantity type of kind isq::length.

Thanks to that, if you divide pixels/inch, you will end up with just a dimensionless quantity but something stronger (you could also name it somehow, e.g., pixel_density).

em-quad could be a unit of another quantity type as well (e.g. dimensionless) or a unit of length where instead of multiplying by the SI unit you could convert to it. Such conversion can be defined:

• at compile time and performed automatically by the library
• at runtime and performed by the user-provided function

We also have an old and simple prototype of the typographic system that could be extended with your use cases.

@JohelEGP has more experience in GUIs library, so maybe he can provide more guidance here as well.

[takev]

https://godbolt.org/z/PzaTWodxf

The typographic system you linked to only adds a few lengths that are based on physical sizes. The units I need to add are in another coordinate system, but are still lengths.

[mpusz]

I must admit I am not an expert in typography. I just read a few articles today to get a general understanding of the subject. From what I've read at https://fonts.google.com/knowledge/glossary/em it seems that the em is a relative unit and it specified per specific font-size (e.g., ideally we should not be able to mix ems of two different font sizes).

It is really hard to correctly define it that way. The only way to prevent accidental mixing of different font-sizes would be to define such a unit as a template, but this would require to know the font-size at compile-time: https://godbolt.org/z/EhEj78z9s.

Other options are less safe or correct. As you pointed out, we can define em as a dimensionless unit and use it as a scaling factor of a font size. Alternatively, we can provide a runtime conversion function that will convert em to the font-size (https://godbolt.org/z/n7qs3hd4a).

The above examples, are not final for sure. For example, the hierarchy of quantities still needs some polishing there. However, it should provide you some ideas to model this in a way that works best for you.

[ltbmb]

I am at a similiar point in a project needing to model sensor and image dimensions in pixels as well as in mm/µm and calculate between them.

First I tried to model pixel as an isq::length but the problem I am facing is, that it is very common to say an image contains 100 pixels * 100 pixels = 10000 pixels. But now I am getting 10000 pixels². This problem let's me think it would be better to model pixels as dimensionless, but how do I make sure that the result is still pixel?.

Another thing I have to do is model the physical pixel height and width in µm which may be isq::width and isq::length and multiplying this by the pixel count in either direction should give the sensor size. Which would be trivial if pixel are dimensionless, but akward if pixel are an isq::length.

Maybe pixelsize could be modeled as µm/px which would work in theory. But this effectively makes pixelSize dimensionless (isq::length / isq::length).

Maybe someone could elaborate on this use case and give a few ideas?

[mpusz]

Hi @ltbmb! 😃

It is a really interesting problem. At first pixel² may look strange, but it actually makes a lot of sense. However, I understand it might not be a desired outcome for you.

If you want to multiply things and don't change their type, then the only way to do it is to work with identities. We have those of those (one per each abstraction):

• dimension_one for dimensions,
• dimensionless for quantity type,
• one for unit.
  Only those multiplied by themselves will not change the type.

Regarding mapping to µm. Is the ratio known at compile time or only at runtime? Typically it is a runtime property so you can't provide compile-time known conversions between those. Still, it could be modelled similarly to our currency.cpp example.

Another problem is that a pixel for width may have a different scaling factor than for height. This makes it even harder to model. Is it the case for you?

[ltbmb]

Hi @mpusz .

First let me thank you for your efforts and this great library. I watched most of your talks and I really like the modern design!

To answer your questions:

Indeed we configure the camera at run time and can not know the pixel size at compile time. And yes we have to support different pixel dimensions in horizontal and vertical direction (especially with binning involved).

We are just getting started with evaluating the capabilities of the library and right now I'm a little bit confused how all the pieces fit together.

I gave it another shot and tried to model pixel as dimensionless unit like so:

QUANTITY_SPEC(resolution, dimensionless, is_kind); //not sure about the name 'resolution' here 
inline constexpr struct pixel final : named_unit<"px", one, kind_of<resolution>>{} pixel;

inline constexpr auto px = pixel; // Id like to use 'px' as a unit symbol. This works, but is this intended to do it this way?

But with this approach the following does not work:

  auto width  = 100 * px;
  auto height = 100 * px;

  auto total = width * height;

  // how do I get this to work? internally it is px² so this is a compiler error. 
  // auto num = total.numerical_value_in(px);

However with unit one it does work:

  auto width  = 100 * one;
  auto height = 100 * one;

  auto total = width * height;

  auto num = total.numerical_value_in(one);

I think this relates to what you wrote above about the "identities". Can you give me a hint how to model my pixel unit like this?

There is another complication though. In a configuration struct I tried to do something like this:

using RelativeWidth = quantity<percent>;
using AbsoluteWidth = quantity<pixel>;
using ROIWidth         = std::variant<RelativeWidth, AbsoluteWidth>;

and have a struct with a member like this:

struct ROI {
 //...
 units::ROIWidth width                   = 50 * units::percent; //default to 50%
};

The struct is written in a json configuration file and we use the unit symbols to write the variant out as string like "50%" or "10 px", which works great so far. However for this to work I needed to model my pixel unit with the kind_of<resolution> "trait". If I just use one, pixels and percent would be ambiguous and the default inside the struct did not work.

I hope this makes sense. Thank you again for your time and work to make c++ a safer language!

[mpusz]

I am having a tough time answering this question here. The main issue is related to the fact that people often simplify things and overload terms. Doing the same in computer programming is usually tricky.

Assuming we will provide some way to make pixel work for both lengths and resolutions. This would mean that the below would compile:

void foo(quantity<pixel> resolution) { /* ... */ }

quantity width = 800 * px;
quantity height = 600 * px;
quantity resolution = width * height;
foo(height);

To prevent such cases, I really think that pixel² is the right way to go here. Although, this is not how we communicate in daily life.

The pixel definition from your example:

inline constexpr struct pixel final : named_unit<"px", one, kind_of<resolution>>{} pixel;

means that the resolution will also be possible to be measured in the unit of one. If that is OK with you, then you can leave like that. If not, I recommend creating a dedicated dimension for pixels. This would introduce a lot of type safety:

inline constexpr struct dim_pixel_length final : base_dimension<"Px"> {} dim_pixel_length;

inline constexpr struct pixel_length final : quantity_spec<dim_pixel_length> {} pixel_length;
inline constexpr struct pixel_width final : quantity_spec<pixel_length> {} pixel_width;
inline constexpr struct pixel_height final : quantity_spec<pixel_length> {} pixel_height;

inline constexpr struct resolution final : quantity_spec<pixel_width * pixel_height> {} resolution;

inline constexpr struct pixel final : named_unit<"px", kind_of<pixel_length>> {} pixel;
inline constexpr auto px = pixel;

void foo1(quantity<square(pixel)> res) {}
void foo2(quantity<resolution[square(pixel)]> res) {}

quantity width = pixel_width(800 * px);
quantity height = pixel_height(600 * px);
quantity<resolution[square(pixel)]> res = width * height;
// quantity<resolution[square(pixel)]> res2 = width * width;  // Complie-time error
foo1(res);
foo2(res);
// foo1(width);  // Complie-time error
// foo2(width);  // Complie-time error
```cpp

Also conversions to metric length can be defined as follows:

```cpp
inline constexpr struct width_to_pixel_ratio final : quantity_spec<isq::width / pixel_width> {} width_to_pixel_ratio;
inline constexpr struct height_to_pixel_ratio final : quantity_spec<isq::height / pixel_height> {} height_to_pixel_ratio;

quantity<isq::width[si::micro<si::metre>]> to_width(quantity<pixel_width[px]> pixels,
                                                    quantity<width_to_pixel_ratio[si::micro<si::metre> / pixel]> ratio)
{
  return pixels * ratio;
}

quantity<isq::height[si::micro<si::metre>]> to_height(quantity<pixel_height[px]> pixels,
                                                      quantity<height_to_pixel_ratio[si::micro<si::metre> / pixel]> ratio)
{
  return pixels * ratio;
}

quantity<width_to_pixel_ratio[um / px]> width_to_pixel = 46 * um / px;
quantity<height_to_pixel_ratio[um / px]> height_to_pixel = 43 * um / px;

std::cout << to_width(width, width_to_pixel) << '\n';
// std::cout << to_width(width, height_to_pixel) << '\n';  // Complie-time error
// std::cout << to_width(height, width_to_pixel) << '\n';  // Complie-time error
// std::cout << to_width(res, width_to_pixel) << '\n';     // Complie-time error
std::cout << to_height(height, height_to_pixel) << '\n';

See more in: https://godbolt.org/z/roKeWPvzY

I hope it helps.