• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
jpeg i/o performance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

jpeg i/o performance


  • Subject: jpeg i/o performance
  • From: email@hidden
  • Date: Sun, 5 May 2002 18:34:24 -0700

I asked this earlier, but I just thought I would update people and see if I can find anyone else who cares about this issue.

I'm trying to read and write JFIF files... and finding that it seems very very slow using the standard code from IJG.

Especially when compared to the Intel JPEG library which has been hand tuned by Intel to use their SIMD extensions.

I used the super-cool CHUD tool Shikari and sampled a huge amount of reading and writing JFIF files.

I found that the bulk of the time spent writing progressive JPEGs is spent in encode_mcu_AC_refine() which is the huffman encoder. It would be great if anyone knows of any optimizations that have been done on this routine...

More interestingly, I found that when Appkit is reading JPEG files, via NSImage imageFromPath:, it spends a ton of time in _NS_jpeg_idct_islow(), which seems to indicate that there might be an _NS_jpeg_idct_fast()! I'm guessing that _islow() is an accurate integer algorithm, and that there could be one using floats that would be faster.

Also, ycc_rgb_convert is pretty hot, although I would assume that this has been hand tuned to be as fast as possible.

I also burn a lot of cycles in ColorSync's Convert8BitMtxOnlyWithLookup... and friends... This makes me think that I am specifying the wrong colorspace when I create the image that I composite the jpeg into? Should I be using Device or Calibrated?

I also spend a bunch of time in CoreGraphics' argb32_image_rgb24()... which I assume is a swizzler from ARGB to RGB... I'd be happy to waste the 25% space to get perf, however the IJG's jpeg encoder doesn't deal with unpacked RGB.

Sigh... if any of you have read this far... the issue really stems from the fact that NSImage's JPEG reading code doesn't deal well with progressive or truncated files. If anyone from apple can comment on support for this in the future, I can leave this alone...
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
  • Prev by Date: Re: Cocoa --> GnuStep
  • Next by Date: Current application
  • Previous by thread: Re: Building OmniFrameworks with PB 2.0
  • Next by thread: Current application
  • Index(es):
    • Date
    • Thread