How do I make a semi-transparent piece with a gradual blend?

Module Design
21

Jr and Joel,
Got it. A new release number for every upload. This will be 3.1.1 and I’ll be more careful next time. Thanks.

Hi Christian,
That “being more careful next time” means running it by you first…if you’re okay with that. The corrected module is on MediaFire at this link:

Thank you for the step-by-step instructions. Here’s what I did:

All of the scenarios (vsavs) were opened one by one, in Player mode, I Retired and selected Observer, (I think my personal preferences still said Frank at the time. Should I have left that blank?) Then I saved each game and closed the module. I reopened in Editor mode, selected each vsav in Predefined Setup, and closed the module. Now when it opens, it asks me what side I want to play, so I think it’s correct.

The png file that you said was corrupted: IrfanView said it was interlaced and so I saved it non-interlaced. Maybe that was the problem. Interestingly, the text in the new saved file looks choppy in Windows Photo Viewer but perfect in the drawing programs. The previous file, the interlaced one, looked okay in both.

The Wiki formatting: Ahhh. NOW I see what you’re talking about; I left a lot of excess garbage around the url. Kinda like me repairing your chairs and leaving the gluing clamps still on. Okay, I think I stripped out all the formatting and I put your new url in, where the old address was.

If you check it out and give me the okay, I’ll put it back up in the Library…with the new release number of course: 3.1.1

Thank you,
Frank

22

Looks good in terms of the set-ups (.vsav). Two, minor, things

  • Rather than “camo”, shouldn’t it be “fatigues” - after all, the units do not have camouflage patterns, but are coloured like the fatigues of the armies (actually, in 1944 the SS fatigues were seldom black - rather they were feldgrau like the regular German Wehrmacht. And the British Uniform No.5 wasn’t really khaki but rather a brownish green. The American uniform was olive drap).
  • The Allied set-up seems to be the same - historical - in all the saves, placed on the on-map OOB, so perhaps it is not relevant to mention that in the set up titles.

No, that is irrelevant.

Interlacing PNGs is probably not a good idea. In fact, it seems that most of the counter images are also interlaced

$ pnginspect 1\ Army\ Hq.png 
Contents of '1 Army Hq.png':

File size: 1585 bytes
...
Interlace method: ADAM7
...

If I run the image through ImageMagick’s convert

$ convert 1\ Army\ Hq.png 1\ Army\ Hq-new.png

then it is no longer interlaced, and the file size is reduced

$ pnginspect 1\ Army\ Hq-new.png
Contents of '1 Army Hq-new.png':

File size: 1286 bytes
...
Interlace method: None
...

A search on the web seems to indicate that Windows Photo Viewer - like so many other apps out of Redmond - has a number of “issues”.

:slight_smile:

Yours,
Christian

23

Hi Christian,

Thanks for checking it out and giving me the green light.

You’re right about the fatigues and the Allied historical setup. I’m just going to leave it as is ‘cause “Classic & Camo” has a bit of alliteration and fatigues sounds…tired. (Groan) The Allied setup is the same ‘cause…well, it’s always the same. At least it’s not in numerical order. I mean the 13th and 17th Airborne jumping on D-Day and the 82nd and 101st coming 24 weeks later! The order of appearance is pretty much historical.

You might have noticed my comment to Kevin, I’m running an old drawing program that I’ve been using for years. It must default to interlaced exports; I don’t consciously pick it. I guess I’ll have to break down and learn Gimp. I’ll convert all those files (495!!) in a future release.

Thanks again Christian. Your willingness to help is admirable…and very much appreciated.

And thanks to everyone else here who responded to my question.

Frank

24

If you use use ImageMagick, you can convert them all in one shot. (Or, better: use optipng to convert them and repack them so they’re losslessly smaller.)

25

Thank you Joel. I’m not familiar with either of those programs but I will definitely check them out. My old Corel PhotoPaint 9 is comfortable for me but I guess it’s time for an old dog to learn new tricks. Thanks for the recommendations.

26

At Tools for module developers you will find a list of tools, with links, that are useful for module development.

For example, the tool ImageMagick is really great for doing batch (multi-file) operations on multiple images. To install it, open a terminal (Win+R - or windows+R and then write cmd in the dialog and press OK). This will open a new window, which is entirely black with white text on it. You will see a command prompt

C:\Users\username>

where username is your user name.

In that terminal type

C:\Users\username> winget install ImageMagick.Q16-HDRI

and press enter. That will install the application.

Now, if you have unpacked the images into a directory - say C:\Users\username\Document\D-Day\images, then you can change to that directory

C:\Users\username> cd Documents\D-Day\images

To list the files in that directory, do

C:\Users\username\Documents\D-Day\images> dir

Create a new sub-directory for the converted images

C:\Users\username\Documents\D-Day\images> mkdir new

You can now run magick on all these files with

C:\Users\username\Documents\D-Day\images> mogrify -format png -path new *.png

or

C:\Users\username\Documents\D-Day\images> for %f in (*.png) do magick "%f" "new\%f"

The converted images are now all in the sub-directory new, and if you are happy with them, you can move them to the images directory.

C:\Users\username\Documents\D-Day\images> move /Y new\*.png . 
C:\Users\username\Documents\D-Day\images> rmdir new

With the above magick, you will probably not gain much - if anything - from applying optipng to the images also.

Yours,
Christian

27 
uckelman@scylla:Downloads$ magick -format png chart.png out.png
uckelman@scylla:Downloads$ ls -l chart.png out.png 
-rw-rw-r--. 1 uckelman uckelman 110519 Jun  6  2020 chart.png
-rw-r--r--. 1 uckelman uckelman 110347 Mar 26 21:19 out.png
uckelman@scylla:Downloads$ optipng out.png 
** Processing: out.png
2080x820 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 3x8 bits/pixel, RGB
Input IDAT size = 110021 bytes
Input file size = 110347 bytes

Trying:
  zc = 9  zm = 8  zs = 0  f = 0		IDAT size = 78670
                               
Selecting parameters:
  zc = 9  zm = 8  zs = 0  f = 0		IDAT size = 78670

Output IDAT size = 78670 bytes (31351 bytes decrease)
Output file size = 78960 bytes (31387 bytes = 28.44% decrease)

optipng is almost always worth running. -format doesn’t recompress.

28

Are you guys going at it? Cause, like I can step back.

29

:slight_smile:
My post above was more meant for you to get acquainted with command line and batch tools for image manipulations. For your specific case, doing

C:\Users\username\Documents\D-Day\images> mogrify -format png *.png

will reduce the total size of the PNG images from 3476kB to 3244kB (a 7% reduction). With optipng, the size of the PNGs becomes 2840kB (18% reduction). However, the point was not so much a reduction in the file size, as it was to remove the interlacing - which optipng doesn’t do, and to show how to use command line tools for tedious tasks, so Joel was a bit off the mark.

If the goal is to reduce the size of the images, then ImageMagick has a number of tools to do that, like changing the number of colours, compression level, filter, or strategy, and so on.

Yours,
Christian

30

The -i 0 flag will make optipng deinterlace.

31

Hi Joel,

I downloaded and worked (fought) with optipng all day today. I was disappointed when the files came out smaller but were still interlaced. I just used your -i 0 flag and sure as sh-t, they came out non-interlaced. Thank you. (I could have saved hours if I had been able to see the difference between a dash and a tilde.)

Christian, yes I am learning how to use the command prompt, batch files and a AI. I remember some stuff from DOS but this is very slow going for me.

And speaking of slow… Does optipng take a long time to do its thing? It seems like it’s been working on 8 test pngs for the last 10 minutes. None are larger than 10 mb. I have it flagged to remove interlacing, metadata, and go to o7 optimization. Is the o7 what’s taking so long?

Anyway, my batch file works and I can do a whole folder at a time if I want.

I’m tired.

32

PNG supports a number of compression options. It’s not possible to know before trying which set of options will produce the best compression, so optipng tries several sets of them by default, and keeps the smallest result. Increasing the optimization level means that optipng tries more sets of options, so the higher you set -o, the longer it will take.

Also, you might not need a batch file for this, as optipng can take multiple files as input. E.g., optipng *.png will process all files in the current directory.

33

Okay, I thought it meant increasing levels of compression. I’ll experiment with the setting and see what happens. If the compression is negligible I’ll try a higher setting.

What I did was create a folder called Optimize PNG, and put my batch file and optipng.exe in it. I move the folder (or copies of it) to the game I’m working on and dump the pngs into it. The batch file creates a backup directory, puts a copy of the current pngs there and then optimizes the files in the main directory. This way I can compare what I had with what optipng did.

34

Perhaps you should consider what smaller image file sizes really entails in terms of benefits. If it means you can reduce the module file size by 50%, then it is a good idea to make the images smaller. However, if you only shave off say 10%, it is probably not worth the hassle.

Also, remember that the image when in memory - as when a user is running a module in Vassal - will have the same size however large the image is on disk. As a way of illustration:

  • You may have an image compressed to use 1 byte per pixel, and suppose the image is 75px × 75px. Then that image will take up roughly 75×75×1 byte ≈ 5.5kB on disk.
  • Suppose the same image is “only” compressed to use 2 bytes per pixel, then the on-disk will take up 75×75×2 bytes ≈ 11.0kB.
  • However, when the image is loaded into memory every pixel will be decoded into 4 bytes per pixel, taking up 75×75×4 bytes ≈ 22.0kB - irrespective of the on-disk file size.
  • All things equal, a larger compression means a longer time to decode. Consider that it takes 1.5ns to decode a 1 byte pixel and 1ns to decode a 2 byte pixel. Then it will take 75×75×1.5 ns ≈ 8.4 μs to decode the 1 byte / pixel image, while it will take 5.6 μs to decode the 2 bytes/pixel image.

The point is, that smaller image sizes is not necessarily a goal in and of it self. Only if the resulting module becomes very large, does it make sense to consider better compression. For the module in question - D-Day (3rd Ed) Classic & Camo - the module is only 13572 kB, so shaving off 10% would mean a reduction to 12215 kB. Also, the on-disk compression will not help with run-time performance.

A way to improve performance both on-disk and in-memory, will be to reduce the image sizes. If counter images are 76px × 76px they will take up 22.6 kB in memory and on disk (without compression). If we reduce the image size to 38px × 38px, the in-memory footprint will be 5.6 kB - a factor 4 reduction with comparable runtime speed up.

Now, counters probably shouldn’t be much smaller than 60px × 60px if they have any kind of detail on them. For the module at hand - D-Day (3rd Ed) Classic & Camo - the fatigue variant of the counters has a small division ensign on them, and those would probably be completely illegible if the counters are too small.

Windows’ cmd is essentially DOS :slight_smile:

Batch files (typically ending in .bat on Windows) can be a good way to remind oneself of what one needs to do. And when you do more than one thing - like making back-ups and staging areas - then it starts to be good practice.

Yours,
Christian

35

It’s worth it from the perspective of not storing unnecessary data indefinitely in the Module Library.

36

From my perspective, I would want to make the file as small as possible without losing image quality. I have a vague understanding that a smaller file is better so I would run all my pngs–small and large–through optipng and let it do its thing. Unless it takes an exceptionally long time to complete, I would choose a setting that would result in the smallest file that would preserve the image quality.

My concern is the interlacing…and frankly I don’t know why. Everyone says it’s “bad” but I don’t see a difference when I look at my game components. I mean, I’m going to take it off the pieces I’ve already done and I’m going to make sure my future work is non-interlaced, but,other than it’s no longer a necessary option, I don’t know why it’s a concern.

37

Check the post on Stack-Overflow (SO amongst friends) which explains it a bit. In particular

My general rule of thumb : don’t ever use interlacing. Interlaced formats typically occupy more space, have (slightly) more complexity and less support in decoders, and the alleged advantages for the user experience are at least debatable.

That strongly depends on the application that you use. Some PNG decoders do not cope with it well - probably because interlacing PNGs is considered deprecated. Older decoders probably support it better because it was more prevalent in the past - probably because interlaced JPEGs was prevalent and justified.

Another way to deal with that, would be to allow deletion of older versions of modules from the module library. That would probably free up way more space than shaving off 5% to 10% on modules. Another way to save storage would be to have module developers not make overly high-resolution modules.

Yours,
Christian

38

I figured that. I’m going to take everyone’s advice and clear mine out.

Oh boy, I definitely second that. I volunteer starting with my D-Day 3.1.0 which didn’t last a day before needing to be replaced.