I am making a little game app that allows users to load up textures manually. One such example would be a standard deck of 52 cards.
Would it be bad to store the processing info as:
Card_79x123_53_53.png
Upon getting the filename from a file dialog, I would split the underscores to get the following info:

ObjectType : matched to list
(w,h)
Number of objects expected (in case there's tailing empty space)
Extra info (in this case the location of the face-down texture relative to N above)
and the dimensions of the image provide the rest, of course.

ANY error in processing would of course be raised and the attempt to load textures would be rejected.
Is there a reason why this is a bad idea or should I keep toying with it?
Is there a reason why this is a bad idea or should I keep toying with it?

This is essentially like encoding file type by file extension. The only bad thing about encoding file metadata in the filename is it's quite limited in space. You can encode much richer metadata if you used proper PNG metadata field or in a separate file. Encoding metadata in the file name is hard to extend with new fields in new version, with optional fields, etc.
For example, you might find out that you want miscellaneous sprite sheet where each frame has different size, and so you need to encode the position, size, class name, and serial number for each individual frame.
It's fine as long as you don't expect to want to encode many other metadata in the future.
Is it a bad idea to use a PNG image's filename to store the info on how to process it?