ImageMagick writer/reader

[jackoneill]

Behaves exactly the same. Even "imwrif" does not exist, only "imwri".

Hmm, indeed. Anyway, I compiled it again. This time it's definitely "imwrif".

http://ulozto.net/xTaV1SY2/imwri-r32-win64-7z

Does it crash when you pass --info to vspipe or just when you make it output the clip?

[LigH]

Users of ImageMagick (also indirectly by image conversion services, especially when available via web) shall close security holes immediately:

ImageTragick (https://imagetragick.com/)

[sneaker_ger]

Hmm, indeed. Anyway, I compiled it again. This time it's definitely "imwrif".

http://ulozto.net/xTaV1SY2/imwri-r32-win64-7z

Does it crash when you pass --info to vspipe or just when you make it output the clip?
That version crashes as well. --info is enough to make it crash. Says "NULL passed to getPluginPath".

[jackoneill]

That version crashes as well. --info is enough to make it crash. Says "NULL passed to getPluginPath".

Oops. That was a small bug unrelated to your original crash. Fixed in this one: http://ulozto.net/xP4Ldykd/imwri-r32-win64-7z

[sneaker_ger]

Crashes with exr (but works with e.g. png).

[jackoneill]

When I use Test7, unfortunatelly I can't load a sequence of files anymore.

Test7 with wildcard:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path='C:/Program Files (x86)/VapourSynth/plugins32/imwri7/libimwri.dll')
v = core.imwri.Read( filename=r"d:/test/%d.png", firstnum=1001)
v.set_output()
==> not ok :(, "Read: No files matching the given pattern exist"

Thanks!!!

Wildcards should work again:
https://ulozto.net/xaWaZ5NM/imwri-wildcards-win32-7z
https://ulozto.net/x9zryeNx/imwri-wildcards-win64-7z

[shader]

Thanks a lot!!!!!
It's working well and just one dll remained!

[jmac698]

Does it read 16 bit TIFFs? Or even RAW files (*.cr2)? That would be amazing, immedately solving some plans I have for raw processing (like median denoising)

[Keiyakusha]

With this plugin, is it possible to read:
a) 16bit PNG sequence into RGB48 video?
b) 4:2:0 JPEG sequence into YV12 video? (same for other variants of subsampling)

If I am reading 16bit PNG sequence into RGBS video, will fmtc.bitdepth(clip, bits=16) produce RGB48 output identical to the case a) ? If not, is there a function that will?

[Myrsloik]

With this plugin, is it possible to read:
a) 16bit PNG sequence into RGB48 video?
b) 4:2:0 JPEG sequence into YV12 video? (same for other variants of subsampling)

If I am reading 16bit PNG sequence into RGBS video, will fmtc.bitdepth(clip, bits=16) produce output identical to the case a) ? If not, is there a function that will?

a) If you compile the plugin against a Q16 imagemagick (Without HDRI), yes, that's what should happen.
b) No yuv output support because imagemagick hates stuff like that. You'll always get rgb. But FFMS2 should decode it properly to YUV.

If you use round to nearest in the conversion, yes, since 32 bit float can accurately represent it.

Not actually tested but that's what I expect.

[Keiyakusha]

a) If you compile the plugin against a Q16 imagemagick (Without HDRI), yes, that's what should happen.
b) No yuv output support because imagemagick hates stuff like that. You'll always get rgb. But FFMS2 should decode it properly to YUV.

If you use round to nearest in the conversion, yes, since 32 bit float can accurately represent it.

Not actually tested but that's what I expect.

Sounds good, thanks! I'll do some tests when I'll have time then.

[dipje]

... But FFMS2 should decode it properly to YUV....

FFMS2 handles image sequences? I tried something like %04d in the filename once and it didn't like it (Vapoursynth plugin that is). Was I trying it wrong?

[Myrsloik]

FFMS2 handles image sequences? I tried something like %04d in the filename once and it didn't like it (Vapoursynth plugin that is). Was I trying it wrong?

It doesn't handle it so you'll have to use some python code to get around it.

[dipje]

d'oh.. that's me coming from the avisynth era. Never thought of using python itself for problems like this :).

[dipje]

'It' seems to crash when loading a single DPX file (Created by ffmpeg IIRC).

Vapoursynth-editor shows something in RGB30 (which is correct) but crashes, 'vspipe -i' also crashes. Probably some fault in ffms2 I guess.

[poisondeathray]

FFMS2 handles image sequences? I tried something like %04d in the filename once and it didn't like it (Vapoursynth plugin that is). Was I trying it wrong?

It doesn't handle it so you'll have to use some python code to get around it.


Can you post an example of using python to load and image sequence with ffms2 please, for a python newbie

[Myrsloik]

Can you post an example of using python to load and image sequence with ffms2 please, for a python newbie

Sure can. Enjoy this beauty of scripting:

import vapoursynth as vs

first_image = 4
num_images = 160
filename_pattern = 'D:/imgseq/output_{0:05d}.jpg'

c = vs.get_core()
placeholder_clip = c.std.BlankClip(clip=c.ffms2.Source(filename_pattern.format(first_image), cache=False), length=num_images)
def image_loader(n):
return c.ffms2.Source(filename_pattern.format(n + first_image), cache=False)[0]
clip = c.std.FrameEval(placeholder_clip, image_loader)
clip.set_output()

The roundabout way of doing it is to avoid having a gazillion ffms2 instances created at once.

[poisondeathray]

Sure can. Enjoy this beauty of scripting:

import vapoursynth as vs

first_image = 4
num_images = 160
filename_pattern = 'D:/imgseq/output_{0:05d}.jpg'

c = vs.get_core()
placeholder_clip = c.std.BlankClip(clip=c.ffms2.Source(filename_pattern.format(first_image), cache=False), length=num_images)
def image_loader(n):
return c.ffms2.Source(filename_pattern.format(n + first_image), cache=False)[0]
clip = c.std.FrameEval(placeholder_clip, image_loader)
clip.set_output()

The roundabout way of doing it is to avoid having a gazillion ffms2 instances created at once.


It works nicely, thanks

Seek latency is a bit high, but I'm not complaining.

Sometimes the vpy imagemagick plugin has problems with some formats and it's a nice alternative just in case

[Tormaid]

What exactly is the "mismatch" option supposed to do? VS always crashes for me when I have an output with varying dimensions when mismatch is set to "True."

[jackoneill]

What exactly is the "mismatch" option supposed to do? VS always crashes for me when I have an output with varying dimensions when mismatch is set to "True."

From the documentation (http://www.vapoursynth.com/doc/plugins/imwri.html):

mismatch
Allow reading of multiple images with different resolutions. If required and not set, an error will be generated.

Tell me about this crash.

[Tormaid]

I'm aware what it is supposed to do, but I don't know how it does it. It seems like Vapoursynth does not support frame sequences with mismatched resolutions, so is mismatch=True just padding the edges to match those of the largest image?



Tell me about this crash.

Here is my script:


import vapoursynth as vs
core = vs.get_core()

v = core.imwrif.Read(r'%03d.jpg', firstnum=1, mismatch=True, alpha=False)

v.set_output()


This was crashing Vapoursynth Editor, so I thought it might be a problem with that program, but when I tried calling up the script though vspipe, I got the following error, "Cannot output clips with varying dimensions."

I ended up just writing a Photoshop script to add padding, but I would like to figure this out, as it is a nice quality-of-life feature.

[jackoneill]

I'm aware what it is supposed to do, but I don't know how it does it. It seems like Vapoursynth does not support frame sequences with mismatched resolutions, so is mismatch=True just padding the edges to match those of the largest image?




Here is my script:


import vapoursynth as vs
core = vs.get_core()

v = core.imwrif.Read(r'%03d.jpg', firstnum=1, mismatch=True, alpha=False)

v.set_output()


This was crashing Vapoursynth Editor, so I thought it might be a problem with that program, but when I tried calling up the script though vspipe, I got the following error, "Cannot output clips with varying dimensions."

I ended up just writing a Photoshop script to add padding, but I would like to figure this out, as it is a nice quality-of-life feature.

You can have a clip with varying resolutions. A clip like that will have 0 width and height. That's all "mismatch" does: it sets the clip's width and height to 0. Frames are not padded in any way.

It's possible that vsedit was not tested with such clips. To see if your script crashes outside vsedit you'll need to use the Python function get_frame:

for i in range(v.num_frames):
v.get_frame(i)

Run your script with Python:

python3.exe script.py

If it doesn't crash, recreate the crash using two BlankClips (and no Imwri) and complain about it to the author of vsedit.

[Tormaid]

You can have a clip with varying
It's possible that vsedit was not tested with such clips. To see if your script crashes outside vsedit you'll need to use the Python function get_frame:

for i in range(v.num_frames):
v.get_frame(i)

Run your script with Python:

python3.exe script.py

If it doesn't crash, recreate the crash using two BlankClips (and no Imwri) and complain about it to the author of vsedit.

Sorry for the long delay there. So, I pulled it up in Python like this and it didn't crash, just continued to process as (I assume) it jumps around to random frames.

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "C:\\Users\\tormaid\\Desktop\\test script.vpy"
'C:\\Users\\tormaid\\Desktop\\test script.vpy'
>>> for i in range(v.num_frames): v.get_frame(i)
...


So, assuming I did that test right, I guess I'll report this issue to the developer of Vapoursynth Editor, but I am curious as to why it crashes vspipe too.

[jackoneill]

Sorry for the long delay there. So, I pulled it up in Python like this and it didn't crash, just continued to process as (I assume) it jumps around to random frames.

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "C:\\Users\\tormaid\\Desktop\\test script.vpy"
'C:\\Users\\tormaid\\Desktop\\test script.vpy'
>>> for i in range(v.num_frames): v.get_frame(i)
...


So, assuming I did that test right, I guess I'll report this issue to the developer of Vapoursynth Editor, but I am curious as to why it crashes vspipe too.

Are you sure it's running the loop? Those three dots on the last line look like Python's waiting for you to type more.

[Tormaid]

Are you sure it's running the loop? Those three dots on the last line look like Python's waiting for you to type more.

I must just be doing something really stupid because I don't know why it's waiting for more input. Is there a run command I'm missing? I loaded up just the script with just the imwrif.Read() and v.set_output() commands in it and then ran the python code you gave me, and it just gave me the three dots.

[TheFluff]

Does it become any clearer if I write it like this instead?
for i in range(v.num_frames):
v.get_frame(i)

Or, perhaps:
>>> if True:
... print "hi"
... print "and hello"
...
hi
and hello

Remember, Python does not use curly braces ( { and } ) to open and close blocks like C-like languages do. In the Python REPL (the interactive code editor you're using), if you start a block (which you do with a colon) you can continue typing more code into that block by just hitting enter to start a new line - the interpreter tells you this is happening by replacing the regular ">>>" prompt with one that reads "...". The code will only get executed once you terminate the block, which you do by entering a blank new line.

tl;dr: press enter one more time

[jackoneill]

vspipe crashes when trying to open an exr file.
import vapoursynth as vs
core = vs.get_core()

ret = core.imwri.Read("0001.exr")
ret.set_output()
http://distribution.bbb3d.renderfarming.net/video/exr/1114/0001.exr
imwri "test7" build
VS R32 64 bit on Windows 7

This will be finally fixed in the next set of DLLs. The problem was in Openexr. It was caused by a mistake in a patch required to make it cross-compile.

[Myrsloik]

Here's test8 (https://dl.dropboxusercontent.com/u/73468194/imwri_test8.7z).

It's the first version after switching to imagemagick7 so behavior may have changed a bit. I guess.

[sneaker_ger]

Thx. Can confirm the crash is fixed.

[george84]

Thank you everyone for vapoursynth. I have very large AVIsynth scripts (up to 1M characters, generated automatically). They are used to make Slideshows. Everything works fine even up to 4K resolution.
Now I want to use 10bit BT.2020 colors and evaluate vapoursynth. I am stuck with converting jpegs to YUV.

x = core.imwrif.Read("C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/colorcheckerchart.jpg", firstnum=0, mismatch=False, alpha=False)
#x = core.ffms2.Source(source='C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/colorcheckerchart.jpg')
x = fAVSimgExtend(x, 240)
SMILregion1 = core.resize.Point(x, format=vs.YUV420P10, primaries = 1, transfer_s = "709", transfer_in_s = "709", matrix_s="709", range_s = "full")

The above code sequence crashes VS Editor when doing preview because of primaries=1 in resize. (only primaries=2 will work)

Crash happens when reading jpef with imwrif as well as with ffms2. I used TEST8 for imwrif and have vapoursynth R38, 32 bit on Windows10.

What is the correct resize statement to convert an RGB (assume BT.2020 colorspace, not sRGB) to HDR10. Matrix, Transfer and primaries?

[Myrsloik]

I'll try to reproduce this in a day or two. It definitely shouldn't be crashing...

[age]

Thank you everyone for vapoursynth. I have very large AVIsynth scripts (up to 1M characters, generated automatically). They are used to make Slideshows. Everything works fine even up to 4K resolution.
Now I want to use 10bit BT.2020 colors and evaluate vapoursynth. I am stuck with converting jpegs to YUV.

x = core.imwrif.Read("C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/colorcheckerchart.jpg", firstnum=0, mismatch=False, alpha=False)
#x = core.ffms2.Source(source='C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/colorcheckerchart.jpg')
x = fAVSimgExtend(x, 240)
SMILregion1 = core.resize.Point(x, format=vs.YUV420P10, primaries = 1, transfer_s = "709", transfer_in_s = "709", matrix_s="709", range_s = "full")

The above code sequence crashes VS Editor when doing preview because of in . (only will work)

Crash happens when reading jpef with imwrif as well as with ffms2. I used for imwrif and have vapoursynth R38, 32 bit on Windows10.

What is the correct resize statement to convert an RGB (assume BT.2020 colorspace, not sRGB) to HDR10. Matrix, Transfer and primaries?

I don't have an hdr or bt2020 monitor so I can't test my code.
Assuming a standard srgb jpeg
jpeg to bt2020 10bit NOT HDR
ffms2 open the jpeg as yuv

import vapoursynth as vs

core = vs.get_core()
c = core.ffms2.Source(source = 'C:/Users/...')


c=core.resize.Bicubic(clip=c, format=vs.RGB48, filter_param_a=0, filter_param_b=0.75, matrix_in_s="470bg", range_in_s="full", range_s="full", chromaloc_in_s="center", dither_type="none")

c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="709", transfer_s="linear")
c=core.resize.Bicubic(clip=c, format=vs.RGB48, primaries_in_s="709", primaries_s="2020")
c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="linear", transfer_s="2020_10")
c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_s="2020ncl", range_in_s="full", range_s="limited")


imwri open the jpeg as rgb

import vapoursynth as vs

core = vs.get_core()
c = core.imwri.Read(filename='C:/....')




c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="709", transfer_s="linear")
c=core.resize.Bicubic(clip=c, format=vs.RGB48, primaries_in_s="709", primaries_s="2020")
c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="linear", transfer_s="2020_10")
c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_s="2020ncl", range_in_s="full", range_s="limited")



rgb bt2020 to HDR10 1000 nits yuv

c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="2020_10", transfer_s="linear")
c=core.resize.Bicubic(clip=c, format=vs.RGB48, transfer_in_s="linear", transfer_s="st2084", nominal_luminance=1000)
c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_s="2020ncl", range_in_s="full", range_s="limited")

[george84]

Thank you @age.
I have an OLED TV which supports HDR10. It will take me some time to test and understand your solution.
Currently I have two solutions which don't look too bad:
Option 1:
Read JPG in avisynth to YV12 and pipe to FFMPEG and then to X265. In FFMPEG I do
zscale=p=2020:t=smpte2084:m=2020_ncl:pin=709:tin=709:min=709" -pix_fmt yuv420p10

Option 2:
Read JPG in vapoursynth to RGB and do
x = core.resize.Point(x, format=vs.YUV420P10,
primaries = 9, primaries_in =1,
transfer_s = "st2084", transfer_in_s = "709",
matrix_s = "2020ncl",matrix_in_s = "rgb",
range_s = "full", range_in_s = "full")

For both options things look good on TV, but not really better than a normal HDR encoding (I assume TV does a quite good upscale of HDR to HDR10). I am aware that jpg is only 8 bits and have no real BT.2020 source. To overcome this I will try to convert 14bit DNG to 10bit tiff

[age]

Thank you @age.
I have an OLED TV which supports HDR10. It will take me some time to test and understand your solution.
Currently I have two solutions which don't look too bad:
Option 1:
Read JPG in avisynth to YV12 and pipe to FFMPEG and then to X265. In FFMPEG I do


Option 2:
Read JPG in vapoursynth to RGB and do


For both options things look good on TV, but not really better than a normal HDR encoding (I assume TV does a quite good upscale of HDR to HDR10). I am aware that jpg is only 8 bits and have no real BT.2020 source. To overcome this I will try to convert 14bit DNG to 10bit tiff
You could play with the nominal_luminance parameter, if not set it is equal to 100(nits) so it is HDR10 100 nits.

#c=core.resize.Bicubic(clip=c, format=vs.RGB48, filter_param_a=0, filter_param_b=0.75, matrix_in_s="470bg", range_in_s="full", range_s="full", chromaloc_in_s="center")#jpeg to rgb


c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_in_s="rgb",matrix_s="2020ncl",primaries_in_s="709",primaries_s="2020", transfer_in_s="709", transfer_s="st2084", range_in_s="full", range_s="limited", nominal_luminance=1000)





I prefer to use bicubic 75 for chroma resize :-)

[george84]

You could play with the nominal_luminance parameter, if not set it is equal to 100(nits) so it is HDR10 100 nits.

I tried out your code with sRGB jpeg source. The good news is, that both versions (read with imwrif, and read with ffms2) give identical results.
But on TV the colors are too vivid. There is no contrast in bright spots. When I replace transfer function "2020_10" with "st2084" it looks better. My encoding is:

"C:\Program Files (x86)\VapourSynth\core32\vspipe" --y4m v1.vpy - | "C:\Users\Walter\Downloads\ffmpeg-20170605-4705edb-win32-static\bin\ffmpeg.exe" -nostats -i pipe: -strict -1 -r 24 -f yuv4mpegpipe - | "x265_x64_10bit.exe" - --y4m --bitrate 40000 --input-csp 1 --level-idc 5.1 --no-open-gop --hdr --aud --hrd --hdr-opt --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" --max-cll "1000,400" --output "v4.hevc"

PAUSE
muxer -i v4.hevc -o v4.mp4
del v4.hevc
PAUSE

In HDR10 specs they say transfer function is ST2084. How can I vary this nominal luminance parameter?

[george84]

When I encode a colorchart test image then I get:
with 2020_10 transfer function for Luminance Y values between 64 and 940

with st2084 transfer function for Luminance Y values between 64 and 509

according to https://art-drivers.net/understanding-hdr/the_hdr_cheat_sheet/ I should get a maximum of about Y=700 because my display has a peak luminance of about 650nits.

So the question is really how to vary this. I try with Levels filter.

[age]

the values in https://art-drivers.net/understanding-hdr/the_hdr_cheat_sheet/
are in standard yuv limited range.

You can vary Y with

transfer_s="st2084",nominal_luminance=



Have you tried?

c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_in_s="rgb",matrix_s="2020ncl",primaries_in_s="709",primaries_s="2020", transfer_in_s="709", transfer_s="st2084", range_in_s="full", range_s="limited", nominal_luminance=1000)
hdr10 generally is 1000 nits,nominal_luminance=1000, transfer_s="st2084"



your monitor has a peak luminance of about 650nits so you could use nominal_luminance=650, transfer_s="st2084"
c=core.resize.Bicubic(clip=c, format=vs.YUV420P10, filter_param_a=0.0,filter_param_b=0.75, matrix_in_s="rgb",matrix_s="2020ncl",primaries_in_s="709",primaries_s="2020", transfer_in_s="709", transfer_s="st2084", range_in_s="full", range_s="limited", nominal_luminance=650)

Black level for hdr10 is 64 (10 bit) because the full to limited range conversion
HDR10: Nominal Black for 10-bit at 64

[george84]

Thank you for this hint. As I understand I could also use nominal_luminance in x265 zscale as npl parameter.

I tried in vapoursynth and found that default of 100 is almost too bright. In TV I have three picture settings for HDR (vivid, bright, standard). Best quality is when I set npl=50 and use vivid setting. Of course the TV is not calibrated.

What I don't understand is why the white in jpeg does not become white on TV. I attach a screenshot of vapoursynth preview. You see that the clip info, which I added immediately after resize with x=x.text.ClipInfo() has real white (Y=940) and real black (Y=64). But the white of jpeg is Y=509 and the black is Y=64. (this was with npl=100)

[age]

@george84
Post your script because there could be some errors.

I think you really should not use nominal_luminance=100 (100nits), because 100nits is SDR and of course it looks bad with an HDR picture style.

PS. Maybe it's better to open a new topic for this discussion "sdr to hdr"

[poisondeathray]

Is there a way that you can prevent writing an alpha channel with imwrif.Write ? I tried alpha=None , alpha=False but no luck

If internally there is no alpha channel , the plugin seems to write a "dummy" one anyways

[Myrsloik]

Is there a way that you can prevent writing an alpha channel with imwrif.Write ? I tried alpha=None , alpha=False but no luck

If internally there is no alpha channel , the plugin seems to write a "dummy" one anyways

No, probably not then. Imagemagick doesn't really document how it determines when to write an alpha channel.

[poisondeathray]

Were you still investigating IM alternatives ?

What about OpenImageIO ? It's used in open software such as blender, natron ; and commercial software as well . Quite active development
https://sites.google.com/site/openimageio/home
https://github.com/OpenImageIO/oiio

[Myrsloik]

Were you still investigating IM alternatives ?

What about OpenImageIO ? It's used in open software such as blender, natron ; and commercial software as well . Quite active development
https://sites.google.com/site/openimageio/home
https://github.com/OpenImageIO/oiio

I shall add it to my list of things to look at. Could be interesting if the api isn't shit.

[Myrsloik]

Download link updated. Dropbox seems to have randomly broken some of my older links.

[poisondeathray]

Current namespace for test8 is imwrif, but documentation says imwri ; can you update the documentation if it's going to stay that way

[Myrsloik]

Current namespace for test8 is imwrif, but documentation says imwri ; can you update the documentation if it's going to stay that way

It depends on how the imagemagick library was compiled. Also don't stop reading the documentation after the first line.

[Myrsloik]

Is there a way that you can prevent writing an alpha channel with imwrif.Write ? I tried alpha=None , alpha=False but no luck

If internally there is no alpha channel , the plugin seems to write a "dummy" one anyways

I looked at this and tried to improve it. What's the format you tried it with? Alpha in the output seems to mostly depend on which format you specify in the formatstring. Like PNG24 or 32. I think. I've made some changes that should at least not set the alpha at all now but most formats still write it.

[poisondeathray]

I looked at this and tried to improve it. What's the format you tried it with? Alpha in the output seems to mostly depend on which format you specify in the formatstring. Like PNG24 or 32. I think. I've made some changes that should at least not set the alpha at all now but most formats still write it.

IIRC, I think it was a DPX sequence that lead me to post, but I confirmed it with a PNG export too . Typically DPX shouldn't have an alpha channel and it "confused" some other programs on import

[Myrsloik]

IIRC, I think it was a DPX sequence that lead me to post, but I confirmed it with a PNG export too . Typically DPX shouldn't have an alpha channel and it "confused" some other programs on import

I think I found the main issue. No more alpha written unless an alpha clip is specified. If you compile things yourself you can test it. I also fixed a lot of the bitdepth mess and removed the need for two versions so expect a new build soon.

[poisondeathray]

I think I found the main issue. No more alpha written unless an alpha clip is specified. If you compile things yourself you can test it. I also fixed a lot of the bitdepth mess and removed the need for two versions so expect a new build soon.

Ok thanks. I'll test when the official build comes out