This is the
talk page for discussing improvements to the
JPEG XR article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||
|
The licensing section of the article needs to state that it is a license quite similar to a BSD one in that a BSD licensed file does not become GPL licensed just because it is compiled and linked into an application that has a GPL license. MS is stating that the code does not go into a GPL type license. The article also incorrectly states that it cannot be distributed with a GPL based operating system. That is not true because it can be distributed as its own self-contained binary along with the operating system.
The article's licensing section doesn't mention that most of the other consumer level image, video, audio formats are under a much more closed licensing than HD Photo.
—The preceding unsigned comment was added by 199.253.16.1 ( talk) 16:22, 4 May 2007 (UTC).
I am working on this article. Please hang on for a day or two. -- so U m y a S ch 19:17, 12 May 2006 (UTC)
Any idea of the licensing issues of this format? Is it patented? Free to use in any application? -- WhiteDragon 14:11, 25 May 2006 (UTC)
The problem with the licence description is that the fact that it mentions 'opensource operating systems" - given there are multiple operating systems under different 'opensource licences' - the description needs to be rephrased as, "opensource operating systems licenced under the General Public Licence (GPL)" - Kaiwai (kaiwai dot gardiner at gmail dot com)
Onother licensing issue; don't know where the 'Compression Algorithm' bit came from but I have some strong thoughts it came from the HDPhoto Bitstream Specification 1.0. It is explicitily forbidden by the License Agreement accompanied in that document to distribute any part of the document and... Even better it is not allowed to use any of the reference material for a product other than one that can interface with a Microsoft product (Thus Windows)... Just some thoughts, don't know how to implement this on this page
As for all other JPEG technologies, the target is to make the baseline technology of JPEG XR available on a royality-free licence. That means while patents will apply, you shall be able to get a licence-fee-free licence to use JPEG XR. Currently, the situation is that Mircosoft is granting licence-fee free access to their JPEG XR patents, though at least two additional patents from third parties have been identified that *might* apply to JPEG XR and whose owners are not willing to grant a royality-free access to the technology. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:12, 17 November 2009 (UTC)
A truly integer-only (that nonetheless handles floating-point color), block-based compression/decompression algorithm that performs more than twice as well as JPEG, while still retaining comparable computational cost? Unless i'm really behind on developments in the state of the art, this sounds way too good to be true.
Are there independent verifications of these claims, or at least slightly more concrete descriptions of the algorithm(s) in question? -- Piet Delport 12:36, 27 May 2006 (UTC)
Well, removed the confusing bit for now. What do you think? -- so U m y a S ch 08:28, 29 May 2006 (UTC)
Here again one need to be very carefully how to define "the error". MS has claimed in the past to have an absolute error less than that of JPEG, which can be confirmed. However, this type of error has little to do with "PSNR" = log of mean square error, which is the most accepted error measure in the community, and the two have yet again little to do with the visual error (as found in subjective tests).
What can be said is that the PSNR (MSE) is somewhere half-way between JPEG and JPEG 2000, and closer to JPEG 2000.
As far as the visual error (subjective quality) is concerned, JPEG XR is actually much closer to JPEG than JPEG 2000 if applied "naively" as in the reference implementation, sometimes even worse than JPEG. However, this is not the end of the story. Similar to JPEG 2000 and JPEG, JPEG-XR can be improved and tuned towards visual performance. These optimizations of course increase the complexity (maybe more than similar improvements would require for JPEG or JPEG 2000), but they can help significantly and bring the JPEG XR performance close to JPEG 2000.
Thus, I can certainly not "confirm" Microsoft's claims in so far as "useful" error measures are concerned. Rather, MS decided to use an error measure in the demos they were good at. It is more realistic to say that JPEG XR is midway between the standards, and where exactly depends on the measure. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:20, 17 November 2009 (UTC)
Will there be DRM on that format? David.Monniaux 13:47, 8 June 2006 (UTC)
How open will this format be? Will third parties be able to write plugins using this format? Will it be legally encumbered to sabotage any hope of interoperability? grendel| khan 17:45, 10 December 2006 (UTC)
The format will be open, and MS is playing nice here as much as I can see it. MS grants royality free licences to the JPEG XR technology. However, see above, there are other players in industry that might not play so nicely. Whether their patents withstand a court is, of course, another question. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:22, 17 November 2009 (UTC)
The list of audio/video formats at the bottom of this article needs to have some added links for physical media containers for audio/video for the major types of media used (DVD, SVCD, VCD, audio CD, etc).—Preceding unsigned comment added by User:199.253.16.1 ( talk • contribs)
"Integer operations typically work faster than divides". i beleive this should be "integer operations typically work faster than floating point operations". there is an integer devide as an integer operation.
Can there be a section which talks about the support of this file format, i.e. which programs can read it? Althepal 05:41, 30 April 2007 (UTC)
How about someone comparing jpeg to hd photo (at same file size) and uploading as a png? Althepal 23:22, 29 July 2007 (UTC)
I use Mac OS X and Windows XP, and I have both Safari and Firefox on both comps. I almost always use Firefox, because it is far more secure than IE, and far more feature-packed (when extended) than Safari. I only use IE when a Microsoft website requires it. However, truth be told, about 70% of people use IE. Nevertheless, PNG has wider support than TIFF, and I don't even know if Wikipedia supports TIFF. I think the focus of the comparison would be on artifacts, not color reproduction, but even in Internet Explorer the color thing wouldn't mess up the point of the comparison. Althepal 18:46, 31 July 2007 (UTC)
Well, I was actually inspired to do some lossless compression tests. I used two images from the RAWpository. The first was Nikon D2X sample #2; it's an outdoor scene with sky, trees, a building, and ripply reflective water in about equal proportion, 4288x2848, 24bpp. The second was Konica/Minolta 7D sample #2; it's an indoor image of someone's desk, in fairly good light but with lots of CCD noise visible, 3008x2000, 24bpp. Results (again, this is lossless):
encoder | image 1 size | image 2 size | comp. time (image 1) |
---|---|---|---|
Uncompressed RGB | 36,636,672 | 18,048,000 | |
TIFF (Photoshop, ZIP mode) | 20,408,524 | 11,167,832 | 28 sec |
PNG (Irfanview PNGOUT plugin) | 18,979,890 | 10,201,126 | several minutes |
JPEG-LS (HP locoe.exe v1.00) | 18,444,088 | 10,148,631 | 4 sec |
HD Photo (MS Photoshop plugin) | 17,733,494 | 9,388,934 | 3-4 sec |
JPEG 2000 (Kakadu 5.2.5) | 15,236,055 | 8,319,031 | 7-8 sec |
So JPEG 2000 beats the pants off everyone else, much to my surprise, and TIFF and PNG were far more competitive than I expected (except for compression time). On the other hand, the difference between the best and worst compression is only about 33%, which is too little to matter in most cases.
Incidentally, libjpeg at 99% quality with chroma subsampling off gets the images down to 12,627,855 and 6,856,482 bytes respectively, and I'm damned if I can see the slightest difference between the output and the input, even flipping between them at high zoom. So one can argue about the practical usefulness of lossless compression modes.
Note that I would expect different encoders to produce different results, even in lossless modes. For example, I used PNGOUT because it usually compresses far better than most PNG implementations (it's very slow by design), and I used Photoshop and ZIP for TIFF because it did the best of the combinations I tried. But I only tried one implementation of HD Photo and JPEG 2000. So there's still plenty of room for bias here. -- BenRG 21:02, 3 August 2007 (UTC)
I've just learned that Kodak published "a default set of Kodak reference images that are commonly used in the image compression industry to demonstrate the effectiveness of various methods" (ref.: StuffIt® Image Compression White Paper, Date: 1/5/2006 (Revision 2.1) page 5 of 15). The reference set consists of a series of uncompressed *.png photos. Thumbnails of the Kodak reference images can be seen on page 6 of 15; obtain your own free copy of the white paper by filling out a very brief form at http://www.stuffit.com/imagecompression/.
I'm still trying to find out how to obtain a set of Kodak's images, and whether or not they are free. In the meantime if someone else already knows, please enlighten all of us.
Meanwhile I did some stopwatch-timed tests on my Mac and verified what I already strongly suspected. When I compress a *.tif it slashes the size by 36%. When saved to my fastest HDD, the compressed versions take about 31% longer to open. To be a fair test, my graphics editor was launched well prior to the test and left open continuously. (E.g. 3.5" x 4.5" 24-bit RGB, 7.5 MB uncompressed opens in 3.54 sec, vs. 4.8 MB compressed opens in 4.63 sec).
Badly Bradley 17:46, 14 August 2007 (UTC)
JPEG offers a set of test images for image quality and performance assessment that have been used internally. These images are available for testing on a royality-free basis. Note that the Kodak test set is potentially problematic as their images are both too small, and also potentially have licence implications. To get access to the JPEG test set, write to "thor at math dot tu dash berlin dot de". —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:26, 17 November 2009 (UTC)
XP user already support to view the HD photo by downloading Windows Live Photo Gallery. Matthew_hk t c 21:18, 13 September 2007 (UTC)
If it has not been already standardized, why is the article title changed? The lines in the article say "under consideration" and "tentatively titled". —Preceding unsigned comment added by 221.128.147.219 ( talk) 15:57, 19 January 2008 (UTC)
Halfway through the "Compression algorithm" section, the article begins referring to something called the "PCT", which I assume is some kind of transform. A google search gives two possibilities: "Pairwise Correlating Transform" and "Photo Core Transform". The former could be a reference to the Karhunen-Loève theorem, and would kind of make sense, but the latter looks to be the more likely expansion. In any case, it's pointless to just start using an acronym mid-article without any explanation.
As it stands, the article's explanation of the algorithm is essentially:
mistercow ( talk) 00:34, 29 February 2008 (UTC)
Greetings, everyone
I'm sure by now you all know that this file format is now officially called JPEG XR is now a free international standard:
It is time to rename the article into JPEG XR. Is there any valid objections?
Please register any valid objections within the next seven days. Afterward, I'll archive this topic and will proceed with the rename.
17:26, 20 August 2009 (UTC)
The HD Photo bitstream specification claims that "HD Photo offers image quality comparable to JPEG-2000 with computational and memory performance more closely comparable to JPEG",
Is this taken from MS presentation? seems it is not truth. Is independent reaserch availible ? —Preceding unsigned comment added by 78.26.156.207 ( talk) 16:55, 16 September 2010 (UTC)
I am looking at the sidebar. How is it possible that the latest release was before the initial release? Is this a mistake? —Preceding unsigned comment added by Mikez302 ( talk • contribs) 05:09, 1 October 2010 (UTC)
This article is not a standalone list. Therefore, it may have a number of items without a Wikipedia articles, just for the sake of having broad coverage on the matter, especially in the light of the fact that the total number of supporting software isn't so high to threaten a violation of WP:INDISCRIMINATE.
In time, I think I have found independent sources on some of the items. I am about to add them to the article. Fleet Command ( talk) 17:33, 29 September 2011 (UTC)
The section "Support for more color accuracy" does not mention all the colour modes supported. I just added the other day that it supports RGB555 and RGB565. It also supports YUV however and premultiplied alpha. It seems like it would make the section a bit long and hard to read if i added another paragraph explaining this. I've created a table showing all colour modes supported that I reckon makes things a bit easier to understand. Below is a proposal for a replacement for that section.
--start--
JPEG XR supports a wide range of color formats including RGB, YUV, CMYK and RGBE in a range of color depths. Color data can also be stored as unsigned integers, floating points or fixed points. It also contains support for alpha channels as well as an arbitrary of extra channels. The table below represents a comprehensive list of pixel format supported in JPEG XR.
Color Modes | Integer | Floating Point | Fixed Point | Optional Alpha Channel |
---|---|---|---|---|
1-bit (Monochrome) | Yes | No | No | No |
8-bit Grayscale | Yes | No | No | No |
16-bit Grayscale | Yes | Yes | Yes | No |
32-bit Grayscale | No | Yes | Yes | No |
24-Bit RGB | Yes | No | No | Yes |
48-Bit RGB | Yes | Yes | Yes | Yes |
96-Bit RGB | No | Yes [1] | Yes | Yes |
16-Bit RGB555 | Yes | No | No | No |
16-Bit RGB565 | Yes | No | No | No |
32-Bit RGB101010 | Yes | No | No | No |
64-Bit RGB | No | Yes | Yes | No |
128-Bit RGB | No | Yes | Yes | No |
32-Bit CMYK | Yes | No | No | Yes |
64-Bit CMYK | Yes | No | No | Yes |
12-Bit YUV420 | Yes | No | No | Yes |
16-Bit YUV422 | Yes | No | No | Yes |
20-Bit YUV422 | Yes | No | No | Yes |
24-Bit YUV444 | Yes | No | No | Yes |
48-Bit YUV444 | Yes | No | Yes | Yes |
30-Bit YUV444 | Yes | No | No | Yes |
32-Bit RGBE | No | Yes | No | No |
8-Bit N-Channels | Yes | No | No | Yes |
16-Bit N-Channels | Yes | No | No | Yes |
In addition to the pixel formats listed above JPEG XR also has some support for BGR channel ordering and Pre-multiplied alpha.
--end--
Does this read okay to everybody? I might go ahead and add it to the article if there are no objections after a few days. Myutwo33 ( talk) 20:13, 12 October 2011 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on JPEG XR. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 00:06, 19 September 2017 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on JPEG XR. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 22:21, 18 November 2017 (UTC)
I almost didn't notice it honestly, but when not logged in, this article is served with most of the navigation links in chinese. Inspecting the source shows the root html tag has lang="zh-Hans-CN"
, and several script and stylesheet links contain href="https://en.wikipedia.org/w/load.php?lang=zh-cn..."
at the beginning of their url. Some content elements contain a lang="en"
tag though, the article content is all in english, and the dns server name is en.wikipedia.org. Nothing in the article source appears to reference language, chinese or otherwise.
I can't find any reference about non-content issues, maybe I'll have to contact OTRS? I'm running Firefox 73.0.1 on Manjaro Linux, but it seems unlikely to just be me, as every other page loads in english as normal, and this one persists after clearing cache and rebooting. -- Vickas54 ( talk) 07:13, 29 February 2020 (UTC)
This is the
talk page for discussing improvements to the
JPEG XR article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||||||
|
The licensing section of the article needs to state that it is a license quite similar to a BSD one in that a BSD licensed file does not become GPL licensed just because it is compiled and linked into an application that has a GPL license. MS is stating that the code does not go into a GPL type license. The article also incorrectly states that it cannot be distributed with a GPL based operating system. That is not true because it can be distributed as its own self-contained binary along with the operating system.
The article's licensing section doesn't mention that most of the other consumer level image, video, audio formats are under a much more closed licensing than HD Photo.
—The preceding unsigned comment was added by 199.253.16.1 ( talk) 16:22, 4 May 2007 (UTC).
I am working on this article. Please hang on for a day or two. -- so U m y a S ch 19:17, 12 May 2006 (UTC)
Any idea of the licensing issues of this format? Is it patented? Free to use in any application? -- WhiteDragon 14:11, 25 May 2006 (UTC)
The problem with the licence description is that the fact that it mentions 'opensource operating systems" - given there are multiple operating systems under different 'opensource licences' - the description needs to be rephrased as, "opensource operating systems licenced under the General Public Licence (GPL)" - Kaiwai (kaiwai dot gardiner at gmail dot com)
Onother licensing issue; don't know where the 'Compression Algorithm' bit came from but I have some strong thoughts it came from the HDPhoto Bitstream Specification 1.0. It is explicitily forbidden by the License Agreement accompanied in that document to distribute any part of the document and... Even better it is not allowed to use any of the reference material for a product other than one that can interface with a Microsoft product (Thus Windows)... Just some thoughts, don't know how to implement this on this page
As for all other JPEG technologies, the target is to make the baseline technology of JPEG XR available on a royality-free licence. That means while patents will apply, you shall be able to get a licence-fee-free licence to use JPEG XR. Currently, the situation is that Mircosoft is granting licence-fee free access to their JPEG XR patents, though at least two additional patents from third parties have been identified that *might* apply to JPEG XR and whose owners are not willing to grant a royality-free access to the technology. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:12, 17 November 2009 (UTC)
A truly integer-only (that nonetheless handles floating-point color), block-based compression/decompression algorithm that performs more than twice as well as JPEG, while still retaining comparable computational cost? Unless i'm really behind on developments in the state of the art, this sounds way too good to be true.
Are there independent verifications of these claims, or at least slightly more concrete descriptions of the algorithm(s) in question? -- Piet Delport 12:36, 27 May 2006 (UTC)
Well, removed the confusing bit for now. What do you think? -- so U m y a S ch 08:28, 29 May 2006 (UTC)
Here again one need to be very carefully how to define "the error". MS has claimed in the past to have an absolute error less than that of JPEG, which can be confirmed. However, this type of error has little to do with "PSNR" = log of mean square error, which is the most accepted error measure in the community, and the two have yet again little to do with the visual error (as found in subjective tests).
What can be said is that the PSNR (MSE) is somewhere half-way between JPEG and JPEG 2000, and closer to JPEG 2000.
As far as the visual error (subjective quality) is concerned, JPEG XR is actually much closer to JPEG than JPEG 2000 if applied "naively" as in the reference implementation, sometimes even worse than JPEG. However, this is not the end of the story. Similar to JPEG 2000 and JPEG, JPEG-XR can be improved and tuned towards visual performance. These optimizations of course increase the complexity (maybe more than similar improvements would require for JPEG or JPEG 2000), but they can help significantly and bring the JPEG XR performance close to JPEG 2000.
Thus, I can certainly not "confirm" Microsoft's claims in so far as "useful" error measures are concerned. Rather, MS decided to use an error measure in the demos they were good at. It is more realistic to say that JPEG XR is midway between the standards, and where exactly depends on the measure. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:20, 17 November 2009 (UTC)
Will there be DRM on that format? David.Monniaux 13:47, 8 June 2006 (UTC)
How open will this format be? Will third parties be able to write plugins using this format? Will it be legally encumbered to sabotage any hope of interoperability? grendel| khan 17:45, 10 December 2006 (UTC)
The format will be open, and MS is playing nice here as much as I can see it. MS grants royality free licences to the JPEG XR technology. However, see above, there are other players in industry that might not play so nicely. Whether their patents withstand a court is, of course, another question. —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:22, 17 November 2009 (UTC)
The list of audio/video formats at the bottom of this article needs to have some added links for physical media containers for audio/video for the major types of media used (DVD, SVCD, VCD, audio CD, etc).—Preceding unsigned comment added by User:199.253.16.1 ( talk • contribs)
"Integer operations typically work faster than divides". i beleive this should be "integer operations typically work faster than floating point operations". there is an integer devide as an integer operation.
Can there be a section which talks about the support of this file format, i.e. which programs can read it? Althepal 05:41, 30 April 2007 (UTC)
How about someone comparing jpeg to hd photo (at same file size) and uploading as a png? Althepal 23:22, 29 July 2007 (UTC)
I use Mac OS X and Windows XP, and I have both Safari and Firefox on both comps. I almost always use Firefox, because it is far more secure than IE, and far more feature-packed (when extended) than Safari. I only use IE when a Microsoft website requires it. However, truth be told, about 70% of people use IE. Nevertheless, PNG has wider support than TIFF, and I don't even know if Wikipedia supports TIFF. I think the focus of the comparison would be on artifacts, not color reproduction, but even in Internet Explorer the color thing wouldn't mess up the point of the comparison. Althepal 18:46, 31 July 2007 (UTC)
Well, I was actually inspired to do some lossless compression tests. I used two images from the RAWpository. The first was Nikon D2X sample #2; it's an outdoor scene with sky, trees, a building, and ripply reflective water in about equal proportion, 4288x2848, 24bpp. The second was Konica/Minolta 7D sample #2; it's an indoor image of someone's desk, in fairly good light but with lots of CCD noise visible, 3008x2000, 24bpp. Results (again, this is lossless):
encoder | image 1 size | image 2 size | comp. time (image 1) |
---|---|---|---|
Uncompressed RGB | 36,636,672 | 18,048,000 | |
TIFF (Photoshop, ZIP mode) | 20,408,524 | 11,167,832 | 28 sec |
PNG (Irfanview PNGOUT plugin) | 18,979,890 | 10,201,126 | several minutes |
JPEG-LS (HP locoe.exe v1.00) | 18,444,088 | 10,148,631 | 4 sec |
HD Photo (MS Photoshop plugin) | 17,733,494 | 9,388,934 | 3-4 sec |
JPEG 2000 (Kakadu 5.2.5) | 15,236,055 | 8,319,031 | 7-8 sec |
So JPEG 2000 beats the pants off everyone else, much to my surprise, and TIFF and PNG were far more competitive than I expected (except for compression time). On the other hand, the difference between the best and worst compression is only about 33%, which is too little to matter in most cases.
Incidentally, libjpeg at 99% quality with chroma subsampling off gets the images down to 12,627,855 and 6,856,482 bytes respectively, and I'm damned if I can see the slightest difference between the output and the input, even flipping between them at high zoom. So one can argue about the practical usefulness of lossless compression modes.
Note that I would expect different encoders to produce different results, even in lossless modes. For example, I used PNGOUT because it usually compresses far better than most PNG implementations (it's very slow by design), and I used Photoshop and ZIP for TIFF because it did the best of the combinations I tried. But I only tried one implementation of HD Photo and JPEG 2000. So there's still plenty of room for bias here. -- BenRG 21:02, 3 August 2007 (UTC)
I've just learned that Kodak published "a default set of Kodak reference images that are commonly used in the image compression industry to demonstrate the effectiveness of various methods" (ref.: StuffIt® Image Compression White Paper, Date: 1/5/2006 (Revision 2.1) page 5 of 15). The reference set consists of a series of uncompressed *.png photos. Thumbnails of the Kodak reference images can be seen on page 6 of 15; obtain your own free copy of the white paper by filling out a very brief form at http://www.stuffit.com/imagecompression/.
I'm still trying to find out how to obtain a set of Kodak's images, and whether or not they are free. In the meantime if someone else already knows, please enlighten all of us.
Meanwhile I did some stopwatch-timed tests on my Mac and verified what I already strongly suspected. When I compress a *.tif it slashes the size by 36%. When saved to my fastest HDD, the compressed versions take about 31% longer to open. To be a fair test, my graphics editor was launched well prior to the test and left open continuously. (E.g. 3.5" x 4.5" 24-bit RGB, 7.5 MB uncompressed opens in 3.54 sec, vs. 4.8 MB compressed opens in 4.63 sec).
Badly Bradley 17:46, 14 August 2007 (UTC)
JPEG offers a set of test images for image quality and performance assessment that have been used internally. These images are available for testing on a royality-free basis. Note that the Kodak test set is potentially problematic as their images are both too small, and also potentially have licence implications. To get access to the JPEG test set, write to "thor at math dot tu dash berlin dot de". —Preceding unsigned comment added by 141.58.47.118 ( talk) 15:26, 17 November 2009 (UTC)
XP user already support to view the HD photo by downloading Windows Live Photo Gallery. Matthew_hk t c 21:18, 13 September 2007 (UTC)
If it has not been already standardized, why is the article title changed? The lines in the article say "under consideration" and "tentatively titled". —Preceding unsigned comment added by 221.128.147.219 ( talk) 15:57, 19 January 2008 (UTC)
Halfway through the "Compression algorithm" section, the article begins referring to something called the "PCT", which I assume is some kind of transform. A google search gives two possibilities: "Pairwise Correlating Transform" and "Photo Core Transform". The former could be a reference to the Karhunen-Loève theorem, and would kind of make sense, but the latter looks to be the more likely expansion. In any case, it's pointless to just start using an acronym mid-article without any explanation.
As it stands, the article's explanation of the algorithm is essentially:
mistercow ( talk) 00:34, 29 February 2008 (UTC)
Greetings, everyone
I'm sure by now you all know that this file format is now officially called JPEG XR is now a free international standard:
It is time to rename the article into JPEG XR. Is there any valid objections?
Please register any valid objections within the next seven days. Afterward, I'll archive this topic and will proceed with the rename.
17:26, 20 August 2009 (UTC)
The HD Photo bitstream specification claims that "HD Photo offers image quality comparable to JPEG-2000 with computational and memory performance more closely comparable to JPEG",
Is this taken from MS presentation? seems it is not truth. Is independent reaserch availible ? —Preceding unsigned comment added by 78.26.156.207 ( talk) 16:55, 16 September 2010 (UTC)
I am looking at the sidebar. How is it possible that the latest release was before the initial release? Is this a mistake? —Preceding unsigned comment added by Mikez302 ( talk • contribs) 05:09, 1 October 2010 (UTC)
This article is not a standalone list. Therefore, it may have a number of items without a Wikipedia articles, just for the sake of having broad coverage on the matter, especially in the light of the fact that the total number of supporting software isn't so high to threaten a violation of WP:INDISCRIMINATE.
In time, I think I have found independent sources on some of the items. I am about to add them to the article. Fleet Command ( talk) 17:33, 29 September 2011 (UTC)
The section "Support for more color accuracy" does not mention all the colour modes supported. I just added the other day that it supports RGB555 and RGB565. It also supports YUV however and premultiplied alpha. It seems like it would make the section a bit long and hard to read if i added another paragraph explaining this. I've created a table showing all colour modes supported that I reckon makes things a bit easier to understand. Below is a proposal for a replacement for that section.
--start--
JPEG XR supports a wide range of color formats including RGB, YUV, CMYK and RGBE in a range of color depths. Color data can also be stored as unsigned integers, floating points or fixed points. It also contains support for alpha channels as well as an arbitrary of extra channels. The table below represents a comprehensive list of pixel format supported in JPEG XR.
Color Modes | Integer | Floating Point | Fixed Point | Optional Alpha Channel |
---|---|---|---|---|
1-bit (Monochrome) | Yes | No | No | No |
8-bit Grayscale | Yes | No | No | No |
16-bit Grayscale | Yes | Yes | Yes | No |
32-bit Grayscale | No | Yes | Yes | No |
24-Bit RGB | Yes | No | No | Yes |
48-Bit RGB | Yes | Yes | Yes | Yes |
96-Bit RGB | No | Yes [1] | Yes | Yes |
16-Bit RGB555 | Yes | No | No | No |
16-Bit RGB565 | Yes | No | No | No |
32-Bit RGB101010 | Yes | No | No | No |
64-Bit RGB | No | Yes | Yes | No |
128-Bit RGB | No | Yes | Yes | No |
32-Bit CMYK | Yes | No | No | Yes |
64-Bit CMYK | Yes | No | No | Yes |
12-Bit YUV420 | Yes | No | No | Yes |
16-Bit YUV422 | Yes | No | No | Yes |
20-Bit YUV422 | Yes | No | No | Yes |
24-Bit YUV444 | Yes | No | No | Yes |
48-Bit YUV444 | Yes | No | Yes | Yes |
30-Bit YUV444 | Yes | No | No | Yes |
32-Bit RGBE | No | Yes | No | No |
8-Bit N-Channels | Yes | No | No | Yes |
16-Bit N-Channels | Yes | No | No | Yes |
In addition to the pixel formats listed above JPEG XR also has some support for BGR channel ordering and Pre-multiplied alpha.
--end--
Does this read okay to everybody? I might go ahead and add it to the article if there are no objections after a few days. Myutwo33 ( talk) 20:13, 12 October 2011 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on JPEG XR. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 00:06, 19 September 2017 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on JPEG XR. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 22:21, 18 November 2017 (UTC)
I almost didn't notice it honestly, but when not logged in, this article is served with most of the navigation links in chinese. Inspecting the source shows the root html tag has lang="zh-Hans-CN"
, and several script and stylesheet links contain href="https://en.wikipedia.org/w/load.php?lang=zh-cn..."
at the beginning of their url. Some content elements contain a lang="en"
tag though, the article content is all in english, and the dns server name is en.wikipedia.org. Nothing in the article source appears to reference language, chinese or otherwise.
I can't find any reference about non-content issues, maybe I'll have to contact OTRS? I'm running Firefox 73.0.1 on Manjaro Linux, but it seems unlikely to just be me, as every other page loads in english as normal, and this one persists after clearing cache and rebooting. -- Vickas54 ( talk) 07:13, 29 February 2020 (UTC)