Search Results

Search found 16 results on 1 pages for 'lzw'.

Page 1/1 | 1 

  • Splitting TIFF Files on different formats using .NET

    - by Jojo
    HI All, I have below code to extract a single page from a multi-paged TIFF file. The problem is, the input file is in CCITT Group 4 compression however the output compression is LZW. Can .NET outputs TIFF files other than this compression? FileStream fileStream = File.Open(outputFileName, FileMode.Create, FileAccess.ReadWrite); sourceImage.SelectActiveFrame(firstFrameDimension, pageNumbers[i]); sourceImage.Save(fileStream, ImageFormat.Tiff); fileStream.Close();

    Read the article

  • Is there a way to initialize ImageKit's IKSaveOptions to default to TIFF with LZW compression?

    - by Rei
    I'm using Mac OS X 10.6 SDK ImageKit's IKSaveOptions to add the file format accessory to an NSSavePanel using: - (id)initWithImageProperties:(NSDictionary *)imageProperties imageUTType:(NSString *)imageUTType; and - (void)addSaveOptionsAccessoryViewToSavePanel:(NSSavePanel *)savePanel; I have tried creating an NSDictionary to specify Compression = 5, but I cannot seem to get the IKSaveOptions to show Format:TIFF, Compression:LZW when the NSSavePanel first appears. I've also tried saving the returned imageProperties dictionary and the userSelection dictionary, and then tried feeding that back in for the next time, but the NSSavePanel always defaults to Format:TIFF with Compression:None. Does anyone know how to customize the default format/compression that shows up in the accessory view? I would like to default the save options to TIFF/LZW and furthermore would like to restore the user's last file format choice for next time. I am able to control the file format using the imageUTType (e.g. kUTTypeJPEG, kUTTypePNG, kUTTypeTIFF, etc) but I am still unable to set the initial compression option for TIFF or JPEG formats. Thanks, -Rei

    Read the article

  • Dynamically generated PDF files working in most readers except Adobe Reader

    - by Shane
    I'm trying to dynamically generate PDFs from user input, where I basically print the user input and overlay it on an existing PDF that I did not create. It works, with one major exception. Adobe Reader doesn't read it properly, on Windows or on Linux. QuickOffice on my phone doesn't read it either. So I thought I'd trace the path of me creating the files - 1 - Original PDF of background PDF 1.2 made with Adobe Distiller with the LZW encoding. I didn't make this. 2 - PDF of background PDF 1.4 made with Ghostscript. I used pdf2ps then ps2pdf on the above to strip LZW so that the reportlab and pyPDF libraries would recognize it. Note that this file looks "fuzzy," like a bad scan, in Adobe Reader, but looks fine in other readers. 3 - PDF of user-input text formatted to be combined with background PDF 1.3 made with Reportlab from user input. Opens properly and looks good in every reader I've tried. 4 - Finished PDF PDF 1.3 made from PyPDF's mergePage() function on 2 and 3. Does not open in: Adobe Reader for Windows Adobe Reader for Linux QuickOffice for Android Opens perfectly in: Google Docs' PDF viewer on the web evince for linux ghostscript viewer for linux Foxit reader for Windows Preview for Mac Are there known issues that I should know about? I don't know exactly what "flate" is, but from the internet I gather that it's some sort of open source alternative to LZW for PDF compression? Could that be causing my problem? If so, are there any libraries I could use to fix the cause in my code?

    Read the article

  • Separation of multipage tiff with compression "CCITT T.6" very slow

    - by Alex
    I need to separate multiframe tiff files, and use the following method: public static Image[] GetFrames(Image sourceImage) { Guid objGuid = sourceImage.FrameDimensionsList[0]; FrameDimension objDimension = new FrameDimension(objGuid); int frameCount = sourceImage.GetFrameCount(objDimension); Image[] images = new Image[frameCount]; for (int i = 0; i < frameCount; i++) { MemoryStream ms = new MemoryStream(); sourceImage.SelectActiveFrame(objDimension, i); sourceImage.Save(ms, ImageFormat.Tiff); images[i] = Image.FromStream(ms); } return images; } It works fine, but if the source image was encoded using the CCITT T.6 compression, separating a 20-frame-file takes up to 15 seconds on my 2,5ghz CPU.(edit: One core is at 100% during the process) When saving the images afterward to a single file using standard compression (LZW), the separation time of the LZW-file is under 1 second. Saving with CCITT compression also takes very long. Is there a way to speed up the process?

    Read the article

  • What does ZIP stand for (the compression format, not the postal codes)

    - by codymanix
    Does anybody know for what the acronym ZIP stands for which was and is used in programs like PKZIP and GZIP? There is a compression algorithm named Lempel-Ziv-Welch-Algorithm (LZW) maybe the guy named Ziv invented together with other people ZIP? I cannot find anything about it, maybe its not an abbreviation but instead it just means "to zip files" but I think originally there was more about it..

    Read the article

  • Why is HTML/Javascript minification beneficial

    - by Channel72
    Why is HTML/Javascript minification beneficial when the HTTP protocol already supports gzip data compression? I realize that Javascript/HTML minification has the potential to significantly reduce the size of Javascript/HTML files by removing unnecessary whitespace, and perhaps renaming variables to a few letters each, but doesn't the LZW algorithm do especially well when there are many repeated characters (e.g. lots of whitespace?) I realize that some Javascript minification tools do more than just reduce size. Google's closure compiler, for example, also tries to improve code performance by inlining functions and doing other analyses. But the primary purpose of Javascript minification is usually to reduce file size. I also realize there are other reasons you might want to minify aside from performace, such as code obfuscation. But again, that reason is not usually emphasized as much as performance gain and file size reduction. For example, Closure Compiler is not advertised as an obfuscation tool, but as a code size reducer and download-speed enhancer. So, how much performance do you really gain from Javascript/HTML minification when you're already significantly reducing file size with gzip compression?

    Read the article

  • Compressing/compacting messages over websocket on Node.js

    - by icelava
    We have a websocket implementation (Node.js/Sock.js) that exchanges data as JSON strings. As our use cases grow, so have the size of the data transmitted across the wire. The websocket protocol does not natively offer any compression feature, so in order to reduce the size of our messages we'd have to manually do something about the serialisation. There appear to be a variety of LZW implementations in Javascript, some which confuses me on their compatibility for in-browser use only versus transmission across the wire due to my lack of understanding on low-level encodings. More importantly, all of them seem to take a noticeable performance drag when Javascript is the engine doing the compression/decompression work, which is not desirable for mobile devices. Looking instead other forms of compact serialisation, MessagePack does not appear to have any active support in Javascript itself; BSON does not have any Javascript implementation; and an alternative BISON project that I tested does not deserialise everything back to their original values (large numbers), and it does not look like any further development will happen either. What are some other options others have explored for Node.js?

    Read the article

  • Problem on Windows 7 using Image.FromStream to open cmyk+alpha tiff file

    - by Stefan Andersson
    I'm having a problem running the following code om Windows 7 x86 when creating an Image from a lzw encoded cmyk + alpha TIFF file. The FromStream call throws a System.ArgumentException: Parameter is not validRunning When I run the code on Vista or Server 2008 (both x86 and x64 bit) it just works. using System; using System.Drawing; using System.Drawing.Imaging; . . . using (FileStream stream = File.OpenRead(fileName)) { using (Image image = Image.FromStream(stream, false, false)) { // Do something with the image } }

    Read the article

  • C#/.NET: Separation of multipage tiff with compression "CCITT T.6" very slow

    - by Alex B
    I need to separate multiframe tiff files, and use the following method: public static Image[] GetFrames(Image sourceImage) { Guid objGuid = sourceImage.FrameDimensionsList[0]; FrameDimension objDimension = new FrameDimension(objGuid); int frameCount = sourceImage.GetFrameCount(objDimension); Image[] images = new Image[frameCount]; for (int i = 0; i < frameCount; i++) { MemoryStream ms = new MemoryStream(); sourceImage.SelectActiveFrame(objDimension, i); sourceImage.Save(ms, ImageFormat.Tiff); images[i] = Image.FromStream(ms); } return images; } It works fine, butt if the source was encoded using the CCITT T.6 compression, separating a 20-frame-file takes up to 15 seconds on my 2,5ghz CPU. Saving the images afterwards to a single file using standard compression (LZW), the separation time is under 1 second. Is there a way to speed up the process?

    Read the article

  • .NET Multipage Tiff with Lossy Compression

    - by Adam Berent
    I need a way to take several jpgs and convert them into a single multi page Tiff. I have that working using GDI+ however it only works with the compression LZW which is lossless. This means that my 3 50KB Jpgs turn into 3MB multipage Tiff file. This is not something I can accept for the software that I am working on. I know that Tiff Image format can use a JPG compression scheme but GDI+ does not seem to support this. If anyone knows how to do this in .NET (C#) or of any component that does this conversion.

    Read the article

  • Getting animated gif data in c or c++

    - by Pickles
    I'm trying to get the frames (properly decoded) and the frames delay times from an animated gif. I've opened up the code to gifsicle and have also tried lungif but I'm not accustomed to c code and I'm having a difficult time following the logic. I've also tried other examples and I've gotten one to work but it didn't do the proper LZW decoding. Can anyone give me a quick example of how to do this? I'm building this app in xcode and trying to get an NSArray of the image frames. Thanks.

    Read the article

  • Producing CCITT compressed TIFF from CGImage

    - by Brian Postow
    I have a CGImage (core graphics, C/C++). It's grayscale. Well, originally it was B/W, but the CGImage may be RGB. That shouldn't matter. I want to create a CCITT-Group 4 TIFF. I can create an LZW TIFF (grayscale or color) via creating a destination with the correct dictionary and adding the image in. No problem. However, there doesn't seem to be an equivalent kCGImagePropertyTIFFCompression value to represent CCITT-4. It should be 4, but that produces uncompressed. I have a manual CCITT compression routine, so if I can get the binary (1 bit per pixel) data, I'm set. But I can't seem to get 1 BPP data out of a CGImage. I have code that is supposed to put the CGImage into a CGBitmapContext and then give me the data, but it seems to be giving me all black. I've asked a couple of questions today trying to get at this, but I just figured, lets ask the question I REALLY want answered and see if someone can answer it. There's GOT to be a way to do this. I've got to be missing something dumb. What is it?

    Read the article

  • Generate jpeg compressed Tiff using RGB colorspace (using Java + JAI)

    - by nOiSe gaTe
    I'm trying to make tiled pyramidal tiffs from master tiff images using Java (JAI 1.1.3 + imageIO). The problem is: I NEED to make tiff files compressed in jpeg with RGB photometric interpretation and no matter what I try, the image still faces YCbCr photometric interpretation. Note: if I change compression type (eg. LZW or Deflate) I can get RGB colorspace but, as I said, I need jpeg compression. Except this detail the tiled PTiff I create it's ok, so I think it's better to focus the attention on simple compression step (uncompressed tiff -- jpeg tiff) this may be a basic example (removing any check to make it more readable) // reading MASTER BufferedImage img = ImageIO.read(uncompressedTiff); ImageOutputStream ios=null; ImageWriter writer=null; ios = ImageIO.createImageOutputStream(outFile); Iterator <ImageWriter> writers = ImageIO.getImageWritersByFormatName("tiff"); writer = writers.next(); // saving and compression params writer.setOutput(ios); ImageWriteParam param = writer.getDefaultWriteParam(); param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT); param.setCompressionType("JPEG"); param.setCompressionQuality(0.8f); param.setTilingMode(ImageWriteParam.MODE_EXPLICIT); param.setTiling(256, 256, 0, 0); IIOMetadata metadata = getWriteMD(writer, param); // writing writer.write(metadata, new IIOImage(img, null, metadata), param); in getWriteMD method: .... TIFFTag photoInterp = base.getTag(BaselineTIFFTagSet.TAG_PHOTOMETRIC_INTERPRETATION); TIFFField fieldPhotoInter = new TIFFField(photoInterp, BaselineTIFFTagSet.PHOTOMETRIC_INTERPRETATION_RGB); .... here is the full version of getWriteMD()

    Read the article

1