Can we improve screenshot DPI

"AnthonyL" wrote

| What determines the resolution of any given screenshot on your own
screen?
|
| My ageing laptop screen is 1280 x 800. If I take a screenshot of the
| full screen it will give me a jpg of 1280 x 800 pixels. If I take a
| screenshot from my other computer I get more because it has a finer
| resolution screen, eg 1600x1200.
|

There's a confusion of terminology here. Resolution is
the level of detail. The bigger screen is nice because
you can fit more things onto it. But the degree of detail
of those things is the same.

An icon 32x32 or 128x128.... a program window
600x600px.... a Desktop background photo of your dog
Spot that's 800x600.... None of those things will change.
Those measurements are all in pixels. They'll just look
smaller on the bigger screen. (Unless you set the
background photo to stretch. Then that will get bigger.
But the resolution will not change because it's still an
800x600 image.)

| What gets written into the DPI field of the EXIF info depends on what
| software was used to take the screenshot and bears no/little
| relationship to that actual pixel size.

Bears *no* relationship to pixels, which don't have
a size. It helps here to understand what the picture
actually is, as I detailed somewhat above. The image
is essentially a bitmap. A grid of pixel values stored as
byte data. 3 bytes to a pixel in most cases.

00 00 00 represents a black pixel.
FF FF FF represents a white pixel.
FF 00 00 represents red or blue, depending on how you
read it.

If the first 9 bytes in the bitmap are
FF 00 FF FF 00 FF FF 00 FF
then the first 3 pixels in the image are all purple. That's
it. That's the digital image data. Very simple at that level.
But that's all there is.
The resolution, or level of detail, is already set. How it
gets seen will depend on the monitor, screen size, OS,
your eyesight, room lighting, and even your mood. (As
Jim Morrison said, faces look ugly when you're alone.)
If you're color-blind you may not see purple as others do.

That may seem like irrelevant nitpicking, but when it comes
to graphics those are very real factors. The pixel data in
the image file only represents intensities of red, green
and blue light. Even the structure of our eyes restricts
how we see those colors. (The reason it's so hard to get
a pure yellow is because we don't have cones for yellow.
We see yellow when red and green blend, so most yellows
tend to skew toward orange or lemon. And as interior
decorators know, an off-white is defined in part by what
it's next to.)

Your background photo of Spot will probably have lots
of white and black pixels. Maybe lots of green ones, too,
if he was photographed on a lawn. Those don't have a
size. The only size for the image is the width and height,
pixel count. The image size will depend on the rendering
medium.

If you want more detail then it's not going to happen by
putting the image on computer #2. You're just enlarging
the display of the image. What you can do is to edit the
image in a graphic editor. By doing that you *might* be
able to get a bigger image that still looks good. But you
still won't increase the *resolution* of the original image.

"GS" wrote

| screen shots are just pixels. if you set your display to a higher
| resolution, you get more pixels in the screen shot. that's all.
|
| Now that's *exactly* what I said!!!

I think there's just a mixup of terms here. Nospam
is pointing out the fact that there's no absolute size
in a screenshot -- only pixel dimensions. You're
referring to screen DPI, which most people are unaware
of and which adds an unnecessary complication in
this context. (It's relevant to you writing software, but
it's not relevant to a computer user in practice.)

I don't understand why DPI is even a possible
EXIF tag. It makes no sense. (That reminds me of
Joan Baez singing, "a couple of lightyears ago", not
understanding that a lightyear is distance and not
time.

Steven Roman, in his VB Win32 API Programming
book, includes a dizzying discussion of the difficulty
in even translating between logical screen inches
and pixels.
Windows knows the screen size in pixels, but it can't
know the precise physical size of the screen. With
standard 96 PPI setting, a monitor inch is 96 pixels.
But set it to 120 and a monitor inch is 120 pixels. So
the theoretical physical size of the screen is changed.
Since the display is in pixels, there's no absolute size
and no true PPI, just as with raster images.

In article , GS wrote:

A 'screenshot' captures the screen area you specify!

exactly the point. there is no dpi (or ppi).

That's just wrong!

it's not wrong

The DPI for the screenshot is *exactly* what the screen DPI setting is. If
you
change the screen DPI setting then all subsequent screenshots will be
whatever
the new setting is! Ergo: changing the screen DPI setting changes the
screenshot DPI!!!

it can be anything you want it to be. it's completely meaningless.

go into photoshop and change it to whatever you want. the screenshot is
unaffected.

In article , Wolf K
wrote:

There's another problem.

When oriented horizontally, with lens to the right or to the left. One
may produce an upside down video when played back on a computer/TV.
There seems to be no consistency. Same problem with horizontal photos.

there is no problem

I didn't say there _is_ one, I said there _may be_ one.

the possibility is so incredibly low that it can be considered to be
zero.

because of the orientation tag in the photo or
video.

Aha! Therefore, a camera without an orientation sensor can't add an
orientation tag. So that must be the problem when the image/video is
incorrectly oriented on playback.

smartphones have orientation sensors, as do all but the ****tiest
cameras, so that situation is *very* rare.

if you're seeing it upside-down, then your software is ignoring the tag
which means your software is at fault.

Nonsense.

not nonsense at all. only ****ty software ignores orientation tags.

"Wolf K" wrote
|
| DPI is not PPI. Eg, my screen is 1920x1080 _pixels_, 21.75" horizontal,
| or 80 PPI. A screen capture with the snipping tool shows shows 120 DPI.
|

See my last post to Garry. It's confusing. The screen capture
tool is probably showing "logical pixels per inch horizontally", as
retrieved from Windows. It's a relative value. As you noted,
that has little to do with the actual screen size, or with inches.
The value in EXIF tags is pointless. People need to stop talking
about DPI outside of printing, and PPI is of no practical use.

In article , Mayayana
wrote:

|
| DPI is not PPI. Eg, my screen is 1920x1080 _pixels_, 21.75" horizontal,
| or 80 PPI. A screen capture with the snipping tool shows shows 120 DPI.
|

See my last post to Garry. It's confusing. The screen capture
tool is probably showing "logical pixels per inch horizontally", as
retrieved from Windows. It's a relative value. As you noted,
that has little to do with the actual screen size, or with inches.
The value in EXIF tags is pointless. People need to stop talking
about DPI outside of printing,

so far so good..

and PPI is of no practical use.

that is absolutely wrong.

Wolf K wrote:
On 2017-08-23 17:59, nospam wrote:

if you're seeing it upside-down, then your software is ignoring the tag
which means your software is at fault.

Nonsense.

Actually, there is one specific failure case, and it's
associated with Apple.

Apple stored metadata in the file header, indicating
orientation. On an Apple box, the displayed result
may be correct. But the scheme doesn't seem to be portable,
and if an Apple user sends the video to a recipient on
a different platform, the video could be upside-down.

For me at least, the way to deal with hillbilly formats,
is to convert them to something that doesn't have
orientation metadata. And the only possible outcome
is What You See (in your video editor) is What You Get
(on the recipient computer when they open your movie attachment).

https://discussions.apple.com/thread...art=0&tstart=0

"only a subset of them actually interpret the EXIF Orientation flag"

Now, think about it. It's one thing to have "in-band" metadata,
a flag defined in a movie or picture format for this specific purpose.
Placing a "hint" in the form of EXIF, is to coin
a phrase, "weak". You can imagine how this would be a
recipe for "platform-specific disaster". EXIF should be
considered "volatile" and "not part of the video or image",
and "can be erased at any time or moment, or even ignored".
For example, some people filter their content with
"EXIF Eraser" to make sure there is no personally identifiable
info, such as GPS coords, in the file header.

That's why doing such a thing in EXIF, is so... "weak".

Paul

In article , Paul
wrote:

if you're seeing it upside-down, then your software is ignoring the tag
which means your software is at fault.

Nonsense.

Actually, there is one specific failure case, and it's
associated with Apple.

nope.

apple, as do other smartphone vendors, writes a proper orientation tag.

apple, adobe and other software vendors check the tag and do the right
thing.

unfortunately, not everyone. any app that ignores the tag is at fault.

Apple stored metadata in the file header, indicating
orientation. On an Apple box, the displayed result
may be correct. But the scheme doesn't seem to be portable,

it's very portable. the tag is standard.

and if an Apple user sends the video to a recipient on
a different platform, the video could be upside-down.

it has nothing to do with apple. lots of cameras write orientation tags.

For me at least, the way to deal with hillbilly formats,
is to convert them to something that doesn't have
orientation metadata. And the only possible outcome
is What You See (in your video editor) is What You Get
(on the recipient computer when they open your movie attachment).

that's very bad and causes problems for those who use software that
checks for the tag.

https://discussions.apple.com/thread...art=0&tstart=0

"only a subset of them actually interpret the EXIF Orientation flag"

software that use the orientation tag is broken. contact the developer
and tell them to fix it.

those who create photos or videos should not cater to those who choose
to use ****ty software.

note that your link says that apple and adobe software works properly.

Now, think about it. It's one thing to have "in-band" metadata,
a flag defined in a movie or picture format for this specific purpose.
Placing a "hint" in the form of EXIF, is to coin
a phrase, "weak". You can imagine how this would be a
recipe for "platform-specific disaster". EXIF should be
considered "volatile" and "not part of the video or image",
and "can be erased at any time or moment, or even ignored".
For example, some people filter their content with
"EXIF Eraser" to make sure there is no personally identifiable
info, such as GPS coords, in the file header.

it's possible to remove gps while leaving the orientation tag.

in other words, user error.

That's why doing such a thing in EXIF, is so... "weak".

it's not weak and is standard across the industry.

Windows knows the screen size in pixels, but it can't
know the precise physical size of the screen. With
standard 96 PPI setting, a monitor inch is 96 pixels.
But set it to 120 and a monitor inch is 120 pixels. So
the theoretical physical size of the screen is changed.
Since the display is in pixels, there's no absolute size
and no true PPI, just as with raster images.
A mizup of terms for sure! We can blame Microsoft for that, though...

Windows refers to this as the screen resolution 'DPI Setting' in ControlPanel.
Changing it as described effectively changes what a screenshot captures in
pixels for the specified area (width/height) of the capture. Nothing changes
physically in the captured image so it reflects the exact current DPI setting
of screen resolution at the time of capture. Nor does the screen resolution
change; -just its ppi. So on my 1920x1200 display's DPI Setting of 120,
everything appears smaller than a 96 setting.

Not sure why all these Windows experts don't know about this ControlPanel
setting or its effects on screenshots when changed. Seems really basic to me!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

"nospam" wrote


| Actually, there is one specific failure case, and it's
| associated with Apple.
|
| nope.
|
| apple, as do other smartphone vendors, writes a proper orientation tag.
|
| apple, adobe and other software vendors check the tag and do the right
| thing.
|
| unfortunately, not everyone. any app that ignores the tag is at fault.
|

He makes a good point. An image file is created with an
orientation. What Apple is doing is to say, "Well, it takes
too much time to coordinate the camera position with
the image file structure. That might make our camera seem
slow. So we'll just put this little note in the EXIF data that
tells the rendering software to rotate the image before
sending it to display." That's just hokey. The fact that an
EXIF tag exists is not an excuse. Apple are not finishing
the job.

In article , Mayayana
wrote:

| Actually, there is one specific failure case, and it's
| associated with Apple.
|
| nope.
|
| apple, as do other smartphone vendors, writes a proper orientation tag.
|
| apple, adobe and other software vendors check the tag and do the right
| thing.
|
| unfortunately, not everyone. any app that ignores the tag is at fault.
|

He makes a good point.

no he doesn't.

the issue has absolutely nothing to do with apple.

An image file is created with an
orientation. What Apple is doing is to say, "Well, it takes
too much time to coordinate the camera position with
the image file structure. That might make our camera seem
slow. So we'll just put this little note in the EXIF data that
tells the rendering software to rotate the image before
sending it to display."

complete nonsense.

the image captured is what comes off the sensor.

there is no need to rotate it, which would not slow down anything since
it would take less time than writing it to flash does.

That's just hokey. The fact that an
EXIF tag exists is not an excuse. Apple are not finishing
the job.

they did finish the job, that being to tag the image as to the
orientation of the camera, exactly the same as just about every other
digital camera.

it's not just apple.

samsung phones, nikon & canon cameras and many others, all do *exactly*
the same thing as what apple is doing.

"nospam" wrote

| and PPI is of no practical use.
|
| that is absolutely wrong.

Read WolfK's description. If he measures his
monitor with a ruler and divides that into the
display setting he gets 80 PPI. If he asks Windows
it will tell him 120 PPI. An inch is a physical
measurement. A pixel is a data measurement.
It's not possible to programmatically calculate
how many pixels in an inch because it's not
possible for software to measure the physical
screen.

It's possible to define PPI in a limited way, in a
specific context, as when WolfK takes a ruler
and holds it up to his screen. But the idea of
PPI is only confusing the issue here. It's not
a relevant concept. It gets even more confused
by graphic software that assigns a DPI spec
based on the OS PPI spec. Forget inches
when it's on the computer. Forget *PI. Inches
is for the physical world of printing, because
a printer will actually spray x dots per actual
linear inch.

"nospam" wrote

| the image captured is what comes off the sensor.
|

Yes. And Apple software knows enough to know
which way is up, since they tag it. so they should
just rotate it on the spot, before saving to file.
Maybe they can't afford such advanced technology
and still keep the price of an iPhone at a bargain
basement $1,000?

"Bram van den Heuvel" wrote

| Is there any way to snap a screenshot at better resolution than 96 DPI?
|

After all this hoopla, a number of people have explained
in numerous ways that you can't get better *resolution*
of a specific image onscreen. So it might be worth looking
at the next step:
Do you have graphic software? Have you tried sharpening,
resizing, contrast, brightness, saturation, etc? Sometimes
you can get a bit more mileage thay way. Unfortunately,
there's not a lot of data to work with in a screenshot. But
it's often worth trying.

In article , Mayayana
wrote:


| and PPI is of no practical use.
|
| that is absolutely wrong.

Read WolfK's description.

he's confused, as are you.

ppi is not only of practical use for printing, but it's *vital*.

If he measures his
monitor with a ruler and divides that into the
display setting he gets 80 PPI. If he asks Windows
it will tell him 120 PPI. An inch is a physical
measurement. A pixel is a data measurement.

no, a pixel is just a value, typically a triplet but can be any number
of components.

It's not possible to programmatically calculate
how many pixels in an inch because it's not
possible for software to measure the physical
screen.

for devices with fixed displays, such as phones and tablets, the size
of the display is known and never changes, which means software can
precisely create onscreen objects of a known size.