smartYUV for sRGB
127 views
Skip to first unread message
pdknsk
Aug 28, 2016, 1:24:07 AM8/28/16
to WebP Discussion
Please try this patch. It slightly improves details in averaged areas and tone accuracy in darker areas.
diff --git a/src/enc/picture_csp.c b/src/enc/picture_csp.c
--- a/src/enc/picture_csp.c
+++ b/src/enc/picture_csp.c
@@ -184,10 +184,14 @@ static WEBP_TSAN_IGNORE_FUNCTION void InitGammaTablesF(void) {
const double norm = 1. / MAX_Y_T;
const double scale = 1. / kGammaTabSize;
for (v = 0; v <= MAX_Y_T; ++v) {
- kGammaToLinearTabF[v] = (float)pow(norm * v, kGammaF);
+ double g = norm * v;
+ kGammaToLinearTabF[v] = (float)(g <= 0.04045 ? g / 12.92 :
+ pow((g + 0.055) / 1.055, 2.4));
}
for (v = 0; v <= kGammaTabSize; ++v) {
- kLinearToGammaTabF[v] = (float)(MAX_Y_T * pow(scale * v, 1. / kGammaF));
+ double g = scale * v;
+ kLinearToGammaTabF[v] = (float)(MAX_Y_T * (g <= 0.0031308 ? g * 12.92 :
+ 1.055 * pow(g, 1 / 2.4) - 0.055));
}
// to prevent small rounding errors to cause read-overflow:
kLinearToGammaTabF[kGammaTabSize + 1] = kLinearToGammaTabF[kGammaTabSize];
@@ -235,12 +239,12 @@ static fixed_y_t clip_y(int y) {
//------------------------------------------------------------------------------
static int RGBToGray(int r, int g, int b) {
- const int luma = 19595 * r + 38470 * g + 7471 * b + YUV_HALF;
+ const int luma = 13932 * r + 46871 * g + 4731 * b + YUV_HALF;
return (luma >> YUV_FIX);
}
static float RGBToGrayF(float r, float g, float b) {
- return 0.299f * r + 0.587f * g + 0.114f * b;
+ return 0.2126f * r + 0.7152f * g + 0.0722f * b;
}
static int ScaleDown(int a, int b, int c, int d) {
Pascal Massimino
Aug 29, 2016, 2:46:20 PM8/29/16
to WebP Discussion
Hi,
On Sat, Aug 27, 2016 at 10:24 PM, pdknsk <pdk...@gmail.com> wrote:
Please try this patch. It slightly improves details in averaged areas and tone accuracy in darker areas.
thanks for the suggestion!
Do you have some samples demonstrating the improvement? (you can send them privately, in case)
thanks!
skal/
--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.
pdknsk
Aug 29, 2016, 8:43:20 PM8/29/16
to WebP Discussion
This is a particularly difficult picture for WebP.
I'm posting at q100 for better comparison of pre4, but I've verified the same improvements at lower quality and equal file size.
(I recommend to load the images in separate tabs and then switch back and forth with ctrl+tab and ctrl+shift-tab.)
Slightly improved sky gradient, particularly at the height of the gift.
On the house on the left, the lilac-ish letter R is sharper and less light.
Likewise on the red/white arches over the stairs in the background.
Less halo and blur around the balloon.
Many other minor improvements.
An interesting part are the cyan-ish ears of the bear, which were previously slightly brighter than in the original image, and are too dark now.
Nicholas Doyle
Aug 29, 2016, 10:30:48 PM8/29/16
to webp-d...@webmproject.org
I noticed that the original PNG image does not have an ICC profile attached nor does it have an sRGB chunk. Both of the WebP images have ICC profiles attached.
In Chrome, this means the original PNG image will (unfortunately) be assumed to be using the (unknown) colour profile of the display while the WebP derivatives will be appropriately colour corrected for the display. Depending on your display (MacBook Airs and new P3 5k iMacs for example, many many other displays as well to various degrees) the browser will render the original PNG incorrectly and unpredictably depending on how close or far the display is calibrated to sRGB.
This should be taken in to consideration when viewing and comparing these images.
--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.
<x2.new.webp><x2.old.webp><x2.png>
pdknsk
Aug 29, 2016, 11:34:41 PM8/29/16
to WebP Discussion
It did have the same profile. (Otherwise both WebP images wouldn't, as I used -metadata icc with cwebp.) Google Groups stripped it, or I made a mistake and attached the wrong image. I'll re-attach. The size of the attached image is 691816 bytes. (The preview shows a size of 676KB, so it appears to be right.)
pdk...@gmail.com
Aug 29, 2016, 11:37:28 PM8/29/16
to WebP Discussion
Nope, it modifies it on the server, and removes the profile. Other changes: IDAT is split into 32KB, which is a clear sign of it (losslessly, but worse) recompressing the image. The original PNG only has a single IDAT.
I have already deleted the WebP images, so I'll remake and re-attach, even though they appear to be un-modified. Quite possible Google Groups altered those as well.
pdknsk
Aug 30, 2016, 12:11:34 AM8/30/16
to WebP Discussion
It doesn't modify WebP. (I wanted to attach a ZIP now, but I half expect Google Groups to unpack and repack it.)
Thanks for noticing!
PS. The patch in the first post has a minor patch format error.
Pascal Massimino
Aug 30, 2016, 8:23:56 AM8/30/16
to WebP Discussion
Hi,
On Tue, Aug 30, 2016 at 6:11 AM, pdknsk <pdk...@gmail.com> wrote:
It doesn't modify WebP. (I wanted to attach a ZIP now, but I half expect Google Groups to unpack and repack it.)
Thanks for the samples!
I'm curious: where are the new constants coming from in RGBToGray?
The previous ones were derived from Rec601, but i'm not sure about the ones you propose.
They seem to introduce more 'hard' edges (which you translated into "Less halo and blur around the balloon.").
For instance, look at the red balloon in the blue sky:
Before / after:
or the roof that seems to have more 'stair-cases':
(Otherwise, the sRGB correction for the kLinearToGammaTabF[] tables seems ok to me).
skal/
PS. The patch in the first post has a minor patch format error.
--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss+unsubscribe@webmproject.org.
pdknsk
Aug 31, 2016, 1:56:38 AM8/31/16
to WebP Discussion
The constants are from Rec.709, but I got them from some w3.org page initially.
I'm posting samples at quality 75 and 50 for comparison, with adjusted quality for equal file size.
I should add that I really focus on the lost detail caused by subsampling. Those additionally bytes may now have to be compromised elsewhere at low quality. (I consider below default, 75, low.)
Pascal Massimino
Aug 31, 2016, 10:39:53 AM8/31/16
to WebP Discussion
Hi,
On Wed, Aug 31, 2016 at 7:56 AM, pdknsk <pdk...@gmail.com> wrote:
The constants are from Rec.709, but I got them from some w3.org page initially.
Ok, i see. So why not use Rec-709's transfer function too, then? (instead of sRGB's one)
For testing purpose i've split the patch into several [WIP] patches, so we can test separately each effect:
- Rec709 transfer: https://chromium-review.googlesource.com/378995
- sRGB transfer: https://chromium-review.googlesource.com/#/c/378955/
- use Rec709 for Gray evaluation: https://chromium-review.googlesource.com/378856 (note that the coefficients were adjusted, so that they sum up to 65536).
I'd really like to have more samples than just one, though. We're at risk of over-fitting :)
skal/
I'm posting samples at quality 75 and 50 for comparison, with adjusted quality for equal file size.I should add that I really focus on the lost detail caused by subsampling. Those additionally bytes may now have to be compromised elsewhere at low quality. (I consider below default, 75, low.)
--
pdknsk
Sep 2, 2016, 7:15:06 AM9/2/16
to WebP Discussion
Thanks for splitting those up. I'll try them with more samples. I didn't use the Rec.709 function, because the w3.org page recommended sRGB gamma with Rec.709 luminance. (I'll try and find it.) And since the goal is to match sRGB, I don't know if it's good. Both are close*, but different. Whereas both Rec.709 and sRGB have the same chromaticity.
I'll try the combinations and report back.
Pascal Massimino
Sep 5, 2016, 6:04:07 AM9/5/16
to WebP Discussion
Hi,
On Fri, Sep 2, 2016 at 1:15 PM, pdknsk <pdk...@gmail.com> wrote:
Thanks for splitting those up. I'll try them with more samples. I didn't use the Rec.709 function, because the w3.org page recommended sRGB gamma with Rec.709 luminance. (I'll try and find it.) And since the goal is to match sRGB, I don't know if it's good. Both are close*, but different. Whereas both Rec.709 and sRGB have the same chromaticity.
let me attach few additional difficult cases, that surfaced during the various discussions around this topic in this mailing-list.
Seems a good time to gather them all at the same place, for later reference.
Chrome_icon: the 45 -degree separation between green and red is difficult
color_fonts.png: it's near impossible to get all the color combinations right!
color.png: probably one of the oldest 'difficult' sample reported here. The "O" of 'focused' is difficult.
d3.png: the dithering red-pattern is difficult
red-with-black: the black spots on the red leather tend to disappear / smear.
x2.png: your test case. Balloon's edge are difficult.
I'll try the combinations and report back.
Pascal Massimino
Sep 5, 2016, 9:57:12 AM9/5/16
to WebP Discussion
Pascal Massimino
Sep 6, 2016, 9:33:49 AM9/6/16
to WebP Discussion
hi again,
for the sake of completeness, i'm adding here for later reference a 'bad' case of smartYUV.
The following image shows nasty banding when -pre 4 is used [1].
This is one of the reason why i think -pre 4 is not totally finished. Need to investigate where the overshoot is coming from.
skal/
[1] cwebp -pre 4 bad_banding.png -o test.webp [-q 100]
pdknsk
Sep 6, 2016, 9:46:02 AM9/6/16
to WebP Discussion
On the topic of banding: what does SFIX do exactly? I noticed that increasing SFIX to 6 helps banding in some cases, because it increases the size of the gamma table, but it doesn't appear to be a simple correlation. In particular code like luma >> SFIX confuses me, because it should have a very adverse effect.
Pascal Massimino
Sep 8, 2016, 10:05:19 AM9/8/16
to WebP Discussion
Hi,
On Tue, Sep 6, 2016 at 3:46 PM, pdknsk <pdk...@gmail.com> wrote:
On the topic of banding: what does SFIX do exactly?
It indeed controls the precision and the size of the look-up table used during the linear -> Gamma conversion.
I found SFIX=2 being enough to get a reasonable extra precision headroom, while keeping the LUT reasonable.
Above 2, it's overkill. Note that 'SFIX=0' works reasonably too, but some banding can pop-up so it's not worth
the saving.
I noticed that increasing SFIX to 6 helps banding in some cases, because it increases the size of the gamma table, but it doesn't appear to be a simple correlation. In particular code like luma >> SFIX confuses me, because it should have a very adverse effect.
You are referring to ConvertRGBToY() right? It's only used during the final value computation, to remove once and for all the extra uplifted bits that were used during the previous computations.
skal/
(and for the sake of completeness, i attach here another good test sample from the other thread on this mailing list)
Pascal Massimino
Sep 9, 2016, 1:39:47 PM9/9/16
to WebP Discussion
Hi,
quick update: the following patches
should have taken care of the 'bad' corner cases of banding and such.
Now, looking at crispness and difference between rec601 and 709 should be easier.
Pascal Massimino
Sep 13, 2016, 5:06:02 AM9/13/16
to WebP Discussion
Hi,
so i'm not sure this sRGB patch is beneficial overall.
i've tried the sRGB transfer function patch [1]. It doesn't seem to improve the details overall, and has an
adverse effect on dark area, esp. red ones.
See for instance kodim02, when using 'cwebp -pre 4 ...':
before:
After:
(this is best seen looking at the luma plane).
so i'm not sure this sRGB patch is beneficial overall.
skal/
pdknsk
Sep 14, 2016, 11:47:04 AM9/14/16
to WebP Discussion
It's a winner. Very noticeable improvement. In particular gradients, but also detail. Even the cyanish ears of the bear. I haven't tried it with sRGB/R.709 yet.
pdknsk
Sep 15, 2016, 11:23:48 AM9/15/16
to WebP Discussion
I've tried the 6 combinations now, but before I get to that, I'm wondering: why did my patch yield many of the same improvements as the recent fixes? It's like a side-effect, that for some reason quite consistently pushed the code past the criterion? Strange.
Pascal Massimino
Sep 15, 2016, 4:17:56 PM9/15/16
to WebP Discussion
Hi,
On Thu, Sep 15, 2016 at 8:23 AM, pdknsk <pdk...@gmail.com> wrote:
I've tried the 6 combinations now, but before I get to that, I'm wondering: why did my patch yield many of the same improvements as the recent fixes? It's like a side-effect, that for some reason quite consistently pushed the code past the criterion? Strange.
Not sure exactly, maybe helping compensating for the sub-optimal initial state. That could be an explanation.
skal/
Pascal Massimino
Sep 16, 2016, 7:16:28 AM9/16/16
to WebP Discussion
Hi,
FYI, i've uploaded the following patch: https://chromium-review.googlesource.com/386557
It does the simple trick of sharpening the U/V plane after conversion. It's quite efficient for improving the red areas.
It's not as precise as '-pre 4', but much faster. In particular, sharp edges are not resolved as well as with -pre 4. But
overall if red tint is better preserved.
If you want to give it a try, just use 'cwebp -pre 8 ...' with the above patch.
I'm considering making it default, but there's one caveat: the output size increases a little, for the better.
skal/
skal/
Pascal Massimino
Sep 16, 2016, 8:37:37 AM9/16/16
to WebP Discussion
On Fri, Sep 16, 2016 at 1:16 PM, Pascal Massimino <pascal.m...@gmail.com> wrote:
Hi,On Thu, Sep 15, 2016 at 10:17 PM, Pascal Massimino <pascal.m...@gmail.com> wrote:Hi,On Thu, Sep 15, 2016 at 8:23 AM, pdknsk <pdk...@gmail.com> wrote:I've tried the 6 combinations now, but before I get to that, I'm wondering: why did my patch yield many of the same improvements as the recent fixes? It's like a side-effect, that for some reason quite consistently pushed the code past the criterion? Strange.Not sure exactly, maybe helping compensating for the sub-optimal initial state. That could be an explanation.FYI, i've uploaded the following patch: https://chromium-review.googlesource.com/386557It does the simple trick of sharpening the U/V plane after conversion.
[and for the record, it's an idea that originates from Lode Vandevenne, also known for Zopfli]
pdknsk
Sep 16, 2016, 9:23:31 PM9/16/16
to WebP Discussion
I've made a simple page for better comparison of the combinations. The explanation for the names is gamma+luminance. I've also added pre8, even though it's not competing against the others. I'll post my observations in the next post.
PS. For faster switching, use keys 1-9. And the page supports 2x displays.
pdknsk
Sep 16, 2016, 10:08:16 PM9/16/16
to WebP Discussion
Differences are subtle.
(A)
As previously mentioned, +r709 reduces halo, albeit by "boxy" aliasing. This is really noticeable in Y at 1x, where it looks like a clear defect. It also has some other deficiencies.
More interesting is r709+r601. It does ever so slightly reduce halo, but introduces a more noticeable step in the sky gradient at x1. Interesting: in Y, the source has the same step. (I'm not sure what to make of this.) Some other minor improvements.
(B)
With r709+r601, the wallpaper shapes have fewer irregularities. It seems to have less of a tendency to wander off a few pixels. Less detail in very dark tones. (Interesting result in YUV: U and V sharper in r709+r601, Y in g22+r601.)
So a bit inconclusive.
Perhaps there is some logic to r709+r601 possibly being better, when you know that for gamma, R.709 == R.601. So it's actually r601+r601. I dismissed it previously, because the curve is quite different from both 2.2 and sRGB.
pdknsk
Sep 16, 2016, 10:11:22 PM9/16/16
to WebP Discussion
PS. The page also works in other browsers, but loads PNGs then, which are obviously significantly slower to load. And pre8 is good.
Pascal Massimino
Sep 19, 2016, 10:59:42 AM9/19/16
to WebP Discussion
Hi,
On Sat, Sep 17, 2016 at 4:08 AM, pdknsk <pdk...@gmail.com> wrote:
Differences are subtle.
nice, very useful page!
After some experimentation, it seems that the combination of both patches (so: srgb+r709) is useful for:
a) accelerating the convergence (with srgb+r709, most images finish in just 1 pass. There's not even iterations)
b) helping with dark green areas.
Here's an example picture link for b). Note how the green area on the right is too light without the srgb+r709 combo.
This is because the initial state is not close enough, and iterations can't recover the initial gap.
With srgb+r709, the initial guess is much better and convergence is overall better.
skal/
--
Pascal Massimino
Sep 19, 2016, 4:47:55 PM9/19/16
to WebP Discussion
Hi,
On Mon, Sep 19, 2016 at 7:59 AM, Pascal Massimino <pascal.m...@gmail.com> wrote:
Hi,On Sat, Sep 17, 2016 at 4:08 AM, pdknsk <pdk...@gmail.com> wrote:Differences are subtle.nice, very useful page!After some experimentation, it seems that the combination of both patches (so: srgb+r709) is useful for:a) accelerating the convergence (with srgb+r709, most images finish in just 1 pass. There's not even iterations)b) helping with dark green areas.Here's an example picture link for b). Note how the green area on the right is too light without the srgb+r709 combo.This is because the initial state is not close enough, and iterations can't recover the initial gap.With srgb+r709, the initial guess is much better and convergence is overall better.
after further visual inspection, it really seems 709+709 is the best combination.
For photos sources, the convergence is much faster and the loop exists faster. It's good because there's rarely any 'difficult' cases there.
For graphic / graph / drawing sources, color is preserved accurately even with few iterations.
Accordingly, the patch i'd like to finalize is : https://chromium-review.googlesource.com/387025
(and then some more speed-up using assembly)
Please have a look if you can!
thanks,
pdknsk
Sep 19, 2016, 4:55:37 PM9/19/16
to WebP Discussion
I've added another sample in line with your comment. I think g22+r601 does relatively poorly, as it noticeably (well, relatively) lightens the leaves, and also "flattens" many, particularly in the upper half. Also notice the window to the left.
I think it'll be difficult to crown an overall winner that is best for every sample. I think the current default for pre4 isn't though.
PS. I assume your viewing those on macOS (as most Googlers, I think)? If you're on Ubuntu, then I recommend to use Firefox, as Chrome ignores the monitor color space, which, depending on how far your screen is from sRGB, can make a difference. This is fixed in M55+.
pdknsk
Sep 19, 2016, 5:17:46 PM9/19/16
to WebP Discussion
Just a short note on the patch, or rather the patch description: the autoritative source for the values is in sections 1.1 and 3.1 of the PDF. (Only the reverse value of 0.018 is mentioned, but 0.081 is obviously 0.018 * 4.5.)
pdknsk
Sep 19, 2016, 5:19:05 PM9/19/16
to WebP Discussion
Oh, it's 1.2 and 3.2.
Pascal Massimino
Sep 20, 2016, 1:17:49 AM9/20/16
to WebP Discussion
On Mon, Sep 19, 2016 at 2:17 PM, pdknsk <pdk...@gmail.com> wrote:
Just a short note on the patch, or rather the patch description: the autoritative source for the values is in sections 1.1 and 3.1 of the PDF. (Only the reverse value of 0.018 is mentioned, but 0.081 is obviously 0.018 * 4.5.)
Thanks for pointing this out. Commit message updated...
pdknsk
Sep 20, 2016, 6:27:46 AM9/20/16
to WebP Discussion
I notice you merged it already. Another step towards quality. (When you compare default WebP with the new pre4, it's impressive.) Just in time for Firefox adding (preliminary) WebP support.
A good opportunity to make either pre4 or pre8 default with a renamed switch, I think. I'd argue to go for pre4 (with pre8 being the fast* variant), but pre8 is good too.
* IMO WebP encoding is fast already, with any switch.
Pascal Massimino
Sep 20, 2016, 8:31:46 AM9/20/16
to WebP Discussion
Hi,
On Tue, Sep 20, 2016 at 12:27 PM, pdknsk <pdk...@gmail.com> wrote:
I notice you merged it already. Another step towards quality.
yes, the only point remaining was whether to go srgb+709 or 709+709, but it was a close tie-break. With small preference for the latter, so let's merge and iterate.
I expect work on speed next, so it can reasonably be made default without penalizing speed too much.
Maybe one idea would be the activate it automatically for method 4 and up.
Another idea would be activating pre4/pre8 depending on the image hints (PICTURE/PHOTO/DRAWING/...).
Not sure yet, but speeding things up can't be bad.
An SSE2 version of pre8 is right around the corner already [1]
(When you compare default WebP with the new pre4, it's impressive.) Just in time for Firefox adding (preliminary) WebP support.
indeed, good timing!
A good opportunity to make either pre4 or pre8 default with a renamed switch, I think. I'd argue to go for pre4 (with pre8 being the fast* variant), but pre8 is good too.* IMO WebP encoding is fast already, with any switch.
thanks!
here's where we stand right now, using [1]:
cwebp bryce_big.jpg -v
Time to encode picture: 3.146s
cwebp bryce_big.jpg -v -pre 8
Time to encode picture: 3.247s
cwebp bryce_big.jpg -v -pre 4
Time to encode picture: 4.475s
37% is not totally dramatic when encoding one-off for storage, but still a bit problematic for on-the-fly serving. 20% or less would be ideal.
skal/
pdknsk
Sep 30, 2016, 12:55:12 PM9/30/16
to WebP Discussion
Another idea would be activating pre4/pre8 depending on the image hints (PICTURE/PHOTO/DRAWING/...).
(Do people actually use the hints?)
Pascal Massimino
Oct 5, 2016, 2:47:43 AM10/5/16
to WebP Discussion
Hi,
On Fri, Sep 30, 2016 at 9:55 AM, pdknsk <pdk...@gmail.com> wrote:
Another idea would be activating pre4/pre8 depending on the image hints (PICTURE/PHOTO/DRAWING/...).(Do people actually use the hints?)
Not sure exactly, but at least the incoming Gimp 2.10 release has a 'Save as WebP' menu
that explicitly exposes Hints.
But, agreed, i'm not sure using 'hints' are the definitive answer here...
skal/
Pascal Massimino
Mar 23, 2018, 7:05:44 PM3/23/18
to WebP Discussion
Hi,
On Tue, Sep 20, 2016 at 2:31 PM, Pascal Massimino <pascal.m...@gmail.com> wrote:
Hi,On Tue, Sep 20, 2016 at 12:27 PM, pdknsk <pdk...@gmail.com> wrote:I notice you merged it already. Another step towards quality.yes, the only point remaining was whether to go srgb+709 or 709+709, but it was a close tie-break. With small preference for the latter, so let's merge and iterate.I expect work on speed next, so it can reasonably be made default without penalizing speed too much.Maybe one idea would be the activate it automatically for method 4 and up.Another idea would be activating pre4/pre8 depending on the image hints (PICTURE/PHOTO/DRAWING/...).Not sure yet, but speeding things up can't be bad.An SSE2 version of pre8 is right around the corner already [1](When you compare default WebP with the new pre4, it's impressive.) Just in time for Firefox adding (preliminary) WebP support.indeed, good timing!A good opportunity to make either pre4 or pre8 default with a renamed switch, I think. I'd argue to go for pre4 (with pre8 being the fast* variant), but pre8 is good too.* IMO WebP encoding is fast already, with any switch.thanks!here's where we stand right now, using [1]:cwebp bryce_big.jpg -vTime to encode picture: 3.146scwebp bryce_big.jpg -v -pre 8Time to encode picture: 3.247scwebp bryce_big.jpg -v -pre 4Time to encode picture: 4.475s
following up on this old thread: latest patch [1] sped up sharp-yuv quite a bit. It's now:
cwebp bryce_big.jpg -v -sharp_yuv
Time to encode picture: 3.852s
37% is not totally dramatic when encoding one-off for storage, but still a bit problematic for on-the-fly serving. 20% or less would be ideal.
we're getting there :)
skal/
Reply all
Reply to author
Forward
0 new messages