Announcement

Collapse
No announcement yet.

Chromium Adds Support For Animated PNGs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Gusar View Post
    In contrast to VP8/VP9 though, AV1 will not be proprietary. Because it is a joint collaboration, open to participation from anyone and there will be a spec from the very beginning.
    no amount of bullshit assertions will make you right. there is definition in dictionary https://en.wiktionary.org/wiki/proprietary
    by your idiotic definition if someone buys proprietary software and opens it, it will be still proprietary because it was written without joint collaboration. real world does not work like that
    Last edited by pal666; 20 March 2017, 04:04 PM.

    Comment


    • #52
      pal666
      You are confusing free and open source vs. proprietary software with open vs. proprietary standards.
      The term "open" has a very different meaning when it comes to standards.

      Also note that it is very well possible to take some proprietary standard and turn it into an open one. This happened multiple times in the history of the Internet, and currently happens with Daala, Thor and VP9 who form the basis of AV1.
      Last edited by chithanh; 20 March 2017, 07:33 PM.

      Comment


      • #53
        Originally posted by pal666 View Post
        by your idiotic definition if someone buys proprietary software and opens it, it will be still proprietary because it was written without joint collaboration.
        Nothing idiotic about this view, the software will indeed be proprietary. Of course, if the entity releasing the source is open to outside contributors, then the proprietary nature goes away. But if the entity does not accept outside contributions and is the only one working on the code, then despite you having access to the source, the software remains proprietary (though then someone might fork the source and outside contributors could all work on the fork, something that's not possible with closed source software). This would then be a difference between "open/closed source" and "open/closed development process".

        Context. It matters. Words can and do change meaning depending on context.

        Comment


        • #54
          Originally posted by chithanh View Post
          That is not the point. I have no problems if Mozilla creates APNG (based on PNG or whatever) and uses their own MIME type and file signature for it. It would just be another proprietary format that you can support or ignore if you wish. I would not care whether Chrome supports it or not.

          But Mozilla instead chose the embrace-and-extend approach of hijacking PNG, using the same MIME type and file signature, in a blatant disregard for open standards. This is why I think very poorly of them now.
          They eventually agreed on image/apng MIME type. So it's not the same.

          Chromium added it to their accept header:

          Code:
          -const char kImageAcceptHeader[] = "image/webp,image/*,*/*;q=0.8";
          
          +const char kImageAcceptHeader[] = "image/webp,image/apng,image/*,*/*;q=0.8";
          Last edited by maxst; 21 March 2017, 09:37 AM.

          Comment


          • #55
            To my knowledge, Firefox will still accept and animate APNG images served with image/png MIME type. So they still use the same MIME type as PNG.

            That they accepted Google's proposal for an optional new MIME type is certainly positive, but not sufficient. They need to do more work to divorce APNG from PNG still.

            Comment


            • #56
              Originally posted by chithanh View Post
              They need to do more work to divorce APNG from PNG still.
              Why exactly is that? The idea was to follow GIF, where the animated version does not have a different mime type, and the point is backwards compatibility - if a decoder knows nothing about animation, it'll still show at least something (the first frame), with no change to the decoder necessary. Which is how it works with GIF.

              Comment


              • #57
                Since PNG and APNG are so similar, there is no point for browsers to separate them too much. They receive a file, read first 4 bytes, detect that's a PNG, and invoke combined APNG/PNG decoder. What's the incentive for browser devs to work on some "divorce"? Their decoders for GIF and WebP are dual-purpose too.

                Comment


                • #58
                  We explained this already in the last APNG thread: APNG is a violation of the PNG spec which explicitly says that the image must not contain more than one image.

                  Now you have some almost-PNG images floating around which APNG decoders will treat as animated, while PNG decoders will see as single image. In cases where this is undesirable, you now have to run a complex parser like libpng (or worse, your own implementation) on the file to determine which is APNG and which is PNG instead of just relying on checking the file signature.

                  And when unnecessary, running a complex parsers on content from the Internet is an exquisitely bad idea from a security perspective.

                  Comment


                  • #59
                    Originally posted by chithanh View Post
                    We explained this already in the last APNG thread: APNG is a violation of the PNG spec which explicitly says that the image must not contain more than one image.
                    As mentioned earlier in the thread, they are likely to add thumbnail support to the PNG spec, which according to you would violate the spec.

                    Comment


                    • #60
                      Originally posted by chithanh View Post
                      We explained this already in the last APNG thread: APNG is a violation of the PNG spec which explicitly says that the image must not contain more than one image.
                      That's not a good reason. Standards are not commandments from god chiseled in stone. They can be amended.

                      Originally posted by chithanh View Post
                      Now you have some almost-PNG images floating around which APNG decoders will treat as animated, while PNG decoders will see as single image.
                      I find it good that a decoder that hasn't been amended to handle animation still shows something, it's much better than showing nothing. So I don't see a problem here. But I see in the thread you linked to bellow that there is a potential problem - animation happening were it isn't desired. Well, platforms that don't desire animation will need to adjust accordingly then. Some specific cases are in that thread already, with good answers - forums not desiring animated avatars for example, and the answer is that forum software is already very strict regarding what it accepts.

                      Basically, it boils down to "new tech requires new solutions to manage it". Something that has happened before and will for sure happen again. So I don't see this as a reason to reject amending the standard.

                      Originally posted by chithanh View Post
                      In cases where this is undesirable, you now have to run a complex parser like libpng (or worse, your own implementation) on the file to determine which is APNG and which is PNG instead of just relying on checking the file signature.
                      Reading that thread and the replies you got, I'd say you're exaggerating the required additional complexity. You do have a point here, but I don't see this as such a big problem as you're trying to make it.

                      Originally posted by chithanh View Post
                      And when unnecessary, running a complex parsers on content from the Internet is an exquisitely bad idea from a security perspective.
                      Security is always important, I'll give you that. But compared to other craziness pushed onto the web (webbluetooth and webusb anyone?), apng is very tame. I don't see the security angle as a sufficient reason to reject amending the standard.

                      Comment

                      Working...
                      X