I understand gamma topic but maybe not 100% and
want to ask somebody to answer and clarify my
doubts.
As I understand
there is a natural linear color space where color
with value 100 is exactly four times brighter then color
with value 25 and so on (it would be good to hold and
process color images in that format/space
when you will copy such linear light image onto
device you would get wrong colors becouse generally
some medium values would appear to dark sou you
generally need to rise up this middle values by something
like x <- power(x, 1/2.2) (or something)
this is reasonably clear, but now
are the normal everyday bitmap or jotpeg images
gamma precomputed ? If they are when i would do
some things al blending and so should i do some
inverted-gamma to boath them to convert them to
linear then add them and then gamma-correct them
to result?
when out of scope would apperr it is better co cut
colors or resacle it linearly into more wide range or
something else?
tnx for answers
There's nothing "natural" about linear color values. Your own eyes respond to brightness logarithmically, and the phosphors in televisions and monitors respond exponentially.
GIF and JPEG files do not specify a gamma value (JPEG can with extra EXIF data), so it's anybody's guess what their color values really mean. PNG does, but most people ignore it or get it wrong, so they can't be trusted either. If you're displaying images from a file, you'll just have to guess or experiment. A reasonable guess is to use 2.2 unless you know the file came from an Apple device, in which case use 1.0 (Apple devices are generally linear).
If you need to store images accurately, Use JPEG from a camera with good EXIF data embedded for photos, and maybe something like TIFF for uncompressed images. And use high-quality software that understands these things. Unfortunately, that's pretty rare and/or expensive.
Related
I'm writing an astronomy application using Apple's SceneKit and want to provide a skybox of stars to surround a planet.
I have found a large JPEG (8192x4096) with suitable content but my "camera" field of view (10 degrees) magnifies the skybox image background enough to cause serious loss of resolution. In short, it doesn't look good .. here's a screenshot showing blurry stars:
https://ramsaycons.com/screenshots/SkyBoxRes.png
One solution for greater fidelity would be, I imagine, to use a resolution independent 'material' image like a PDF, but SceneKit doesn't support PDF 'materials'.
Or, I could find, or build, a better or bigger image for the skybox material. For example, a (32768x16384) would look better, at the cost of a massive image ~ the 'small' one I'm using now is nearly 8MB already.
Another option would be to move closer to the planet and widen the field of view, but I don't want to move the camera so close (specifically, because I want it 'above' geosynchronous objects in my model).
This code-less question feels not quite appropriate for StackOverflow, but my reading of related Q&A's here reveals a knowledge of clever SceneKit tricks I wouldn't have thought off .. maybe there's a trick for me out there!
I have a standard jpeg image, which I use within some commercial software to colorize other data (by mapping the image's color onto the data). Then I export the colored data from this software to an XYRGB ascii file, i.e. I store the data information in the first two columns of each row and then the three RGB colors in the last three columns.
Since I need to convert the color to CIELab or CIELuv, it seems I need to know which exact colorspace (RGB, sRGB, gamma, whitepoint - you name it) my RGB values are in. But the question is: How can I find out? Or could I just assume a certain profile being a good approximation?
(Remark: The company of the commercial software I used was not able to tell me any specifics...)
If you don't know the provenance of the image, there's not anything you can do to determine the color space from the RGB data alone. It's a little like having a blueprint without a scale. You could guess and check with an application like Photoshop that can assign a profile to an image but even then it's not always obvious which is correct unless the image contains colors you can recognize as correct.
For many images sRGB is good guess. Most image on the web are sRGB and many non-color managed apps assume sRGB. But just understand that it is still a guess. If color accuracy is critical, you need the profile.
I am trying to do my own blob detection who will receive a real time video, and try to detect a white paper sheet.
Even if is something written inside the paper. I need to detect the paper and is corner, because what i really want is to draw a opengl polygon over the paper in each corner of the paper will be a corner of the polygon. Then i need the coordinates of the paper to do other stuffs.
So i need to:
- detect a square white blob.
- get the coordinates of the cornes
- draw a polygon over the white sheet.
Any ideias how can i do that?
Much depends on context. For example, suppose that you:
know that the paper is always roughly centered (i.e. W/2, Y/2 is always inside the blob), and no more rotated than 45 degrees (30 would be better)
have a suitable border around the sheet so that the corners never touch the edges of the FOV
are able (through analysis of local variance, or if you're lucky, check of background color or luminance) to say whether a point is inside or outside the blob
the inside/outside function never fails (except possibly in the close vicinity of a border)
then you could walk a line from a point on the border (surely outside) and the center (surely inside), even through bisection, and find a point - an areal - on the edge.
Two edge points give a rect (two areals give a beam), two rects give an intersection (two beams give a larger areal) - and there's your corner. You should carry along the detection uncertainty (areal radius) in order to validate corners (another less elegant approach is to roughly calculate where the corner is, and pinpoint it with a spiral search or drunkard's walk).
This algorithm is amenable to parallelization and, as long as the hypotheses hold, should be really fast.
All that said, it remains a hack -- I agree with unwind, why reinvent the wheel? If you have memory or CPU constraints (embedded systems, etc.), I believe there ought to be OpenCV and e-Vision "lite" ports also for ARM and embedded platforms.
(Sorry for my terminology - I'm monkey-translating from Italian. "Areal" is likely to correspond to your "blob", a beam is the family of lines joining all couples of points in two different blobs, line intensity being the product of distance from a point from its areal's center)
I am trying to do my own blob detection who will receive a real time video, and try to detect a white paper sheet.
Your first shot could be a simple flood-fill. That is, select a good threshold to binarize the image and apply the algorithm. The threshold can be fixed if you know the paper is always brighter than X and the background is always darker than this. Or this can be an adaptive threshold, for example Otsu's method. OpenCV offers this for free.
If you'd need to speed it up you could use a union-find data structure.
Finally you'd need to come up with some heuristic how to identify the corners (e.g. the four extreme values in x/y direction).
Then i need [...] the coordinates of the cornes [...]
Then you don't need blob detection, but corner detection or contour detection in the first place. OpenCV has some nice functionality for exactly this.
If you can't use it, I would suggest to binarize the image as above and use a harris-detector to find the corners of the object.
OpenCV's TBB support could also come quite handy if you'd use it and you have problems to meet your real-time requirements.
I have a sequence of images taken from a camera. The images consists of hand and surroundings. I need to remove everything except the hand.
I am new to Image processing. Would anyone help me in regard with the above Question. I am comfortable using C and Matlab.
A really simple approach if you have a stationary background and a moving hand (and quite a few images!) is simply to take the average of the set of images away from each image. If nothing else, it's a gentle introduction to Matlab.
The name of the problem you are trying to solve is "Image Segmentation". The Wikipedia page here: wiki is a good start.
If lighting consistency isn't a problem for you, I'd suggest starting with simple RGB thresholding and see how far that gets you before trying anything more complicated.
Have a look at OpenCV, a FOSS library for computer vision applications. Specifically, see the Video Surveillance module. For a walk through of background subtraction in MATLAB, see this EETimes article.
Can you specify what kind of images you have. Is the background moving or static? For a static background it is a bit straightforward. You simply need to subtract the incoming image from the background image. You can use some morphological operations to make it look better. They all depend on the quality of images that you have. If you have moving background I would suggest you go for color based segmentation. Convert the image to YCbCr then threshold appropriately. I know there are some papers available on it(However I dont have time to locate them). I suggest reading them first. Here is one link which might help you. Read the skin segmentation part.
http://www.stanford.edu/class/ee368/Project_03/Project/reports/ee368group08.pdf
background subtraction is simple to implement (estimate background as average of all frames, then subtract each frame from background and threshold resulting absolute difference) but unfortunately only works well if 1. camera has manual gain and exposure 2. lighting conditions do not change 3.background is stationary. 4. the background is visible for much longer than the foreground.
given your description i assume these are not the case - so what you can use - as already pointed out - is colour as a means of segmenting foreground from background. as it's a hand you are trying to isolate best bet is to learn the hand colour. opencv provides some means of doing this. if you want to do this yourself you just get the colour of some of the hand pixels (you would need to specify this manually for at least one frame) and convert them to HUE (which encapsulates the colour in a brightness independen way. skin colour has a very constant hue) and then make a HUE histogram. compare this to the rest of the pixels and then decided if the hue is simmilar enough.
When designing a website, what do you consider the best image format to use for a particular task?
I always find myself in a dilemma when trying to figure out what format to use for a specific task...like for example, should I use .jpg all round? or, when and why should I use a .png?
For example, taking Amazon's website, they use .jpg for product images (Example), .gif for this transparent pixel (Example) and .png for their CSS Sprites (Example)
On the other hand, Play.com use a .gif for their website logo (Example), but use .jpg for their website products (like Amazon) (Example) and as far as their main page goes, they dont have any .pngs on it.
So what formats should I use for my websites? and why should I use them?
[UPDATE]
Thanks CruellO for this link for explaining the differences, and also Dustin for giving reasons on what to use.
You should be aware of a few key factors...
First, there are two types of compression: Lossless and Lossy.
Lossless means that the image is made smaller, but at no detriment to the quality. Lossy means the image is made (even) smaller, but at a detriment to the quality. If you saved an image in a Lossy format over and over, the image quality would get progressively worse and worse.
There are also different colour depths (palettes): Indexed color and Direct color.
With Indexed it means that the image can only store a limited number of colours (usually 256) that are chosen by the image author, with Direct it means that you can store many thousands of colours that have not been chosen by the author.
BMP - Lossless / Indexed and Direct
This is an old format. It is Lossless (no image data is lost on save) but there's also little to no compression at all, meaning saving as BMP results in VERY large file sizes. It can have palettes of both Indexed and Direct, but that's a small consolation. The file sizes are so unnecessarily large that nobody ever really uses this format.
Good for: Nothing really. There isn't anything BMP excels at, or isn't done better by other formats.
GIF - Lossless / Indexed only
GIF uses lossless compression, meaning that you can save the image over and over and never lose any data. The file sizes are much smaller than BMP, because good compression is actually used, but it can only store an Indexed palette. This means that there can only be a maximum of 256 different colours in the file. That sounds like quite a small amount, and it is.
GIF images can also be animated and have transparency.
Good for: Logos, line drawings, and other simple images that need to be small. Only really used for websites.
JPEG - Lossy / Direct
JPEGs images were designed to make detailed photographic images as small as possible by removing information that the human eye won't notice. As a result it's a Lossy format, and saving the same file over and over will result in more data being lost over time. It has a palette of thousands of colours and so is great for photographs, but the lossy compression means it's bad for logos and line drawings: Not only will they look fuzzy, but such images will also have a larger file-size compared to GIFs!
Good for: Photographs. Also, gradients.
PNG-8 - Lossless / Indexed
PNG is a newer format, and PNG-8 (the indexed version of PNG) is really a good replacement for GIFs. Sadly, however, it has a few drawbacks: Firstly it cannot support animation like GIF can (well it can, but only Firefox seems to support it, unlike GIF animation which is supported by every browser). Secondly it has some support issues with older browsers like IE6. Thirdly, important software like Photoshop have very poor implementation of the format. (Damn you, Adobe!) PNG-8 can only store 256 colours, like GIFs.
Good for: The main thing that PNG-8 does better than GIFs is having support for Alpha Transparency.
Important Note: Photoshop does not support Alpha Transparency for PNG-8 files. (Damn you, Photoshop!) There are ways to convert Photoshop PNG-24 to PNG-8 files while retaining their transparency, though. One method is PNGQuant, another is to save your files with Fireworks.
PNG-24 - Lossless / Direct
PNG-24 is a great format that combines Lossless encoding with Direct color (thousands of colours, just like JPEG). It's very much like BMP in that regard, except that PNG actually compresses images, so it results in much smaller files. Unfortunately PNG-24 files will still be much bigger than JPEGs, GIFs and PNG-8s, so you still need to consider if you really want to use one.
Even though PNG-24s allow thousands of colours while having compression, they are not intended to replace JPEG images. A photograph saved as a PNG-24 will likely be at least 5 times larger than the equivalent JPEG image, with very little improvement in visible quality. (Of course, this may be a desirable outcome if you're not concerned about file size, and want to get the best quality image you can.)
Just like PNG-8, PNG-24 supports alpha-transparency, too.
JPEGs are for photos. I see JPEGs with text in them occasionally and they just look awful. Text is best for text, otherwise use PNG.
If it's not a photo, but you want a graphic of it, use a PNG. A PNG is almost always smaller than the equivalent gif and will not lose quality like a JPEG file. A PNG equivalent of a JPEG will typically be a lot larger (assuming it's photorealistic). There may be times where this is still desirable.
PNG does allow for 8-bits of transparency, but if you have to support IE, you'll find that they continually refuse to support that correctly. They do support a single bit of transparency in an 8-bit image (essentially the same as gif) as far as I know. There are also numerous hacks to get 8-bit transparency to work in IE. I've never bothered, myself.
In summary:
Photos → jpg
!Photos → png
PNG can be used when:
You need transparency (either 1-bit or alpha transparency)
Lossless compression will work well (such as a flat-style icon or logo)
JPEG can be used when:
Lossless compression will not work well (such as a photograph)
GIF can be used when:
Animation is necessary, and video is not possible (though you should really try and use video; animated GIFs are poor quality and very inefficient)
Despite myths to the contrary, PNG outperforms GIF in all like for like comparisons. PNG is capable of every image mode of GIF apart from animation, and when using the same image mode, PNG will have better compression due to its superior DEFLATE algorithm compared to LZW. PNG is also capable of additional modes that GIF cannot do, such as 24 bit color, and multi-bit transparency (alpha transparency). Note that multi-bit transparency used to be a problem back when people used IE6.
PNG modes include (this is just a small subset)
Palette colour of 2 to 256 colors (like GIF)
Palette colour of 2 to 256 colors, with transparent color (like GIF)
True color (24 bit color)
True color with alpha channel (24 bit color + 8 bit transparency)
For best compression in PNG for the web, always use a palette mode. If you find PNG files are larger than the equivalent GIF files, then chances are you're saving the PNG in 24 bit color and the GIF in palette mode (because saving a full color GIF always requires translation to palette mode). Try converting the image to palette mode before saving in both cases.
PNG also has other modes such as palette color with alpha transparency in the palette. Modes such as this work in browsers but software like Photoshop have (or once had) problems with creating or working with them due to not supporting those image modes.
If you are storing or presenting a large number of images the new Google WebP format might be worth considering as it is 25% smaller than PNG/JPG.
Note this is not supported by all browsers at the moment.
NB. This came out in 2010 after this question was posted.
JPEG FILE FORMAT
Great for images when you need to keep the size small
Good option for photographs
Bad for logos, line art, and wide areas of flat color
GIF FILE FORMAT
Great for animated effects
Nice option for clip art, flat graphics, and images that use minimal colors and precise lines
Good option for simple logos with blocks of colors
PNG FILE FORMAT
Lossless
Excellent choice when transparency is a must
Good option for logos and line art
Not supported everywhere
You can see this infographics for more detailed information, Image File Types: When to use JPEG, GIF & PNG