Go Back   IceInSpace > Equipment > Astrophotography and Imaging Equipment and Discussions

Reply
 
Thread Tools Rate Thread
  #21  
Old 09-07-2010, 09:22 AM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by multiweb View Post
Hi Ivo, you're talking about software binning? I thought hardware binning was different.
You're absoluetely right - I'm talking about software binning and I should've mentioned that. IMHO hardware binning should be avoided, as it is best done in software, giving you more flexibility.
Quote:
On a camera you lose color information for an OSC and resolution for a mono as well but apparently I hear your SNR is better because signal ratio to readout noise increases too. Which is one real advantage.
You're bringing up a very interesting point here which is very relevant to this discussion as well. A CCD with an on-chip Color Filter Array (e.g. a 'color camera') will need to somehow conjur up a lot of missing data, since pixels are distributed over different color channels. In the case of the most used CFA, the Bayer filter (RGB), this means that only 1/3rd of the data is available and 2/3rds needs to be interpolated (aka 'Demosaicing' or 'Debayering'). This process too is a great source of noise, and it's usually noise of the 'worst' kind; correlated noise.

Whereas uncorrelated noise (aka 'random' noise) can be dealt with by the methods posted in this forum or even software noise filters, correlated noise is much harder to deal with because it affects neighboring pixels as well.

Worse, most demosaicing algorithms assume a correlation between the brightness levels of the green channel and the blue and red channel, which means that noise in any of these channels may 'migrate' into other channels. This makes any traditional software noise filtering useless and can really confuse stacking software and quality estimation algorithms.

Some Demosaicing routines are worse than others for noisy images and I encourage anyone to try as many as possible to see what works best. Funnily enough I've found that the best algorithms for natural photography sometimes perfom the worst when it comes to noisy astrophotography images. This usually has to do with high-frequency detail detection, which, when given noiseless input, works as intended and reduces color artefacts (blue, yellow, green, purple fringes and artefacts). However the high-detail frequency detection is often thrown off by random noise (which is by it's very nature high frequency).

Other algorithms look at neighbouring pixels to aid in edge and/or gradient detection. If such a pixel is incorrectly set due to noise, the effect can be a cascade of errors in the debayerd output image affecting neighbouring pixels, introducing yet more artifacts and thus correlated noise.

Nebulosity, for example, uses a demosaicing algorithm that is very simple - no serious natural photographer would touch it with a barge pole. However, it's exactly its simplicity that makes it a much better candidate for dealing with noisy images than the more complicated algorithms found in the various photo processing suites.

Quote:
But if you have skyglow to start with and you bin 2x2 then flatfield/calibrate would you get a better result than no binning+calibration then software binning?
The reason why you would choose software binning over hardware binning is that, when using hardware binning, your image gets saturated quicker and you need to stop your exposure sooner to avoid ending up with a completely white image (due to skyglow).

A longer exposure gives you a better signal-to-noise ratio (the signal goes up linearly with the exposure, the noise goes up as the square root of the exposure). Also my rule is to only throw away data at the last possible moment, only if I get something for it in return and, if I can help it, on my terms under my control.

When I process images, at every step, I actually envision what I'm doing to my pixels and why - it's not just a matter of 'what looks good at the moment'. It really does pay to learn about the algorithms behind the operations you perform on your image - it can help you combine processing steps in your head and think ahead.

Sorry, went a bit on a tangent there...


Last edited by irwjager; 09-07-2010 at 09:50 AM.
Reply With Quote
  #22  
Old 09-07-2010, 10:37 AM
JohnH's Avatar
JohnH
Member # 159

JohnH is offline
 
Join Date: Feb 2005
Location: NSW
Posts: 1,226
Nobody has mentioned setting the GAIN correctly. Can this not help S/N?

I am pterrty sure it does on my ccd where the signal can be bosted mare rapidly than noise (well it looks that way in the graphs I have seen) - the compromise will be saturation occurs faster for the bright elements.

The comment about h'ware binning is the opposite of what I have heard - s'ware binning is not binning at all really - it is a 2x2 or 3x3 averaging. H'ware binning 2x2 will reduce the required exposure time by a factor of 4 (at the cost of resolution) for a given signal level and is used to great effect in LRGB imaging where L is 1x1 and colours are taken at 2x2.

Reply With Quote
  #23  
Old 09-07-2010, 11:47 AM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by JohnH View Post
Nobody has mentioned setting the GAIN correctly. Can this not help S/N?

I am pterrty sure it does on my ccd where the signal can be bosted mare rapidly than noise (well it looks that way in the graphs I have seen) - the compromise will be saturation occurs faster for the bright elements.
Very good point!

Gain in digital systems comes down to multiplication of the signal (and thus also multiplication of the noise). When using gain settings that are higher than unity (e.g. a factor > 1.0), as you're suggesting, saturation is reached sooner and there is less time to average noise events, resulting in noisier images.

Gain factors that are lower than unity (e.g. < 1.0) may help, in that there is more time before saturation occurs, so there's more time to collect light/expose and average out noise events.

In the real world, however, your mileage may vary depending on your hardware's characteristics (triggering voltages, thermal noise, circuit noise, rounding errors due to gain multiplication, etc.).

Quote:
The comment about h'ware binning is the opposite of what I have heard - s'ware binning is not binning at all really - it is a 2x2 or 3x3 averaging.
Actually, the term 'binning' does not define how the binned data is used. Binning is pretty cool; you can use binning to increase exposure (e.g. add the pixel values), use binning for noise reduction (e.g. add the pixels, then divide the result by the number of pixels you binned), use binning to increase bit-depth (e.g add the pixels and promote the image to a higher bit-depth at the same time), or any other exotic operation such as median filtering, adaptive binning, fractional binning (1.75x1.75, 3.14x3.14), etc.

It doesn't matter whether this is done at the hardware level, or the software level; the operation is *exactly* the same and there's no difference. Hardware binning is still software binning, only that's it's performed by the software in the firmware, instead of the software on your computer.

EDIT: Though they are almost the same, RickS points out that the latter statement is nevertheless untrue (it is done at the hardware level) and there is one important benefit to hardware (summed) binning; read out noise reduction.

'Software' binning allows more flexibility in two ways; 1. It allows you to manipulate the image before it is binned (ex. subtract light pollution - stuff that you don't want binned). And 2. It allows you to use more advanced types of binning than your hardware supports (for example, StarBright determines how much a group of pixels needs to be fractionally binned for maximum contrast and no over exposure, reducing resolution only by the smallest amount possible).

Quote:
H'ware binning 2x2 will reduce the required exposure time by a factor of 4 (at the cost of resolution) for a given signal level and is used to great effect in LRGB imaging where L is 1x1 and colours are taken at 2x2.
And that's exactly what I use binning for most of the time. After I have taken my shorter than normal exposed image without binning (e.g. dimmer, but at full resolution). Then using a binning algorithm on my computer after I have taken out the light pollution.

Last edited by irwjager; 11-07-2010 at 08:20 PM.
Reply With Quote
  #24  
Old 09-07-2010, 12:04 PM
JohnH's Avatar
JohnH
Member # 159

JohnH is offline
 
Join Date: Feb 2005
Location: NSW
Posts: 1,226
Is there really no difference between an image of, say, 120s binned 2x2 in hware and one of 120s binned 1x1 and then processed in sware? Is it just that the default behavious in H'ware (sum?) and S'ware (average?) binning are not the same?
Reply With Quote
  #25  
Old 09-07-2010, 12:36 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by JohnH View Post
Is there really no difference between an image of, say, 120s binned 2x2 in hware and one of 120s binned 1x1 and then processed in sware?
There should be no difference. Unless there's some other magic performed in the firmware and they're not telling us about it (personally, I've never come across a proprietary summing algorithm, but we can't say for sure).

EDIT: RickS points out that there is in fact a difference (it is done at the hardware level) and there is one important benefit to hardware (summed) binning; read out noise reduction.

Quote:
Is it just that the default behavious in H'ware (sum?) and S'ware (average?) binning are not the same?
I guess that depends on what you define as default behavior; In Nebulosity 2.x, for example, you can choose from the menu Image->Bin/Blur-> and you'll have a choice of 3 operations; "2x2 bin: Sum", "2x2 bin: Average" and "2x2 bin: Adaptive". So I guess, at least in Nebulosity, there is no default behavior when it comes to binning.

Last edited by irwjager; 11-07-2010 at 08:21 PM.
Reply With Quote
  #26  
Old 09-07-2010, 01:57 PM
multiweb's Avatar
multiweb (Marc)
ze frogginator

multiweb is offline
 
Join Date: Oct 2007
Location: Sydney
Posts: 22,060
Quote:
Originally Posted by irwjager View Post
(aka 'Demosaicing' or 'Debayering'). This process too is a great source of noise, and it's usually noise of the 'worst' kind; correlated noise....

Some Demosaicing routines are worse than others for noisy images and I encourage anyone to try as many as possible to see what works best.

Nebulosity, for example, uses a demosaicing algorithm that is very simple - it's exactly its simplicity that makes it a much better candidate for dealing with noisy images than the more complicated algorithms found in the various photo processing suites.
Very interesting. I'm definitely going to look at my subs and debayer with different softwares and compare the results. I wasn't aware that noise from other channels in the bayer matrix could bleed into neighbouring pixels during the process. Thanks for pointing all this out Ivo.
Reply With Quote
  #27  
Old 09-07-2010, 03:08 PM
avandonk's Avatar
avandonk
avandonk

avandonk is offline
 
Join Date: Aug 2005
Location: Melbourne
Posts: 4,786
For one shot colour it is far better to do all corrections for flats and darks in FIT form. I also do the initial stretch in fit form and only then do the interpolation to tif for stacking.

Try doing just one image and correct for flats and darks in tiff form and in Fit form and comparing the result. I use ImagesPlus for this.

Bert
Reply With Quote
  #28  
Old 09-07-2010, 03:46 PM
multiweb's Avatar
multiweb (Marc)
ze frogginator

multiweb is offline
 
Join Date: Oct 2007
Location: Sydney
Posts: 22,060
Quote:
Originally Posted by avandonk View Post
For one shot colour it is far better to do all corrections for flats and darks in FIT form.
I always calibrate and flat field the raw files with the bayer matrix in as advised by Stan Moore then debayer to individual channels and stack separately. I also tried to debayer then calibrate debayered channels but the result was the same in CCDStack so it was not worth the extra work.
Reply With Quote
  #29  
Old 09-07-2010, 04:29 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by multiweb View Post
then debayer to individual channels and stack separately
Interesting... So you stack the channels separately? Does that include per-channel quality estimation? Or do you use the quality estimation for the composite RGB image?
Reply With Quote
  #30  
Old 09-07-2010, 04:36 PM
multiweb's Avatar
multiweb (Marc)
ze frogginator

multiweb is offline
 
Join Date: Oct 2007
Location: Sydney
Posts: 22,060
Quote:
Originally Posted by irwjager View Post
Interesting... So you stack the channels separately? Does that include per-channel quality estimation? Or do you use the quality estimation for the composite RGB image?
Yes - my work flow is not different than working with a mono. I'm not sure about the quality estimation bit but I use the sub with the best FWHM as per CCD Inspector report still with its bayer matrix in for everything. Registration, normalisation and data rejection. I make a note of it and use it as a base to work from in each channel.
Reply With Quote
  #31  
Old 09-07-2010, 04:45 PM
RickS's Avatar
RickS (Rick)
PI cult recruiter

RickS is offline
 
Join Date: Apr 2010
Location: Brisbane
Posts: 10,584
Quote:
Originally Posted by JohnH View Post
Is there really no difference between an image of, say, 120s binned 2x2 in hware and one of 120s binned 1x1 and then processed in sware? Is it just that the default behavious in H'ware (sum?) and S'ware (average?) binning are not the same?
This short document I read recently claims there is a signal to noise advantage in hardware binning because it reduces the effect of read noise: http://www.roperscientific.de/binning.html. Seems like a plausible argument to me...

Cheers,
Rick.
Reply With Quote
  #32  
Old 09-07-2010, 04:55 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by multiweb View Post
Yes - my work flow is not different than working with a mono. I'm not sure about the quality estimation bit but I use the sub with the best FWHM as per CCD Inspector report still with its bayer matrix in for everything. Registration, normalisation and data rejection. I make a note of it and use it as a base to work from in each channel.
Very interesting. You just gave me an idea! Since most debayering algorithms use data from other channels to help with the interpolation, they may "inherit' each other's noise (as I described above).

Now, what if you would extract all the red, green1, green2 and blue pixels from the bayered image, and put these in their own image?

You would end up with 4 images, all 1/4th the size. You could then stack those, do your usual thing and then, at the very end, put them together in a bayer matrix again and, only then, debayer them with the algorithm of your choice.

If I'm correct, this could yield a better quality image since you're delaying the potential noise crosstalk until the very end when you have a single, much better quality image... Any noise would stay confined to its own channel and be rejected by the quality estimator during the per-channel stacking, with no chance of spreading to other channels.

Hmmm....
Reply With Quote
  #33  
Old 09-07-2010, 05:08 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by RickS View Post
This short document I read recently claims there is a signal to noise advantage in hardware binning because it reduces the effect of read noise: http://www.roperscientific.de/binning.html. Seems like a plausible argument to me...

Cheers,
Rick.
Interesting read and I stand corrected regarding hardware binning; "This process is performed prior to digitization in the on-chip circuitry of the CCD by specialized control of the serial and parallel registers." as opposed to in the firmware after digitizing.

You got to wonder though if the increased read noise (4 reads instead of 1 read for 2x2 binning) would really register when performing a single readout per-pixel at the end of a long exposure; you certainly wouldn't hope so! I can definitely see how this would impact video though.
Reply With Quote
  #34  
Old 09-07-2010, 05:37 PM
RickS's Avatar
RickS (Rick)
PI cult recruiter

RickS is offline
 
Join Date: Apr 2010
Location: Brisbane
Posts: 10,584
Quote:
Originally Posted by irwjager View Post
You got to wonder though if the increased read noise (4 reads instead of 1 read for 2x2 binning) would really register when performing a single readout per-pixel at the end of a long exposure; you certainly wouldn't hope so! I can definitely see how this would impact video though.
That's the big question! Perhaps on faint targets it could make a difference. I'm still very much a newbie on this stuff and keeping an open mind!
Reply With Quote
  #35  
Old 10-07-2010, 02:20 PM
rat156's Avatar
rat156
Registered User

rat156 is offline
 
Join Date: Aug 2005
Location: Melbourne
Posts: 1,694
An interesting discussion, but how do you "subtract skyglow"?

Skyglow is NOT noise, it's unwanted signal. If there's a way to subtract unwanted signal I want to know about it.

WRT binning, I really should bin as my resolution is a little over 1"/pixel, which, considering the seeing I usually contend with is way too much. But then I give up image scale, which I like. Also some of the deconvolution algorithms rely on oversampled data.

Cheers
Stuart
Reply With Quote
  #36  
Old 10-07-2010, 02:50 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by rat156 View Post
An interesting discussion, but how do you "subtract skyglow"?

Skyglow is NOT noise, it's unwanted signal. If there's a way to subtract unwanted signal I want to know about it.
You're absoluetely right; skyglow is certainly not noise, and that's the sole reason you can subtract it at all. Skyglow is not random, like noise, and therefore fortunately you can do some meaningful processing on it.

For a very crude subtraction of skyglow, you can take the pixel value of the darkest pixel (don't count dead pixels ofcourse ) you can find in your image, then subtract this value from all pixels in the image.

Ofcourse this isn't likely to remove all the skyglow, as skyglow usually ends up being uneven (there are other tools for that such as my StarWipe tool, PixelInsight's DBE tool, GradientXterminator, etc.). However it should take out the bulk of the unwanted signal without 'under clipping'. A simple way to do this in any photo processing suite is to create an extra layer, filled with the darkest pixel value you could find in the image, then set the layer to 'subtract'.

From here you can software bin the image. Because you took out the skyglow, you can bin the image more than you were able to with the skyglow still in, without the image starting to clip/over expose. You can not do this with hardware binning and this is the reason why I don't recommend hardware binning.
Reply With Quote
  #37  
Old 11-07-2010, 03:37 PM
Bassnut's Avatar
Bassnut (Fred)
Narrowfield rules!

Bassnut is offline
 
Join Date: Nov 2006
Location: Torquay
Posts: 5,064
Quote:
Originally Posted by irwjager View Post
Interesting read and I stand corrected regarding hardware binning; "This process is performed prior to digitization in the on-chip circuitry of the CCD by specialized control of the serial and parallel registers." as opposed to in the firmware after digitizing.

You got to wonder though if the increased read noise (4 reads instead of 1 read for 2x2 binning) would really register when performing a single readout per-pixel at the end of a long exposure; you certainly wouldn't hope so! I can definitely see how this would impact video though.
Your ideas about binning generally are very wrong there Ivo .

Hardware binning is not done in firmware (but the hardware process is controlled by firmware, totally different). As per ricks excellent link, electrons say in bin 2 are dumped from 2 adjacent pixels into one serial "super pixel" register and read out as one pixel, halving the readout noise. In bin 4 the readout noise is 4 times less, a significant S/N improvement, especially with low signal.

In fact for low signal levels, hardware binning improves read S/N so much it can make the difference between unusable data at bin 1 (due to read noise domination) and more than usable at bin 2.

Many, many times, I have wasted imaging time with bin 1 on dim nebs with 20min exposures with very NB filters and reimaged at bin2 with excellent results.

Your statement avoiding hardware binning and using sofware binning is very missleading, I would say the reverse (from hard experience), software binning is next to useless, its just unnecessary data manipulation for next to no S/N gain at all, and hardware binning is not only necessary, but often critical for any result at all !.

With advanced CCD chips (especially ith ABGs), binning is unlikely to cause saturation as decribed in the link, and anyway, if the signal is so high that blooming occures, then you would simply not need to bin, or take shorter exposures.

Hardware binning is very common BTW, all this is not just my opinion.
Reply With Quote
  #38  
Old 11-07-2010, 05:53 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by Bassnut View Post
Your ideas about binning generally are very wrong there Ivo .

Hardware binning is not done in firmware. As per ricks excellent link, electrons say in bin 2 are dumped from 2 adjacent pixels into one serial "super pixel" register and read out as one pixel, halving the readout noise. In bin 4 the readout noise is 4 times less, a significant S/N improvement, especially with low signal.
As I have graciously admitted

Quote:
In fact for low signal levels, hardware binning improves read S/N so much it can make the difference between unusable data at bin 1 (due to read noise domination) and more than usable at bin 2.

Many, many times, I have wasted imaging time with bin 1 on dim nebs with 20min exposures with very NB filters and reimaged at bin2 with excellent results.
We're both right! I'm talking from the context from a light polluted site (e.g. lots of skyglow). In that case your read out noise is drowned out by skynoise at relatively short exposure times.

If you're doing your photography from dark sites (lucky you!), read noise definitely becomes an issue and binning can really help.

This is a great read on the subject;
http://www.starrywonders.com/ccdcame...derations.html

Quote:
Your statement avoiding hardware binning and using sofware binning is very missleading, I would say the reverse (from hard experience), software binning is next to useless, its just unnecessary data manipulation for next to no S/N gain at all, and hardware binning is not only necessary, but often critical for any result at all !.
I take issue with saying that software binning is next to useless though.

For starters, some of us have OSC's and have no way of doing hardware binning without sacrificing color.

Aside from that. The reduction of read noise in hardware binning is merely a (very welcome) side effect of the implementation of binning in the hardware. There are still further benefits to binning, also in the realm of reducing noise. That's why you'll frequently find 'averaging' as one of the binning options in the different software suites.

EDIT: Removed "For example, averaging the 4 pixels in a 2x2 area drops noise by a factor of 2 (it's the same as stacking 4 subs). This can *far* outweigh any read noise gains made by hardware (summing) binning." - It's more complicated than that

As I've said before in this thread, "binning" is just the process of putting multiple samples together and choosing a single sample to represent the multiple samples. This totally leaves open the method/algorithm you chose to assign the single value. There are many ways to avail from the benefits of binning - all of them can be accessed by software and only one (summing) is accessed through hardware (with the added benefit of read out noise reduction).

Quote:
With advanced CCD chips (especially ith ABGs), binning is unlikely to cause saturation as decribed in the link, and anyway, if the signal is so high that blooming occures, then you would simply not need to bin, or take shorter exposures.

Hardware binning is very common BTW, all this is not just my opinion.
I was referring to excessive skyglow, not blooming. When you have a lot of skyglow at your site, your wells fill up quickly and skyglow drowns out the signal you're after to the point where everything is overexposed. Binning makes this worse - you collect light faster (4x for 2x2), but for some sensors, your well capacity does not increase by the same factor on all sensors due to ADU limitations; the increased dynamic range you collect can not fully be encoded by the A/D converter. Therefore it is better to record everything you can get, export it to your computer and bin it there. However, if you image very faint objects at dark sites, this is obviously not of concern or use to you at all.

Add to that the flexibility of removing data that you don't want binned and software binning becomes a lot more useful.

That said, hardware binning definitely has its uses and I apologize if I came across as dismissing it completely.

Last edited by irwjager; 11-07-2010 at 06:56 PM.
Reply With Quote
  #39  
Old 11-07-2010, 06:39 PM
multiweb's Avatar
multiweb (Marc)
ze frogginator

multiweb is offline
 
Join Date: Oct 2007
Location: Sydney
Posts: 22,060
I believe hardware binning has its advantages on extremely faint objects because I have seen it done practically in narrowband test shots (oiii on the helix). The improvement was just second to none. The signal (and contrast in details) was just overwhelming any noise.

If you're in a light polluted environment or imaging a very bright object then hardware binning has very diminished returns. The data will saturate very quickly and the skyglow will also be worse.

So hardware binning does definitely have its place. As far as software binning goes, I hear what you're saying Ivo but I'm still to see a real life example of the kind of improvement you'd get. Are you saying that if you remove skyglow first then software bin the data the result would be better?

I can provide some light polluted uncalibrated raw data if you wish to demonstrate. Got stacks of that.
Reply With Quote
  #40  
Old 11-07-2010, 07:52 PM
irwjager's Avatar
irwjager (Ivo)
Registered User

irwjager is offline
 
Join Date: Apr 2010
Location: Melbourne
Posts: 532
Quote:
Originally Posted by multiweb View Post
As far as software binning goes, I hear what you're saying Ivo but I'm still to see a real life example of the kind of improvement you'd get. Are you saying that if you remove skyglow first then software bin the data the result would be better?

I can provide some light polluted uncalibrated raw data if you wish to demonstrate. Got stacks of that.
The removal of the skyglow frees up dynamic range, which can be used to bin an image more until the whole of the dynamic range is used up. This would be fractional binning obviously and not a neat 2x2 - think 2,25x2,25 or thereabouts. The image would be smaller than the 2x2 hardware binned image with the light pollution still in.

You could do the same thing to the hardware binned image though - take out the light pollution and then software bin it again until the full dynamic range is used.

I'd be happy to demonstrate it!
Reply With Quote
Reply

Bookmarks

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +10. The time is now 05:25 PM.

Powered by vBulletin Version 3.8.7 | Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Advertisement
Bintel
Advertisement
Testar
Advertisement