When inspecting an image in Chrome Dev Tools I notice that when hovering on the HTML it will display dimensions followed by other dimensions in parenthesis.
For example: 298 x 274 pixels (intrinsic: 860 x 731 pixels)
What is the meaning of the dimension in the parenthesis?
When you hover on the HTML it will display dimensions followed by other dimensions in parenthesis.
For example: 298 x 274 pixels (intrinsic: 860 x 731 pixels)
860 x 731 pixels is the image's actual size, and 298 x 274 pixels are the size after applying CSS to that image.
I currently display 115 (!) different sponsor icons at the bottom of many web pages on my website. They're lazy-loaded, but even so, that's quite a lot.
At present, these icons are loaded separately, and are sized 75x50 (or x2 or x3, depending on the screen of the device).
I'm toying with the idea of making them all into one sprite, rather than 115 separate files. That would mean, instead of lots of tiny little files, I'd have one large PNG or WEBP file instead. The way I'm considering doing it would mean the smallest file would be 8,625 pixels across; and the x3 version would be 25,875 pixels across, which seems like a really very large image (albeit only 225 px high).
Will an image of this pixel size cause a browser to choke?
Is a sprite the right way to achieve a faster-loading page here, or is there something else I should be considering?
115 icons with 75 pixel wide sure will calculate to very wide 8625 pixels image, which is only 50px heigh...
but you don't have to use a low height (50 pixel) very wide (8625 pixel) image.
you can make a suitable rectangular smart size image with grid of icons... say, 12 rows of 10 icons per line...
115 x 10 = 1150 + 50 pixel (5 pixel space between 10 icons) total 1200 pixel wide approx.
50 x 12 = 600 + 120 pixel (5 pixel space between 12 icons) total 720 pixel tall approx.
This is probably a very simple answer but I want to double check I'm not making some obvious assumption.
Let's say I have a picture of a person...and I know that person is 66 inches tall. If I want to determine how many pixels represents one inch RELATIVE TO THE IMAGE ITSELF...do I simply divide the number of pixels / the number of inches?
Example:
Person a = 66 inches tall
Bitmap of person a = person a is 500 pixels in the Bitmap
Pixels in "real world" inches of the photo -> 500 / 60??
When I am reading about the resolution of a digital image from the following link http://www.rideau-info.com/photos/whatis.html, I confused at the following Paragraph:
If the field of view is 20 feet across, a 3 megapixel camera will be resolving that view at 102 pixels per foot. If that same shot was taken with an 18 Mp camera it would be resolving that view at 259 pixels per foot, 2.5 times more resolution than a 3 Mp camera.
Here, how come the author is arriving at the conclusion: "102 pixels per foot and 259 pixels"?
A 3MP camera, in that article, is 2048 wide x 1536 high. Think of 2048 pixels across as 2048 boxes laid in a straight line. Now, if you were to divide these equally amongst 20 sections (20 feet of field of view), you would get ~120 boxes per section. Hence, the logic behind 102 pixels per foot. Similar reasoning is used for the 18MP camera which is 5184 W x 3546 H. 5184 divided into 20 is ~259.
I have to integrate an LCD screen to my embedded linux (ARM9) system. The LCD is portrait 320x480 and I need to run the screen in landscape orientation 480x320.
Using the LCD config register I can rotate it in hardware, so that (x,y)(0,0) is rotated 90 degrees.
Here starts my problem, the screen's wide side gets narrowed from 480 pixels to 320, and the long side of the picture is out of the screen. This should be fixed by changing the framebuffer dimensions AFAIK, but I tried a few ways to do it with no success yet.
using the fbset, below are the settings for portrait:
mode "480x320-55"
# D: 9.091 MHz, H: 18.182 kHz, V: 55.096 Hz
geometry 480 320 480 320 16
timings 110000 4 4 4 4 12 2
rgba 5/0,6/5,5/11,0/0
endmode
Sending the command:
fbset --geometry 480 320 480 320 16
Results in:
mode "480x320-55"
# D: 9.091 MHz, H: 18.182 kHz, V: 55.096 Hz
geometry 480 320 480 320 16
timings 110000 4 4 4 4 12 2
rgba 5/0,6/5,5/11,0/0
endmode
Which makes the picture appear a few times and overlaps, but the screen width is still too narrow.
I tried to provide double the screen size for the virtual xres and yres, but no change.
fbset --geometry 480 320 960 640 16
I also tried using fb rotate function I found on the web "saFbdevRotation.c", which uses the FB IOCTL, but the active screen size is still incorrect.
rotate 90 degrees, see output
$> ./fb_rotate -r 90
## Before rotation
### Fix Screen Info:
Line Length - 640
Physical Address = 81a00000
Buffer Length = 1048576
### Var Screen Info:
Xres - 320
Yres - 480
Xres Virtual - 320
Yres Virtual - 480
Bits Per Pixel - 16
Pixel Clk - 110000
Rotation - 0
## after rotation
### Fix Screen Info:
Line Length - 960
Physical Address = 81a00000
Buffer Length = 1048576
### Var Screen Info:
Xres - 480
Yres - 320
Xres Virtual - 480
Yres Virtual - 320
Bits Per Pixel - 16
Pixel Clk - 110000
Rotation - 90
I can also add that the system is very limited with free memory, can this cause the fb to NOT allocate a new buffer? However there were no errors in dmesg.
Will appreciate your advise.
I can also add that the system is very limited with free memory, can
this cause the fb to NOT allocate a new buffer? However there were no
errors in dmesg.
Normally,the standard way for allocating video buffer is to pre-allocate a large video buffer(based on the max video resolution you support) in the boot time,which pass a men= argument to the kernel so that kernel won't occupy it initially.
then later on,the video driver can do
void *ioremap(unsigned long phys_addr, unsigned long size)
which will create a mmap area for driver directly operate the frame buffer.
You can check it via doing cat /proc/iomen
Thus,the video driver memory is pre-allocated and is different from linux kernel system memory(like kmalloc() or get_free_pages() or vmalloc()), what you concerned is ruled out.
I think your issue is related to the LCD that you are using. I have seen several embedded LCDs that claim to support 90 deg rotation, but the result was exactly as you described.
My problems were always encountered using the RGB display interface. I suspect that the rotation might have worked using the CPU interface.
I have seen only one embedded display that was able to do the rotation correctly for RGB interface.
The thing is, you should try to do the rotation either with
LCD HW, your processor HW, or pure SW.
I do not know if Linux framebuffer might use pure SW or your processor HW, it probably depends on your driver.
Have you tried rotating the display by adding a line in config.txt (on the DOS boot partition)?
The line you would need is:
display_rotate=0..3
(where 0 is the default and 1 is 90 degrees clockwise, 2 180 degrees, etc.)
There's also an lcd_rotate command, but I'm not sure what the difference is.