fjcore - Project Hosting on Google Code

Earlier this year Sep 08, 2009 issue 11 (Not able to generate image at 300 dpi resolution) reported by offlinester - Not able to generate image at 300 dpi resolution Not able to generate image at 300 dpi resolution Aug 23, 2009 issue 3 (Hierarchical JPEG Support) commented on by gilad.kapel - Hi, As for SL3 (and WPF) it is impossible to get a preview of a 'progressive jpeg'. This can be a very useful feature with large images that take allot of time to download. This was actually the reason I came upon this utility and would be very happy to see this feature as part of the fjcore in the future. Gilad. Hi, As for SL3 (and WPF) it is impossible to get a preview of a 'progressive jpeg'. This can be a very useful feature with large images that take allot of time to download. This was actually the reason I came upon this utility and would be very happy to see this feature as part of the fjcore in the future. Gilad. Aug 13, 2009 issue 9 (ProgressChanged event never fires on ImageResizer?) commented on by bdonphi...@gmail.com - FYI, this was an easy fix as well. The ImageResizer's "ResizeProgressChanged" Event Handler was never being attached to the resizeFilter.ProgressChanged event. FYI, this was an easy fix as well. The ImageResizer's "ResizeProgressChanged" Event Handler was never being attached to the resizeFilter.ProgressChanged event. Aug 12, 2009 issue 10 (Resize not to scale?) reported by bdonphi...@gmail.com - Probably not a high priority request, but I just easily changed FjCore (all credit to a well-written library) to allow me to resize a photo to specific dimensions (stretch/squeeze) rather than to the same scale. We'd like our users to upload at 3x4 ratio, but it doesn't always happen and if not, we squash their photo rather than crop it. I renamed Resize to ResizeToScale which is not backwards compatible, but you could probably just add a ResizeToDimensions or something to Resizer. The quality is very good, from what I can tell. Your library has been great! Probably not a high priority request, but I just easily changed FjCore (all credit to a well-written library) to allow me to resize a photo to specific dimensions (stretch/squeeze) rather than to the same scale. We'd like our users to upload at 3x4 ratio, but it doesn't always happen and if not, we squash their photo rather than crop it. I renamed Resize to ResizeToScale which is not backwards compatible, but you could probably just add a ResizeToDimensions or something to Resizer. The quality is very good, from what I can tell. Your library has been great! Aug 10, 2009 issue 9 (ProgressChanged event never fires on ImageResizer?) reported by bdonphi...@gmail.com - What steps will reproduce the problem? 1. instantiate an ImageResizer 2. attach a handler to the resizer's ProgressChanged event 3. Resize an image What is the expected output? What do you see instead? Expected progress updates via the event, but it was never thrown. Please provide any additional information below. Looking at the ImageResizer source, it seems like the ResizeProgressChanged handler event is never attached/thrown, so it would never report progress. Is this something that may come in future versions? What steps will reproduce the problem? 1. instantiate an ImageResizer 2. attach a handler to the resizer's ProgressChanged event 3. Resize an image What is the expected output? What do you see instead? Expected progress updates via the event, but it was never thrown. Please provide any additional information below. Looking at the ImageResizer source, it seems like the ResizeProgressChanged handler event is never attached/thrown, so it would never report progress. Is this something that may come in future versions? Jul 31, 2009 issue 8 (DivideByZeroException when passing in 0 quality) reported by Daniel.L.Friedman - What steps will reproduce the problem? 1. Using the .NET ImageTools library which uses fjcore WriteableBitmap bitmap = new WriteableBitmap(pictureElement, null); ImageTools.Image image = bitmap.ToImage(); MemoryStream stream = new MemoryStream(); JpegEncoder encoder = new JpegEncoder(); encoder.Encode(image, stream); What is the expected output? What do you see instead? EXPECTED: Image is encoded ACTUAL: Attempted to divide by zero. at FluxJpeg.Core.DCT.Initialize(Int32 quality) at FluxJpeg.Core.DCT..ctor(Int32 quality) at FluxJpeg.Core.Encoder.JpegEncoder..ctor(DecodedJpeg decodedJpeg, Int32 quality, Stream outStream) at ImageTools.IO.Jpeg.JpegEncoder.Encode(Image image, Stream stream) I used .NET Reflector to determine that they are passing in 0 for quality, which fjcore will change to 1. What version of the product are you using? On what operating system? ImageTools 0.1: http://imagetools.codeplex.com/Release/ProjectReleases.aspx? ReleaseId=30309#DownloadId=75694 Not sure what version of fjcore they are using. Win7 RC. Please provide any additional information below. What steps will reproduce the problem? 1. Using the .NET ImageTools library which uses fjcore WriteableBitmap bitmap = new WriteableBitmap(pictureElement, null); ImageTools.Image image = bitmap.ToImage(); MemoryStream stream = new MemoryStream(); JpegEncoder encoder = new JpegEncoder(); encoder.Encode(image, stream); What is the expected output? What do you see instead? EXPECTED: Image is encoded ACTUAL: Attempted to divide by zero. at FluxJpeg.Core.DCT.Initialize(Int32 quality) at FluxJpeg.Core.DCT..ctor(Int32 quality) at FluxJpeg.Core.Encoder.JpegEncoder..ctor(DecodedJpeg decodedJpeg, Int32 quality, Stream outStream) at ImageTools.IO.Jpeg.JpegEncoder.Encode(Image image, Stream stream) I used .NET Reflector to determine that they are passing in 0 for quality, which fjcore will change to 1. What version of the product are you using? On what operating system? ImageTools 0.1: http://imagetools.codeplex.com/Release/ProjectReleases.aspx? ReleaseId=30309#DownloadId=75694 Not sure what version of fjcore they are using. Win7 RC. Please provide any additional information below. Jul 28, 2009 issue 4 (CMYK Support) commented on by andr.pierini - YEs please, support that YEs please, support that Jul 08, 2009 issue 7 (RGBA Support) reported by maldi...@terra.es - the only way to work with this in c# is with a wrapper to c libraries. Microsoft doesn`t support this. it would be great if fjcore support this. the only way to work with this in c# is with a wrapper to c libraries. Microsoft doesn`t support this. it would be great if fjcore support this. Jun 23, 2009 issue 6 (Decoder bug: black and grabled/dotted images) reported by snakeware95 - What steps will reproduce the problem? 1. new FluxJpeg.Core.Decoder.JpegDecoder(fileStream).Decode() 2. Save file What is the expected output? What do you see instead? I expect an image that looks like the input. Instead it is black and grabled/dotted; see attached file: output.jpg What version of the product are you using? On what operating system? Current, on Vista Please provide any additional information below. Decoding the image with .NET lib give expected/correct result: System.Drawing.Bitmap.FromStream(fileStream)) Use the attached 321.jpg image as input. What steps will reproduce the problem? 1. new FluxJpeg.Core.Decoder.JpegDecoder(fileStream).Decode() 2. Save file What is the expected output? What do you see instead? I expect an image that looks like the input. Instead it is black and grabled/dotted; see attached file: output.jpg What version of the product are you using? On what operating system? Current, on Vista Please provide any additional information below. Decoding the image with .NET lib give expected/correct result: System.Drawing.Bitmap.FromStream(fileStream)) Use the attached 321.jpg image as input. Jun 17, 2009 issue 3 (Hierarchical JPEG Support) commented on by marauderz - That's an interesting find indeed tgreenfield, I have this urge to start throwing all the files I have from my camera at it and see what sticks but I'm a bit tied up now. That's an interesting find indeed tgreenfield, I have this urge to start throwing all the files I have from my camera at it and see what sticks but I'm a bit tied up now. Jun 17, 2009 issue 3 (Hierarchical JPEG Support) commented on by marauderz - That's an interesting find indeed tgreenfield, I have this urge to start throwing all the files I have from my camera at it and see what sticks but I'm a bit tied up now. That's an interesting find indeed tgreenfield, I have this urge to start throwing all the files I have from my camera at it and see what sticks but I'm a bit tied up now. Jun 14, 2009 issue 3 (Hierarchical JPEG Support) commented on by tgreenfield - I did more research and found that actually very few pictures kicking on the hierarchtical exception. Unfortunately, I can't seem to find any rhyme or reason to which ones do. Pictures from the same carmera (Canon Digital Rebel) will work just fine; it just depends on the picture. Unfortunately, I don't know the history of the file so I'm not sure if it's ever been post-processed. I also noticed that if I open an offending file in photoshop and resave it doesn't not have the problem anymore. Which makes me wonder if maybe there a bug in the decoder library and the file is actually not hierarchtical? Just a thought. I attached a file that causes the exception if anyone wants to take a look. I did more research and found that actually very few pictures kicking on the hierarchtical exception. Unfortunately, I can't seem to find any rhyme or reason to which ones do. Pictures from the same carmera (Canon Digital Rebel) will work just fine; it just depends on the picture. Unfortunately, I don't know the history of the file so I'm not sure if it's ever been post-processed. I also noticed that if I open an offending file in photoshop and resave it doesn't not have the problem anymore. Which makes me wonder if maybe there a bug in the decoder library and the file is actually not hierarchtical? Just a thought. I attached a file that causes the exception if anyone wants to take a look. May 25, 2009 issue 3 (Hierarchical JPEG Support) commented on by marauderz - My camera is a Sony Alpha 350, it's one year old. tgreenfield : I too feel uneasy about requesting for the feature support. But... it's not something that I can fix myself. My camera is a Sony Alpha 350, it's one year old. tgreenfield : I too feel uneasy about requesting for the feature support. But... it's not something that I can fix myself. May 25, 2009 issue 3 (Hierarchical JPEG Support) Labels changed by jeff.powers - This format will be supported soon. However, until these comments I haven't been aware of a single camera that uses this format. It'd be interesting to find out how prevalent this format actually is. marauderz, what model is your camera? Labels: Priority-Medium −Priority-Low This format will be supported soon. However, until these comments I haven't been aware of a single camera that uses this format. It'd be interesting to find out how prevalent this format actually is. marauderz, what model is your camera? Labels: Priority-Medium −Priority-Low May 25, 2009 issue 3 (Hierarchical JPEG Support) commented on by tgreenfield - I feel a little odd asking for anything after getting this whole fantastic jpg library for free but I do have to agree with marauderz, that many images that come from cameras appear to be hierarctical (whatever that is, I just know it throws an exception about it). This puts a big dent in the ability to use the library if certain users essentially won't be able to use it for any of this own photos. Hopefully the vast majority of pics are not like this but I know that just trying my own photos, I was able to easily find some that were hierarchtical. It's going to be an interesting challenge to explain to average Joe why their friend's jpg will load but their's won't. Aside from that, great library; fantastic job! I feel a little odd asking for anything after getting this whole fantastic jpg library for free but I do have to agree with marauderz, that many images that come from cameras appear to be hierarctical (whatever that is, I just know it throws an exception about it). This puts a big dent in the ability to use the library if certain users essentially won't be able to use it for any of this own photos. Hopefully the vast majority of pics are not like this but I know that just trying my own photos, I was able to easily find some that were hierarchtical. It's going to be an interesting challenge to explain to average Joe why their friend's jpg will load but their's won't. Aside from that, great library; fantastic job! May 10, 2009 issue 3 (Hierarchical JPEG Support) commented on by marauderz - Would just like to point out that as I was testing the library against JPEG images produced by my camera, the images were all of the Hierarchical type. Considering how this library would be utilized by people to do client side resizing of images. I' think this might be a higher priority then low? Would just like to point out that as I was testing the library against JPEG images produced by my camera, the images were all of the Hierarchical type. Considering how this library would be utilized by people to do client side resizing of images. I' think this might be a higher priority then low? May 01, 2009 issue 2 (Memory usage) commented on by phil.pat...@btinternet.com - Hi Jeff, thanks for picking this up. If you need any help please let me know. Regards, Phil Hi Jeff, thanks for picking this up. If you need any help please let me know. Regards, Phil Apr 23, 2009 issue 2 (Memory usage) Labels changed by jeff.powers - Labels: Priority-High −Priority-Medium Labels: Priority-High −Priority-Medium Apr 23, 2009 issue 5 (Encoding a 8-bit Grayscale jpg fails (colorspace conversion ...) changed by jeff.powers - Will make sure this is fixed ASAP. Owner: jeff.powers Labels: Priority-High −Priority-Medium Will make sure this is fixed ASAP. Owner: jeff.powers Labels: Priority-High −Priority-Medium Apr 23, 2009 issue 4 (CMYK Support) Status changed by jeff.powers - Status: Accepted Status: Accepted Apr 23, 2009 issue 3 (Hierarchical JPEG Support) Labels changed by jeff.powers - Labels: Type-Enhancement −Type-Defect Labels: Type-Enhancement −Type-Defect Apr 23, 2009 issue 3 (Hierarchical JPEG Support) changed by jeff.powers - It's not part of the baseline spec as far as I know, but it would be a nice addition. Lower priority than some other updates, though, like reducing memory footprint. Status: Accepted Labels: Priority-Low −Priority-Medium It's not part of the baseline spec as far as I know, but it would be a nice addition. Lower priority than some other updates, though, like reducing memory footprint. Status: Accepted Labels: Priority-Low −Priority-Medium Apr 08, 2009 issue 5 (Encoding a 8-bit Grayscale jpg fails (colorspace conversion ...) commented on by snakeware95 - Here is the file i decode, resize and re-encode. Here is the file i decode, resize and re-encode. Mar 03, 2009 issue 5 (Encoding a 8-bit Grayscale jpg fails (colorspace conversion ...) reported by snakeware95 - What steps will reproduce the problem? 1. Try to encode a 8-bit Grayscale jpg What is the expected output? What do you see instead? Expected: Encoded image. Actual: IndexOutOfException on Encoding (Line 261, "CompressTo"-method). What version of the product are you using? On what operating system? Original version (v1.0?) on. Vista Business SP1 Please provide any additional information below. This is a Resubmit with more info. I first reported it as a comment on issue 1 : --- Comment 1 by snakeware95, Feb 03, 2009 Also there is a bug in the JpegEncoder constructor converting (8-bit) Grayscale images. Replace: _input.Image.ChangeColorSpace(ColorSpace.YCbCr); With this to fix: _input = new DecodedJpeg(_input.Image.ChangeColorSpace(ColorSpace.YCbCr), _input.MetaHeaders); --- Comment 3 by jeff.powers, Feb 19, 2009 snakeware95: the colorspace change happens in-place so I think that edit isn't needed. resubmit a bug if problems remain. --- The colorspace change itself is not the problem, but the properties of the surrounding DecodedJpeg (BlockWidth array f.e.) are not updated (still 1 component). So when you loop over them using the Image.ComponentCount (which is 3 after the conversion) in "CompressTo", you get an IndexOutOfException on Encoding (Line 261, "CompressTo"-method). Please try it yourself! What steps will reproduce the problem? 1. Try to encode a 8-bit Grayscale jpg What is the expected output? What do you see instead? Expected: Encoded image. Actual: IndexOutOfException on Encoding (Line 261, "CompressTo"-method). What version of the product are you using? On what operating system? Original version (v1.0?) on. Vista Business SP1 Please provide any additional information below. This is a Resubmit with more info. I first reported it as a comment on issue 1 : --- Comment 1 by snakeware95, Feb 03, 2009 Also there is a bug in the JpegEncoder constructor converting (8-bit) Grayscale images. Replace: _input.Image.ChangeColorSpace(ColorSpace.YCbCr); With this to fix: _input = new DecodedJpeg(_input.Image.ChangeColorSpace(ColorSpace.YCbCr), _input.MetaHeaders); --- Comment 3 by jeff.powers, Feb 19, 2009 snakeware95: the colorspace change happens in-place so I think that edit isn't needed. resubmit a bug if problems remain. --- The colorspace change itself is not the problem, but the properties of the surrounding DecodedJpeg (BlockWidth array f.e.) are not updated (still 1 component). So when you loop over them using the Image.ComponentCount (which is 3 after the conversion) in "CompressTo", you get an IndexOutOfException on Encoding (Line 261, "CompressTo"-method). Please try it yourself! Mar 02, 2009 issue 4 (CMYK Support) reported by michael.a.cartwright - 4 color component mode is part of "baseline" specification. It would be great to have it supported. 4 color component mode is part of "baseline" specification. It would be great to have it supported. Mar 02, 2009 issue 3 (Hierarchical JPEG Support) reported by michael.a.cartwright - How hard would it be to add hierarchical JPEG support? Is hierarchical Jpeg part of the "baseline" spec? Happy to help if possible. How hard would it be to add hierarchical JPEG support? Is hierarchical Jpeg part of the "baseline" spec? Happy to help if possible. Feb 19, 2009 issue 1 (Bug in color space conversion) Status changed by jeff.powers - Resolved with revision 9. snakeware95: the colorspace change happens in-place so I think that edit isn't needed. resubmit a bug if problems remain. Status: Fixed Resolved with revision 9. snakeware95: the colorspace change happens in-place so I think that edit isn't needed. resubmit a bug if problems remain. Status: Fixed Feb 19, 2009 r9 (Resolving issue 1) committed by jeff.powers - Resolving issue 1 Resolving issue 1 Feb 19, 2009 r8 (Adding a new resize method - LowpassAntiAlias - which helps ...) committed by jeff.powers - Adding a new resize method - LowpassAntiAlias - which helps reduce jaggy aliasing effects. Adding other filters is a high priority. Adding a new resize method - LowpassAntiAlias - which helps reduce jaggy aliasing effects. Adding other filters is a high priority. Feb 19, 2009 r7 ([No log message]) committed by jeff.powers - [No log message] [No log message] Feb 19, 2009 issue 2 (Memory usage) changed by jeff.powers - Status: Accepted Owner: jeff.powers Status: Accepted Owner: jeff.powers Feb 19, 2009 issue 1 (Bug in color space conversion) changed by jeff.powers - Status: Accepted Owner: jeff.powers Status: Accepted Owner: jeff.powers Feb 03, 2009 issue 1 (Bug in color space conversion) commented on by snakeware95 - Also there is a bug in the JpegEncoder constructor converting (8-bit) Grayscale images. Replace: _input.Image.ChangeColorSpace(ColorSpace.YCbCr); With this to fix: _input = new DecodedJpeg(_input.Image.ChangeColorSpace(ColorSpace.YCbCr), _input.MetaHeaders); Also there is a bug in the JpegEncoder constructor converting (8-bit) Grayscale images. Replace: _input.Image.ChangeColorSpace(ColorSpace.YCbCr); With this to fix: _input = new DecodedJpeg(_input.Image.ChangeColorSpace(ColorSpace.YCbCr), _input.MetaHeaders); Older Dec 18, 2008 issue 2 (Memory usage) reported by phil.pa...@btinternet.com - What steps will reproduce the problem? 1. Run the fjexample silverlight sample code. 2. Open task manager and watch iexplore.exe process. 3. Upload a large file. What is the expected output? What do you see instead? Memory usage leaps when decoding the jpeg but should drop after resizing. Unfotunately memory usage remains high. What version of the product are you using? On what operating system? Using latest source code running on Vista Business, IE 7.0. Running the fjexample silverlight project. Please provide any additional information below. When running the http://fluxcapacity.net/fluxtools/emailphotos/ demo, memory usage DOES drop - is there some cleanup code that we need to implement, or should we use fjcore in a different way to that in fjexample? Our testing has led us to believe that calling "new JpegDecoder (fileStream).Decode()" is the problem. What steps will reproduce the problem? 1. Run the fjexample silverlight sample code. 2. Open task manager and watch iexplore.exe process. 3. Upload a large file. What is the expected output? What do you see instead? Memory usage leaps when decoding the jpeg but should drop after resizing. Unfotunately memory usage remains high. What version of the product are you using? On what operating system? Using latest source code running on Vista Business, IE 7.0. Running the fjexample silverlight project. Please provide any additional information below. When running the http://fluxcapacity.net/fluxtools/emailphotos/ demo, memory usage DOES drop - is there some cleanup code that we need to implement, or should we use fjcore in a different way to that in fjexample? Our testing has led us to believe that calling "new JpegDecoder (fileStream).Decode()" is the problem. Dec 04, 2008 issue 1 (Bug in color space conversion) reported by db...@yahoo.com - Hi, The color space conversion from YCbCr to RGB simply does not work (Image.ChangeColorSpace). The actual code is: else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) { ycbcr[0] = (byte)_raster[0][x, y]; // 0 is LUMA ycbcr[1] = (byte)_raster[1][x, y]; // 1 is BLUE ycbcr[2] = (byte)_raster[2][x, y]; YCbCr.fromRGB(rgb, ycbcr); YCbCr.toRGB(ycbcr, rgb); _raster[0][x, y] = ycbcr[0]; _raster[1][x, y] = ycbcr[1]; _raster[2][x, y] = ycbcr[2]; } _cm.colorspace = ColorSpace.RGB; } I found two bugs: 1) The "FromRGB" call must be removed, since it will overwrite the YCbCr array data with converted values from the previous RGB pixel, 2) The final assignment to the _raster array takes its value from the ycbcr array. It should be read from the rgb array. Also, it is possible to get a performance boost by avoiding to write the raster data to a temporary array, and read the converted values back after the conversion. The trick is to rewrite the "toRGB" and "fromRGB" to accept three "by- ref" byte values, one for each component. So, the _raster value could be read/written directly without the use of a temporary array. Also, the two conversion routines could be rewritten in a more optimized way by converting the byte type to the floating point type only once (and in "ToRGB", by substracting 128 from chroma components only once also, this is why I appended a "2" to the variable names: Cb2, Cr2) So, here's my new version: internal class YCbCr { public static void toRGB(ref byte c1, ref byte c2, ref byte c3) { double dY = (double)c1; double dCb2 = (double)c2 - 128; double dCr2 = (double)c3 - 128; c1 = (byte)Math.Max(0, Math.Min(255, (dY + 1.402 * dCr2))); c2 = (byte)Math.Max(0, Math.Min(255, (dY - 0.34414 * dCb2 - 0.71414 * dCr2))); c3 = (byte)Math.Max(0, Math.Min(255, (dY + 1.772 * dCb2))); } public static void fromRGB(ref byte c1, ref byte c2, ref byte c3) { double dR = (double)c1; double dG = (double)c2; double dB = (double)c3; c1 = (byte)( 0.299 * dR + 0.587 * dG + 0.114 * dB); c2 = (byte)(-0.16874 * dR - 0.33126 * dG + 0.5 * dB + 128); c3 = (byte)( 0.5 * dR - 0.41869 * dG - 0.08131 * dB + 128); } } The class still contains the (less-performant) "in-out array" version: public static void toRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; toRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } public static void fromRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; fromRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } ...but they exist only for future use, because now some parts of the ChangeColorSpace method can be rewritten to use the "ref byte" version: if (_cm.colorspace == ColorSpace.RGB && cs == ColorSpace.YCbCr) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.fromRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.YCbCr; } else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.toRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.RGB; } Of course, I deleted the local ycbcr and rgb arrays since they are no longer used. I attach the two files with this post. I would greatly appreciate to be included as a member of this very cool project. Hi, The color space conversion from YCbCr to RGB simply does not work (Image.ChangeColorSpace). The actual code is: else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) { ycbcr[0] = (byte)_raster[0][x, y]; // 0 is LUMA ycbcr[1] = (byte)_raster[1][x, y]; // 1 is BLUE ycbcr[2] = (byte)_raster[2][x, y]; YCbCr.fromRGB(rgb, ycbcr); YCbCr.toRGB(ycbcr, rgb); _raster[0][x, y] = ycbcr[0]; _raster[1][x, y] = ycbcr[1]; _raster[2][x, y] = ycbcr[2]; } _cm.colorspace = ColorSpace.RGB; } I found two bugs: 1) The "FromRGB" call must be removed, since it will overwrite the YCbCr array data with converted values from the previous RGB pixel, 2) The final assignment to the _raster array takes its value from the ycbcr array. It should be read from the rgb array. Also, it is possible to get a performance boost by avoiding to write the raster data to a temporary array, and read the converted values back after the conversion. The trick is to rewrite the "toRGB" and "fromRGB" to accept three "by- ref" byte values, one for each component. So, the _raster value could be read/written directly without the use of a temporary array. Also, the two conversion routines could be rewritten in a more optimized way by converting the byte type to the floating point type only once (and in "ToRGB", by substracting 128 from chroma components only once also, this is why I appended a "2" to the variable names: Cb2, Cr2) So, here's my new version: internal class YCbCr { public static void toRGB(ref byte c1, ref byte c2, ref byte c3) { double dY = (double)c1; double dCb2 = (double)c2 - 128; double dCr2 = (double)c3 - 128; c1 = (byte)Math.Max(0, Math.Min(255, (dY + 1.402 * dCr2))); c2 = (byte)Math.Max(0, Math.Min(255, (dY - 0.34414 * dCb2 - 0.71414 * dCr2))); c3 = (byte)Math.Max(0, Math.Min(255, (dY + 1.772 * dCb2))); } public static void fromRGB(ref byte c1, ref byte c2, ref byte c3) { double dR = (double)c1; double dG = (double)c2; double dB = (double)c3; c1 = (byte)( 0.299 * dR + 0.587 * dG + 0.114 * dB); c2 = (byte)(-0.16874 * dR - 0.33126 * dG + 0.5 * dB + 128); c3 = (byte)( 0.5 * dR - 0.41869 * dG - 0.08131 * dB + 128); } } The class still contains the (less-performant) "in-out array" version: public static void toRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; toRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } public static void fromRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; fromRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } ...but they exist only for future use, because now some parts of the ChangeColorSpace method can be rewritten to use the "ref byte" version: if (_cm.colorspace == ColorSpace.RGB && cs == ColorSpace.YCbCr) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.fromRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.YCbCr; } else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.toRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.RGB; } Of course, I deleted the local ycbcr and rgb arrays since they are no longer used. I attach the two files with this post. I would greatly appreciate to be included as a member of this very cool project. Oct 26, 2008 r6 ([No log message]) committed by jeff.powers - [No log message] [No log message] Oct 23, 2008 r5 (Adding RGB->YCbCr) committed by jeff.powers - Adding RGB->YCbCr Adding RGB->YCbCr

issue 1 (Bug in color space conversion) reported by db...@yahoo.com - Hi, The color space conversion from YCbCr to RGB simply does not work (Image.ChangeColorSpace). The actual code is: else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) { ycbcr[0] = (byte)_raster[0][x, y]; // 0 is LUMA ycbcr[1] = (byte)_raster[1][x, y]; // 1 is BLUE ycbcr[2] = (byte)_raster[2][x, y]; YCbCr.fromRGB(rgb, ycbcr); YCbCr.toRGB(ycbcr, rgb); _raster[0][x, y] = ycbcr[0]; _raster[1][x, y] = ycbcr[1]; _raster[2][x, y] = ycbcr[2]; } _cm.colorspace = ColorSpace.RGB; } I found two bugs: 1) The "FromRGB" call must be removed, since it will overwrite the YCbCr array data with converted values from the previous RGB pixel, 2) The final assignment to the _raster array takes its value from the ycbcr array. It should be read from the rgb array. Also, it is possible to get a performance boost by avoiding to write the raster data to a temporary array, and read the converted values back after the conversion. The trick is to rewrite the "toRGB" and "fromRGB" to accept three "by- ref" byte values, one for each component. So, the _raster value could be read/written directly without the use of a temporary array. Also, the two conversion routines could be rewritten in a more optimized way by converting the byte type to the floating point type only once (and in "ToRGB", by substracting 128 from chroma components only once also, this is why I appended a "2" to the variable names: Cb2, Cr2) So, here's my new version: internal class YCbCr { public static void toRGB(ref byte c1, ref byte c2, ref byte c3) { double dY = (double)c1; double dCb2 = (double)c2 - 128; double dCr2 = (double)c3 - 128; c1 = (byte)Math.Max(0, Math.Min(255, (dY + 1.402 * dCr2))); c2 = (byte)Math.Max(0, Math.Min(255, (dY - 0.34414 * dCb2 - 0.71414 * dCr2))); c3 = (byte)Math.Max(0, Math.Min(255, (dY + 1.772 * dCb2))); } public static void fromRGB(ref byte c1, ref byte c2, ref byte c3) { double dR = (double)c1; double dG = (double)c2; double dB = (double)c3; c1 = (byte)( 0.299 * dR + 0.587 * dG + 0.114 * dB); c2 = (byte)(-0.16874 * dR - 0.33126 * dG + 0.5 * dB + 128); c3 = (byte)( 0.5 * dR - 0.41869 * dG - 0.08131 * dB + 128); } } The class still contains the (less-performant) "in-out array" version: public static void toRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; toRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } public static void fromRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; fromRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } ...but they exist only for future use, because now some parts of the ChangeColorSpace method can be rewritten to use the "ref byte" version: if (_cm.colorspace == ColorSpace.RGB && cs == ColorSpace.YCbCr) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.fromRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.YCbCr; } else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.toRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.RGB; } Of course, I deleted the local ycbcr and rgb arrays since they are no longer used. I attach the two files with this post. I would greatly appreciate to be included as a member of this very cool project.

Hi, The color space conversion from YCbCr to RGB simply does not work (Image.ChangeColorSpace). The actual code is: else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) { ycbcr[0] = (byte)_raster[0][x, y]; // 0 is LUMA ycbcr[1] = (byte)_raster[1][x, y]; // 1 is BLUE ycbcr[2] = (byte)_raster[2][x, y]; YCbCr.fromRGB(rgb, ycbcr); YCbCr.toRGB(ycbcr, rgb); _raster[0][x, y] = ycbcr[0]; _raster[1][x, y] = ycbcr[1]; _raster[2][x, y] = ycbcr[2]; } _cm.colorspace = ColorSpace.RGB; } I found two bugs: 1) The "FromRGB" call must be removed, since it will overwrite the YCbCr array data with converted values from the previous RGB pixel, 2) The final assignment to the _raster array takes its value from the ycbcr array. It should be read from the rgb array. Also, it is possible to get a performance boost by avoiding to write the raster data to a temporary array, and read the converted values back after the conversion. The trick is to rewrite the "toRGB" and "fromRGB" to accept three "by- ref" byte values, one for each component. So, the _raster value could be read/written directly without the use of a temporary array. Also, the two conversion routines could be rewritten in a more optimized way by converting the byte type to the floating point type only once (and in "ToRGB", by substracting 128 from chroma components only once also, this is why I appended a "2" to the variable names: Cb2, Cr2) So, here's my new version: internal class YCbCr { public static void toRGB(ref byte c1, ref byte c2, ref byte c3) { double dY = (double)c1; double dCb2 = (double)c2 - 128; double dCr2 = (double)c3 - 128; c1 = (byte)Math.Max(0, Math.Min(255, (dY + 1.402 * dCr2))); c2 = (byte)Math.Max(0, Math.Min(255, (dY - 0.34414 * dCb2 - 0.71414 * dCr2))); c3 = (byte)Math.Max(0, Math.Min(255, (dY + 1.772 * dCb2))); } public static void fromRGB(ref byte c1, ref byte c2, ref byte c3) { double dR = (double)c1; double dG = (double)c2; double dB = (double)c3; c1 = (byte)( 0.299 * dR + 0.587 * dG + 0.114 * dB); c2 = (byte)(-0.16874 * dR - 0.33126 * dG + 0.5 * dB + 128); c3 = (byte)( 0.5 * dR - 0.41869 * dG - 0.08131 * dB + 128); } } The class still contains the (less-performant) "in-out array" version: public static void toRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; toRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } public static void fromRGB(byte[] colorIn, byte[] colorOut) { byte c1 = colorIn[0]; byte c2 = colorIn[1]; byte c3 = colorIn[2]; fromRGB(ref c1, ref c2, ref c3); colorOut[0] = c1; colorOut[1] = c2; colorOut[2] = c3; } ...but they exist only for future use, because now some parts of the ChangeColorSpace method can be rewritten to use the "ref byte" version: if (_cm.colorspace == ColorSpace.RGB && cs == ColorSpace.YCbCr) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.fromRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.YCbCr; } else if (_cm.colorspace == ColorSpace.YCbCr && cs == ColorSpace.RGB) { for (int x = 0; x < width; x++) for (int y = 0; y < height; y++) YCbCr.toRGB(ref _raster[0][x,y], ref _raster[1][x,y], ref _raster[2][x,y]); _cm.colorspace = ColorSpace.RGB; } Of course, I deleted the local ycbcr and rgb arrays since they are no longer used. I attach the two files with this post. I would greatly appreciate to be included as a member of this very cool project.

Earlier this year

Older