Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[maackey]

Version 2.1 is here!!!

You can download it here: http://dffd.wimbli.com/file.php?id=8564
Source: https://github.com/maackey/PictureFort

Please let me know if you encounter any problems/bugs, and any suggestions/comments are appreciated and welcome.

[Lazevedo]

Thanks for this simple yet good and functional piece of software. I prefered it over Chromafort and will use it from now on.

I have one suggestion, to remember the last designation string used. I know it already keeps the string between images, which is a great improvement over Chromafort, but it could also keep it between runs. Even better, a combo box history. You know, with a default value at start (#dig) but with that nifty arrow on the side that when clicked shows previously used strings below.

Are you a redditor? You should post about this on /r/dwarffortress. I'll do that if you want.

[Meph]

With you permission I would like to add this to Masterwork Df in a future update, as an addition to Quickfort.

[maackey]

@Meph: Of course!

@Lazevedo: The combo box is a good idea. I'll add it in when I do the saving of the designations (which I had already planned to do - I just haven't gotten around to it yet) By the way, do you happen to have a list of alternative strings to use? I'm a nub at quickfort and don't know anything more advanced than #dig. It would be useful to include some default options.

I don't have a reddit account (I already waste enough time without it) but I do lurk occasionally.  Feel free to post. I can't say no to some free advertising :p

[PeridexisErrant]

Looks great!  I'll add this to the next version of my Starter Pack, and if it works out remove Chromafort a few versions later - this looks like an alternative superior in every way. 

A couple of suggestions / questions / requests: 

• Is it open-source?  If so, have you posted it somewhere? (GitHub is good)
• Potential feature: output folder ('blueprints').  With symlinking shenanigans, I can then get it to dump the .csv in the standard starter pack Quickfort blueprints folder.
• Cross-platform-ness: if it can be built for OSX as well as Linux in the future, people will love you forever.
• Also a thought about easier color selection - something like holding a key and clicking on the color to match them would be awesome.  Remembering selection is already a massive step up over Chromafort here. 

Feel free to ignore any or all of these, but I thought I might as well mention some ideas.  Thanks again for the tool - I wish I'd had it when I was doing the Mines of Moria... chromafort really wasn't up to the job. 

[krenshala]

So, I've never used Chromafort.  What exactly is it (well, either one) used for?

[PeridexisErrant]

Chromafort and now Picturefort are tools that convert an image into a .csv file, which can be used with Quickfort for very fast designation of large and complex designs.  See the linked posts for more details. 

[krenshala]

ah, that makes sense.  that makes this utility even more useful than it at first sounded.

[maackey]

@PeridexisErrant:
 - Not currently. I can put up the source somewhere when I get back from my vacation. Although as it is now there isn't much to put up.
 - A custom output folder was planned, that's part of the saving/settings that I figured could wait till later. I just wanted to get something out that works in a standalone executable at first.
 - I've been doing some research on how to make it cross-platform. It's written in C# -- I was hoping that mono would work out of the box but that didn't work quite as expected. I would love a Linux version just as much as you
 - I'm not really sure how I could make color selection easier. The designation text boxes are already color coded -- I guess its possible to focus them if you click on a corresponding pixel in the image... but that seems like a lot of work for little benefit. Especially after adding a settings file which would save all of your current color settings (among other things).

BTW, does Quickfort support multi-level designations? If so, how would I format the .csv for that?

[PeridexisErrant]

@PeridexisErrant:
 - Not currently. I can put up the source somewhere when I get back from my vacation. Although as it is now there isn't much to put up.
 - A custom output folder was planned, that's part of the saving/settings that I figured could wait till later. I just wanted to get something out that works in a standalone executable at first.
 - I've been doing some research on how to make it cross-platform. It's written in C# -- I was hoping that mono would work out of the box but that didn't work quite as expected. I would love a Linux version just as much as you
 - I'm not really sure how I could make color selection easier. The designation text boxes are already color coded -- I guess its possible to focus them if you click on a corresponding pixel in the image... but that seems like a lot of work for little benefit. Especially after adding a settings file which would save all of your current color settings (among other things).

Awesome, it sounds like you're on top of the whole thing  .  I personally recommend GitHub as it's free in both senses, works well, and most DF-related stuff is on there already.  Release early!  You're right that saving color choice takes care of selection, I'm just too used to chromafort...

BTW, does Quickfort support multi-level designations? If so, how would I format the .csv for that?

The whole readme for editing blueprints is worth a look. 

Multilevel designations are possible, see here, and work by adding a '#>' to the first cell of the enclosing '#'s.  In fact, a high priority for enhancement should probably be to add the enclosing '#'s around exported blueprints, since they don't exist at the moment. 

I'm not quite sure how you'd get multi-level plans out of an image - multiple images could work but would be pretty clumsy, or you could go for a tall image with 1px dividing lines of some unique color (#).  That would be tricky unless the first pixel was a different (#>), and even then I'm not sure how QF handles multiple levels of different sizes so there's potentially a lot of error handling to be done.  Generally it can probably be done by a user right now, but takes some careful thought. 

Another enhancement would be to enhance the opening cell by limiting input and allowing users to explicitly specify a  starting position and comment/s.  Where there is currently a text entry field (with '#dig' in the image above), you could instead use a drop-down menu as there are only four valid choices for blueprint type.  Having three explicit text entry fields for start point coordinates and comments would also be good, defaulting to "#dig (1;1;cursor starts at top-left)".

[Astarch]

Looks nice! Some of the restrictions you have are weird though, why are you limited to 64 colors if the user is required to use 32bit or higher color? Is this only for the dig phase? How are you storing your color selections internally? If you're using C# it should be pretty easy to save them to a file that the user can edit by hand if they want to do something more complex.


I wrote my own image to blueprint converter a while ago, if you're looking to expand on what you've done so far feel free to take a look, it's open source.
http://dffd.wimbli.com/file.php?id=7994

[maackey]

@PeridexisErrant: Sweet. That editing blueprints page is exactly what I needed. It looks like multilevel designations will be pretty trivial, it's just a matter of figuring out how to do the UI, which is probably the opposite of trivial. But I'm sure I can work something out.

@Astarch: It's an arbitrary limit. I noticed a slowdown in the UI with unlimited colors. Also, 24 bit images are supported. It's just that when you have less than a full 8 bytes per color (ie. 16 bit and lower images), you have to change the algorithm for the color selection of each pixel, which IMO is more effort than its worth to implement, because seriously, who is really going to need the space savings of creating a 16 bit image vs 24 bits?

IIRC (I don't have the source handy, as I mentioned before I'm still on vacation) .NET has a pixelcopy function which stores the image as a byte array with each pixel as 4 bytes of RGBA (or ARGB I don't recall which) or if there is no alpha channel 3 bytes of RGB -- which are converted to a hexadecimal value which is used for doing all the heavy lifting. Additionally there is a function which automagically creates a list of colors from the image palette which dynamically generates the designation inputs.

In retrospect the color limit is a  poor workaround for the actual problem. I was trying to protect people from loading jpgs of millions of colors and freezing the program. While testing I opened up some random .jpg of blood soaked icebergs and polar bears and figured someone out there would accidentally do something similar with their pictures of cats or boobies or whatever else they may have handy. I can probably increase the limit on colors, and also add a limit for the image dimensions, 2 or 3k square pixels maybe?

edit: also, thanks for the link. I actually just saw your program while searching for more information about quickfort earlier today on the forums, and I've added it to my list of things to look at when I get back home.

[Rogue Yun]

I can probably increase the limit on colors, and also add a limit for the image dimensions, 2 or 3k square pixels maybe?

An embark rectangle of 2x2 gives a fortress size of 96x96 pixels. As far as I know the max an embark rectangle could possibly be is 16x16 or 768x768 pixels. I can't see a reason for making an image wider than 768 pixels. That could be one of your limits right there. As for height it would depend on how deep they would want the fort design. The deepest design I made has been 12 z-levels. If I designed it on a 16x16 embark rectangle that was 12 z-levels deep it would give me an image roughly 768x9216 pixels. My experience is limited though, best if someone else with more experience confirmed what I am speculating. You could ask the dimensions including the z-levels to get your y pixel multiplier.

There wouldn't by chance be a way to combine this with the quickfort converter and convert the file directly to a .mak would there?

This is pretty awesome. I am looking forward to your linux version.

[Astarch]

An embark rectangle of 2x2 gives a fortress size of 96x96 pixels. As far as I know the max an embark rectangle could possibly be is 16x16 or 768x768 pixels. I can't see a reason for making an image wider than 768 pixels.

It's not exactly a likely scenario to exceed that size, but some people do like to have padding around their actual blueprint.

Realistically the average user is not going to attempt to pass in an image that is too large to handle(for starters, they'd have trouble creating that image on the same computer) so you can probably get away with having no restrictions, but have a really big image trigger a warning that it might run slowly.

[PeridexisErrant]

I can ... add a limit for the image dimensions, 2 or 3k square pixels maybe?

A size limit makes perfect sense, but it should be smaller - Quickfort has hard limits on the size of blueprints it can convert. 

Horizontal:  limit of 768 tiles; the width of 16 embark squares
Vertical:  limit between 1344 and 1680 tiles; I've done blueprints for a 7-squares embark and while four z-levels works five fails.