Short: Shows picture dimensions using datatypes Author: amiga@rripley.de (Ralph Reuchlein) Uploader: amiga@rripley.de (Ralph Reuchlein) Version: 1.2 Type: util/dtype Kurz: Zeigt Bildausmaße anhand Datatypes Date: 26-Dec-1999 Replaces: util/dtype/picsize.lha PicSize ======= PURPOSE The archive contains a small program to determine picture dimensions including the sources. Since I am working alot with images that were downloaded from Aminet or other internet sources, were made by myself or were generated by software, sometimes its useful to list image dimensions instead of showing them or using other image viewers with verbose output. This picture dimension determiner is based on the datatypes system which is available since OS 3.0. Therefore you can scan each image which datatype you have installed on your system. The sources is only one C source :-) This file should be compatible to each compiler and contains features like Templates and ReadArgs(), functions with variable arguments, a pseudo RawDoFmt() function and -of course- the (simple) datatype handling. HISTORY v1.2: - a bugfix (I forgot a return statement in my most important function, thanks to Jerome Chesnot) - added file size information format type %s - changed filename suffix format type %s to %e (to avoid conflict with the added file size information format type) - corrected BUGS section of this readme v1.1: The first version of Picsize (released at 25-Mar-1999) had only some switches for specific output. It wasn't good enough for me and I now have built in a format string feature for various output strings. This version now also got a version string. INSTALL Simply unpack the archive to anywhere you want. I prefer to copy the executable to C:. REQUIREMENTS - OS 3.0 - datatypes for your image types USAGE The template is FILE/A,FORMAT=FMT,INTRODUCER=INTR/K You always have to provide the image file you want to determine. Using only the first option you will get full information about the image: » picsize amiga8.jpg DATA1:Images/Amiga/amiga8.jpg: 336x502x24 [JFIF] Column 1 displays the filename (with path, even when you didn't provided one), then the image dimension with width, height and depth is shown and finally the internal base name of the datatype is displayed. The option FORMAT allows you to define an own output string. The default format string is "%f: %wx%hx%d [%t]" The format types are: %n basename of the file (the filename without path) %f full filename including path (even, when you didn't provided one) %P path name including trailing '/' and ':' %p path name excluding trailing '/', but with ':' (warning: there are different cases of the two 'p'!) %o basename of the file without suffix %e suffix of the file including leading '.' %w width of image %h height of image %d depth of image %t image type %s file size Each format type can be formatted like the printf() function from the C standard libraries. There is only one restriction: You cannot add a type qualifier to the type, e.g. "%lw" (must only be "%w"). Some examples of formatting: %30n Basename will be displayed in a 30 column wide space. If the basename length is less than 30, it will be right filled by spaces. %-30n Equals %30n, but field will be left filled by spaces. %.4n Truncates basename to 4 characters or will be right filled if name length is less than 4. %04w Writes width of image in a 4 column wide field. If the number has less than 4 digits, it will be left filled with zeros instead of spaces. For more information refer to the C standard library documentation of printf(), sprintf() or fprintf(). Finally the INTRODUCER option (you have to use the keyword INTRODUCER or INTR to specify this option) changes the default format type introducer character '%' to another value. This is useful for scripting to avoid collisions with other programs using '%' as introducer too. EXAMPLES Following table shows the format types and its output, when the file "amiga8.jpg" is used: %n amiga8.jpg %f DATA1:Images/amiga8.jpg %P DATA1:Images/ %p DATA1:Images %o amiga8 %e .jpg %w 336 %h 502 %d 24 %t JFIF %s 47906 You might miss a format type for a full filename without suffix, but its really no problem, because you simply need to concatenate format types to %P%o which leads to DATA1:Images/amiga8 Voilá. The main purpose of picsize is scripting. For example you can use the script s:SPAT for a simple picture list: s:SPAT picsize IMAGES:xfiles/scully#? "INTR $" *"$-30n $wx$hx$d, $t*" which prints: > s:spat picsize IMAGES:xfiles/scully#? "INTR $" *"$-30n $wx$hx$d, $t*" scully03.jpg 522x317x24, JFIF scully02.jpg 476x328x24, JFIF scully01.jpg 476x365x24, JFIF You have to replace the introducer character to '$', because s:spat uses the '%' introducers for itself (s:spat uses LIST LFORMAT). Another example includes the command substitution feature of CLI/Shell: > rename scully02.jpg as `picsize scully02.jpg "%o_%wx%h%s"` This one would rename the file "scully02.jpg" as "scully02_476x328.jpg". BUGS Unfortunately there is a bug - or better to say: insufficency -, but don't blame me for that, because the error lies in the datatypes. Most of the datatypes were based on the example provided by Commodore. This example shows creating the image data in a DISPLAYABLE memory area during the OM_NEW method. So the picture datatypes like ilbm.datatype or jfif.datatype first unpack the image to CHIP RAM, then build up a BitMap structure and finally a BitMapHeader structure. The BitMapHeader structure holds the information like width, height, depth and so on. If you now try to open a huge image which bitmap can't be build in CHIP MEM due to insufficient memory, picsize returns an error. Until now everything works fine, but now the bug strikes back: You might detect that the datatype system grabbed a huge portion of CHIP RAM and the datatype forgot to free it! You have no chance to free that unused memory; the only thing is a reboot. This bug may lie in the picture.datatype you use. For the datatypes developers back to image creation: During OM_NEW there is no need for image creation, maybe later at OM_DRAW. (Thanks to Gunther Nikl for the background information) But ... Good news for CyberGraphX V3/V4 users: CGFX has a environment variable PLANES2FAST which allowes swapping unused bitmaps to FAST RAM. If the variable is set to 1, the datatype system build the bitmaps in FAST RAM. If you have 64 MB RAM, you can determine very huge images without having a memory bug as described above. The variable unfortunately has some negative side effects: Each program assuming a bitmap in CHIP RAM would access on a non-allocated area in CHIP RAM (remember, the bitmap is swapped to FAST RAM!) that surely leads to system crashes. DISCLAIMER THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. MISC Suggestions and bug reports are welcome, but I think the little program's purpose is fully accomplished. It is my first experience in programming datatypes, so I still have some questions: 1) Is it possible to avoid decoding the image data, if I only want the image dimensions? This would speed up the processing alot. 2) Why I can't force DTA_GroupID,GID_PICTURE at NewDTObject? When I use a picture it works fine, but when using e.g. an executable, first a new Object will be created, but I can't access its attributes, because my machine shows me an red alert 'privilege violation'. According to the datatype autodocs it should not create a new object and return a ERROR_OBJECT_WRONG_TYPE in IoErr(). Is there a bug? The only way I can use is feeding it without any attributes at object generation. Did I something wrong there? CONTACT snail Ralph Reuchlein mail: Eibseestr. 18c 86163 Augsburg GERMANY eMail: amiga@rripley.de WWW: http://www.rripley.de IRC: RRipley on #germany ============================= Archive contents ============================= Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 124 89 28.2% 05-Dec-99 17:39:02 SCOPTIONS 13236 8433 36.2% 21-Apr-00 11:24:22 picsize 9345 2680 71.3% 21-Apr-00 11:24:16 picsize.c 9509 4257 55.2% 09-Jan-00 23:14:48 picsize.readme -------- ------- ----- --------- -------- 32214 15459 52.0% 21-Apr-100 22:51:08 4 files