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.3a (20021127):
- just added NOLINE switch
v1.3:
- added multi-file processing with patterns (thanks to the fine
ExAll() function of dos.library :-)
- added thumbnail feature
- added format types %x, %y, %q, %b and %l
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,SCALE_WIDTH=W/K,SCALE_HEIGHT=H/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,47906 bytes]
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, the internal base name of the datatype and finally
the file size is displayed.
The options SCALE_WIDTH and SCALE_HEIGHT are used to calculate
thumbnail sizes. You can provide none, one of them or both that
reflects these four cases:
· Neither SCALE_WIDTH nor SCALE_HEIGHT:
No thumbnail size will be calculated. The format types %x and %y
contain the origin sizes like %w and %h.
· Only SCALE_WIDTH:
The thumbnail is always SCALE_WIDTH pixels width and the height
is calculated considering the image aspect.
· Only SCALE_HEIGHT:
The thumbnail is always SCALE_HEIGHT pixels height and the width
is calculated considering the image aspect.
· SCALE_WIDTH and SCALE_HEIGHT:
The image will be scaled up/down (still considering the image
aspect) until the image does fit in the area specified by both
thumbnail sizes.
Note that the thumbnail size values are always rounded up.
The option FORMAT allows you to define an own output string. The
default format string is
"%f: %wx%hx%d [%t,%s bytes]"
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
%x maximum width of thumbnail the image must fit in
%y maximum height of thumbnail the image must fit in
%q single quote '"'
%l newline character 'n'
%b tabulator character 't'
The format types %x and %y are used for generating thumbnails.
Imagine you want to build an image index in HTML. For that purpose
you need small images (called thumbnails) that show quickly what
the original sized images contain. To simplyfy the process you
only need to provide the maximum size of the thumbnails in which
the images have to be reduced without changing the image aspect.
See Examples and the four cases of the parameters SCALE_WIDTH and
SCALE_HEIGHT above.
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 following for a simple picture list:
picsize IMAGES:xfiles/scully#? "%-30n %wx%hx%d, %t"
which prints:
> picsize IMAGES:xfiles/scully#? "%-30n %wx%hx%d, %t"
scully03.jpg 522x317x24, JFIF
scully02.jpg 476x328x24, JFIF
scully01.jpg 476x365x24, JFIF
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".
The format types %x and %y can be used to scale up/down images for
a nearly same sized series of images. To generate thumbnail sizes
from Scully's images, simply use:
picsize IMAGES:xfiles/scully#? "%-30n %wx%hx%d => %xx%y" w 80 h 80
You will get
scully03.jpg 522x317x24 => 80x49
scully02.jpg 476x328x24 => 80x56
scully01.jpg 476x365x24 => 80x62
and as you can see, all thumbnail sizes does fit into an area of
80 x 80 pixels (as specified in the command line).
You also can force all images to a height of 100:
picsize IMAGES:xfiles/scully#? "%-30n %wx%hx%d => %xx%y" h 100
Result:
scully03.jpg 522x317x24 => 165x100
scully02.jpg 476x328x24 => 146x100
scully01.jpg 476x365x24 => 131x100
To process an image conversion to thumbnail sizes, a command line
for each image can be built:
picsize IMAGES:xfiles/scully#? "UCONV:rexx/scale.rexx %n %x %y" w 80 h 80 >t:exe
that generates following lines in 'T:exe':
UCONV:rexx/scale.rexx scully03.jpg 80 49
UCONV:rexx/scale.rexx scully02.jpg 80 56
UCONV:rexx/scale.rexx scully01.jpg 80 62
Finally you only need to call
execute t:exe
and the conversion process can run.
By the way, without the parameters W and H, %x and %y will return
the original size like this:
scully03.jpg 522x317x24 => 522x317
scully02.jpg 476x328x24 => 476x328
scully01.jpg 476x365x24 => 476x365
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
Ralph Reuchlein <aminet@rripley.de>
[updated 30-May-2020 because neither address nor email was valid]
|
aminet net>