In 1.7.1. Never seen this one before. What is it?
Its a conflict with the hardware decoding aspect in the app. In the preferences turn that off under Processing settings and then it should run without issue.
Have sent some logs and screesnhots to the devs of the situation to investigate.
I cant export my videos because its giving me color space Error in new version - There was no issue in previous versions; for comparison, the same files upscaled 2x in Topaz Video AI 7 do not have this problem on the same computer.
LOG 
2026-09-23 07-03-32.178 Thread: 20372 Info FF Process Output: 54 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from âV:/260919_40-RajdHardego/MOV/DSC_2355.MP4â:
Metadata:
major_brand : mp42
minor_version : 1
compatible_brands: mp42avc1niko
creation_time : 2026-09-19T09:33:07.000000Z
Duration: 00:00:26.53, start: 0.000000, bitrate: 32635 kb/s
Stream #0:0 0x1: Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 1920x1080, 32437 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)
Metadata:
creation_time : 2026-09-19T09:33:07.000000Z
encoder : AVC Coding
2026-09-23 07-03-32.272 Thread: 20372 Info FF Process Output: 54 Stream mapping:
Stream #0:0 (h264) â hwdownload:default
tvai_up:default â Stream #0:0 (hevc_nvenc)
2026-09-23 07-03-32.276 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0m[h264 @ 0000018C6F887A40] [0m[48;5;0m[38;5;0mdecoder->cvdl->cuvidCreateDecoder(&decoder->decoder, params) failed[0m[48;5;0m[38;5;0m â CUDA_ERROR_INVALID_VALUE: invalid argument[0m[48;5;0m[38;5;0m
[0m
2026-09-23 07-03-32.277 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0m[h264 @ 0000018C6F887A40] [0m[48;5;0m[38;5;0mUsing more than 32 (37) decode surfaces might cause nvdec to fail.
[0m[48;5;0m[38;5;0m[h264 @ 0000018C6F887A40] [0m[48;5;0m[38;5;0mTry lowering the amount of threads. Using 16 right now.
[0m[48;5;0m[38;5;0m[h264 @ 0000018C6F887A40] [0m[48;5;0m[38;5;0mFailed setup for format cuda: hwaccel initialisation returned error.
[0m
2026-09-23 07-03-32.288 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0mImpossible to convert between the formats supported by the filter âgraph 0 input from stream 0:0â and the filter âauto_scale_0â
[0m[48;5;0m[38;5;0mLink âgraph 0 input from stream 0:0.defaultâ â âauto_scale_0.defaultâ:
[0m[48;5;0m[38;5;0m Pixel formats:
[0m[48;5;0m[38;5;0m src: yuvj420p
[0m[48;5;0m[38;5;0m dst: yuvj420p
[0m[48;5;0m[38;5;0mLink âauto_scale_0.defaultâ â âParsed_hwdownload_0.defaultâ:
[0m[48;5;0m[38;5;0m Pixel formats:
[0m[48;5;0m[38;5;0m src: yuv420p yuyv422 rgb24 bgr24 yuv422p yuv444p yuv410p yuv411p gray monow monob pal8 yuvj420p yuvj422p yuvj444p uyvy422 bgr8 bgr4 bgr4_byte rgb8 rgb4 rgb4_byte nv12 nv21 argb rgba abgr bgra gray16be gray16le yuv440p yuvj440p yuva420p rgb48be rgb48le rgb565be r
2026-09-23 07-03-32.290 Thread: 20372 Info FF Process Output: 54 gb565le rgb555be rgb555le bgr565be bgr565le bgr555be bgr555le yuv420p16le yuv420p16be yuv422p16le yuv422p16be yuv444p16le yuv444p16be rgb444le rgb444be bgr444le bgr444be ya8 bgr48be bgr48le yuv420p9be yuv420p9le yuv420p10be yuv420p10le yuv422p10be yuv422p10le yuv444p9be yuv444p9le yuv444p10be yuv444p10le yuv422p9be yuv422p9le gbrp gbrp9be gbrp9le gbrp10be gbrp10le gbrp16be gbrp16le yuva422p yuva444p yuva420p9be yuva420p9le yuva422p9be yuva422p9le yuva444p9be yuva444p9le yuva420p10be yuva420p10le yuva422p10be yuva422p10le yuva444p10be yuva444p10le yuva420p16be yuva420p16le yuva422p16be yuva422p16le yuva444p16be yuva444p16le xyz12le xyz12be nv16 nv20le nv20be rgba64be rgba64le bgra64be bgra64le yvyu422 ya16be ya16le gbrap gbrap16be gbrap16le 0rgb rgb0 0bgr bgr0 yuv420p12be yuv420p12le yuv420p14be yuv420p14le yuv422p12be yuv422p12le yuv422p14be yuv422p14le yuv444p12be yuv444p12le yuv444p14be yuv444p14le gbrp12be gbrp12le gbrp14be gbrp14le yuvj411p yuv440p10le yuv440p10be yuv440p12le yuv440p12be ayuv64le ayuv64be p010le p010be gbrap12be gbrap12le gbrap10be gbrap10le gray12be gray12le gray10be gray10le p016le p016be
2026-09-23 07-03-32.292 Thread: 20372 Info FF Process Output: 54 gray9be gray9le gbrpf32be gbrpf32le gbrapf32be gbrapf32le gray14be gray14le grayf32be grayf32le yuva422p12be yuva422p12le yuva444p12be yuva444p12le nv24 nv42 y210le x2rgb10le x2bgr10le p210be p210le p410be p410le p216be p216le p416be p416le vuya vuyx p012le p012be y212le xv30le xv36be xv36le p212be p212le p412be p412le gbrap14be gbrap14le ayuv uyva vyu444 v30xle y216le xv48be xv48le yuv444p10msbbe yuv444p10msble yuv444p12msbbe yuv444p12msble gbrp10msbbe gbrp10msble gbrp12msbbe gbrp12msble
[0m[48;5;0m[38;5;0m dst: vaapi dxva2_vld vdpau qsv mmal d3d11va_vld cuda videotoolbox_vld mediacodec d3d11 drm_prime opencl vulkan d3d12 amf ohcodec
[0m
2026-09-23 07-03-32.293 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0m[fc#0 @ 0000018C52282B40] [0m[48;5;0m[38;5;0mError reinitializing filters!
[0m[48;5;0m[38;5;0m[fc#0 @ 0000018C52282B40] [0m[48;5;0m[38;5;0mTask finished with error code: -40 (Function not implemented)
[0m[48;5;0m[38;5;0m[fc#0 @ 0000018C5
2026-09-23 07-03-32.293 Thread: 20372 Info FF Process Output: 54 2282B40] [0m[48;5;0m[38;5;0mTerminating thread with return code -40 (Function not implemented)
[0m[48;5;0m[38;5;0m[vost#0:0/hevc_nvenc @ 0000018C521F6140] [0m[48;5;0m[38;5;0m[enc:hevc_nvenc @ 0000018C55700240] [0m[48;5;0m[38;5;0mCould not open encoder before EOF
[0m
2026-09-23 07-03-32.294 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0m[vost#0:0/hevc_nvenc @ 0000018C521F6140] [0m[48;5;0m[38;5;0mTask finished with error code: -22 (Invalid argument)
[0m[48;5;0m[38;5;0m[vost#0:0/hevc_nvenc @ 0000018C521F6140] [0m[48;5;0m[38;5;0mTerminating thread with return code -22 (Invalid argument)
[0m
2026-09-23 07-03-32.308 Thread: 20372 Info FF Process Output: 54 [48;5;0m[38;5;0m[out#0/mov @ 0000018C52281200] [0m[48;5;0m[38;5;0mNothing was written into output file, because at least one of its streams received no packets.
[0mframe= 0 fps=0.0 q=0.0 Lsize= 0KiB time=N/A bitrate=N/A speed=N/A elapsed=0:00:00.03
2026-09-23 07-03-32.326 Thread: 20372 Info FF Process Output: 54 Conversion failed!
In the Preferences Panel, turn off the hardware decoding option and the error should go away and allow processing.
File>Preferences>Processing
This is being looked into by the devs at this time for further update.
1 Like
The error disappears here also when downgrading to 1.7.0
Never had this before tooâŠ
After the latest Topaz Video update, I can no longer render video normally. Every render fails with a Color Space Error.
Before this update, the same computer, the same GPU, the same files and the same workflow worked without any problems.
My system uses an NVIDIA GeForce RTX 5070 Ti on Windows 11.
The problem started only after the Topaz update.
I have now been trying to solve this for three days. I contacted support and followed their recommendations. I changed the hardware decoding settings, tested Auto mode, reduced the processing setting to 80%, updated the NVIDIA driver, restarted the system and repeated the tests.
Nothing has fixed it.
Support also told me that changes in version 1.7.0 caused a hardware decoding issue for some users and that a hardware decoding toggle was added because of this.
While researching the problem myself, I also found discussions here about a hardware decoding regression in Topaz Video 1.7.0. There are reports of files working correctly in 1.6.1 and then failing after upgrading to 1.7.0, including hardware decoding / FFmpeg related errors. I also saw recommendations from Topaz staff in those discussions to roll back to 1.6.1 while the issue was being investigated.
This is why I am now asking the community for a clear answer.
Has anyone here had the same Color Space Error after the update, especially with an RTX 50-series GPU?
If yes, what actually solved it?
Did you roll back to 1.6.1?
Did a newer Topaz version fix it?
Did changing hardware decoding solve it?
Or is this still an unresolved bug?
Topaz Video is part of my professional workflow, and at the moment I cannot work normally. I have already spent three days changing settings and troubleshooting a system that worked perfectly before the update.
I would really appreciate a concrete working solution from anyone who has experienced the same problem.
My colorspace errors started when I updated 1.7.0 to 1.7.1. I rolled back to 1.7.0.
Whatever it is, itâs still unresolved at this time.
Thank you for information
I am trying to understand a very specific technical problem with Topaz Video 1.7.1, and I would appreciate detailed input from users who have experienced something similar or understand the decoding and color-processing pipeline in Topaz.
My current situation is very clear: Topaz Video 1.6.1 works correctly on my system. Topaz Video 1.7.1 does not work correctly on the same system. The error is Color Space Error during processing/rendering. The source file is a normal H.264 MP4 exported from Adobe. The computer, Windows installation, NVIDIA GeForce RTX 5070 Ti, NVIDIA driver environment, source file, workflow and processing task are the same. The only major variable that changes the result is the Topaz Video version.
With 1.6.1, the file works. With 1.7.1, the same file produces a Color Space Error.
This is why I am trying to understand whether the problem is related to changes in decoding, hardware decoding, FFmpeg handling, pixel-format conversion, color metadata interpretation, GPU frame handling, or some other internal change in 1.7.1.
The fact that the source is H.264 MP4 does not exclude metadata or color information as a trigger. A normal H.264 MP4 can still contain technical information such as color primaries, transfer characteristics, matrix coefficients, color range, pixel format, chroma subsampling, profile, level, frame-rate mode, time base, codec flags, container metadata, full-range or limited-range signaling, sample aspect ratio, display aspect ratio, timestamps, GOP structure, B-frame configuration, reference-frame structure, VUI parameters inside the H.264 bitstream and container-level color metadata.
Adobe can write some of these values differently depending on export settings, hardware or software encoding, color-management configuration, sequence settings, source interpretation and output preset. That does not automatically mean the file itself is incorrect. The important point in my case is that Topaz Video 1.6.1 can read, process and render the same file correctly.
A simplified technically plausible chain could look like this: Adobe â H.264 MP4 with normal stream/container metadata â Topaz 1.6.1 reads it correctly â Topaz 1.7.1 uses changed decoding or frame-handling logic â one property is interpreted differently â internal processing fails â the user sees Color Space Error.
There are several technically plausible scenarios.
Scenario 1: Adobe H.264 MP4 contains incomplete, unusual or differently written color metadata. The file may contain or omit Rec.709 signaling, color primaries, transfer characteristics, matrix coefficients, full vs limited range, color-description flags, pixel-format information, H.264 VUI metadata or container-level color tags. Topaz 1.6.1 may interpret this correctly, fall back to safe defaults, ignore non-critical inconsistencies, assume Rec.709 or use a more tolerant decoder path. Topaz 1.7.1 may interpret the same metadata differently or require values that 1.6.1 did not. In that case the metadata would be the trigger, but the regression would still be in 1.7.1 because the same file works in 1.6.1.
Scenario 2: The metadata is completely valid, but Topaz 1.7.1 interprets a valid combination incorrectly. The file may contain a normal combination such as BT.709 primaries, BT.709 transfer characteristics, BT.709 matrix coefficients, limited range, 8-bit H.264, YUV 4:2:0, progressive scan and normal MP4 timestamps. 1.6.1 reads it correctly. 1.7.1 may contain a regression affecting one specific valid combination such as BT.709 + limited range, yuv420p + NVDEC, duplicated color information in both container and bitstream, or one metadata field being present while another is absent.
Scenario 3: The real failure is not color metadata at all. Color Space Error may be misleading. The actual failure may happen in decoder initialization, FFmpeg filter initialization, NVDEC initialization, hardware-frame handling, pixel-format negotiation, frame upload/download, CUDA frame conversion, YUV-to-RGB conversion, RGB-to-YUV conversion, color-range conversion, chroma conversion or unsupported intermediate format. If one of these stages fails, Topaz may simply report a higher-level Color Space Error.
Scenario 4: The interaction between hardware decoding and the 1.7.1 processing path is the problem. The RTX 5070 Ti has dedicated NVIDIA hardware for H.264 decoding through NVDEC. The actual chain is something like H.264 MP4 â demuxer â FFmpeg â NVIDIA NVDEC â decoded hardware frames â pixel-format/color conversion â Topaz internal RGB processing â AI model â output conversion â encoder. If 1.7.1 changed the way any of these stages interact, a file that worked perfectly in 1.6.1 could fail. Possible failure points include NVDEC returning a format Topaz does not correctly convert, FFmpeg selecting a different hardware surface format, changed frame-transfer logic, changed CUDA frame mapping, incorrect color-range assumptions, incorrect conversion from NV12/YUV420 to RGB or failure in hwdownload/hwupload stages.
This would also explain why disabling Hardware Decoding may sometimes avoid the problem. It can force the file through a different software-decoding path and bypass the broken GPU decode path. But I do not consider that a proper long-term solution. I specifically use a powerful RTX 5070 Ti because I expect the software to use the hardware correctly. Disabling hardware decoding may be a diagnostic test or temporary workaround, but it does not explain why the same hardware worked correctly before.
Scenario 5: Pixel-format negotiation changed between 1.6.1 and 1.7.1. The H.264 stream itself may decode normally, but the decoded frame could be represented internally as yuv420p, nv12, p010, yuvj420p or a hardware-specific CUDA format. If 1.6.1 converted one of these automatically and 1.7.1 now uses a stricter or different conversion path, the failure could appear as a color-space error even though the H.264 stream is valid.
Scenario 6: Full-range vs limited-range handling. If Adobe exports limited-range video with ambiguous metadata, full-range signaling in one location and limited-range signaling in another, or a range flag present in the H.264 stream but not the MP4 container, 1.6.1 may apply a sensible default while 1.7.1 may reject or mishandle the same combination.
Scenario 7: Container metadata and H.264 stream metadata do not match. MP4 files can contain information at both the container level and inside the H.264 bitstream. Different software can choose different sources of truth. If 1.7.1 changed whether it prioritizes container metadata or bitstream metadata, the same file could suddenly fail.
Scenario 8: Adobe hardware encoding writes metadata differently than Adobe software encoding. The visual output may look identical, but the resulting MP4 can differ internally in metadata, profile/level, VUI information, GOP structure, timestamps, encoder flags and color signaling. If 1.7.1 has a regression triggered by one of these differences, files generated through one Adobe encoding path could fail while another works.
Scenario 9: Constant Frame Rate vs Variable Frame Rate. A file may be constant frame rate, variable frame rate, or nominally constant with irregular timestamps. 1.6.1 may tolerate irregular timestamps while 1.7.1 may contain a change in demuxing or frame timing that interacts badly with the decoding or conversion pipeline.
Scenario 10: Timestamp or time-base regression. The issue may involve DTS/PTS timestamps, time base, MP4 edit lists, timing tables or B-frame reordering. If the decoder or processing pipeline receives unexpected timestamps or frame ordering, internal filters can fail in ways that are not obviously related to color space.
Scenario 11: H.264 profile or level handling. The file could use Baseline, Main, High or another normal profile/level combination. A regression in decoder selection or hardware decoder handling could affect one profile or level more than another.
Scenario 12: Chroma subsampling or chroma-location interpretation. Even standard H.264 4:2:0 still has details such as chroma location, chroma siting and conversion matrix. If 1.7.1 changed its conversion path, an issue in chroma conversion could surface as a color-space-related error.
Scenario 13: Incorrect fallback when metadata is missing. Suppose the Adobe file does not explicitly include one optional color field. 1.6.1 may assume Rec.709. 1.7.1 may pass an âunknownâ or âunspecifiedâ value deeper into the pipeline. A downstream converter may then fail because it cannot determine the required conversion, and the UI reports Color Space Error.
Scenario 14: A change in FFmpeg version or FFmpeg build. If 1.7.1 includes a different FFmpeg version, different build flags, different hardware-acceleration support or different defaults, the problem could come from changed decoder selection, changed treatment of unspecified color metadata, different hardware pixel format or stricter validation.
Scenario 15: A libavfilter or swscale conversion issue. Even when decoding succeeds, Topaz may use FFmpeg filters or conversion libraries to transform the image into the internal format expected by the AI model. A failure involving scale, format, colorspace, zscale, swscale or hardware-to-software frame conversion could be reported as a color-space failure.
Scenario 16: NVIDIA driver interaction. The driver cannot be completely excluded technically. A new application version may call the driver differently. The driver may work perfectly with 1.6.1 but expose an incompatibility when 1.7.1 uses a different NVDEC or CUDA path. That is different from simply saying the driver is outdated.
Scenario 17: RTX 50-series specific behavior. The RTX 5070 Ti belongs to a newer GPU generation. It is possible that 1.7.1 changed GPU capability detection, decoder selection, CUDA paths, hardware-frame formats or NVDEC initialization in a way that behaves differently on RTX 50-series cards.
Scenario 18: GPU memory allocation or frame-surface allocation. Hardware decoding requires frame buffers and surfaces. If 1.7.1 changed the number of decode surfaces, buffer alignment, frame queue size, caching or GPU memory allocation, one specific combination of input format and GPU could trigger an internal failure.
Scenario 19: Internal RGB working-space conversion changed. H.264 is normally YUV, while AI processing usually requires another internal image representation. The pipeline has to do YUV â RGB â AI processing â RGB/YUV output. If the YUV-to-RGB conversion behavior changed in 1.7.1, the problem may occur after decoding but before AI processing.
Scenario 20: 8-bit vs internal higher-precision conversion. Even an ordinary 8-bit H.264 file may be converted internally to 16-bit or floating-point RGB. A regression in internal precision conversion could affect only the newer version.
Scenario 21: Model-specific preprocessing. The file may decode correctly, but a specific AI model may request a particular pixel format, resolution, color representation or frame type. If 1.7.1 changed preprocessing for a model, the error could occur only under certain enhancement settings.
Scenario 22: Output codec or output color-space negotiation. The problem might not be in input decoding at all. The input may decode correctly, but the output codec may expect one pixel format while internal processing produces another, or the selected encoder may reject the intermediate format.
Scenario 23: Encoder initialization rather than decoder initialization. Since the error appears during processing/rendering, the source file may be read correctly but the output encoder may fail during initialization. The UI may still report the wrong category of error.
Scenario 24: Color metadata copying from input to output. Topaz may attempt to preserve color metadata from the input. If 1.7.1 cannot map one combination cleanly to the output codec or container, the export stage could fail.
Scenario 25: Cache interaction. A corrupted or stale decode cache, processing cache or metadata cache could theoretically affect the newer version, although this seems less convincing because 1.6.1 works reliably.
Scenario 26: Preferences migration from an older version. 1.7.1 may interpret an older saved preference differently, affecting hardware decoding, GPU selection, output color space, memory use, codec preference or processor selection.
Scenario 27: GPU selection conflict. A system may contain NVIDIA discrete graphics and Intel integrated graphics. A new version could initialize one device for decode and another for AI processing or encoding. The handoff between hardware contexts could fail.
Scenario 28: Intel QSV / NVIDIA NVDEC interaction. A software update may alter decoder priority. 1.7.1 could theoretically choose Intel Quick Sync for one stage even though AI processing runs on NVIDIA, requiring a hardware-frame transfer between devices.
Scenario 29: Codec probing or stream detection changed. Before decoding begins, Topaz has to probe the MP4 file. If 1.7.1 identifies pixel format, range, field order, color metadata or codec profile differently from 1.6.1, a wrong initial assumption could break the rest of the pipeline.
Scenario 30: Strict validation introduced in 1.7.1. A file that is perfectly usable but contains incomplete optional metadata may have been accepted by 1.6.1. If 1.7.1 validates more aggressively, common Adobe H.264 MP4 exports could fail even though they are accepted by other applications.
Scenario 31: The error message itself is wrong. The actual problem could be a decode error, memory error, pixel-format error, codec error, frame-transfer error or encoder error, but several internal exceptions may be mapped to one generic message: Color Space Error.
Scenario 32: A specific Adobe + Topaz compatibility regression. The practical explanation may simply be that Topaz 1.7.1 has a compatibility problem with a particular type of Adobe-generated H.264 MP4. Adobe files are common, and one commonly used metadata combination or encoder signature could trigger the bug without the source file being technically invalid.
I want to emphasize that I am not saying metadata is definitely the cause. I am not saying NVDEC is definitely the cause. I am not saying FFmpeg is definitely the cause. I am trying to identify the most plausible technical areas because the basic comparison is extremely strong:
Topaz Video 1.6.1 + RTX 5070 Ti + same H.264 MP4 + same Windows system = works correctly.
Topaz Video 1.7.1 + RTX 5070 Ti + same H.264 MP4 + same Windows system = Color Space Error.
The file did not change. The hardware did not change. The workflow did not change. The GPU did not suddenly become incapable of decoding H.264. The main change was the application version.
Support suggested changing or disabling Hardware Decoding. I tested Hardware Decoding on and off, Auto mode, driver updates and different settings. The problem remained.
This is why I do not consider âdisable Hardware Decodingâ a satisfactory permanent solution. Hardware decoding is a normal capability of a modern NVIDIA GPU. The RTX 5070 Ti is a powerful graphics card. I expect professional video software to use its hardware acceleration correctly. Disabling hardware decoding may be useful for diagnosis or as a temporary workaround, but it does not explain why the same workflow worked correctly in an earlier version of Topaz.
I am not a software developer, FFmpeg specialist, NVIDIA engineer or color-management engineer. I am a professional user. I use Topaz as a working tool. I need the software to process normal H.264 MP4 files exported from Adobe without requiring me to investigate internal decoding pipelines.
I would especially like to hear from anyone who has experienced this combination: Topaz Video 1.7.1, H.264 MP4 source, Adobe-exported file, Windows 11, NVIDIA RTX 50-series GPU, Color Space Error during processing/rendering.
I would be particularly interested in whether anyone has traced the issue to Adobe export metadata, Rec.709 tags, color primaries, transfer characteristics, matrix coefficients, full vs limited range, H.264 VUI metadata, pixel format, chroma subsampling, profile/level, hardware decoding, NVIDIA NVDEC, CUDA hardware frames, FFmpeg, libavfilter, swscale, hardware-frame transfer, hwupload/hwdownload, YUV-to-RGB conversion, GPU surface allocation, Adobe hardware/software encoding, variable frame rate, timestamps, output codec initialization, encoder initialization, integrated/discrete GPU selection, Intel QSV interaction, preferences migration, model-specific preprocessing or RTX 50-series specific behavior.
At the moment I am staying on Topaz Video 1.6.1 because it works reliably on my system. I am not going to continue experimenting with versions that make my professional workstation unreliable.
What I am trying to understand now is the actual technical reason why the same H.264 MP4 works in 1.6.1 but fails in 1.7.1 with a Color Space Error. If anyone has already traced this specific problem to metadata, decoder behavior, FFmpeg, NVDEC, hardware-frame handling, pixel format, color conversion, Adobe export settings, GPU selection or another technical cause, I would be very interested in the details.
Did you try downloading 1.7.0? I had the color space error problem, but mine didnât start until I updated from 1.7.0 to 1.7.1.
No. Have no time to tests. Waiting for unsver from support
The colorspace error is due to the addition of hardware decoding in the app from 1.7.0 and going forward. In that release of 1.7.0, there was a bug that prevented users from using the app and that feature, with the release of 1.7.1 the option was added to turn that off. This helps with some users workflows who were getting errors and issues from their hardware trying to run the decode stage.
In 1.7.1 the colorspace error was seen and that is being investigated at this time. The recommendation is to roll back to before the hardware decode process was added in to avoid these bugs, or try turning it off and see if that helps. If not, then rolling back is the best option at this time until the devs are able to resolve these issues.
I have the error in 1.7.1 but NOT in 1.7.0. Something else happened in 1.7.1 that made the problem worse.
The team is working on that and sorting out why it started triggering the error message in 1.7.1 whereas in 1.7.0 it would just error out immediately.
I didnât get that in 1.7.0 either. It just worked normally and didnât error out.
The only error I got was the nonspecific error I previously reported (Rhea error on Auto or Dynamic but not on Manual).
I believe in 1.7.0 the situation was seen more with 10-bit videos but they were still working on tracking everything down based on the logs that were shared from affected users.
The Rhea situation is on the devs list for a patch as well as I reminded them about that in a previous meeting.
Makes sense. My vids are all 8-bit. Iâm currently backed down to 1.7.0 and not having any error problems at all as long as I donât use Rhea.
Topaz Video fails to export certain H.264 videos with the error âCurrently selected color space settings are not supportedâ. The issue occurs with both enhancement and stabilization, and even when exporting without AI processing. Disabling Hardware Decoding completely resolves the issue. GPU: NVIDIA RTX 5080. Topaz version: 1.7.1.
This is still being worked on for the next patch update, moved your comment to the larger thread for when it is patched, we will make a comment here for all impacted users.
