.ipp files are HUGE!

This section is for suggesting features and capabilities that you would like to see in Impict, Help & Manual's integrated screenshot editor and enhancer.

Moderators: Alexander Halser, Tim Green

Post Reply
kdalons
Posts: 2
Joined: Mon Sep 20, 2004 9:18 pm

.ipp files are HUGE!

Unread post by kdalons »

Since .ipp files appear to be your own proprietary format, couldn't you implement some basic compression for this image filetype? The files typically compress 90+% percent, for any decent sized help file with a significant number of images, the disk space consumed becomes extreme. If these files are also checked into a scm system (typical) then it becomes even more of an issue.

I realize that you are storing additional info in this file format, but the fact that they are so compressible tells me that implementing even a basic internal compression technique could be very helpful for your average user (by dramatically reducing their average size).
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Unread post by Tim Green »

They are actually only large before you compile; they get compressed quite effectively when you actually compile your output. See this posting by Alex in Tutorials & Guides for the background information on this:

http://helpman.it-authoring.com/viewtopic.php?t=92

(BTW, the information on native formats there is out of date -- H&M now works directly with JPG, GIF and PNG)

The only reason that .IPP images are still slightly larger than some bitmaps even when compressed is that they always store the full range of colors, like JPEGs.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
kdalons
Posts: 2
Joined: Mon Sep 20, 2004 9:18 pm

Unread post by kdalons »

My question about size was directly related to pre-compile time storage, not after compilation. However, my limited testing indicates that png files are much, much smaller than their identical ipp counterparts, and remain more efficient compiled as well.

You don't store the compiled help files in an scm system, but rather the individual components. I realize that the ipp files do compress when compiled, but that isn't what I was referring to.

Regarding compiled size: I understand that ipp files have benefits that png files do not (like storing the different objects in the file independently for future editing), but it appears that the png file format is more efficient for basic images than ipp both uncompressed and compressed.

For example: I have a help file that contained several .png files. I used png files because they are so much smalller than ipp files. I compiled an .chm file and noted the size. I then converted the images to ipp files and recompiled the .chm file. Obviously the ipp files were MUCH larger than their png equivalent, but after reading your documentation, I was under the impression that the ipp files would compress better during compilation. However, the resulting .chm file grew larger using the ipp files than with the png? Any ideas on this?
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Unread post by Martin Wynne »

kdalons wrote:it appears that the png file format is more efficient
for basic images than ipp both uncompressed and compressed.
Hi,

You weigh up all the options, consider this and that, look at the pros and cons,
check which way the wind is blowing, and then you always use PNG ! :)

.png invariably gives you the best image quality for the smallest file size.
I've tried all ways, and for the best results do this:

1. Open .ipp file in Impict.

2. Save from Impict as a temporary .bmp

3. Open .bmp in PaintShopPro or similar and reduce the colour depth to 8-bit.
(Don't do this in Impict, PSP makes a much better job of it. For screenshots
the difference in appearance is minimal but the reduction in file size is massive.)

4. Save from PSP as .png

5. Insert .png in H&M.

.ipp files are big, but that's because each object is stored as a separate
bitmap and remains editable later - an advantage well worth making the
disk space for. If space is a problem, why not simply zip them until you
need them again?

Martin.
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Unread post by Tim Green »

kdalons wrote:My question about size was directly related to pre-compile time storage, not after compilation.
Hmm... do you really see this as a problem? I would have agreed 5-8 years ago when hard drives were small and expensive, but nowadays I really don't think it's much of an issue any more.
However, my limited testing indicates that png files are much, much smaller than their identical ipp counterparts, and remain more efficient compiled as well.
There are actually quite a lot of different factors that interact here, and making a final statement on this is more complicated than it looks at first glance. For all HTML-based output, your settings in Project > Project Properties > HTML Export Output > Image Conversion have a major impact on how IPP and bitmap images are handled when your projects are compiled.

Since IPP images are always True Color (and this is their limitation for some purposes, see below) it is the True Color parts of these settings that have an effect on them. Setting to "Convert to JPEG" will achieve maximum compression if most of your IPPs are photographic images; "Convert to PNG" is a better choice if your IPP images are screenshots, which always look terrible as JPEGs, because of the ugly artefacts that form at all the sharp boundaries. "Convert all images to GIF" may be even better if you have no continuous-tone images, because this will reduce everything to 256 colors.

(These settings have no effect at all on images that you add as native PNG, GIF or JPEG. These images are simply added "as-is" to HTML-based output, without any additional conversion or compression, and converted to standard bitmaps in WinHelp, which doesn't understand anything else.)

In fact, screenshots compress best and look best as 256-color GIFs, and this is the theoretical limitation of the IPP format. Since it is always True Color your screenshots with hotspots must also have 24-bit color, even though they could usually get by with 256 colors.

This might tempt you to use the old Microsoft .SHG format for 256-color screenshots with hotspots. This does reduce size slightly, but not as much as you might think, and it also prevents you from being able to use IPP's other powerful functions for macros and other code in hotspots.

For example, a small test project I just compiled was 359,841 bytes with a True Color IPP graphic with a hotspot. With the same graphic as a 256-color SHG the output file was 338,868 bytes. That is certainly a difference worth considering if you have a lot of these graphics, but if you only have a few it might not matter all that much to you. It's a decision you have to make based on your project. Also, if you have popup links in your hotspots and are generating dual-mode HTML Help with formatted WinHelp popups you must use IPP if you want popup links in your images. These popup links don't work at all in SHG images.

BTW: One thing that Impict doesn't do very well is reduce 24-bit bitmap images to 256-color SHG images. I'm not quite sure why this is, because it does it very well with other formats. When I need 256-color SHGs I save the files as 256-color BMPs with Impict or PaintShop and then load them once and save them with the SHG editor included with Microsoft Help Workshop (the WinHelp compiler).

It's certainly true that PNG is more efficient uncompiled in absolute terms on your hard disk, but that's equally true of Photoshop's PSD format or PaintShop's own layered format (which produces genuinely gigantic files that make IPP look like a model of efficiency) and that doesn't prevent me from using them when I'm working on images. Also, with current hard drive sizes and prices I really tend to see this as a non-issue, certainly for any kind of professional work.
Regarding compiled size: I understand that ipp files have benefits that png files do not (like storing the different objects in the file independently for future editing), but it appears that the png file format is more efficient for basic images than ipp both uncompressed and compressed.... For example: I have a help file that contained several .png files. I used png files because they are so much smalller than ipp files.


Again, this is a complex and very variable issue. Here are the results of a test I just performed with a test project containing one image. To avoid confusing the figures with different levels of JPEG compression I set Image Conversion to "Convert 256 color bitmaps to GIF and True Color to PNG".

True Color IPP image, convert to PNG: 359,841 bytes
True Color bitmap: 359,841bytes
256-color SHG image: 338,868
256-color bitmap: 191,497 bytes
256-color GIF image (precompressed: 190,713 bytes
PNG image, compression 5 (Impict): 491,031 bytes
PNG image, max. compression (Impict): 488,031 bytes
PNG image, PaintShop Pro: 319,041 bytes

True Color IPP image, convert to JPEG, 50% compression: 57,299 bytes

Finally, for comparison, I used the True Color bitmap image and set H&M to convert it to a JPEG with a compression level of 50%. This resulted in an output file of 191,501 bytes and the quality was fine for photographs, but naturally not very nice to look at for screenshots. Why the JPEG compression with IPP was so much better is a mystery to me at the moment...

Of course, you can go on doing tests like this forever, getting different results every time. The figures you get will depend to a very great extent on the nature of your test images. The bottom line, however, is that there really isn't all that much difference between the formats per se in terms of output size. There is not even all that much difference between a True Color IPP image and a 256-color SHG image, probably because of the nature of the old SHG format. PaintShop Pro produces slightly more compact PNG files than Impict, the same will probably hold true for PhotoShop.

The bottom line, however, is that the biggest reduction in output size is achieved by reducing the number of colors and by applying JPEG compression to True Color images (see IPP convert to JPEG at 50%!). So to make output files as small as possible use 256-color GIFs or bitmaps for all screenshots without hotspots, 256-color SHGs for screenshots with plain hotspots, IPP for screenshots with complex hotspots or popup links in dual-mode HTML help, and PNG or JPEG according to taste for True Color images. And choose your conversion and compression settings in H&M on the basis of the nature of your images.
Obviously the ipp files were MUCH larger than their png equivalent, but after reading your documentation, I was under the impression that the ipp files would compress better during compilation. However, the resulting .chm file grew larger using the ipp files than with the png? Any ideas on this?
Again, this will depend on the nature of the files and the image conversion settings in H&M. At compile time IPPs are treated as True Color bitmaps and converted accordingly. For example, if all the images in your project are screenshots without too much in the way of gradients you may be able to save a lot of space by setting "Convert all images to GIF", which will also achieve maximum compression for your IPP screenshots with hotspots because it will automatically reduce them to 256 colors.

The problem with this subject is that there are so many different variables, all of which change depending on the nature of your images. It's not really possible to make any absolute statements one way or another... Many authors swear by a specific set of formats and settings and tend to believe that these are best for everything, then someone else tries them and gets completely different results because of the type of images they use. :roll:
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Unread post by Martin Wynne »

Tim Green wrote:It's not really possible to make any absolute statements one way or another... Many authors swear by a specific set of formats and settings and tend to believe that these are best for everything, then someone else tries them and gets completely different results because of the type of images they use. :roll:
Very diplomatic, Tim. :lol:
Why not just say that Martin is talking rubbish again! :)

Martin.
User avatar
Tim Green
Site Admin
Posts: 23156
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Unread post by Tim Green »

Hi Martin,
Why not just say that Martin is talking rubbish again!
When I wrote that I was actually hoping that you wouldn't think I was talking about you, because I really wasn't. :) This is one of the most hotly "e-mailed" subjects around, and I have scads of mails from people with "their" solutions. All are different and all will produce better results with some types of files and poorer results with other types. And that's why it's so difficult to make any final statements on the subject.

I've often thought that it would be nice to have individual compression and conversion settings that you could enter for every single image you insert, but I'm sure that that would lead to even more confusion and discussion. It's really a never-ending subject...
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply