On this case, you’d better to use none padding since the masked area is small but the range of it is large. Then you can have better resolution output. I plan to solve the speed first since that is the main problem with a lot of complains. Then with the fast removing process, it will be easier to solve the low-res problem.
9 Likes
Hi,
That’s great to hear you’re working to improve the speed of the remove tool.
I have what’s probably a Topaz product mktg question - based on your reply to Thomas re: “padding” But here you go…
“Padding” (the term & its ops) has puzzled me all along for the PAI tool. I’m not a gen AI expert. Just a mere photographer, personal retoucher & (volunteer) photo processing educator. Is there a Topaz educ. video that is dedicated to demos showing which Padding tier/option to select based on different mask example scenarios?
As others have requested, wrt PAI Remove, in Ps content aware fill we can indicate (with a masked overlay) which portions of an image to use as context for filling. In a fair number of Ps instances, I use areas not adjacent to the object/subject I want to remove (in addition to frequent ones adjacent) to create a desired fill. With PAI, I don’t have that control & it’s tough to know how to work effectively with PAI’s “padding”. Any visual (educ video) examples or more guidelines re: how to control the context area (& tradeoffs like resolution impacts) would be appreciated! 
[For anyone else who wants to help… yes, I’ve read the tool tips & they don’t address what I’m asking for]
6 Likes
OK, the clue is not (only) to set the Guidance to “keep area” but also to mask the whole tattooed area in one step - otherwise it’ll replace the tattoos with others and not with plain skin.
So the result is MUCH better now:
A screen recording showing the duration of the process on the MacBook with M1 Pro:
RemoveTool.mp4.zip (512.3 KB)
5 Likes
This also kinda limits the tool to lower res images as long as the mask is “limited” to 2000pix. So we’d definitely need a larger possible mask at least for machines with enough VRAM and/or the possibility to give the tool some guidance of which parts of the image it should preferably use for inpainting, e.g. with a second mask. @bin.sun
1 Like
You really need to read the question I answered which was to mariusz NOT manuel
No, compression for DNGs is Lossy.
Are you saying that the DNG’s that PAI outputs are lossy, Don?
I was under the impression my Adobe DNGs are lossless. i.e. the DNGs I make by running my proprietary Raw images through their DNG converter. At least that’s what I was told…
Thx.
If they are compressed the compression is lossy. It is a DNG Converter option.
Got it! Thx. I have mine set to lossless, so guess after I did that I didn’t pay attn to it…
@ida.topazlabs have I gotten all credit for testing photo ai?
I believe Adobe DNG SDK allows for lossless JPEG compression. Older DNG saving which was going through libtiff did not have access to this because libtiff cannot compress 16-bit JPEG data.
Looking through the DNG SDK code, we save via WriteDNG which says:
// Figure out the compression to use. Most of the time this is lossless
// JPEG.
uint32 compression = uncompressed ? ccUncompressed : ccJPEG;
Specifically, because we use DNG SDK 1.4.0.0 and we have a backwards compatible version set to 1.4.0.0 as well, it allows us to use ccLossyJPEG, which seems unfortunately named because the comment for it says:
// Used in DNG files in places that allow lossless JPEG.
ccLossyJPEG = 34892
4 Likes
It should be lossless, see above post.
That then must be what is used in the DNG Converter because it still doesn’t provide lossless compression, only lossey.
My apologies I assumed the SDK provided the same output as the DNG Converter.
The remove tool can certainly be fun to use, but
I have long pointed out that some of the Exif information disappears on its own.
When will this be fixed?
What EXIF information disappears?
Have you posted on a different account previously? You’ve only got 2 posts on this one.
Some of the changes are not too important to me.
I am curious if I used flash or not.
I previously posted this via email.
2 Likes
Thanks for the side by side. I don’t know 100% what each tag is since it doesn’t include tag numbers, but going based off name and trying to convert to exiftool names, I can say the following.
Some of these tags are not transferable so I don’t believe any application will retain them unless they are making no changes to any tags. This would include:
- Exif-IFD-Offset (Location in file where EXIF data starts)
- MakerNote-IFD-Offset (Same as above, location in file will always be different even if it’s written)
- InteroperabilityOffset (Same, offset to a table)
- JpegIFOffset (Same)
The other tags are potentially fixable, but they may be ExifTool bugs. We use ExifTool in the app to transfer metadata from one file to another. We do not touch certain tags at all. These would include:
- CompressedBitsPerPixel
- MaxAperatureValue
- Flash
- FocalLength
- Maker Note (Vendor)
- Creative Style
You can see if this bug is in ExifTool by itself by running some commands and seeing if the output is the same as ours. For instance, you can take the Sharpen output file you have in your comparison and run this command to strip all EXIF data (note, this will overwrite but also leave a .jpg_original file in the directory)
exiftool "your/file/path.jpg" -all=
After you have a cleaned image, you can copy tags directly with this command:
exiftool -TagsFromFile "file/with/metadata.jpg" "file/without/metadata.jpg"
If these still have the same issues then we’d need to wait for ExifTool to fix them. If you don’t have the same issues with this flow, then there may be an issue with our embedded ExifTool version or maybe we need to update it.
Also to be more technical, that above command is not exactly what we use in the app, but at least it’ll give a baseline. We do special stuff like ignoring some specific tags and not writing MakerNotes in some cases.
Edit:
Looking through the tags some more the main actual bugs seem to be:
- MaxAperatureValue is off slightly
- Flash is missing
- FocalLength is off slightly
The other ones may or may not be bugs. Specifically, CompressedBitsPerPixel might not apply to our output file, so writing it might not make sense. For the other two (Maker Note (Vendor) and Creative Style) I’m not sure where those tags come from but if they’re from MakerNotes and we don’t write them, then those missing is expected.
4 Likes
Could someone with an Intel Mac and AMD GPU let me know if the remove tool now works with it? If not, does it work with the CPU? Sorry, I have looked but cannot find the answer.
After successfully editing a black/white tiff file with Photo AI (using sharpen with the motion option and denoise with the normal mode), Lightroom reports that the returned file is damaged or corrupt. Photo AI returns all color photos to Lightroom with no issues. I’m running the most recent updates of Lightroom and Photo AI.
