Jump to content

Talk:WebP/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Date format

Moved from User talk:Gyrobo/Archive 2#Reversion of your recent edits to WebP per Wikipedia:Manual of Style (dates and numbers)

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 believe very strongly that the dating format of the document should be changed to an ISO 8601 YYYY-MM-DD structure. WP:DATERET states that if an article has "evolved using predominantly one format" that format should continue to be used. But before I changed the date format, there were only two sources that had dates on them. I would hardly call two sources predominant. And from an aesthetic standpoint, I would also like to change the date structure to make all dates a consistent length, and to make it consistent with the WebM article.
--Gyrobo (talk) 13:46, 2 October 2010 (UTC)
Well, when I added {{Use dmy dates}} it was predominantly using DMY dates. So, if you didn't change them to YMD, someone else must have done so and that someone else had violated DATERET. In addition, according to WP:DATESNO, ISO 8601 is not an acceptable date style for Wikipedia. Acceptable date formats are only one of the two forms of day before month (DMY) and month before day (MDY). Hence, I am afraid I think there is enough codified consensus (policy) to sanction DMY dates. Fleet Command (talk) 05:28, 3 October 2010 (UTC)
DATESNO forbids ISO dates in prose, but recommends it as a tool of concision for lists, which is what references are. And I was indeed the editor who changed the date template to YMD, in this edit, for that exact reason. And I dispute that DMY was the predominant format at the time you added {{Use dmy dates}}. The edit prior to that clearly shows a melange of date formats, including ISO 8601.
--Gyrobo (talk) 14:26, 3 October 2010 (UTC)
Where WP:DATESNO says year-initial dates "may be useful in lists and tables" I would assume it's talking about lists and tables as part of the article rather than the references at the end. After all, any particular date format used in references is no more "useful" in one article than it would be in any other. Miremare 16:47, 3 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)
Regrettably, you are the one in error. A variety of date formats was in use prior to your first edit to this article. Secondly, a list of references is a list; specifically, an ordered list. Whether you consider it semantically part of the article or an addendum to it, it is still a list and should be treated as such to improve readability.
--Gyrobo (talk) 14:29, 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)

Please do not threaten me. I'm trying very hard to explain my position: It very much does matter what was written in this article before your edits. Prior to your editing, YMD, DMY, and MDY were all in use. When you "harmonized" the post, you unilaterally decided which format was acceptable, without discussion. The fact is that of the (currently) eleven sources, four use MDY, five omit dates, and only one uses DMY notation. A plurality of sources, as well as the WebM article, use MDY. And Google, the company which maintains this format, use MDY in their documentation. The usage of DMY is inappropriate in this article.
--Gyrobo (talk) 20:03, 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)

I'm not conflating YMD and MDY, there are two separate issues here. Firstly, I contest your assertion that YMD is unacceptable. YMD should not be used within prose, but references are a list context (where they are allowed). Secondly, I contest that the date format of the article was "unified" or "harmonized". You single-handedly decided on a date format without taking into account the formatting of the sources, or of related articles, and without a discussion—and once your preferred format was in place you promptly declared that consensus had already been reached because the date formats were consistent (See Catch-22). Nobody owns this article. I say that the use of DMY is completely inappropriate in this article, given the above reasons.
--Gyrobo (talk) 14:12, 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)

From WP:DATESNO:
As I've said, YMD does not violate DATESNO. And to reiterate one of my earlier points, the formatting of the sources is indeed important, per WP:DATERET:
The topic is a file format created by Google, a company which has used MDY notation in press releases pertaining to WebP. I maintain that usage of DMY in this article is wholly improper. If you want to seek a third opinion, you are free to do so. Your continued input is very important, though I resent your rash effort to terminate the discussion before consensus has been reached.
--Gyrobo (talk) 21:58, 6 October 2010 (UTC)
FIRST:
That's what I did: I started evolving it using DMY. It should not be changed unless there are reasons for changing it based on strong national ties.
 
SECOND: This article is not a list. Especially, it is not a "long list". For an example of a list, in which YMD may be used, see History of Mozilla Firefox#Release history
Fleet Command (talk) 03:14, 7 October 2010 (UTC)
And wait a second! If your problem was use of YMD only in citations, why did you changed the {{Use dmy dates}} into {{Use ymd dates}} template? Fleet Command (talk) 03:45, 7 October 2010 (UTC)
  • "If an article has evolved..."
This article is less than a week old. At the time you changed the format to DMY, there was no predominant format, and the use of DMY was contested (by me) within six hours. I would hardly call this adequate evolution, or consensus.
  • "...strong national ties."
As I've said, Google, the company responsible for creating and maintaining WebP, does not use DMY in its official documentation of this format. It is more closely tied to MDY.
  • "This article is not a list."
At no point did I call the article itself a list; I called the references section a list, which is the only place I have advocated the use of YMD. I'm going to request a third opinion, because you have continually accused me of edit warring and repeating myself, while refusing to respond to my points and declaring the discussion over.
--Gyrobo (talk) 03:48, 7 October 2010 (UTC)
First: WP:DATESNO does not authorize you to contest anything, especially not contest an accepted form in favor of an unaccepted form.
Second: Ties with Google does not consider a national tie; it is considered advertisement. And even if it was, why do you keep mentioning it when you yourself don't use MDY? To win the discussion?
Third: If it is not a list, then even DATESNO does not allow you have YMD in there. A valid candidate for YMD is List of UFO sightings or Index of MS-DOS games (0–9).
Last: Aha! Now, that is the right thing to do! I appreciate your decision and I will help you. Still, no one is accusing you. It is just a fact: If you counter-revert after receiving a BRD notice, then you are edit warring. Until now, you have done it twice. Believe me, admins who attend EW cases are not fools — in fact, they are very intelligent: If one person accuses the other without sufficient evidence, it is the accuser person who gets banned. Fleet Command (talk) 04:13, 7 October 2010 (UTC)
  1. At the time I changed {{Use dmy dates}} into {{Use ymd dates}}, I didn't realize that there were dates within the prose.
  2. WP:DATERET does allow me to contest the format, especially if I believe the article hasn't evolved to the point where consensus has been reached regarding the date.
  3. The fact that a corporation is involved does not automatically make it an advert.
  4. I am advocating MDY within the prose, but YMD in the references as a MOS-accepted shorthand.
  5. Not only are the admins who attend EW cases fools, they're dancing fools.
--Gyrobo (talk) 04:40, 7 October 2010 (UTC)

Response to third opinion request

Third opinion

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.

  • Did this article have an established date format? Yes. The first revision [1] by Pmsyyz (talk · contribs) included "30 September, 2010", which establishes day-before-month as the initial format. That format was predominately retained for much of the article's history, due in part to FleetCommand (talk · contribs) adding the {{Use dmy dates}} template on 1 October 2010.[2] That action was consistent with the MOS. At the time he added the tag, there were five references, only one of which had a date, and that was in ISO 8601 format. That one was added using the generic {{Citation}} template by a relatively inexperienced editor; it cannot be assumed that this was a conscious and informed choice on that editor's part. (An experienced editor would probably have used the more specific {{Cite web}} tag.)
  • Is day-before-month acceptable in references, all other things being equal? Yes. WP:DATESNO explicitly says day-before-month is an acceptable date format. The Manual of Style does not prefer one type of date over another; instead, it defers to three guidelines:
  1. All of the dates in the article should be in the same format, and all of the dates in the references should be in the same format. Note that there is not a requirement that dates in the article and in the references both be the same format.
  2. If the article has strong national ties to a topic, it should use the date format associated with that nation.
  3. In the absense of strong national ties, the existing format should be retained.
  • Is there a strong national tie here? No. There is nothing about this topic that is intrinsically tied to a particular English-speaking country. Even if one made the argument that Google is a US company, and that therefore US dates should be used, that would argue for using month-before-day, not ISO 8601.
  • Are ISO 8601 dates allowable in references? Yes, generally. WP:DATESNO says they shouldn't be used in sentences because they are uncommon in English prose. References are neither sentences nor English prose.
  • If an article has only two sources in it with dates, and they both use the same date format, does that constitute evolved predominantly using one date format? Yes, it does. A date format is used in the article. That format is used more often than any other. Therefore, it is used predominantly. This can be easily settled by the use of any decent dictionary.
  • Does the date format used by sources have any bearing on the date format in the article? No, it doesn't. There's nothing about honoring the date format of the source document in WP:DATESNO.

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)

Discussions arising from third opinion

Before continuing, I'd like to point out that in an early edit, an infobox containing a MDY date was inserted. At the time the dates were changed to DMY, there were three dates, in three different formats. These were then changed to YMD and then changed back to DMY during the ongoing discussion over the default date format. The continued usage of DMY in prose rather than MDY assumes that DMY was predominant, which I still contest. I really don't think it's fair that a format should be retained solely because it was in place during a discussion to determine whether it should be retained.
--Gyrobo (talk) 14:22, 8 October 2010 (UTC)
I still can't attach any weight to that infobox edit, because it was very clearly the work of an naïve editor: they used a questionable citation template, they have no talk or user page, and they haven't made very many edits. The thing is, {{Infobox file format}}'s instructions specify using day-first in the field in question. That doesn't override WP:DATESNO or WP:DATERET, either. The fact is, the person that created the article established day-first as the format for this article, and WP:DATERET says that sets the format for the article until a clear consensus to change it is created. None of the changes since then to other formats are consonant with WP:DATERET. You may not find it fair that the format must be retained during a discussion about whether or not to retain it, but that is what DATERET says. // ⌘macwhiz (talk) 18:53, 8 October 2010 (UTC)
Ah, okay, I was just a little confused. I thought you were making a distinction between initial and predominant formats. Thanks for explaining it. However, that does seem to support the use of YMD in the references: whether or not the editor who placed the first date in the references section was "naïve", it established that format—because, as you and the MOS have said, there is no requirement that the references and article prose each use the same format—and as the first format used in the references, YMD should continue to be used unless there are compelling reasons to change it, per DATERET.
--Gyrobo (talk) 21:18, 8 October 2010 (UTC)
I agree with mostly everything macwhiz said, so I won't repeat it. I will, however, add the following points:
  1. I understand that technically, predominance of a date format can be established from two uses, but that's a rather borderline/literal reading of the definition, and therefore I wouldn't rely on that to make an argument.
  2. "without turning it into a pointing-at-rules contest" -- exactly. I believe it is counter-productive to discuss the topic in the level of "violations" to the guidelines. Discussion and consensus should override the rules, per (reasonable use of) the IAR pillar. Accusations of violations also go against the Civility pillar.
  3. I too think that YDM/ISO is a reasonable choice for the references, for they are lists indeed, and would thus benefit of the very advantages for lists the MoS refers to (conciseness). I would also add ease of reading (not an entry by itself, but the whole references section, e.g. to quickly check which of the references are more recent), as well as the aesthetic argument presented early on the discussion.
--Waldir talk 08:40, 9 October 2010 (UTC)
I see, Gyrobo, that you are once again engaged in edit-warring, even since Macwhiz's 3rd opinion which is written in bold-face reads: "the article, and its references, should continue to use day-before-month." This is your last warning: Cease edit-warring immediately! And please stop using such statements. One instance of it is enough to get you banned. Fleet Command (talk) 05:18, 10 October 2010 (UTC)
  1. I believed that consensus had been reached in favor of YMD for the following reasons:
    1. Macwhiz listed numerous reasons in support of YMD and he encouraged you to support it.
    2. Myself and another editor also supported its use in references.
    3. Your reasoning against YMD in the references earlier in the discussion was that it violated DATERET, and that the prose and references needed to use the same date format. Myself, Waldir and Macwhiz all agreed that references can use a separate format from the prose, as long as it is internally consistent, and I established that the first date date used in the references section was in YMD anyway. So it would violate DATERET to not use YMD in the references.
  2. "Such statements" are considered by some to be playful irony in response to such platitudes, and not a serious attempt to disparage any editor. If you are unfamiliar with the idiom "dancing fool," please read its definition.
  3. We're all trying to prevent a rules-pointing contest, and it's not very productive or civil to accuse other editors of edit-warring or threaten them with bans. My edits were done in good faith, per the above reasoning.
    --Gyrobo (talk) 14:05, 10 October 2010 (UTC)
Okay, we're well out of 3O territory here, as there's more than two editors involved in the question at this point; having given my opinion, I've only got a few more things to toss into the discussion. If they don't help, I suggest you continue up the dispute-resolution chain and try calling an RfC, or engage the services of the Mediation Cabal.
Fleet, your initial objection was that ISO date format is not allowed on Wikipedia, but we've established that you were mistaken on that point as far as it applies to references. Although a date format was established for the body of the article as day-before-month, I have to say Gyrobo has a point about the date format for the references. As noted above, the article body and the references don't have to share a date format. While I would've preferred to see unanimous acceptance of the date format on the talk page before changes were made—not necessarily unanimous approval, but at least "I don't like it but I concede the point"—I think Gyrobo also has a point about consensus changing.
What I haven't seen since I gave my opinion is a reason from Fleet for using day-before-month in the References that hasn't been refuted. Absent that, the only reasonable assumption is that the argument is "I just don't like it", which isn't a valid reason. Remember, on Wikipedia, consensus is defined as "a decision that takes account of all the legitimate concerns raised." (Emphasis added.) In other words, if there are three editors who have given valid reasons to use ISO, and one who is basically arguing "don't like it," it's a unanimous consensus to go with ISO.
I want to be clear here: I am assuming, Fleet, that you have other reasons you just haven't stated clearly yet, and I presume that you don't realize that other people may not know or understand your reasons, so please don't take offense—I'm trying to help you here! If you have a good point to make, please make it: I'm always open to good ideas, and like consensus, my opinion can be swayed by a good argument. // ⌘macwhiz (talk) 19:26, 10 October 2010 (UTC)
First: I take no offense at words (unless they are one of the seven filthy words of English language ... but that's not the matter here.) And yes, you have been very kind macwhiz. Thanks.
Second: Whatever we are doing here, edit-warring is not warranted. Gyrobo is too quick to assume consensus; and suspiciously too quick, if I may say so. I neither threaten nor accuse: What he is doing is defined as Edit-warring by WP:EW.
Third: Yes, I have my own reasons for using DMY dates. I don't use anything just because it is a standard (e.g. JPEG 2000) and don't cease using something just because it is superseded by another standard (e.g. HTML 4). This YMD date is also an awkward standard which is not reader-friendly. YMD date format is not concise, it's cryptic. Why should I force readers to do some number-to-month conversion in their minds when I can simply write the date in a format that most of my fellow worldmates are familiar with? (I myself often mistake which number is June and which is July.) I only use YMD dates in long list articles where it is important to sort lists alphabetically, either in a table or bulleted list. Even then, I use the sort template to mask them with DMY or MDY, (e.g. {{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.
Fourth: My and your personal reason notwithstanding, as you too partly mentioned earlier, according to WP:DATERET, I and every Wikipedian have a non-disputable right to tag an article with a date format tag that corresponds to respectively either (1) its current dominant date format or (2) the tagger's mere wish and then expect no one to touch that date format unless STRONGNAT applies. You don't seem me running through computer-related articles and using DMY dates there because I understand that their established format is usually MDY. First-tagged first-served; that's our prerogative. In those cases, I usually add a {{Use mdy dates}}.
Fifth: I find assuming good faith in Gyrobo a more and more challenging task. He does things that do not correspond to his words: He says: "I believed that consensus had been reached in favor of YMD" but he also changed the date format of the infobox to MDY! He keeps telling me "Don'threaten! Don't accuse!" but he has given me a barnstar for "keeping my head!" (See my talk page.) His list of three reasons for his last instance of reversion are all inconsistent with the truth! He says "Myself and another editor also supported its use in references" but that another editor is Administrator Waldir which Gyrobo previously called a "Dancing fool". He says "Your reasoning against YMD in the references earlier in the discussion was that it violated DATERET" but you completely discredited this statement earlier. Looks like Gyrobo just likes YMD and resorts to every measure to reinstate that format.
Conclusion: (1) I take no offense. (2) Edit-warring is "No! No!" (3) Personally, I think DMY date format is better because most people in the world use it and credible manuals of style recommend it for citation (along with MDY). (4) WP:DATERET affirms DMY in this case. (5) Oh, Gyrobo... Fleet Command (talk) 12:20, 11 October 2010 (UTC)
I forgot to cite my sources for my Third section (MOS suggestions). Here:
Although, my Fourth section still takes precedence. Fleet Command (talk) 13:20, 11 October 2010 (UTC)
  1. Edit warring involves repeated changes made in bad faith. You have frequently accused me of edit warring for making a single change, without evidence that I did so in bad faith.
  2. You may not feel that your words are threatening, but I find phrases like these patronizing, threatening, and offensive:
    1. "Moreover, you use the popularity of MDY format amongst the sources to sanction YMD? That's odd."
    2. "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."
    3. "And even if it was, why do you keep mentioning it when you yourself don't use MDY? To win the discussion?"
    4. "Aha! Now, that is the right thing to do! I appreciate your decision and I will help you. Still, no one is accusing you ... Until now, you have done it twice."
    5. "I see, Gyrobo, that you are once again engaged in edit-warring ... This is your last warning: Cease edit-warring immediately! ... One instance of it is enough to get you banned."
    6. "Whatever we are doing here, edit-warring is not warranted. Gyrobo is too quick to assume consensus; and suspiciously too quick, if I may say so"
    7. "I find assuming good faith in Gyrobo a more and more challenging task ... Looks like Gyrobo just likes YMD and resorts to every measure to reinstate that format ... Edit-warring is "No! No! ... Oh, Gyrobo..."
  3. I gave you that barnstar in the hope that it would make you realize that I'm not your enemy, just a fellow editor who just wants to work with you to improve a Wikipedia article. I thought it would be a nice gesture to alleviate the tension.
  4. I removed the 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.
  5. It has already been established that references are lists, and that the term "dancing fool" is not an insult.
--Gyrobo (talk) 14:49, 11 October 2010 (UTC)

In regards to Fleet's numbered points:

Point 2 (Edit warring): I disagree with the characterization that Gyrobo is edit-warring. You say that you do not accuse Gyrobo, and then go on to do exactly that. He has engaged in discussion, obtained what he believed in good faith to be a consensus, and acted boldly upon it. I'd also note that it takes two to edit-war. As the song says, "Before you accuse me, take a look at yourself." See also my reply to Point 5 below.
Point 3 (Personal preference):
  • I understand your reasons, and if I were writing for a predominantly American audience, I'd probably use MDY dates for the same reasons. However, we're not writing for a predominantly American audience, we're writing for a global audience. Outside of the United States, the ISO date format is much more common, and therefore much more readily parsed by readers. Further, it is machine-parseable, which means that it can be easily altered programatically if a user is so inclined. Further, it creates more useful metadata.
  • The Chicago Manual of Style, 16th Edition, does not require the use of a particular date format. Its examples use American date formatting, as it is a guide to American English. It does note the ISO style (CMoS 9.37), and it does imply that ISO is suitable for citations based on local guidelines:

    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
  • The Chicago Manual of Style is not binding upon Wikipedia. Neither are the other sources you cite. Only the Wikipedia Manual of Style is binding.
  • Both the MOS and Chicago recognize that prose and references are distinct. Your preference may be to not treat them as such, but neither work provides justification to enforce that preference upon others on Wikipedia.
  • WP:CITE#HOW controls here. It says, in part: "Citations in Wikipedia articles should be internally consistent. You should follow the style already established in an article if it has one; where there is disagreement, the style used by the first editor to use one should be respected." The first editor to use a date in a citation on this article was Aeluthhiet (talk · contribs), who used ISO format.[3] Therefore, per our MOS, we should be using ISO.
Point 4 (WP:DATERET):
  • I don't recognize any such thing as a "non-disputable right to tag an article". Every edit is disputable. I would challenge you to find a citation that establishes that "non-disputable right" in Wikipedia's rules.
  • The documentation for Template:Use mdy dates states clearly: "The purpose of this template is to allow bots to recognise that the 'mm dd, yyyy' (aka 'American') date format has been applied to an article so tagged." It further explains that the tag is systematically applied to articles under the first main contributor rule or the close national ties rule. This refutes your assertion that the tag exists as a sort of flag that can be planted by the first person to see a hill with no flag on it. As mentioned previously, the first main contributor used day-before-month dates in the article prose. Therefore, your use of the Use-mdy-dates tag was improper; by the documentation of the tags, you were constrained to apply Template:Use dmy dates instead.
  • Further, as established under Point 3 above, the "flag" had already been planted for ISO dates in citations before you came along, and under WP:CITE#HOW that choice should be respected.
Point 5 (Gyrobo): This paragraph is ad hominem, and as such could be considered a personal attack, especially if you continue to use such arguments. Argue the content, not the person. If you have issues with the personal behavior of another editor, the right place to bring it up is WP:WQA, not the article talk page.
// ⌘macwhiz (talk) 14:59, 11 October 2010 (UTC)
[edit conflict] What if we use DMY with abbreviated months? That would retain both the readability of full DMY/MDY dates, and the conciseness (per MOS), aesthetic (per Gyrobo, i.e. same length) and practical (per me, i.e. easiness to spot/compare) features of ISO/YMD; and even though it would lose the sorting ability, the references couldn't be sorted anyway. Granted, it's not an international standard like ISO, but it is more global than MDY. Overall, I think the advantages outweigh the drawbacks, and it might be a middle-ground format we can agree on. [edit: I see now, as pointed by Macwhiz, that CMOS itself suggests that, and I feel confident that it might be a good idea. It is highly regular and easily machine-parsable — perhaps only a little less so than ISO/YMD.]
A side note: I consider myself a regular editor like all of you, and participated on this discussion as such, not as an admin. In fact it was quite strange to see myself referred to as "Administrator Waldir" :) Also, I didn't feel Gyrobo's remark as directed at me, because it because I'm not an "admin who attends EW". --Waldir talk 15:18, 11 October 2010 (UTC)
The use of abbreviations was not something I considered (abbreviations are only mentioned in WP:MONTH), but while I find the concept interesting, I oppose it for three reasons:
  1. YYYY-MM-DD provides a recognizable structure that can be immediate spotted by skimming the references: four numbers, a dash, two numbers, a dash, then two numbers. Abbreviations introduce fragments of words that (I believe) aren't immediately recognizable as distinct from the surrounding text.
  2. YMD requires a leading zero for days of the month, while an abbreviated DMY does not; the lengths of the dates would still be inconsistent for days of he month less than the 10th.
  3. The use of abbreviated dates in references isn't something terribly common, and editors who seek to add refs in the future may assume a past editor made a mistake and try to "correct" the date format, leading to a rehashing of this whole discussion.
--Gyrobo (talk) 16:02, 11 October 2010 (UTC)
  1. I would argue that the abbreviated DMY also contains recognizable structure. Maybe not as much as DMY, but it is a middle-ground proposal after all.
  2. We can agree to use the leading zero on this article. We certainly don't need to ignore whatever is not on the rules (not even follow strictly the rules if we agree they're not appropriate for this case, per IAR)
  3. In that case it's very simple to just undo and point to this discussion. Or even better, we can put a html comment in the source, as is done in many similar cases where conventions are agreed upon in the article's talk page. --Waldir talk 04:51, 12 October 2010 (UTC)
The primary allure of YMD, in terms of readability gains, is that it uses exclusively numbers and dashes—characters which aren't common in author names, article titles, publishers, etc.—and it creates a recognizable structure that is immediately associated with dates, much like how 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).
--Gyrobo (talk) 05:20, 12 October 2010 (UTC)

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:

“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.”
—Macwhiz

Until then, please don't do this:

“An edit war occurs when editors who disagree about some aspect of the content of a page repeatedly override each other's contributions, rather than try to resolve the disagreement by discussion”
—WP:EW

Fleet Command (talk) 10:03, 12 October 2010 (UTC)

Waldir, myself and Macwhiz all expressed a preference for YMD for both aesthetic reasons, and because it was the default date format for references (and a variety or other reasons). Waldir began discussing the possibility of using abbreviated DMY to broker a compromise that (correct me if I'm mistaken, Waldir), while not initially palatable, might have brought in FleetCommand and received unified toleration, if not acceptance. I no longer believe that such a compromise is possible or desirable. I'm changing the date format for the references to YMD, per DATERET and consensus, and I'd like to discuss whether IAR should override DATERET in establishing MDY rather than DMY in the prose; the article may not be tied to any particular country, but it uses American spelling, and related articles use MDY. Additionally, for those who may be interested in the YMD sorting script I described to Waldir, it's available at User:Gyrobo/sortISODate.js and can be included in your vector.js page with importScript("User:Gyrobo/sortISODate.js");
--Gyrobo (talk) 19:58, 12 October 2010 (UTC)

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)

  1. I'm not sure which policy you are referring to, we've already established that the first reference was in YMD. If the prose must remain in DMY for the duration of the discussion, per DATERET, then the references should retain their original format for the same reason, unless there is consensus to change it.
  2. The decision to use YMD has not been derived from a few votes, or the personal preferences of any one editor; these changes have been discussed in every detail for almost two weeks, and is consistent with the MoS.
  3. If you perceive my changes as edit warring, you really should read my reasoning here, and in the edit summaries. The three times I have changed the date formats, I believed in good faith that consensus had been reached, and I said so.
  4. If ESkog chooses to read this entire discussion, he'd certainly have my respect as well.
--Gyrobo (talk) 16:53, 13 October 2010 (UTC)

Neutral appraisal of the discussion of this matter

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)

Too right, anonymous editor!
Personally I found the contributions of ⌘macwhiz to be fair and balanced. I found Gyrobo's contributions to be made in good faith, and the (ultimate) arguments persuasive. I found Fleet Command's arguments tiresome.
Other than archiving the discussion, how about about hiding the bulk of this long drawn out discussion by default (like derivations in some of the WP articles)??
—DIV (49.186.238.246 (talk) 13:39, 7 February 2022 (UTC))

JPEG 2000, JPEG XR

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)

Hello, Bxj and thanks for attending the talk page. Unfortunately, the reasons you have given are promotional and Wikipedia is not a promotional mean. Google mentions JPEG, WebM, JPEG 2000 and JPEG XR because they are its competitors and rivals in the way of its dominance over the web market share. However, from the neutral point of view to which Wikipedia must adhere, WebP is yet another image format just like a lot of others. Putting JPEG, JPEG XR and the others in See Also section is equivalent to stealing the attention from the other image formats that must rightfully receive enough attention. These select formats has already receive their attention in the text of the article. That's enough. Advertise them no more. Fleet Command (talk) 05:27, 5 October 2010 (UTC)
By the way, the phrase "emphatic" which our dear Bxj uses is part of my message that reads: "Why should some file formats be promoted more emphatically than others?" Fleet Command (talk) 05:33, 5 October 2010 (UTC)
I just wanted to say I didn't see this discussion going on when I added the section back. But here's my opinion: it should definitely be kept. Navboxes are a way of giving context to items in a category, but the "See also" section describes related articles that have immediate relevancy — it's not about promoting anything. This reasoning is consistent with related articles, such as WebM.
--Gyrobo (talk) 14:20, 5 October 2010 (UTC)
A logical third opinion! Hence, we have a consensus! You may go ahead and add back WebM, JPEG, JPEG 2000 and JPEG XR. However, your addition of DjVu (a compound document format) and PGF is still questionable. I don't see how they are even remotely related to this article except for being file formats. Fleet Command (talk) 19:46, 5 October 2010 (UTC)
Just for the record: if all it took was two people standing for the addition, we already had "consensus", since at least two editors (me and later Bxj) added those links, which in both cases were removed by you. Granted, directly adding content doesn't count as justifying its inclusion, but Bxj's edit's text had precisely the reasoning he presented here, and my edit could at least be assumed to have had a valid reason behind, per AGF. But again, I'm just saying this for historical record, please don't take it personally. --Waldir talk 11:20, 8 October 2010 (UTC)
I'm afraid I have to disagree. Two people who add a section which is deemed as advertisement may very well be both fans. (Don't you think there can be more than two fans for something on Wikipedia?) Fans promote their topic. Wikipedia is not a promotional mean – commercial or otherwise. Promoting commercial things is advertisement (See WP:NOTADVERTISING); promoting non-commercial things is at very least a violation of NPOV. But here there are two people that say they do understand my concern but their intent had not been promotional. Here, my duty is to believe their word and consider a third-opinion to have reached. Fleet Command (talk) 12:41, 8 October 2010 (UTC)
I don't think the intent should count more than the content. Most image formats are not WebP competitors in the sense that it is meant to be a JPEG replacement for the web (lossy, low file size, reasonable quality, etc). It could easily be established that the direct competitors as JPEG replacements (the "niche market", taking the commercial analogy further) would indeed be JPEG 2000 and JPEG XR. This was explicitly stated in Bxj's edit. But even if he hadn't done that, and even if his intent (but not his text) was promotional, the fact that only these two could be considered equivalent "products" by reasonable assumption would IMO be enough to keep the edit, since the net result would be informational rather than promotional. But I understand that you might disagree. --Waldir talk 13:08, 8 October 2010 (UTC)
You are right: Content matters very much. That's why I removed the See Also section: I saw its contents and deemed them unnecessary and partly-promotional. Fleet Command (talk) 04:56, 10 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)

Thanks for the free lecture, JoG. I think I'll skip reading today's tabloids. Now, would please tell us what do you mean by all this and how your lecture is supposed to help us improve this article? Fleet Command (talk) 23:44, 25 November 2010 (UTC)

Open Format?

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)

First, you had better actually read what you link to: The section "Commonwealth of Massachusetts" states that "Ecma-376 Office Open XML Formats (Open XML)" which you call "MFST .docx" IS an open format. Second, you had better read what Google says before editing the article and writing the retort-like "Yes, according to Google" because Google does not assert WebP to be an open format at all. The WebP software however, are available as open source; but open-source is different from Open-Format. Finally, you are right: WebP is not an open format. Fleet Command (talk) 23:05, 10 February 2011 (UTC)

Is WebP still in development??

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)

No, — obviously it is not. Eight years later I still see all those abandoned pipe dreams still listed as imminent. Those unbelievably nice features described here smell like false advertising, please fix.
--2602:306:CFCE:1EE0:305E:100D:36A4:2349 (talk) 18:13, 1 March 2020 (UTC) Just Saying

a description of the algorithm

There was a good description of the encoding mechanism on the mailing list [4]:

there's mainly three steps in the WebP encoder:

  • Step I: analysis phase: every 16x16 macroblock is assessed for its

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.

  • Step II: so far, Step I was compression-agnostic: no bitrate was

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.

  • Step III: VP8 spec allows the transmission of custom probability

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)

Reference #5 is out of date

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)

Format adoption is two-fold: browser implementations vs web designers

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)

IrfanView support

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)

Six years later Irfan gives me a warning, unknown source, are you sure? To me this implies, unlike dumb formats like JPG, PNG, GIF, BMP, etc, there are potentially dangerous aspects to it, perhaps like HTML and certain popular document formats like PDF. Why isn't this danger addressed, yes or no?
However, after saying OK, IrfanView can open, save, edit and convert to the above safe formats. At first glance it seems this format became popular due to now unrealized hopeful fantasizing. Why are those years-old pipe dreams (akin to false advertising?) still listed as imminent?
--2602:306:CFCE:1EE0:305E:100D:36A4:2349 (talk) 17:57, 1 March 2020 (UTC) Just Saying
There's no warning in version 4.54 x32 of IrfanView on my system.
A warning about an "unknown source" doesn't necessarily mean that there are potentially dangerous aspects. It might even be that Windows has marked the file as a 'web download' (as it often does), and IrfanView is merely indicating the file status designated by Windows.
—DIV (49.186.238.246 (talk) 13:24, 7 February 2022 (UTC))
Support good-faith IP editors: insist that Wikipedia's administrators adhere to Wikipedia's own policies on keeping range-blocks as a last resort, with minimal breadth and duration, in order to reduce adverse collateral effects; support more precisely targeted restrictions such as protecting only articles themselves (not associated Talk pages), or presenting pages as semi-protected, or blocking editing from mobile devices (not all devices) when viewed from designated IP ranges.

Examples

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)

6 years later I also think such an example would be helpful. WP should have a page showing such an example using a variety of lossy compression schemes. David Spector (talk) 14:24, 28 May 2020 (UTC)

Seconded. Or thirded, actually.

Zezen (talk) 05:50, 31 July 2020 (UTC)

Native Webp support for some Google Services (blogger, photos)

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.

I have a blogger account and you can upload WebP files without having to use the "rw" option in the URL. The image was 100% unmodified in this case. Regarding Google photo, it supports WebP images but requires the "rw" option to access the WebP file format. In this case, just because a image is re-encoded, does not mean you can make the claim the site "has no native support". This statement is misleading. It is common practice with a lot of image hosting services to even re-encode uploaded JPEG images. This does not mean the sites "have no native support" for JPEGs, it just means they choose to re-encode the image files. Same goes for WebP, just because they choose to re-encode the files does not mean you can claim the site has no support for the file format when (1) you are able to upload WebP with zero additional effort than it takes to upload JPEG/PNG and (2) you can access the WebP image in the instance of Blogger and you can access a WebP version of the image in the case of Google Photo by using the "rw" url or a JPEG version with no additional effort. Offnfopt(talk) 12:02, 3 July 2015 (UTC)

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)

Lossless is not YUV420, VP8L is ARGB

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}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 14:38, 31 March 2016 (UTC)

WFM. Be..anyone (talk) 05:38, 7 April 2016 (UTC)

More on license and patent

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)

Software support

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)

Size limits?

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)

For lossy encoding, the vp8 standard (https://datatracker.ietf.org/doc/html/rfc6386) specifies that the max possible image size is 16383x16383, as it uses 14 bits to store width and height. Tmoyar (talk) 00:01, 27 November 2022 (UTC)
That is actually incorrect. According to the specs on Google's developer site, it actually uses 14 bits and stores the size minus 1. "The 14-bit precision for image width and height limits the maximum size of a WebP lossless image to 16384✕16384 pixels." is the relevant part. They add 1 back to it, to get the actual size. So a 512x512 image has 511 and 511 stored in those 14-bit unsigned integers. 174.197.69.12 (talk) 03:53, 28 September 2023 (UTC)

Lede Section too technical, + Outdated

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 default in 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 with pngcrush 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

Suggest adding mention of vulnerability to generation loss

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)

Percentage reduction?

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)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:WebP/Archive_1&oldid=1195557533"