![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Hi, Gyrobo
You recent edits to WebP which involved changing its date format and its date format tag is reverted, since they were in violation of Wikipedia Manual of Style (dates and numbers), specifically section WP:DATERET. However, if you disagree with this reversion, I respect your right to proceed with D part of BRD (discussion).
Thanks, Fleet Command ( talk) 11:10, 2 October 2010 (UTC)
I'm afraid you are in error, Gyrobo.
First, You are wrong as to my addition of {{Use dmy dates}}
. DATERET says:
The date format chosen by the first major contributor in the early stages of an article should continue to be used ... Where an article has shown no clear sign of which format is used, the first person to insert a date is equivalent to "the first major contributor".
I am that person. Hence, the article should continue to use DMY dates. (Note that when I say "it was predominantly using DMY dates", it is in regard to you, not me. As always, please pay attention to the context of speech, or else you may get mislead.)
Second, this article has no lists. Hence, YMD dates should not be used. Even if it had list, YMD format should have been used as an internal format and had been masked with one of the two valid formats as explained in DATESNO.
Fleet Command ( talk) 05:02, 5 October 2010 (UTC)Which part of the sentence which I quoted from DATESNO you did not understand? I don't care about before me: Date format was inharmonious and I harmonized it according to DATESNO. When you changed the date format, a unified date format was perfectly established by me. And no, DATESNO recommends use YMD as an internal technical format for sorting and advises this format to be covered up with a DMY or MDY format via {{
sort|2008-11-01|November 1, 2008}}
and such templates.
Alright Gyrobo: For the last time, if you have a good reason to keep YMD format, present it. Otherwise, your explicit violation of a codified consensus (a Manual of Style) will not be tolerated and I'll be reverting your edit within the next 48 hours. (Any subsequent violation will be reported to administrators noticeboard as an act of edit warring.) Choose your words carefully, Gyrobo. Fleet Command ( talk) 19:31, 5 October 2010 (UTC)
I harmonized the date format into one of two allowed forms because I was perfectly allowed to do so, per WP:DATERET section of the Manual of Style.
However, you did two things that was no allowed by the manual: You used an unaccepted date format and you did so when the date format of the article was unified. As for the date format of the sources, we don't care about them in Wikipedia: Manual of Style does not require (or recommend) it. Moreover, you use the popularity of MDY format amongst the sources to sanction YMD? That's odd. Fleet Command ( talk) 02:41, 6 October 2010 (UTC)
Yes, I'm doing all of these because I am allowed to do so, per WP:DATESNO. I even quoted from DATESNO. But you are simply repeating your own opinion, without quoting any policy and without even mentioning why should DATESNO be violated. You mention a rule of YMD being recommended for lists but I don't see it anywhere.
Enough of this repetition! I'd love to comply to reason; but reason is absent here. I'm reinstating DMY and will not reply here anymore unless you have something really new or important to say. You are still more than welcome to call in a third opinion. Fleet Command ( talk) 19:16, 6 October 2010 (UTC)
“ | Year-initial numerical (YYYY-MM-DD) dates (e.g. 1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness. | ” |
“ | The date format chosen by the first major contributor in the early stages of an article should continue to be used, unless there is reason to change it based on strong national ties to the topic. | ” |
“ | If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic. | ” |
|
See my comment below; this template doesn't care for my formatting...— ⌘macwhiz ( talk) 03:35, 8 October 2010 (UTC) |
Gentlemen, first and foremost, I need to warn you that your discussion is becoming uncivil. I strongly suggest that you both step back and take a deep breath before you say something unproductive that you will regret.
You folks weren't terribly specific about what you wanted a third opinion on, so I'm going to give you a few opinions for the price of one. It appears as if there are several items of confusion in your discussion. I apologize that this is so long-winded, but I'd like to be sure I cover the bases here.
Okay, so here's what I think: This article had already established day-before-month as its date format, both in the body and in the citations. There was no consensus reached to change it on the talk page; indeed, I would hesitate to characterize this discussion as even approaching the concept of "consensus building." I hate to bring up WP:IDONTLIKEIT, but this discussion seems to be heading that way. Unless and until a clear consensus is formed here, the article, and its references, should continue to use day-before-month.
That said, I personally do think that ISO 8601 makes more sense in citations, and I would encourage Fleet to consider agreeing to using it in the citations. Mind you, I think it's ugly and a bit awkward to read, but it has two saving graces: It's an international standard, and for some reason a fair number of the citation template instructions state that you must use ISO 8601 with those templates—so using it reduces confusion, especially amongst the noobs. That's not a bad thing. Note, however, that this is not a statement that ISO 8601 should be used right now; there's no consensus yet, and I would expect to see a strong consensus here to override the inertial imposed by WP:DATERET. I suggest that the discussion continue in this vein: discuss why you think your preferred format is a good idea, without turning it into a pointing-at-rules contest.
Please remember that this is just an opinion, that I am an editor just like you and my opinion does not carry any special weight, and that my opinion is in no way binding upon you. If you don't like the opinion, you're welcome to try other dispute-resolution options. // ⌘macwhiz ( talk) 03:35, 8 October 2010 (UTC)
{{sort|2008-11-01|November 1, 2008}}
) least not to feed my readers with machine-optimized data! I don't take references for lists; they are references, not lists. All citation styles excluding
ISO 690 (including
APA style and
The Chicago Manual of Style) use either DMY or MDY dates. I also threat short lists inside a prose as I do with prose and use the same date format in them; it is akward to suddenly switch date style.{{Use mdy dates}}
.df=yes
parameter from the {{
Start date}} because the initial date for that infobox was in MDY. Earlier in the discussion, Macwhiz expressed concern that {{
Infobox file format}} recommended/mandated the use of DMY. I discovered, per
Template talk:Infobox file format/doc#Date format, that some editor had changed the date structure of that template without finding consensus. I have since changed it back. Because the initial date in the infobox here was in MDY, and because the infobox is also not prose, I thought it appropriate via DATERET to restore the original date format.In regards to Fleet's numbered points:
In documentation and in tables, if numerous dates occur, months may be abbreviated, and the day-month-year form, requiring no punctuation, may be neater (e.g., 5 Oct 2003). See also 10.40. For ISO style, see 9.37.
— Chicago Manual of Style, 16th Edition, paragraph 9.36
http://www.example.com
is immediately recognizable as an URL, or someone@example.com
is recognized as an email address. An abbreviated DMY contains spaces, upper case and lower case letters, all of which are prevalent elsewhere in the reference and prevent the date from being immediately noticeable. I'm actually working on a proposal for
WP:DATE that would recommend YMD for references, and there are also two reasons that may not be applicable here: YMD allows references to be easily copied across different language wikis without translation (which may be useful given the international nature of an image format), and YMD would make it much easier to create a tool/feature that sorted references by date (it is a list context, after all).I'll be frank: This discussion is getting tiresome and futile. Call me whenever you guys have something new to say, other than your personal preferences. Change the date format only you have a strong reason to do so. Until then, we have an explicit third opinion:
Until then, please don't do this:
Fleet Command ( talk) 10:03, 12 October 2010 (UTC)
importScript("User:Gyrobo/sortISODate.js");
It appears that I have been misjudging you, Gyrobo. It seems that have mistakenly taken one of your innocent comments as being extremely offensive. For that, I apologize. I hope you'll excuse my subsequent behavior, but honestly, it is impossible to act politely when one feels that 215 administrators are being indiscriminately offended. In addition to my apology, I am willing to extend two more tokens of good will to you:
It is imperative to understand that I perceive your constant changing of the article in your own favor as an act of edit warring. However, I am willing to refrain from immediately reporting you to the Noticeboard and give you one more chance to continue with dispute resolution process. Please do not let the number of your reverts to reach five. Please understand that Wikipedia is not a voting booth: Although Macwhiz and Waldir's personal opinion is in favor of YMD date style, this preference is against the codified consensus of hundreds of thousands of Wikipedians (i.e MOS policy); to violate this policy, more than just a couple of votes are needed: You need a very good reason.
As for my second token, I'm willing to offer you a way to cut the discussion short: There is one Administrator ESkog in Wikipedia. I hold great respect for him; everyone does: He is elected as an administrator without a single oppose vote! I suggest that we ask ESkog to enter the discussion and give his opinion. If ESkog's opinon was in favor of YMD, I'll stand down — immediately. But if his opinion was in favor of DMY, you have no obligation whatsoever to stand down unconditionally. How is that?
Fleet Command ( talk) 16:03, 13 October 2010 (UTC)
One last thing. Although I do understand that mentioning it here is perhaps not appropriate (as it may disturb the apologetic atmosphere) but I feel obliged to mention it: I still perceive your constant editing of article in your own favor edit-warring. As a Wikipedian sworn to serve Wikipedia dutifully, I warn you that should you repeat your act of edit warring, I will report you to the Noticeboard. If you think this is threatening and accusing, please do take note that I feel it is a "threatening/accusing" that is may duty (per Wikipedia policies) to commit. Please, please! Never be too quick to revert something in your own favor: It emits a very negative image of you. Fleet Command ( talk) 16:16, 13 October 2010 (UTC)
See, this is why WikiPedia is generally considered an unreliable source. No matter how much they talk about finding sources, it's largely written by people who'll spend all kinds of energy and effort arguing over something as insignificant as how to format dates. — Preceding unsigned comment added by 173.228.6.26 ( talk) 06:58, 14 May 2013 (UTC)
My edit adding a "See also" section that mentioned WebM, JPEG 2000 and JPEG XR was reverted as being too "emphatic," that having these formats buried in a list of bajillion formats is more appropriate, and that if I "disagree" I should comment here ( D part of BRD) because "my rights are respected." I have no interest in being emphatic or disagreeable, and I am the opposite of enthusiastic about the idea of editing a heavily trafficked article, and I have no interest in insisting by appealing or doing anything time consuming of that nature.
But, I would like to at least mention my reasoning for why I listed the particular formats as being relevant to the article. (What I'm about to say may be pretty obvious to some already, though.)
WebM - this is already mentioned in the lead paragraph by someone else, so no additional explanation on my part is necessary. Obviously relevant to the article.
JPEG successors JPEG 2000 and JPEG XR - Google's blog states that with WebP, it is interested in introducing a format that's better than JPEG. Therefore, naturally one would want to compare the two other prominent formats that also tried to supersede JPEG. In fact, that's exactly what Google did with JPEG 2000, in a comparative study titled "Comparative Study of WebP, JPEG and JPEG 2000," already used as a reference in the current version of the article.
As stated above, these are the reasons why I felt these formats were relevant and therefore deserving of mention. Having a forest of formats in a navbox does not compare. I generally prefer having things mentioned in prose rather than in a list, but a list was just a wikiwiki way to mention them. -- Bxj ( talk) 13:37, 3 October 2010 (UTC)
It's 1½ months later and the "See also" section mentions WebM, JPEG 2000 and JPEG XR. I have to say I hard time interpreting that as promotion. I personally believe JPEG 2000 has failed, and that anything Microsoft touches is poison, yet I don't mind them. It's odd though that plain JPEG — the only lossy image file format which has succeeded in the "market" so far – is not in the list. JöG ( talk) 20:55, 24 November 2010 (UTC)
Google claims this is an open format, but it fails to come close to meeting the definition of “open format” defined by the State of Massachusetts: Open format#Commonwealth of Massachusetts, namely being developed by an open group or coalition and being ratified/published by a standards body like ISO or IETF. In the interest of maintaining a NPOV, I believe that stating Google claims this to be an open format, or describing its status as debated (assuming good sources for that can be found) would be more accurate. Unless it is Wikipedia policy to consider all published, royalty-free formats “open,” in which case MFST .docx would be “open” as well (in fact, a stronger case for that can be made than for WebP as it actually was published by a standards body). -- X883 ( talk) 23:16, 7 February 2011 (UTC)
There doesn't seem to be much going on with WebP, and even on the WebP Home Page, under WebP support, it still refers to Chrome 9 as in the developer channel, when it has now been officially released as the stable version, indicating that the WebP home page isn't being look after - is this a sign that WebP is on the sidelines?
Yes, it is, there are new modes coming. SyP ( talk) 09:12, 15 February 2012 (UTC)
You can see the most recent changes at http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=shortlog - development looks to be pretty active. They may just not be updating their front page much. 76.119.235.42 ( talk) 05:48, 24 July 2012 (UTC)
There was a good description of the encoding mechanism on the mailing list [4]:
there's mainly three steps in the WebP encoder:
complexity (basically: how many bits are removed every time the decimation factor is raised one notch? That's the susceptibility slope). Then macroblocks are grouped in classes of equivalent susceptibility (these are the 'segments' in vp8 terminology) and a quantization factor is assigned to these segments. Macroblocks with high response to decimation factor will tend to blur quickly so we try to not raise the quantization step too much for these. Conversely, macroblocks with a lot signal and low susceptibility can sustain a higher QP. There's always going to be "something" left.
involved. In Step II, every macroblock is analysed again and each coding modes are tried. Should it be coded 4x4? 16x16? What is the distortion incurred? All modes are tried by default, and the PSNR is measured so that the best tradeoff between bit-cost and reconstruction quality is made. Still, during this phase, no encoding is actually done. We just record statistics about the coefficients distribution and the coding tokens that will be needed for the final coding. For evaluating the bit-cost, we use our best prior knowledge of the distribution, which may be off a little compared to what the final one will be.
tables that are best fit to the observed distribution of coding tokens. This is pretty much equivalent to the "optimized Huffman tables" one can find in JPEG. So, during this final assembly phase, the statistics collected during step II are finalized and written into the bitstream, followed by the actual coding of each macroblocks. There can be some "RD-opt" decisions being made. RD-opt stands for rate-distortion optimization. Namely, since the final probabilities are known, we can really compute the exact number of bits for each possible coding modes, along with the reconstruction distortion. And pick the best possible. Afterward, there's still few parameters that can be decided: filtering strength for each segments, etc. Note that you can loop several time on Step II (using the '-pass' option in cwebp), so that the bit-cost is refined several time until convergence. Comparatively, JPEG encoding has very few decisions to make. The freedom you have is around the quantization tables, the Huffman code optimization, and the "coring" of the coefficients (ie. how much you down-quantize them). The extra freedom in coding modes for VP8 allows better compression (but also means there's more modes to try out. Hence, it's slower).
SyP ( talk) 09:19, 15 February 2012 (UTC)
Not sure what the correct procedure is for dealing with this. It redirects to https://developers.google.com/speed/webp/ , which does not provide any information about pronunciation. -- 71.83.109.174 ( talk) 00:04, 24 March 2013 (UTC)
The article 'Support' section talks about client software that can read and display WebP images. It does not, however, talk about how many websites serve WebP images to their visitors. Does anyone have numbers and a reference about this second measure of format adoption? Thanks 140.180.189.23 ( talk) 01:54, 25 August 2013 (UTC)
Support section claims IrfanView "natively support WebP". However, I get "Unknown file format or file not found" error when trying to view a WebP image. It would be good to know what was the first version to support WebP, since my InfanView does not. 82.141.126.42 ( talk) 16:22, 29 June 2014 (UTC)
This is all very interesting, but means nothing to the "layman" without large image examples. Can someone please post a large image, greater than 10 megapixels, uncompressed in any way, and then compressed using this algorithm? It would help readers if they could see for themselves what difference "lossy" compression makes. Perhaps none when viewed on screen, but a lot when downloaded and viewed expanded in Photoshop. Nick Beeson ( talk) 12:36, 22 July 2014 (UTC)
Seconded. Or thirded, actually.
Zezen ( talk) 05:50, 31 July 2020 (UTC)
On the reply of user -- User:Offnfopt of 2 July 15 I don't know what you're confirmed and to whom.. anyway, described Google services (blogger and photos) doesn't support natively webp at the moment. The key here are "Native support" and "original image" means that the services will accept WebP upload and does not transform the file and its size. Thus, Photos does not provide a shareable Permanent link to original, not modified Webp file; "rw" prefix works only through CDN, not known for majority, and it isn't officially documented anywhere and not points to original file. Blogger, too, modify webp image to JPEG, and then can provide webp via rw, but bigger in size comparing to original which in principle goes against webp idea - smaller size in good quality. Bottom line, the ability of these services to accept uploading for Webp files, doesn't mean the Native support of webp simply because these services DO transform the original file to another codec, changing its file size. So, please, read the test case in the source link for this item or better, do yourself similar tests.
for whom it is "common practice"? flickr maybe? does flickr re-convert JPEG to something, or it just provide diff sizes + link to original?..and what file type returns those who re-encode JPEG? i think jpeg, that is why they can claim "native support". In fact, things are easy as one, two, three. If one has uploaded a webp the expectation would be to get output to webp but not anything else, say jpeg following magic "common practice". Just the ability to uload webp and get jpg - it isn't support for webp. Native support is webp in input and webp in output + a link to original image, if any cropping supported. Here is the challange for the experts: original webp file, from official WebP dev page: http://www.gstatic.com/webp/gallery/4.webp , 1024 wide, size 172,8 Kb, Question, where one can see a link to .blogspot source for this image which return the same picture in same width and size? -Size can not be bigger, otherwise the conception of WebP is loosing (and link please to official documentation for using rw in google services) AlexanderTheo ( talk) 18:08, 3 July 2015 (UTC)
Unlike what the article states in its restrictions section, lossless WebP works exclusively with 8-bit ARGB color space. It's called VP8L and not VP8. The information in the article is probably outdated. [5] [6] I added a sentence mentioning this but unless I'm wrong, the whole section is now pointless and confusing since according to Google, lossless YUV420 doesn't even exist.
93.174.36.206 ( talk) 14:10, 3 February 2016 (UTC)
Oh, thank you! That answered the question that was keeping me awake in the middle of the night! However, I'm still not sure why my lossless, 8bpcc HEIF images are darker than their lossless WebP sources.
Noah S. ( talk) 09:57, 30 May 2021 (UTC)
Hello fellow Wikipedians,
I have just added archive links to one external link on
WebP. Please take a moment to review
my edit. You may add {{
cbignore}}
after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether, but should be used as a last resort. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 14:38, 31 March 2016 (UTC)
This article could use more about the intellectual property implications of WebP. Seems like it's the same as WebM, but it would be nice to explicitly state that. See this Google product manager. [7] -- Fuzheado | Talk 12:26, 6 October 2018 (UTC)
Quote: "Amongst graphics software, Picasa (from version 3.9),[25] PhotoLine,[26] Pixelmator,[27] ImageMagick,[28] XnView,[29] IrfanView,[30] GDAL,[31] Aseprite[32] and GIMP (from version 2.10)[33] all natively support WebP."
This is too broad of a statement. For instance, XnViewMP can't display the animated WebP image I created using "img2webp.exe" (Google's own tool). ➧ datumizer ☎ 16:34, 28 February 2019 (UTC)
What are the size (often called resolution) of the WebP images? PNG have very very big limits for example (I think 4 byte for width and 4 byte for height, so 32-bit each, but usually only 31 bits are allowed to be used, just in case they are used as signed integers on 32-bit architectures). Still PNG can easily work with enormous images. (I do use sometimes 70000x70000 pixels images - so about 16-17 bits for width and same for height, far from the limits, few GB in size before lossless PNG compression or colormap indexing, and it can do more even in common software packages - GIMP, ImageMagic, NetPBM, etc.). I assume I will start to have resource issues only when reaching terabyte level sizes most of the time (not all software reads whole image to the RAM, which allow it to do crazy big sizes pretty well). 2A02:168:F609:0:C38D:4039:F7BF:4885 ( talk) 09:22, 16 November 2019 (UTC)
It's jargon laced, as if the article was written by google's programmers with help from the advertising dept. And it's full of lazy links.
It's outdated because it's still in the newbie stage: "OH BOY! Look what we are about to make!" Besides reading like an ad, nine years later, all these nice but failed pipe-dream features are still described as eminent, like next week. Quoting manufacturers' (and their media outlets') claims is NOT appropriate here! Just the facts please.
I suggest some of the following changes, and more:
WebP is an image format employing both lossy[6] and lossless compression. It is currently developed by Google,
based on technology acquired with the purchase of On2 Technologies.[7]
As a derivative of the VP8 video format, it is a sister project to the WebM multimedia container format.[8]WebP-related software is released under a BSD free software license.[9]The format was first announced on September 30 in 2010 as a new open standard for lossy compressed true-color graphics on the web, producing smaller files of comparable image quality to the older JPEG scheme.[10]
On October 3, 2011, Google announced WebP support for animation, ICC profile, XMP metadata, and tiling (compositing very large images from maximum 16384×16384 tiles).[11]
On November 18, 2011, Google began to experiment with lossless compression and support for transparency (alpha channel) in both lossless and lossy modes;support has been enabled by defaultin libwebp 0.2.0 (August 16, 2012).[12][13] According to Google's measurements, a conversion from PNG to WebP results in a 45% reduction in file size when starting with PNGs found on the web, and a 28% reduction compared to PNGs that are recompressed withpngcrush and PNGOUT.[14]certain compression utilities such as PNGOUT and pngcrush.In a comparison made between GIF, APNG and WebP, it was shown, however, that APNG kept lower file size while keeping at least equal quality.[15]
Regarding "both lossy[6] and lossless compression," it's not clear if that is a selectable choice, or if the resulting file is always lossy, etc. Can part of the image be lossy, part not, such as a computer generated 16-color pie chart imposed on a 6.7 Million color (24 BitsPerPixel) lossy face or forest? ...And what was the test image they were using?
(I am presuming all the future features have failed, and it's not due to wikipedia's article updating failures.)
--
2602:306:CFCE:1EE0:305E:100D:36A4:2349 (
talk)
20:15, 1 March 2020 (UTC) Just Saying
Perhaps there could be a section concerning WebP's particular vulnerability to generation loss - both about comparisons that have been made (ex: worse than JPEG) and the technical reasons for it. 198.84.252.4 ( talk) 18:41, 20 April 2020 (UTC)
In several places, image reduction sizes are expressed in this article as a percentage. However, there are two main definitions for a "percentage reduction". The article does not use clear language (or an explicit definition) to make it clear which definition is being used.
Consider a file that is reduced to 1/4 of its original size. This could be called a "25% reduction", meaning that its new size is 25% of the original size. But it could just a well be called a "75% reduction", meaning that 3/4 of the original size has been eliminated by the reduction. If anyone knows for certain which definition is used, please edit the article to make the definition explicit, or reply here and I will edit the article. David Spector ( talk) 14:22, 28 May 2020 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Hi, Gyrobo
You recent edits to WebP which involved changing its date format and its date format tag is reverted, since they were in violation of Wikipedia Manual of Style (dates and numbers), specifically section WP:DATERET. However, if you disagree with this reversion, I respect your right to proceed with D part of BRD (discussion).
Thanks, Fleet Command ( talk) 11:10, 2 October 2010 (UTC)
I'm afraid you are in error, Gyrobo.
First, You are wrong as to my addition of {{Use dmy dates}}
. DATERET says:
The date format chosen by the first major contributor in the early stages of an article should continue to be used ... Where an article has shown no clear sign of which format is used, the first person to insert a date is equivalent to "the first major contributor".
I am that person. Hence, the article should continue to use DMY dates. (Note that when I say "it was predominantly using DMY dates", it is in regard to you, not me. As always, please pay attention to the context of speech, or else you may get mislead.)
Second, this article has no lists. Hence, YMD dates should not be used. Even if it had list, YMD format should have been used as an internal format and had been masked with one of the two valid formats as explained in DATESNO.
Fleet Command ( talk) 05:02, 5 October 2010 (UTC)Which part of the sentence which I quoted from DATESNO you did not understand? I don't care about before me: Date format was inharmonious and I harmonized it according to DATESNO. When you changed the date format, a unified date format was perfectly established by me. And no, DATESNO recommends use YMD as an internal technical format for sorting and advises this format to be covered up with a DMY or MDY format via {{
sort|2008-11-01|November 1, 2008}}
and such templates.
Alright Gyrobo: For the last time, if you have a good reason to keep YMD format, present it. Otherwise, your explicit violation of a codified consensus (a Manual of Style) will not be tolerated and I'll be reverting your edit within the next 48 hours. (Any subsequent violation will be reported to administrators noticeboard as an act of edit warring.) Choose your words carefully, Gyrobo. Fleet Command ( talk) 19:31, 5 October 2010 (UTC)
I harmonized the date format into one of two allowed forms because I was perfectly allowed to do so, per WP:DATERET section of the Manual of Style.
However, you did two things that was no allowed by the manual: You used an unaccepted date format and you did so when the date format of the article was unified. As for the date format of the sources, we don't care about them in Wikipedia: Manual of Style does not require (or recommend) it. Moreover, you use the popularity of MDY format amongst the sources to sanction YMD? That's odd. Fleet Command ( talk) 02:41, 6 October 2010 (UTC)
Yes, I'm doing all of these because I am allowed to do so, per WP:DATESNO. I even quoted from DATESNO. But you are simply repeating your own opinion, without quoting any policy and without even mentioning why should DATESNO be violated. You mention a rule of YMD being recommended for lists but I don't see it anywhere.
Enough of this repetition! I'd love to comply to reason; but reason is absent here. I'm reinstating DMY and will not reply here anymore unless you have something really new or important to say. You are still more than welcome to call in a third opinion. Fleet Command ( talk) 19:16, 6 October 2010 (UTC)
“ | Year-initial numerical (YYYY-MM-DD) dates (e.g. 1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness. | ” |
“ | The date format chosen by the first major contributor in the early stages of an article should continue to be used, unless there is reason to change it based on strong national ties to the topic. | ” |
“ | If an article has evolved using predominantly one format, the whole article should conform to it, unless there are reasons for changing it based on strong national ties to the topic. | ” |
|
See my comment below; this template doesn't care for my formatting...— ⌘macwhiz ( talk) 03:35, 8 October 2010 (UTC) |
Gentlemen, first and foremost, I need to warn you that your discussion is becoming uncivil. I strongly suggest that you both step back and take a deep breath before you say something unproductive that you will regret.
You folks weren't terribly specific about what you wanted a third opinion on, so I'm going to give you a few opinions for the price of one. It appears as if there are several items of confusion in your discussion. I apologize that this is so long-winded, but I'd like to be sure I cover the bases here.
Okay, so here's what I think: This article had already established day-before-month as its date format, both in the body and in the citations. There was no consensus reached to change it on the talk page; indeed, I would hesitate to characterize this discussion as even approaching the concept of "consensus building." I hate to bring up WP:IDONTLIKEIT, but this discussion seems to be heading that way. Unless and until a clear consensus is formed here, the article, and its references, should continue to use day-before-month.
That said, I personally do think that ISO 8601 makes more sense in citations, and I would encourage Fleet to consider agreeing to using it in the citations. Mind you, I think it's ugly and a bit awkward to read, but it has two saving graces: It's an international standard, and for some reason a fair number of the citation template instructions state that you must use ISO 8601 with those templates—so using it reduces confusion, especially amongst the noobs. That's not a bad thing. Note, however, that this is not a statement that ISO 8601 should be used right now; there's no consensus yet, and I would expect to see a strong consensus here to override the inertial imposed by WP:DATERET. I suggest that the discussion continue in this vein: discuss why you think your preferred format is a good idea, without turning it into a pointing-at-rules contest.
Please remember that this is just an opinion, that I am an editor just like you and my opinion does not carry any special weight, and that my opinion is in no way binding upon you. If you don't like the opinion, you're welcome to try other dispute-resolution options. // ⌘macwhiz ( talk) 03:35, 8 October 2010 (UTC)
{{sort|2008-11-01|November 1, 2008}}
) least not to feed my readers with machine-optimized data! I don't take references for lists; they are references, not lists. All citation styles excluding
ISO 690 (including
APA style and
The Chicago Manual of Style) use either DMY or MDY dates. I also threat short lists inside a prose as I do with prose and use the same date format in them; it is akward to suddenly switch date style.{{Use mdy dates}}
.df=yes
parameter from the {{
Start date}} because the initial date for that infobox was in MDY. Earlier in the discussion, Macwhiz expressed concern that {{
Infobox file format}} recommended/mandated the use of DMY. I discovered, per
Template talk:Infobox file format/doc#Date format, that some editor had changed the date structure of that template without finding consensus. I have since changed it back. Because the initial date in the infobox here was in MDY, and because the infobox is also not prose, I thought it appropriate via DATERET to restore the original date format.In regards to Fleet's numbered points:
In documentation and in tables, if numerous dates occur, months may be abbreviated, and the day-month-year form, requiring no punctuation, may be neater (e.g., 5 Oct 2003). See also 10.40. For ISO style, see 9.37.
— Chicago Manual of Style, 16th Edition, paragraph 9.36
http://www.example.com
is immediately recognizable as an URL, or someone@example.com
is recognized as an email address. An abbreviated DMY contains spaces, upper case and lower case letters, all of which are prevalent elsewhere in the reference and prevent the date from being immediately noticeable. I'm actually working on a proposal for
WP:DATE that would recommend YMD for references, and there are also two reasons that may not be applicable here: YMD allows references to be easily copied across different language wikis without translation (which may be useful given the international nature of an image format), and YMD would make it much easier to create a tool/feature that sorted references by date (it is a list context, after all).I'll be frank: This discussion is getting tiresome and futile. Call me whenever you guys have something new to say, other than your personal preferences. Change the date format only you have a strong reason to do so. Until then, we have an explicit third opinion:
Until then, please don't do this:
Fleet Command ( talk) 10:03, 12 October 2010 (UTC)
importScript("User:Gyrobo/sortISODate.js");
It appears that I have been misjudging you, Gyrobo. It seems that have mistakenly taken one of your innocent comments as being extremely offensive. For that, I apologize. I hope you'll excuse my subsequent behavior, but honestly, it is impossible to act politely when one feels that 215 administrators are being indiscriminately offended. In addition to my apology, I am willing to extend two more tokens of good will to you:
It is imperative to understand that I perceive your constant changing of the article in your own favor as an act of edit warring. However, I am willing to refrain from immediately reporting you to the Noticeboard and give you one more chance to continue with dispute resolution process. Please do not let the number of your reverts to reach five. Please understand that Wikipedia is not a voting booth: Although Macwhiz and Waldir's personal opinion is in favor of YMD date style, this preference is against the codified consensus of hundreds of thousands of Wikipedians (i.e MOS policy); to violate this policy, more than just a couple of votes are needed: You need a very good reason.
As for my second token, I'm willing to offer you a way to cut the discussion short: There is one Administrator ESkog in Wikipedia. I hold great respect for him; everyone does: He is elected as an administrator without a single oppose vote! I suggest that we ask ESkog to enter the discussion and give his opinion. If ESkog's opinon was in favor of YMD, I'll stand down — immediately. But if his opinion was in favor of DMY, you have no obligation whatsoever to stand down unconditionally. How is that?
Fleet Command ( talk) 16:03, 13 October 2010 (UTC)
One last thing. Although I do understand that mentioning it here is perhaps not appropriate (as it may disturb the apologetic atmosphere) but I feel obliged to mention it: I still perceive your constant editing of article in your own favor edit-warring. As a Wikipedian sworn to serve Wikipedia dutifully, I warn you that should you repeat your act of edit warring, I will report you to the Noticeboard. If you think this is threatening and accusing, please do take note that I feel it is a "threatening/accusing" that is may duty (per Wikipedia policies) to commit. Please, please! Never be too quick to revert something in your own favor: It emits a very negative image of you. Fleet Command ( talk) 16:16, 13 October 2010 (UTC)
See, this is why WikiPedia is generally considered an unreliable source. No matter how much they talk about finding sources, it's largely written by people who'll spend all kinds of energy and effort arguing over something as insignificant as how to format dates. — Preceding unsigned comment added by 173.228.6.26 ( talk) 06:58, 14 May 2013 (UTC)
My edit adding a "See also" section that mentioned WebM, JPEG 2000 and JPEG XR was reverted as being too "emphatic," that having these formats buried in a list of bajillion formats is more appropriate, and that if I "disagree" I should comment here ( D part of BRD) because "my rights are respected." I have no interest in being emphatic or disagreeable, and I am the opposite of enthusiastic about the idea of editing a heavily trafficked article, and I have no interest in insisting by appealing or doing anything time consuming of that nature.
But, I would like to at least mention my reasoning for why I listed the particular formats as being relevant to the article. (What I'm about to say may be pretty obvious to some already, though.)
WebM - this is already mentioned in the lead paragraph by someone else, so no additional explanation on my part is necessary. Obviously relevant to the article.
JPEG successors JPEG 2000 and JPEG XR - Google's blog states that with WebP, it is interested in introducing a format that's better than JPEG. Therefore, naturally one would want to compare the two other prominent formats that also tried to supersede JPEG. In fact, that's exactly what Google did with JPEG 2000, in a comparative study titled "Comparative Study of WebP, JPEG and JPEG 2000," already used as a reference in the current version of the article.
As stated above, these are the reasons why I felt these formats were relevant and therefore deserving of mention. Having a forest of formats in a navbox does not compare. I generally prefer having things mentioned in prose rather than in a list, but a list was just a wikiwiki way to mention them. -- Bxj ( talk) 13:37, 3 October 2010 (UTC)
It's 1½ months later and the "See also" section mentions WebM, JPEG 2000 and JPEG XR. I have to say I hard time interpreting that as promotion. I personally believe JPEG 2000 has failed, and that anything Microsoft touches is poison, yet I don't mind them. It's odd though that plain JPEG — the only lossy image file format which has succeeded in the "market" so far – is not in the list. JöG ( talk) 20:55, 24 November 2010 (UTC)
Google claims this is an open format, but it fails to come close to meeting the definition of “open format” defined by the State of Massachusetts: Open format#Commonwealth of Massachusetts, namely being developed by an open group or coalition and being ratified/published by a standards body like ISO or IETF. In the interest of maintaining a NPOV, I believe that stating Google claims this to be an open format, or describing its status as debated (assuming good sources for that can be found) would be more accurate. Unless it is Wikipedia policy to consider all published, royalty-free formats “open,” in which case MFST .docx would be “open” as well (in fact, a stronger case for that can be made than for WebP as it actually was published by a standards body). -- X883 ( talk) 23:16, 7 February 2011 (UTC)
There doesn't seem to be much going on with WebP, and even on the WebP Home Page, under WebP support, it still refers to Chrome 9 as in the developer channel, when it has now been officially released as the stable version, indicating that the WebP home page isn't being look after - is this a sign that WebP is on the sidelines?
Yes, it is, there are new modes coming. SyP ( talk) 09:12, 15 February 2012 (UTC)
You can see the most recent changes at http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=shortlog - development looks to be pretty active. They may just not be updating their front page much. 76.119.235.42 ( talk) 05:48, 24 July 2012 (UTC)
There was a good description of the encoding mechanism on the mailing list [4]:
there's mainly three steps in the WebP encoder:
complexity (basically: how many bits are removed every time the decimation factor is raised one notch? That's the susceptibility slope). Then macroblocks are grouped in classes of equivalent susceptibility (these are the 'segments' in vp8 terminology) and a quantization factor is assigned to these segments. Macroblocks with high response to decimation factor will tend to blur quickly so we try to not raise the quantization step too much for these. Conversely, macroblocks with a lot signal and low susceptibility can sustain a higher QP. There's always going to be "something" left.
involved. In Step II, every macroblock is analysed again and each coding modes are tried. Should it be coded 4x4? 16x16? What is the distortion incurred? All modes are tried by default, and the PSNR is measured so that the best tradeoff between bit-cost and reconstruction quality is made. Still, during this phase, no encoding is actually done. We just record statistics about the coefficients distribution and the coding tokens that will be needed for the final coding. For evaluating the bit-cost, we use our best prior knowledge of the distribution, which may be off a little compared to what the final one will be.
tables that are best fit to the observed distribution of coding tokens. This is pretty much equivalent to the "optimized Huffman tables" one can find in JPEG. So, during this final assembly phase, the statistics collected during step II are finalized and written into the bitstream, followed by the actual coding of each macroblocks. There can be some "RD-opt" decisions being made. RD-opt stands for rate-distortion optimization. Namely, since the final probabilities are known, we can really compute the exact number of bits for each possible coding modes, along with the reconstruction distortion. And pick the best possible. Afterward, there's still few parameters that can be decided: filtering strength for each segments, etc. Note that you can loop several time on Step II (using the '-pass' option in cwebp), so that the bit-cost is refined several time until convergence. Comparatively, JPEG encoding has very few decisions to make. The freedom you have is around the quantization tables, the Huffman code optimization, and the "coring" of the coefficients (ie. how much you down-quantize them). The extra freedom in coding modes for VP8 allows better compression (but also means there's more modes to try out. Hence, it's slower).
SyP ( talk) 09:19, 15 February 2012 (UTC)
Not sure what the correct procedure is for dealing with this. It redirects to https://developers.google.com/speed/webp/ , which does not provide any information about pronunciation. -- 71.83.109.174 ( talk) 00:04, 24 March 2013 (UTC)
The article 'Support' section talks about client software that can read and display WebP images. It does not, however, talk about how many websites serve WebP images to their visitors. Does anyone have numbers and a reference about this second measure of format adoption? Thanks 140.180.189.23 ( talk) 01:54, 25 August 2013 (UTC)
Support section claims IrfanView "natively support WebP". However, I get "Unknown file format or file not found" error when trying to view a WebP image. It would be good to know what was the first version to support WebP, since my InfanView does not. 82.141.126.42 ( talk) 16:22, 29 June 2014 (UTC)
This is all very interesting, but means nothing to the "layman" without large image examples. Can someone please post a large image, greater than 10 megapixels, uncompressed in any way, and then compressed using this algorithm? It would help readers if they could see for themselves what difference "lossy" compression makes. Perhaps none when viewed on screen, but a lot when downloaded and viewed expanded in Photoshop. Nick Beeson ( talk) 12:36, 22 July 2014 (UTC)
Seconded. Or thirded, actually.
Zezen ( talk) 05:50, 31 July 2020 (UTC)
On the reply of user -- User:Offnfopt of 2 July 15 I don't know what you're confirmed and to whom.. anyway, described Google services (blogger and photos) doesn't support natively webp at the moment. The key here are "Native support" and "original image" means that the services will accept WebP upload and does not transform the file and its size. Thus, Photos does not provide a shareable Permanent link to original, not modified Webp file; "rw" prefix works only through CDN, not known for majority, and it isn't officially documented anywhere and not points to original file. Blogger, too, modify webp image to JPEG, and then can provide webp via rw, but bigger in size comparing to original which in principle goes against webp idea - smaller size in good quality. Bottom line, the ability of these services to accept uploading for Webp files, doesn't mean the Native support of webp simply because these services DO transform the original file to another codec, changing its file size. So, please, read the test case in the source link for this item or better, do yourself similar tests.
for whom it is "common practice"? flickr maybe? does flickr re-convert JPEG to something, or it just provide diff sizes + link to original?..and what file type returns those who re-encode JPEG? i think jpeg, that is why they can claim "native support". In fact, things are easy as one, two, three. If one has uploaded a webp the expectation would be to get output to webp but not anything else, say jpeg following magic "common practice". Just the ability to uload webp and get jpg - it isn't support for webp. Native support is webp in input and webp in output + a link to original image, if any cropping supported. Here is the challange for the experts: original webp file, from official WebP dev page: http://www.gstatic.com/webp/gallery/4.webp , 1024 wide, size 172,8 Kb, Question, where one can see a link to .blogspot source for this image which return the same picture in same width and size? -Size can not be bigger, otherwise the conception of WebP is loosing (and link please to official documentation for using rw in google services) AlexanderTheo ( talk) 18:08, 3 July 2015 (UTC)
Unlike what the article states in its restrictions section, lossless WebP works exclusively with 8-bit ARGB color space. It's called VP8L and not VP8. The information in the article is probably outdated. [5] [6] I added a sentence mentioning this but unless I'm wrong, the whole section is now pointless and confusing since according to Google, lossless YUV420 doesn't even exist.
93.174.36.206 ( talk) 14:10, 3 February 2016 (UTC)
Oh, thank you! That answered the question that was keeping me awake in the middle of the night! However, I'm still not sure why my lossless, 8bpcc HEIF images are darker than their lossless WebP sources.
Noah S. ( talk) 09:57, 30 May 2021 (UTC)
Hello fellow Wikipedians,
I have just added archive links to one external link on
WebP. Please take a moment to review
my edit. You may add {{
cbignore}}
after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether, but should be used as a last resort. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 14:38, 31 March 2016 (UTC)
This article could use more about the intellectual property implications of WebP. Seems like it's the same as WebM, but it would be nice to explicitly state that. See this Google product manager. [7] -- Fuzheado | Talk 12:26, 6 October 2018 (UTC)
Quote: "Amongst graphics software, Picasa (from version 3.9),[25] PhotoLine,[26] Pixelmator,[27] ImageMagick,[28] XnView,[29] IrfanView,[30] GDAL,[31] Aseprite[32] and GIMP (from version 2.10)[33] all natively support WebP."
This is too broad of a statement. For instance, XnViewMP can't display the animated WebP image I created using "img2webp.exe" (Google's own tool). ➧ datumizer ☎ 16:34, 28 February 2019 (UTC)
What are the size (often called resolution) of the WebP images? PNG have very very big limits for example (I think 4 byte for width and 4 byte for height, so 32-bit each, but usually only 31 bits are allowed to be used, just in case they are used as signed integers on 32-bit architectures). Still PNG can easily work with enormous images. (I do use sometimes 70000x70000 pixels images - so about 16-17 bits for width and same for height, far from the limits, few GB in size before lossless PNG compression or colormap indexing, and it can do more even in common software packages - GIMP, ImageMagic, NetPBM, etc.). I assume I will start to have resource issues only when reaching terabyte level sizes most of the time (not all software reads whole image to the RAM, which allow it to do crazy big sizes pretty well). 2A02:168:F609:0:C38D:4039:F7BF:4885 ( talk) 09:22, 16 November 2019 (UTC)
It's jargon laced, as if the article was written by google's programmers with help from the advertising dept. And it's full of lazy links.
It's outdated because it's still in the newbie stage: "OH BOY! Look what we are about to make!" Besides reading like an ad, nine years later, all these nice but failed pipe-dream features are still described as eminent, like next week. Quoting manufacturers' (and their media outlets') claims is NOT appropriate here! Just the facts please.
I suggest some of the following changes, and more:
WebP is an image format employing both lossy[6] and lossless compression. It is currently developed by Google,
based on technology acquired with the purchase of On2 Technologies.[7]
As a derivative of the VP8 video format, it is a sister project to the WebM multimedia container format.[8]WebP-related software is released under a BSD free software license.[9]The format was first announced on September 30 in 2010 as a new open standard for lossy compressed true-color graphics on the web, producing smaller files of comparable image quality to the older JPEG scheme.[10]
On October 3, 2011, Google announced WebP support for animation, ICC profile, XMP metadata, and tiling (compositing very large images from maximum 16384×16384 tiles).[11]
On November 18, 2011, Google began to experiment with lossless compression and support for transparency (alpha channel) in both lossless and lossy modes;support has been enabled by defaultin libwebp 0.2.0 (August 16, 2012).[12][13] According to Google's measurements, a conversion from PNG to WebP results in a 45% reduction in file size when starting with PNGs found on the web, and a 28% reduction compared to PNGs that are recompressed withpngcrush and PNGOUT.[14]certain compression utilities such as PNGOUT and pngcrush.In a comparison made between GIF, APNG and WebP, it was shown, however, that APNG kept lower file size while keeping at least equal quality.[15]
Regarding "both lossy[6] and lossless compression," it's not clear if that is a selectable choice, or if the resulting file is always lossy, etc. Can part of the image be lossy, part not, such as a computer generated 16-color pie chart imposed on a 6.7 Million color (24 BitsPerPixel) lossy face or forest? ...And what was the test image they were using?
(I am presuming all the future features have failed, and it's not due to wikipedia's article updating failures.)
--
2602:306:CFCE:1EE0:305E:100D:36A4:2349 (
talk)
20:15, 1 March 2020 (UTC) Just Saying
Perhaps there could be a section concerning WebP's particular vulnerability to generation loss - both about comparisons that have been made (ex: worse than JPEG) and the technical reasons for it. 198.84.252.4 ( talk) 18:41, 20 April 2020 (UTC)
In several places, image reduction sizes are expressed in this article as a percentage. However, there are two main definitions for a "percentage reduction". The article does not use clear language (or an explicit definition) to make it clear which definition is being used.
Consider a file that is reduced to 1/4 of its original size. This could be called a "25% reduction", meaning that its new size is 25% of the original size. But it could just a well be called a "75% reduction", meaning that 3/4 of the original size has been eliminated by the reduction. If anyone knows for certain which definition is used, please edit the article to make the definition explicit, or reply here and I will edit the article. David Spector ( talk) 14:22, 28 May 2020 (UTC)