Recently I found out that convpng is having issues converting large amounts of images at once and has no official support anymore since convimg has been released. Left with no choice, I've tried to figure out how convimg's yaml file works. I've already tried to understand the readme but it still does not make sense how I'm suppose to convert an image into an appvar for a C program to access. On top of that, I need to add a header to each appvar but there's no mention of a header anywhere in the readme.

What I want to do is:

• Create one custom palette for a group of images (potentially hundreds of images)
  
• Reserve index 0 and 255 for black and white respectively
  
• Convert that group of images (using the custom palette) to appvars for use in a C program
  
• The appvars must contain a header
  
• Each header in each appvar must be unique
  
• Each appvar name must be unique

The yaml file will eventually be automatically created by a program I wrote so the program can come up with the unique header and appvar name. For now, I'm just trying to convert one image into an appvar.

The best I came up with was this: (Note every comment after // wasn't included in the yaml file when I executed convimg)

Code:

However, when I execute convimg I get the following messages:

Code:

I don't understand what these errors are here for, I only have 16 lines in my yaml file. I also don't understand why it couldn't open a file to write to? None of this makes sense to me, if there was an example yaml file on converting a single image to an appvar I feel like I could figure out the rest. Unfortunately, just going off the readme isn't enough information for me.

Fun fact: Even though the convpng repository was completely chagned, you can still find the convpng documentation on here.

I'm a total newb at convimg, but based on my Minecraft experience with YAML, you have to be careful whether you're using tabs or spaces as whitespace.

Did you read the entire readme, top to bottom? I would highly recommend this so you understand everything. Outputs use converts, not images.

Try something like this:

Code:



I personally tested this code, so this should work.

Here's a link with each line of coded numbered:
https://pastebin.com/6yyki3Sy

Thank you everyone!
Kerm was right about tabs being recognized as new lines so I've been using whitespace instead now.
Mateo that clears up a lot of my confusion, I should have noticed the bare bones example used a convert name instead of an image name.
KaluW that helped me out a ton! I was able to get an image converted into an appvar however there's still one thing I'm confused on.

Even though I re-read the readme from top to bottom I still don't understand how the header works. From what KaluW's comments show, it looks like it's suppose to be stored in the vargfx.h file? Why is it no longer apart of the yaml file like it was in convpng? Also, why is there no mention of the header in the convimg readme?

I'm not entirely sure what you mean by the header file "no longer being a part of the yaml file like it was in convpng." The header file (i.e. vargfx.h) is created by convimg and simply contains a bunch of useful global variables pertaining to your images (such as height.and width of each image). To be perfectly honest, you could could function without it, but you woud end up with a bunch of hard coded values in your program... Which is why the header file gets created in the first place.

Oh I misunderstood and I think we're talking about two different things. I'm referring to convpng's #OutputHeader : <string> command which let you put a string of data before the image data. I'm trying to find this command's replacement in convimg.

Oh I may have removed that. Do you really need it? You could just make a separate appvar that stores the names of the appvars that make up the image -- and indicate if the appvars are compessed or not.

Well that explains why I can't find it! Unfortunately, your suggestion will not suffice. I'm working on my HD Picture CE program which uses Detect() to find all compatible appvars it can display. Using an appvar that stores all the names of compatible appvars (I'll call it a database) would massively complicate the process of reliably finding those appvars.

Every time the user converts new images, the computer program would have to create a database full of those new image names. However, the computer program doesn't know what images are already on the calculator. More importantly, if the database gets deleted, how is the user going to rebuild it? They'd have to manually tell the program which appvars are compatible, and which appvars are apart of which image.

It would be a terrible user experience and it's significantly easier and more reliable to simply add a header my C program can detect.
tl;dr Yes, I really do need this command!

I don't understand your comments. It's one extra appvar per image, that stores the information on how to reconstruct the original image. Then you only have to find one appvar per image, rather than trying to build the list by searching the entire calculator. I still don't see the purpose of this feature.

This appvar would store the image name, image dimensions, whether compression was used, the appvars used to recreate the image, along with extra information such as descriptions, date/time, and version information in case you upgrade the viewer -- and support image compression.