Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIXEL Unit is fixed at 72 #18

Open
bugabinga opened this issue Nov 13, 2015 · 14 comments
Open

PIXEL Unit is fixed at 72 #18

bugabinga opened this issue Nov 13, 2015 · 14 comments

Comments

@bugabinga
Copy link
Contributor

A Pixel however is a relative unit as defined by PPI (Pixel per Inch). How would we define the Unit "PPI" in such a way, that a conversion path leads back to METRE?

@keilw
Copy link
Member

keilw commented Nov 13, 2015

That's an interesting question, but if 72 PPI means Pixel per Inch, then somehow it should be able to get to the inch (similar to telling how many hours it takes travelling at X km/h or mph for a given distance) and from Inch to Metre it'll be a second step.

@bugabinga
Copy link
Contributor Author

How would we get the hours from X km/h?

After reading the NonSI-class, here is how I could imagine an
implementation of PPI to look like:

static final Unit PIXEL = addUnit(BYTE.multiply(4.0));
static final Unit PIXEL_PER_INCH =
addUnit(PIXEL.divide(INCH).asType(Resolution.class));

With "Resolution" being a new Quantity information/length.

Unfortunately, I cannot tell how to proceed. How to extend the
Formatter? Is it necessary to supply converter logic somewhere?

See my failed attempt here : https://github.com/flasheater/uom-systems/
blob/master/common-

java8/src/test/java/systems/uom/common/PixelTest.java

Oliver Jan Krylow okrylow@gmail.com

@keilw
Copy link
Member

keilw commented Nov 15, 2015

The demo I developed for DevoXX to try what's in the slides https://github.com/unitsofmeasurement/uom-demos/blob/master/console/systems/common/src/main/java/tec/uom/demo/systems/common/AirplaneDemo.java shows how to get from a plane's speed and distance to travel time.

At the moment, ISO80000 has
public static final Unit PIXEL...
Why would you pick here?
Other than that the operations below it look sound and doable.

@bugabinga
Copy link
Contributor Author

@keilw Thank you for the hint. I have tested a successful conversion from Pixel to Metre now here .

Are you suggesting PIXEL and PIXEL_PER_INCH should be defined in ISO80000?

Btw, good talk at Devoxx! It gave me an overview of UOM, thanks.
How do I implement i10n formating for PIXEL and PIXEL_PER_INCH?

@keilw
Copy link
Member

keilw commented Nov 16, 2015

As long as they are in scope of ISO 80000 I would imagine.
https://en.wikipedia.org/wiki/IEC_80000-13 does not contain anything other than bit, byte, etc.
And https://en.wikipedia.org/wiki/Display_resolution does not suggest, units like PIXEL or PPI were in ISO either, so we'd have to think of something else.

Thanks for attending the talk, glad you liked it (and weren't lured by the "CSI Cyber" like session as many others ;-) Would you like to create a PR for above conversion example?

As for the right unit system, let's track and discuss it here. I could think of either "common" with a few additional other systems something to replace the only internal "NonSI" which has a far too broad name (all other systems are "Non SI" if you want;-)

@keilw
Copy link
Member

keilw commented Nov 16, 2015

It goes along this already existing ticket for units like FRAMES_PER_SECOND. Whatever system is defined for that, PIXEL or PPI seem quite a good match there, too: #16

@bugabinga
Copy link
Contributor Author

I agree. Those seem to fit together. Even though "common" is still too broad a term. PPI and FPS are quite specific to the domain "digital imagery". Have you decided how to "grow" systems over time? I am eluding to the following problem. Imagine we had this "common" system ( or Miscellaneous or NoSystem ...), then two years from now we realise a subset of units should be moved to its own or a different system. Do those moved units now get deprecated in common etc...?

@keilw
Copy link
Member

keilw commented Nov 17, 2015

I merged the PR and everything still builds fine. I am not entirely sure, if this PIXEL and what was previously defined as are really the same thing. http://www.translatorscafe.com/cafe/EN/units-converter/length/105-110/nautical_mile_(US_Customary)-pixel/ shows a direct conversion of e.g. INCH -> PIXEL with 1 inch = 96.00120946406 pixel. There the quantity is clearly length, not information.
UCUM does not know a "pixel" btw, but all the other typesetting units as in http://unitsofmeasure.org/ucum.html#para-42 are all length, too.

@keilw
Copy link
Member

keilw commented Nov 17, 2015

This is very interesting: http://stackoverflow.com/questions/2025282/difference-between-px-dp-dip-and-sp-in-android
Based on Android Development Center. The old "PIXEL" length unit is called "pt" here, defined as 1/72 Inch. The "PIXEL" closer to what you suggested says it varies. Whether that is really Information or another quantity, we may also think about. This PIXEL (=width*dpi) looks like it's different from width/lenght indeed, but there's a nother "PIXEL" as seen above which is simply 1/72 inch. Both should be defined, likely in different unit systems.

@keilw
Copy link
Member

keilw commented Nov 17, 2015

Do those moved units now get deprecated in common etc...?

Especially for those we moved and quickly deleted from the RI at that point (after a final 1.0 standard it would no longer be possible;-) we did exactly that.
We would put a @deprecated JavaDoc tag with a comment explaining where to find it in future. Java 9 is said to have further extensions to the deprecation mechanism, there something called "Superseded" will be added, either in JavaDoc or maybe via annotations. So for the SE (8+) strain of the implementation and unit systems we might use that, for RI and Java ME Embedded it may simply be JavaDoc until e.g. ME 8.x or 9 also supports some of that.

@bugabinga
Copy link
Contributor Author

Yes, every Platform has its own ideas about what a Pixel is.
CSS
Windows
Apple
... surely there are more.

While I admit, that my implementation of PIXEL could also be named COLOR (and start a whole new discussion on color systems), it is also true, that every Pixel in the length dimension can be expressed as

final Unit<Length> CSS_PIXEL = NonSI.PIXEL_PER_INCH.inverse().multiply( NonSI.PIXEL ).divide( 96 ).asType( Length.class );

or something similar.

@keilw
Copy link
Member

keilw commented Dec 22, 2015

Google also has some interesting thoughts on that in their Material Design: http://www.google.com/design/spec/layout/units-measurements.html

@keilw keilw added ready and removed in progress labels Jul 29, 2016
@keilw keilw added the deferred label Mar 5, 2017
@keilw
Copy link
Member

keilw commented Mar 5, 2017

This should probably move somewhere else. PIXEL is currently still unofficial part of the internal NonSI system, but that one should go away soon. Either subject to a "domain" module or ISO80k.

@keilw keilw removed the ready label Mar 5, 2017
@keilw
Copy link
Member

keilw commented Dec 13, 2019

Since Unicode CLDR 36 (#157) introduced a PIXEL, we might have to revisit that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants