Wikipedia:Reference desk/Archives/Computing/2018 March 22
Computing desk | ||
---|---|---|
< March 21 | << Feb | March | Apr >> | Current desk > |
Welcome to the Wikipedia Computing Reference Desk Archives |
---|
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
March 22
[edit]Smallest meaningful pixel size
[edit]How small can pixel get, until it does not make sense, since humans won't notice the difference? --Doroletho (talk) 14:19, 22 March 2018 (UTC)
- Multiple websites claim that the smallest thing a human can see with a normal, unaided vision is 0.1mm. That conflicts with practice. Micro-oled is 0.0047mm. 209.149.113.5 (talk) 14:44, 22 March 2018 (UTC)
- Depends on how close your eye is to the screen. The determining factor is the angular resolution of your eyes. Here are some calculations. E.g. if you have a 46 inch 4K display you can see individual pixels if you get closer than about one meter to the screen (assuming perfect vision). 85.76.72.88 (talk) 14:51, 22 March 2018 (UTC)
- For camera pixels, the smallest technologies - like Sony's IMX318 - uses imaging unit-cells ("pixels") that are 1.0 microns in linear extent. This is just about equal to the scale length of visible light: if the pixel were made any smaller, its lateral dimensions would be smaller than the wavelength it's trying to sample, and you'd have to start using all kinds of weird quantum-mechanical antenna theory to capture photons of visible light.
- Industry has been driving down to thoes super-tiny pixels for several years, but in the last two or three, the trend has gradually been reversing; more commercially-available sensors are using larger pixels again.
- Pixels ("picture-elements") for physical sensors that construct images using anything other than visible light can be built in different sizes, with the smallest unit-cell corresponding to other physical limitations.
- Nimur (talk) 16:07, 22 March 2018 (UTC)
Raw to Tiff, Tiff to C++, Deep Colour (more than 8 bits per channel)
[edit]I've been working on a suite of image enhancement and analysis tools. I've been using a set of decent jpegs converted to bmp as test images, and I've gotten good results, but I would, ideally, like to work with a source that has more bits per channel than 8.
However, I am not sure the best way to go about this. My ideal work flow would to be find a converter from Raw to Tiff that will give me a 16bit per channel image, then to import this into C++ using some library.
On the first front, I've seen some people mention, elsewhere, that certain Raw viewed and converters just work with the jpg of the image embedded in the file, which would be a major problem for me.
On the second front, libtiff seems like what I should be using for programming, but I am under the impression you can't do more than 8 bits per channel.
Is all of this accurate? Any suggestions or resources that might help? Would it be worth my time to just code my own reader and writer for the Tiff format?
I come for more of a mathematics background than a tech one, so while I can code competently and have no problem with the theoretical side of what I'm actually doing, I'm a bit out of my depth with the specifics of dealing with the file types (which is why i went jpeg to bmp, it's easy to convert and bmp is easy to code a reader for).
Any help would be greatly appreciated, thank you very much.2600:1016:B027:8A65:A34D:55AF:2185:D518 (talk) 17:33, 22 March 2018 (UTC)
- Imagemagick (which uses dcraw to read many RAW image file formats) may be enough for you; it will convert just about any image file format to another. You can try it with TIFF, or use 16 bit-per-channel netpbm or PAM as your intermediate format. A nice feature about netpbm/pam (for your purposes) is the format is mostly just numbers in a regular ASCII text file, so you can see manually what it's done, and write simply code yourself to process them. -- Finlay McWalter··–·Talk 17:56, 22 March 2018 (UTC)
- Libraw https://www.libraw.org/ might be of interest. I have used it, and had no problems with Canon CR2 files (have tried EOS 500D, EOS 77D, powershot G9X), Pentax DNG (K30), Nikon NRW (Coolpix B700) and DNGs from a Lumia mobile phone.
- I have also used LibTIFF, and can assure you that it reads and writes 16-bit images. --NorwegianBlue talk 08:43, 23 March 2018 (UTC)