Some qTrace customers have talked to us and asked how they could reduce the file size of qTrace’s output, i.e. the Word, PDF or JPG files submitted to defect trackers, saved to disk or emailed. Usually, it’s because there’s a restriction on the upload file size of a particular defect tracker or it’s just too time-consuming and inconvenient to upload or email large files. This post provides some tips to reduce qTrace’s output as well as discuss about how qTrace could be improved to more effectively handle the issue of large files.
Three tips to reduce output file size
Tip #1. Choose the lowest possible image quality when exporting
qTrace has option to export images (including those embedded into Word or PDF documents) in 3 different quality levels: High, Medium and Low.
High: the exact image with original size and quality as captured by the qTrace during the recording step is used. In other words, an image exported in this quality level is identical to one captured by hitting the Print Screen key, which is the one with highest possible quality you can get.
Medium and Low: if the image size exceeds a certain threshold, it will be resized to be smaller with the Low level about 15% smaller than the Medium level. At the same time, the image quality is reduced to 75% and 50% for Medium and Low respectively. (For those developers reading this post, we do it by setting the QualityLevel property of JpegBitmapEncoder class.)
To change image quality of documents to be emailed or submitted to defect trackers, go to the Settings screen.
To change image quality of documents to be saved to disk, do it in the Save As dialog.
Depending on the specific information you want to communicate in your report, you have to choose a suitable level of quality. For example, if you want audiences of your report to be able to read body text in an image, then properly choosing the highest quality level is what you need. But then, if you only want to communicate an issue with the application layout for example, then the absence of crispness shouldn’t be a problem while the saving could be huge. How huge? I captured a trace of 23 screens (I don’t expect typical traces to be that big, but this is for the sake of experimenting) and save it to Word documents with 3 different quality levels, and here’s the file size for each:
High: 7 MB
Medium: 2.3 MB
Low: 1 MB
It’s a 700% difference between the lowest and highest quality level! Not bad for the sacrifice in quality. Now for those of you who need both high quality and low file size, read on to the next two tips.
Tip #2. Exclude screenshots from output
This is a little gem that not all qTrace users are aware of: you can exclude a screenshot from the output while still reserving the screen title and all associated steps and notes. If the screen title and steps and notes on it are sufficient for the intended readers to understand the defect, then it helps saving some bandwidth by removing the associated screenshot. How can you do that? Two ways, first you can check off the check box at the bottom-left corner of the screen to be excluded in the thumbnail list.
Or you can right click a screen on the Trace Step tree, right-click and check off the “Include Screen in Output” menu item.
Tip #3. Crop your image to contain only the necessary information
This is a practice that you should do anyway unless you want to confuse the readers with all kinds of unnecessary information in a large screenshot. Simply use qTrace Crop tool to retain only the area of the screen that you think relevant to the defect at hand.
How much can you save? It’s hard to come up with a hard and fast estimation, since the saving not only depends on how big the areas you crop out is but also what exactly are the pixels on those cropped out areas. For example, removing all the extra blank or same-colored areas won’t help much since the JPEG encoder is already very efficient in compressing the bits for those areas. So, I would simplify things here by saying if you crop about half of the image, you might be able to cut down up to 50% of the size of that image. I did a couple of tests and the overall saving is about 40% when I crop exactly 50% of the images in those trace files.
Astute readers might ask “well, but that’s the image size, how about the Word file itself, is it worth any salt?” It is, but very little. Removing all images in the 7MB qTrace output file mentioned in tip #1 and you would have a 10KB document. Yes it is that little. Try it yourself by excluding all the images from your Word output using tip #2 and examine the output file size.
Now that I have discussed different ways to reduce qTrace output, I want to briefly share some thought on how we could improve qTrace to handle this particular feature better in future versions. While we will surely optimize qTrace code to make sure the file exporting module is as economic in file size as possible, there are a couple of other areas in which we could improve. Please note that these are not things we have already decided to implement yet, they are among many other cool improvements for qTrace that we have to prioritize.
1. More fine-grained control of image quality
While qTrace currently allows users to choose among 3 different image quality levels, there is no reason why we can’t give them more power. For example, instead of 3 levels, qTrace could allow users to specify the exact quality level, say from 1 to 100 with 1 being the lowest and 100 being the highest quality respectively.
Or we could also offer ability to choose image bit depth or resize the image manually instead of implicitly handling all these tasks inside qTrace. Furthermore, we could allow them to choose the exact format of the image, e.g. JPG, PNG etc. since one type of file might be suitable than the next depending on the specific circumstance.
Finally, as we enable these options, we might also want to allow users to control which screenshot goes with what image configuration because hardly one configuration works best for all screenshots of the same trace file.
Implementing all these configurable features might make qTrace appear complicated to many users who are already happy with the current basic settings. Therefore, a related challenge is how to design the qTrace UI and workflow so that qTrace is still friendly to users who don’t want much configuration but flexible enough to accommodate those who do.
2. Store submitted documents externally to defect trackers
What do you think about these features? Is there any other thing that qTrace could do to better handle this aspect of the application?