Extend NConvert with a custom format

[Seneral]

Hello,
I'd like to add support for a RAW format (which really only includes raw data) used by WorldMachine and Unity for heightmaps.
The format is very simple fortunately, it is the plain 8-Bit, 16-Bit or even 32-Bit data written out as binary.The filesize alone can be used to calculate the exact size and bit depth. Useful parameters would be per-row/per-column write order, horizontal/vertical flip, bit depth, byte order, etc.

Is it possible to add such a simple custom format to NConvert without creating a 'wrapper'? Or, are you willing to implement this for me (and the whole Unity community )?
It has been a problem for all terrain users in Unity to convert to this not-so-widely-used format, which do not own photoshop, for a long time...

Thanks for you help!
Seneral

[Seneral]

For reference, here is a simple 512x512 16-Bit .raw perlin composition:)

[xnview]

For reference, here is a simple 512x512 16-Bit .raw perlin composition:)

your sample has not a file size of 512x512x2bytes?

[Seneral]

your sample has not a file size of 512x512x2bytes?

Good point, but I'm confused now. I did not work with the file format as closely in my tools yet, I'll ask a developer which has used it in it's tools. I hope to give a detailed explanation on whats going on this evening:)

[Seneral]

For reference, here is a simple 512x512 16-Bit .raw perlin composition:)

your sample has not a file size of 512x512x2bytes?

Ok, the specification actually is correct. But, windows and some other operating system treat kilobytes as 1024 bytes rather than 1000 (see wikipedia) so if you see exactly 512kB, here is what happens:
512*512 * 2Bytes = 524.288 Bytes => 524.288 Bytes / 1024 = 512kb
for operating systems using 1000Bytes/kB it's then obviously roughly 524kB.
So the specification mentioned above is correct:)

[xnview]

For reference, here is a simple 512x512 16-Bit .raw perlin composition:)

your sample has not a file size of 512x512x2bytes?

Ok, the specification actually is correct. But, windows and some other operating system treat kilobytes as 1024 bytes rather than 1000 (see wikipedia) so if you see exactly 512kB, here is what happens:
512*512 * 2Bytes = 524.288 Bytes => 524.288 Bytes / 1024 = 512kb
for operating systems using 1000Bytes/kB it's then obviously roughly 524kB.
So the specification mentioned above is correct:)

houps the download was not good
So you can import RAW file, but currently only 8bits

[Seneral]

houps the download was not good
So you can import RAW file, but currently only 8bits

You mean, in the software I'm using?
No, raw is a fully featured file format in Unity and we can use it fine - but other common formats like png are only supported in 8Bit...
So we would need a converter to convert to 16Bit raw for some special cases like heightmaps - the terrain system uses this format natively, aswell as a tool that I'm using, TC. But without Photoshop we have no way to convert to that format. I hope that makes it clear why we really need a converter, and as I was using NConvert before I thought it would be a great idea to have it integrated, depending on how much it would take in terms of work.
So, I hope the download is now working for you, but anyway it's not too complex as I said;)
I'd appreciate any good news in that regard:)
Seneral

EDIT: I think I misunderstood your post, so does this mean NConvert already supports Raw? I tried it already, but it failed, maybe because as you said it was 16Bit. Is there any chance you'll add 16 bit support and possibly some parameters regarding read behaviour?
Because 16Bit is the real reason behind using the raw format for me and the Unity community;)

[xnview]

yes NConvert support raw file but only 8bits

Code: Select all

-corder ... -ctype .... -size ...

[Seneral]

yes NConvert support raw file but only 8bits

Code: Select all

-corder ... -ctype .... -size ...

Ok, cool, any chance you're going to support 16Bit? Because as I said, that's the only real advantage for Unity users over any other file type;)

[xnview]

in reading or writting?

[Seneral]

in reading or writting?

Preferrably both, but for my use case only write. Reading is actually very simple, there is even an API call for this in Unity. But reading is really important for Unity in general (terrain exports only to 16Bit raw, so to use it we'd need read, too), but for my specific use case it's only write.
The thing preventing of handling all this ourselves in Unity is it's lack of support for other 16Bit formats than raw, so we need a conversion tool, else we'd need loads of third party libraries to account for all possible conversion formats... but this is what NConvert is basically already doing so that's why I'm here;)
If there's any chance you could implement this, I'd very much appreciate it:)

[Seneral]

sry - just realized it was a double post

[xnview]

in reading or writting?

Preferrably both, but for my use case only write. Reading is actually very simple, there is even an API call for this in Unity. But reading is really important for Unity in general (terrain exports only to 16Bit raw, so to use it we'd need read, too), but for my specific use case it's only write.
The thing preventing of handling all this ourselves in Unity is it's lack of support for other 16Bit formats than raw, so we need a conversion tool, else we'd need loads of third party libraries to account for all possible conversion formats... but this is what NConvert is basically already doing so that's why I'm here;)
If there's any chance you could implement this, I'd very much appreciate it:)

what do you have as source? A 16bits image?

[Seneral]

what do you have as source? A 16bits image?

Up to 32Bits, though most are 16-24-Bit PNGs. I'm pretty sure NConvert does support them already, so whats missing is only the raw option, because I thought NConvert has an internal format that the converter converts to and from there is able to convert to any output format, right? So it shouldn't matter...

[xnview]

sorry but i means 8 or 16bits per component as reading? source is grey 8bits/component and destination is 16bits/component??