web-archive-it.com » IT » C » CONECTA.IT

Total: 359

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • jpeg « carlodaffara.conecta.itcarlodaffara.conecta.it
    of my trusted Nokia N97 and tried to convert them in a sensible way Before flaming me about the fact that the images were not in raw format I know it thank you My objective is not to perform a perfect test but to verify Google assumptions that WebP can be used to reduce the bandwidth consumed by traditional already encoded images while preserving most of the visual quality This is not a quality comparison but a field test to see if the technology works as described The process I used is simple I took some photos I know I am not a photographer selected for a mix of detail and low gradient areas compressed them to 5 using GIMP with all Jpeg optimization enabled took notice of size then encoded the same source image with the WebP cwebp encoder without any parameter twiddling using the size command line to match the size of the compressed Jpeg file The WebP image was then decoded as PNG The full set was uploaded to Flickr here and here are some of the results Photo Congress Centre Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Photo LinuxNacht Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Saltzburg castle Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Venice Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size There is an obvious conclusion at small file sizes WebP handily beats Jpeg and a good Jpeg encoder the libjpeg based one used by GIMP by a large margin Using a jpeg recompressor and repacker it is possible to even a little bit the results but only marginally With some test materials like cartoons and anime the advantage increases substantially I

    Original URL path: http://carlodaffara.conecta.it/tag/jpeg/index.html (2016-02-18)
    Open archived version from archive


  • webm « carlodaffara.conecta.itcarlodaffara.conecta.it
    image was then decoded as PNG The full set was uploaded to Flickr here and here are some of the results Photo Congress Centre Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Photo LinuxNacht Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Saltzburg castle Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Venice Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size There is an obvious conclusion at small file sizes WebP handily beats Jpeg and a good Jpeg encoder the libjpeg based one used by GIMP by a large margin Using a jpeg recompressor and repacker it is possible to even a little bit the results but only marginally With some test materials like cartoons and anime the advantage increases substantially I can safely say that given these results WebP is a quite effective low bitrate encoder with substantial size advantages over Jpeg image quality jpeg webm webp 1 Comment On WebM H264 and FFmpeg implementation Posted by cdaffara in blog divertissements on July 6th 2010 I was recently reminded by Gregory Maxwell of Xiph about the new non Google implementation of VP8 done within the context of FFmpeg and many commenters on Slashdot observed that the fact that the implementation shares lots of code with the H264 part is further demonstration that VP8 is infriging on MPEG LA held patents Actually there is nothing in the implementation that suggests this only the fact that some underlying alogrithms are similar but not identical For example the entropy coder is quite similar and it certainly helps to reuse some of the highly optimized librarties that are within FFMPEG this is however no indication of patent infringement What is certain is the fact that

    Original URL path: http://carlodaffara.conecta.it/tag/webm/index.html (2016-02-18)
    Open archived version from archive

  • webp « carlodaffara.conecta.itcarlodaffara.conecta.it
    of my trusted Nokia N97 and tried to convert them in a sensible way Before flaming me about the fact that the images were not in raw format I know it thank you My objective is not to perform a perfect test but to verify Google assumptions that WebP can be used to reduce the bandwidth consumed by traditional already encoded images while preserving most of the visual quality This is not a quality comparison but a field test to see if the technology works as described The process I used is simple I took some photos I know I am not a photographer selected for a mix of detail and low gradient areas compressed them to 5 using GIMP with all Jpeg optimization enabled took notice of size then encoded the same source image with the WebP cwebp encoder without any parameter twiddling using the size command line to match the size of the compressed Jpeg file The WebP image was then decoded as PNG The full set was uploaded to Flickr here and here are some of the results Photo Congress Centre Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Photo LinuxNacht Berlin Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Saltzburg castle Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size Venice Top original Jpeg middle 5 Jpeg Bottom WebP at same Jpeg size There is an obvious conclusion at small file sizes WebP handily beats Jpeg and a good Jpeg encoder the libjpeg based one used by GIMP by a large margin Using a jpeg recompressor and repacker it is possible to even a little bit the results but only marginally With some test materials like cartoons and anime the advantage increases substantially I

    Original URL path: http://carlodaffara.conecta.it/tag/webp/index.html (2016-02-18)
    Open archived version from archive

  • On Symbian, Communities, and Motivation « carlodaffara.conecta.itcarlodaffara.conecta.it
    contribute to Eclipse instead It allowed them to quickly reduce their maintenance and development costs while increasing their quality as well The Symbian foundation should have done the same thing but apparently missed the mark despite having a large number of partners and members Why The reason is time and focus The Eclipse foundation had for quite some time basically used only IBM resources to provide support and development In a similar way it took WebKit which is not quite a foundation but follows the same basic model more than two years before it started receiving substantial contributions as can be found here And WebKit is much much smaller than Symbian and Eclipse For Symbian I would estimate that it would require at least three or four years before such a project could start to receive important external contributions That is unless it is substantially re engineered so that the individual parts some of which are quite interesting and advanced despite the claims that Symbian is a dead project can be removed and reused by other projects as well This is usually the starting point for long term cooperation Some tooling was also not in place from the beginning the need for a separate compiler chain one that was not open source and that in many aspect was not as advanced as open source ones was an additional stumbling block that delayed participation Another problem was focus More or less anyone understood that for a substantial period of time Symbian would be managed and developed mainly by Nokia And Nokia made a total mess of differentiating what part of the platform was real what was a stopgap for future changes what was end of life and what was the future Who would invest in the long term in a platform where the only entity that could gain from it was not even that much committed to it And before flaming me for this comment let me say that I am a proud owner of a Nokia device I love most Nokia products and I think that Symbian still could have been a contender especially through a speedier transition to Qt for the user interface But the long list of confusing announcements and delays changes in plans and lack of focus on how to beat the competitors like iOS and Android clearly reduced the willingness of commercial partners to invest in the venture Which is a pity Symbian still powers most phones in the world and can still enter the market with some credibility But this later announcement sounds like a death knell Obtain the source code through a DVD or USB key You must be kidding Do you really think that setting up a webpage with the code and preserving a read only Mercurial server would be a too much of a cost The only thing that it shows is that Nokia stopped believing in an OSS Symbian Update after the change of CEO and the extraordinary change in strategy

    Original URL path: http://carlodaffara.conecta.it/on-symbian-communities-and-motivation/index.html (2016-02-18)
    Open archived version from archive

  • Index of /category
    08 54 divertissements 28 Apr 2015 08 54 everydesk 28 Apr 2015 08 54 oss adoption 28 Apr 2015 08 54 oss business models 28 Apr 2015 08 54 oss data 28 Apr 2015 08 54 uncategorized 28 Apr 2015

    Original URL path: http://carlodaffara.conecta.it/category/?p=267 (2016-02-18)
    Open archived version from archive

  • symbian « carlodaffara.conecta.itcarlodaffara.conecta.it
    But to get other people to contribute their work you need an advantage for them as well What can this advantage be For Eclipse most of the companies developing their own integrated development environment IDE found it economically sensible to drop their own work and contribute to Eclipse instead It allowed them to quickly reduce their maintenance and development costs while increasing their quality as well The Symbian foundation should have done the same thing but apparently missed the mark despite having a large number of partners and members Why The reason is time and focus The Eclipse foundation had for quite some time basically used only IBM resources to provide support and development In a similar way it took WebKit which is not quite a foundation but follows the same basic model more than two years before it started receiving substantial contributions as can be found here And WebKit is much much smaller than Symbian and Eclipse For Symbian I would estimate that it would require at least three or four years before such a project could start to receive important external contributions That is unless it is substantially re engineered so that the individual parts some of which are quite interesting and advanced despite the claims that Symbian is a dead project can be removed and reused by other projects as well This is usually the starting point for long term cooperation Some tooling was also not in place from the beginning the need for a separate compiler chain one that was not open source and that in many aspect was not as advanced as open source ones was an additional stumbling block that delayed participation Another problem was focus More or less anyone understood that for a substantial period of time Symbian would be managed and developed mainly by Nokia And Nokia made a total mess of differentiating what part of the platform was real what was a stopgap for future changes what was end of life and what was the future Who would invest in the long term in a platform where the only entity that could gain from it was not even that much committed to it And before flaming me for this comment let me say that I am a proud owner of a Nokia device I love most Nokia products and I think that Symbian still could have been a contender especially through a speedier transition to Qt for the user interface But the long list of confusing announcements and delays changes in plans and lack of focus on how to beat the competitors like iOS and Android clearly reduced the willingness of commercial partners to invest in the venture Which is a pity Symbian still powers most phones in the world and can still enter the market with some credibility But this later announcement sounds like a death knell Obtain the source code through a DVD or USB key You must be kidding Do you really think that setting up a webpage

    Original URL path: http://carlodaffara.conecta.it/tag/symbian/index.html (2016-02-18)
    Open archived version from archive

  • The neverending quest to prove Google evilness. Why? - carlodaffara.conecta.itcarlodaffara.conecta.it
    addr nr 5 1 nr 31 endif or for something longer ifndef RFCOMM H define RFCOMM H ifdef cplusplus endif include sys socket h define RFCOMM DEFAULT MTU 127 define RFCOMM PSM 3 define RFCOMM CONN TIMEOUT HZ 30 define RFCOMM DISC TIMEOUT HZ 20 define RFCOMM CONNINFO 0x02 define RFCOMM LM 0x03 define RFCOMM LM MASTER 0x0001 define RFCOMM LM AUTH 0x0002 define RFCOMM LM ENCRYPT 0x0004 define RFCOMM LM TRUSTED 0x0008 define RFCOMM LM RELIABLE 0x0010 define RFCOMM LM SECURE 0x0020 define RFCOMM MAX DEV 256 define RFCOMMCREATEDEV IOW R 200 int define RFCOMMRELEASEDEV IOW R 201 int define RFCOMMGETDEVLIST IOR R 210 int define RFCOMMGETDEVINFO IOR R 211 int define RFCOMM REUSE DLC 0 define RFCOMM RELEASE ONHUP 1 define RFCOMM HANGUP NOW 2 define RFCOMM TTY ATTACHED 3 ifdef cplusplus endif struct sockaddr rc sa family t rc family bdaddr t rc bdaddr uint8 t rc channel endif What can we say of that They contain interfaces definitions constants that are imposed by compatibility or efficiency reasons For this reason they are not copyrightable or more properly would be excluded in the standard test for copyright infringement in the abstraction filtration test In fact it would not be possible to guarantee compatibility without such an expression But Florian guesses the authors put a copyright notice on top That means that it must be copyrighted In fact he claims The fact that such notices are added to header files shows that the authors of the programs in question consider the headers copyrightable Also without copyright there s no way to put material under a license such as the GPL Actually it s simply not true I can take something add in the beginning a claim of copyright but that does not imply that I have a real copyright on that Let s imagine that I write a file containing one number and put a c notice on top Do I have a copyright on that number No because the number is not copyrightable itself The same for the headers included before to test for copyright infringement you must first remove all material that is forced for standard compatibility then Scenes a Faire a principle in copyright law that says that certain elements of a creative work are not protected when they are mandated by or customary for an environment then code that cannot be alternatively expressed for performance reasons What is left is potential copyright infringement Now let s apply the test to the code I have pasted What is left Nothing Which is why up to now most of the commentators that are working on the kernel mentioned that this was also just a big large interesting but ultimately useless debate In fact in the BlueZ group the same view was presented include bluetooth bluetooth h is only an interface contract It contains only constants and two trivial macros Therefore there is no obligation for files that include bluetooth h to abide by the terms of

    Original URL path: http://carlodaffara.conecta.it/the-neverending-quest-to-prove-google-evilness-why/index.html (2016-02-18)
    Open archived version from archive

  • droid « carlodaffara.conecta.itcarlodaffara.conecta.it
    at one of the incriminated files ifndef HCI LIB H define HCI LIB H ifdef cplusplus endif ifdef cplusplus endif static inline int hci test bit int nr void addr return uint32 t addr nr 5 1 nr 31 endif or for something longer ifndef RFCOMM H define RFCOMM H ifdef cplusplus endif include sys socket h define RFCOMM DEFAULT MTU 127 define RFCOMM PSM 3 define RFCOMM CONN TIMEOUT HZ 30 define RFCOMM DISC TIMEOUT HZ 20 define RFCOMM CONNINFO 0x02 define RFCOMM LM 0x03 define RFCOMM LM MASTER 0x0001 define RFCOMM LM AUTH 0x0002 define RFCOMM LM ENCRYPT 0x0004 define RFCOMM LM TRUSTED 0x0008 define RFCOMM LM RELIABLE 0x0010 define RFCOMM LM SECURE 0x0020 define RFCOMM MAX DEV 256 define RFCOMMCREATEDEV IOW R 200 int define RFCOMMRELEASEDEV IOW R 201 int define RFCOMMGETDEVLIST IOR R 210 int define RFCOMMGETDEVINFO IOR R 211 int define RFCOMM REUSE DLC 0 define RFCOMM RELEASE ONHUP 1 define RFCOMM HANGUP NOW 2 define RFCOMM TTY ATTACHED 3 ifdef cplusplus endif struct sockaddr rc sa family t rc family bdaddr t rc bdaddr uint8 t rc channel endif What can we say of that They contain interfaces definitions constants that are imposed by compatibility or efficiency reasons For this reason they are not copyrightable or more properly would be excluded in the standard test for copyright infringement in the abstraction filtration test In fact it would not be possible to guarantee compatibility without such an expression But Florian guesses the authors put a copyright notice on top That means that it must be copyrighted In fact he claims The fact that such notices are added to header files shows that the authors of the programs in question consider the headers copyrightable Also without copyright there s no way to put material under a license such as the GPL Actually it s simply not true I can take something add in the beginning a claim of copyright but that does not imply that I have a real copyright on that Let s imagine that I write a file containing one number and put a c notice on top Do I have a copyright on that number No because the number is not copyrightable itself The same for the headers included before to test for copyright infringement you must first remove all material that is forced for standard compatibility then Scenes a Faire a principle in copyright law that says that certain elements of a creative work are not protected when they are mandated by or customary for an environment then code that cannot be alternatively expressed for performance reasons What is left is potential copyright infringement Now let s apply the test to the code I have pasted What is left Nothing Which is why up to now most of the commentators that are working on the kernel mentioned that this was also just a big large interesting but ultimately useless debate In fact in the BlueZ group the same view was presented include

    Original URL path: http://carlodaffara.conecta.it/tag/droid/index.html (2016-02-18)
    Open archived version from archive