paint.net equivelant to 8.8.8.8.argb 32 save for msn.dds file type

[croc123]

I am somewhat new to using paint.net, but am trying to wean myself away from adobe.  I am currently trying to edit some textures for Skyrim, and am having issues with the msn.dds format. 

 

First issue, if I edit out a feature, I am left with a transparent hole.  There is no 'merge down' option.  How, in Paint.net do I backfill my edits with my default background?

 

Second, I need to do a save.  There is no 8.8.8.8 ARGB 32 option.  What is the paint.net equivelant? 

[MJW]

You can merge down in PDN, but you need a layer to merge down to; which is to say, you need at least two layers. I'm not sure what you have in mind when you say a "default background,"  but for instance if you want to merge down to white, you can add a new layer under the original background layer and fill it with white.

 

I'm also not sure what you mean by "8.8.8.8 ARGB 32 option." Each layer in PDN images is in ARGB (or BGRA, depending on how you think about it) format with eight bits per color channel (so 32 bits in all). The default file formats are PNG for single layer images and a custom format called PDN for multiple-layer images. Both are lossless formats that save the image as eight-bits-per-channel ARGB.

[croc123]

You can merge down in PDN, but you need a layer to merge down to; which is to say, you need at least two layers. I'm not sure what you have in mind when you say a "default background,"  but for instance if you want to merge down to white, you can add a new layer under the original background layer and fill it with white.

 

I'm also not sure what you mean by "8.8.8.8 ARGB 32 option." Each layer in PDN images is in ARGB (or BGRA, depending on how you think about it) format with eight bits per color channel. The default file formats are PNG for single layer images and a custom format called PDN for multiple-layer images. Both are lossless formats that save the image as eight-bits-per-channel ARGB.

As I said, I am trying to get away from using Adobe.  Skyrim's old engine cannot take uncompressed formats with any size to them, so I usually for the .dds and the _s.dds use either dxt1 or dxt5 depending on whether or no there is an alpha channel.  However, -msn.dds files ('normals') tend to get real 'artifacty' if compressed, and the Photoshop format of choice is '8.8.8.8.  ARGB 32' which fills in with a nice transparent background.  I ended up saving it in a8r8g8b8 style, with mipmaps using fant.  (I need to know more about paint.net's mipmaps...)  I am not sure that was the best format to use, but there seem to be no artifacts and the file size is pretty similar to what I started with.  Also, Nifskope didn't complain.

 

As to the background issue, I simply did a 'magic wand' on the existing background and used the 'bucket' tool to flood the removed areas.  Looked OK in game, the areas that were removed did not show (were transparent).  A bit more trouble than PS, but  I am tired of being constantly nagged about 'the cloud'.

[MJW]

It's quite easy to create a new layer and fill it with a color. A new layer can be added with one click of the Add New Layer button on the Layer menu. Then the entire layer can be selected with Edit>Select All (or Ctrl+D). and filled with Edit>Fill Selection (or Backspace).

[Ego Eram Reputo]

DXT1 and variants that start with X have no alpha support.

DXT1, DXT3 & DXT5 are compressed formats. The others are uncompressed.

You were probably correct to choose A8R8G8B8.

Sorry I can't shed any light on the mipmap subject.

[null54]

DXT1 and variants that start with X have no alpha support.

 

DXT1 has a one bit alpha channel, if your image only has 0 and 255 alpha values you will get better compression using DXT1.

[MJW]

Paint.net doesn't use mipmaps. Mipmaps are a concept used by 3D renderers to render texture maps at various distances and view angles. PDN isn't a 3D renderer, so I don't see why it would have any use for them. It would likely be possible to write a file plugin to save images as mipmaps for use by other programs, provided the desired file format was specified.

[croc123]

Paint.net doesn't use mipmaps. Mipmaps are a concept used by 3D renderers to render texture maps at various distances and view angles. PDN isn't a 3D renderer, so I don't see why it would have any use for them. It would likely be possible to write a file plugin to save images as mipmaps for use by other programs, provided the desired file format was specified.

I wonder if it plays nice with the imbedded mipmaps?  I guess that I'll have to check that with PS...

[MJW]

I don't think it would unless there were a special file plugin to read and write mipmap files. Mipmap files are not much different from other image files except for the arrangement of the pixels. (That is, assuming all the levels are stored in a single file, since if each level is stored as a separate file, they can just be standard image files, with each level half as large in each dimension as the last.) If all the levels are saved in one file, PDN would need to know how the pixels are arranged. If the save-file routine computes the mipmap from an image (as it seems like it would have to), I would suppose the read-file routine would just read the upper level, since that's the level the lower levels are computed from.

 

EDIT: Of course, this assumes there's someone who knows how to write file plugins who's interested enough in the problem to write the plugin.

 

EDIT 2: I also don't really know what you mean by "embedded" mipmaps. Embedded in what? Is this another way of saying all the levels are stored in a single file? If not, how do they get into PDN in this embedded form?

 

EDIT 3: According to my (quite old) copy of Foley and van Dam (a widely-used graphics reference), the R, G, and B channels are grouped separately. I don't recall this being the way it was done way back when I used them, but it's been a long time. It's the same size no matter what the order, so I don't see the advantage.

Edited April 3, 2016 by MJW

[Ego Eram Reputo]

DXT1 has a one bit alpha channel, if your image only has 0 and 255 alpha values you will get better compression using DXT1.

 

Thanks for the info Null54!

[croc123]

I don't think it would unless there were a special file plugin to read and write mipmap files. Mipmap files are not much different from other image files except for the arrangement of the pixels. (That is, assuming all the levels are stored in a single file, since if each level is stored as a separate file, they can just be standard image files, with each level half as large in each dimension as the last.) If all the levels are saved in one file, PDN would need to know how the pixels are arranged. If the save-file routine computes the mipmap from an image (as it seems like it would have to), I would suppose the read-file routine would just read the upper level, since that's the level the lower levels are computed from.

 

EDIT: Of course, this assumes there's someone who knows how to write file plugins who's interested enough in the problem to write the plugin.

 

EDIT 2: I also don't really know what you mean by "embedded" mipmaps. Embedded in what? Is this another way of saying all the levels are stored in a single file? If not, how do they get into PDN in this embedded form?

 

I am no PS guru by any stretch.  Perhaps PS just makes them up on the fly.  However, I seem to remember somewhere, somewhen, that part of the DDS spec was that mipmap information was included by default in uncompressed files.  I presume 'embedded'.  However, it does seem that a8r8g8b8 is a close enough equivelant for PS's 8.8.8.8. ARGB 32 that there is no issue when going back and forth from Paint.net's save to PS's save.  The file I edited in paint.net works just fine in-game, loads fine (with all mipmaps) in PS.  When I saved, I did check the generate mipmaps box, and used the 'fant' selection below.  I have no idea what 'fant' is, but the other selections did not 'feel' right.

[MJW]

I don't think that's much different from saying PS has a plugin, or the built-in ability, to read and write DDS files. I probably somewhat missed your original point, so my answer wasn't as clear as it might have been. What PDN would need (assuming it doesn't already have it) is a plugin to read and write DDS files. Assuming there's no fancy filtering going on (which I don't think is common), each level of a mipmap is just the average of four-pixel squares from the the previous level. That's pretty easy to compute, so I would expect opening the file just reads in the upper level, and saving the file computes the new lower levels.

 

Because DDS is a standard format, you're more likely to find someone who might be interested in writing the file plugin. Unfortunately, writing PDN file plugins seems to be a rather arcane art.

[croc123]

I don't think that's much different from saying PS has a plugin, or the built-in ability, to read and write DDS files. I probably somewhat missed your original point, so my answer wasn't as clear as it might have been. What PDN would need (assuming it doesn't already have it) is a plugin to read and write DDS files. Assuming there's no fancy filtering going on (which I don't think is common), each level of a mipmap is just the average of four-pixel squares from the the previous level. That's pretty easy to compute, so I would expect opening the file just reads in the upper level, and saving the file computes the new lower levels.

 

Because DDS is a standard format, you're more likely to find someone who might be interested in writing the file plugin. Unfortunately, writing PDN file plugins seems to be a rather arcane art.

 

One of the reasons I like Paint.net over Gimp is that Paint.net has the DDS included, so no need to track down a plug-in, verify it, etc.  PS does NOT come with DDS default, but both the Nvidia DDS (original) and the newer Intel version were created first (and in Intel's case only) for PS.  So I won't be getting rid of PS quite yet, but the time WILL come...

 

As my hobby is doing mods for Bethesda Studio games, something like Paint.net needs to be in my toolbox.

[MJW]

I had no idea PDN has DDS built in. Perhaps someone who knows about that feature can fill us in on the details of what's implemented. (My previous comments were based on the incorrect assumption that PDN didn't natively support DDS.)

 

EDIT: By gosh! I investigated a bit and discovered PDN does seem to compute the mipmap levels when saving DDS files.

Edited April 3, 2016 by MJW

[croc123]

That would be the hopeful situation.  So far, just so far...  I'd REALLY like to know what FANT is.  In the gaming world, where almost everything is a console port, memory-saving is crucial.  So, mipmaps are really necessary, and they need to be well done.  I've never before had to worry about them enough to find out the finer details, until now.

[MJW]

I have reason to believe PDN supports the following formats: DXT1, DXT3, DXT5, A8R8G8B8, X8R8G8B8, A8B8G8R8, X8B8G8R8, A4R4G4B4, A1R5G5B5, R8G8B8, and R5G6B5

[MJW]

I believe (based on a Google search) that FANT means the downscaling for the mipmap levels is done by using a box filter; which is to say the downscaled samples are formed by giving equal weight to all the samples that make them up. That's the standard way of doing it, and almost certainly the way PDN does it.

[MJW]

I found a short PDN forum thread that mentions Fant resampling. Rick Brewster says, "Fant is basically super sampling." That's consistent with what I've read elsewhere that for downscaling, Fant is equivalent to a box filter. (Though I can't say I'm certain, since other sites say Fant's method (Fant is a person, BTW) is CPU-intensive, but box filtering is about as simple as it comes.)

 

EDIT: In any case, the PDN thread seems to indicate you're given a choice, and Fant is one of the choices.

 

EDIT 2: It's not correct to say, "Fant's method is CPU-intensive, but box filtering is about as simple as it comes." Obviously, doing texture supersampling by summing up all the texture pixels that corresponded to each image pixel could be very CPU intensive!