PSA: 2019.6 difference between "Export from Browse" vs "Export from Edit" still exist
Public Service Announcement = PSA
As reported to support, the issues with On1 export issues from 2019.0 (and before?) remain.
Specifically, "Export from Browse" vs "Export from Edit" still exist. Examples attached. Still pays to be careful when using On1 export in 2019.6.
Please note, post images are reduced to ~800x600, this reduction significantly reduced the quality from the original, but minimally still shows the color differences.
Also as reported to support, the exported JPGs stll remain 30% smaller than most (all?) other tools.
Gus, which photo belongs to which version of export? I always export from Browse because of earlier issues where it seemed that not all of the filters were being processed correctly if I exported in Edit.
Just my 2 cents. I have pulled up windows explorer and watched the timestamp on the sidecar file for the image I am editing and have observed the following. The time stamp does not change on the sidecar file until you return from edit to browse. I think this means any changes to the sidecar file are fully written and saved to the file when you return to browse. I am guessing that this is why exporting after returning to Browse produces more consistent results. Results may be different if sidecars are not enabled and Export is generating the image from the ON1 database vs the sidecar file.1
That would make sense, strangely, the issue survives a back/forth between browse/edit and/or a restart of the application. MAybe it is the unsyncing between the database info and the sidecar info.
Being an engineer, this is why I try to avoid having the same information in two places (except for backups, of course)0
The second image is Exported from "Edit"... IT is also the closest to the image when viewed in the application or viewing the thumbnail.0
I, too, used the "Export from Browse" method because of the Export from Edit issues. Now it seems in reverse... at least in what I am seeing.
I am not sure how best to investigate syncing between the On database of edits and the sidecar.
Is the On1 database schema known to the public?0
Gus, At one time I tried to get my hands around the internal database but was unsuccessful. With sidecars turned on... If you rename the sidecar on1 side car file, restart ON1, then ON1 will make a new sidecar file from it's internal database. You may have to touch the image file in Browse (like toggle the Heart) in order to get it to make the new sidecar file with the edits in it.0
Thanks Kevin! I will give it a try.0
I am getting different random results when exporting. Sometimes the export from browse does not take into account the applied effects. When I export from edit, I sometimes get the edited picture and sometimes not. Sometimes I get blank (black) outputs and when I re-export the same image it works. I am not sure I will want to pay for a new release especially if it does just contain corrections to problems and bugs that WE users are reporting.0
Something you can try if you have the time is to go into On1 Preferences, System Tab and turn off GPU Render. This will make On1 use the CPU only. This will obviously slow everything down while it's off but will help determine if the GPU is part of the problem. If your exports look better with CPU only, then the problem may be with the GPU and you can report that to On1.
Some of the problems I've been having when merging layers don't happen at all when the GPU is off.
Don't forget to turn it back on after your test.0
I can recreate / create Gerald's issue over and over... In my case, it has nothing to do with the GPU settings. Instead, it has everything to do with where the image is saved.
Save in the same directory... I experience the same thing that started this thread...
If I save the file to a different folder location.... it is pure black output. Sigh.
Undoubtedly buggy export routines, my list to support/development includes
* self inconsistent color export
* Overcompressed JPG exports
* and now the newest, pure black output when saving to alternative folders from browse > export
Are there really GPU/CPU related issues to export, too? Yikes! One can't help but wonder when will the lemon law kick in.0
Gus, having photo quality affected by the location it's saved in doesn't make a lot of sense to me, but stranger things have happened. If you can document that make sure you update Tech support.
The GPU, since there are so many of them that all need to be compatible, is the most likely cause of these kinds of problems.0
It is more than image quality, iin one case, it is a 175MB completely black image... in the other it is totally different colors. These may or may not make sense, but it is repeatable. And from this thread, on more than one system.
There are many examples that demonstrate On1 uses different code segments all through the application to do the same thing. This could be one of those.
Rick, You should try duplicating the issue on your system. Thus, you could enter the same issue into support, too.0
Gus, Not sure what you are saying. Since I like to keep my finished files separate from the RAW files, I always export my finished files from browse to a different drive / directory and have not had a blank/black image occur. I can also say I don't really see color differences either0
I guess there is something strange, as it seems some systems experience this, other systems do not..
I started seeing this after the 2019.6 update. The only decision we have during the update is on keeping old revisions. I chose to not keep the old revision.
After trying to track down at least 12 of these types of things, it is getting a bit frustrating.
Without knowledge of the code architecture, it is just too difficult to continue to pass through the "report this to support", "no problem found", "but I can repeat it over-and-over", "it must be your hardware" cycle of insanity. Trying to be creative while simultaneously having to be cognizant of all the workarounds is a long row to hoe... and I have only been at this tool since November of 2018.
The interface and workflow are excellent which is why I keep trying... and keep reporting to support.
It feels like the growing pains from being an Adobe addin to having a database driven architecture is part of the issue.
The sidecar to database sync (or lack thereof) seems especially troubled.
I wish there was a way to turn-off the database... and ONLY rely on a sidecar.... You would think that turning off the cataloging would do that, but it doesn't seem to be the case. Maybe a new thread on how to turn off the database is in order?0
Please sign in to leave a comment.