* Export Gedcom Plugin - Resizing media

[Jane]

I might have missed it, but is it possible to get the Export plugin to resize all the media? I found I can resize the cutouts, but I would like to resize all the media down when I am exporting for TNG as some of my scanned documents are huge and I only want to post a "1000x1000" copy of documents, etc.

[tatewise]

Yes, it does already.
For any Multimedia Conversion mode that includes Part Frames the Max height/width below will restrict image size.
They are greyed out for modes that do not apply.
They currently default to 600 but you can increase them to 1000.

[Jane]

Ok, the help lists

*PART~LMO exports Face/Detail frames as cropped files for local Media Objects where Max height/Max width limit their size
◦ FULL~LMO exports all images as full frame files linked to local Media Objects
◦ ALL~LMO combines the above two options
◦ PART~ABS exports Face/Detail frames as cropped files for Media Records where Max height/Max width limit their size
◦ FULL~ABS exports all images as full frame files linked to Media Records using GEDCOM Draft 5.5.1 FILE link tags
◦ ALL~ABS combines the above two options
◦ FILE~REL keeps relative links for Media Records, and is the default for (FH5) Family Historian 5 export mode
◦ FILE~ABS makes absolute links for Media Records, and is the default for (GST) GedSite export mo
◦ WIPE~ALL excludes all Media Records from the export

So is it ALL~LMO I want?

[tatewise]

I have re-examined the code and it does only apply the Max height/Max width to Part Frame cutouts. Sorry.
The full frame files just get copied as they are.
So the trick would be to add an almost full frame cutout to those oversized Media.

I think I chose not to apply the Max height/Max width to all Media because it invokes quite a time penalty.

[Jane]

No problem, I'll run write a plug in to go through the files after running your plugin.

[Valkrider]

Jane

It may be easier just to use one of the bulk jpg resizing programmes rather than writing a plugin. You could just do a resize on the export media folder keeping the same file names and locations.

[Jane]

Not all my media is in jpg, so I'll need to change the gedcom as well so for me it's probably easier to do all in one place.

[tatewise]

I'm well advanced in updating the Plugin to optionally allow ALL Media to be limited in size.

[Jane]

Thanks Mike you are a star

[tatewise]

Try Export Gedcom File Plugin Version 3.6.1 Date 26 Sep 2018 ZIP file, so remember to unpack.
[EDIT: Attachment deleted as Plugin Version 3.7 now in Plugin Store.]

Use the tick option to Apply the settings above to all image files.

You will probably have to Empty Export Folder to get the Plugin to export & resize all the files.

The Plugin will take longer to export if there are many files to reduce in size.
But subsequently will be quicker if only a few Media files have changed since last run.

Took me longer to get it working than expected, because the imlua library function being used objected to working on full files.
Anyway, substituted them with the im.ProcessReduceNew(...) and all seems to be working.
I'm sure you'll let me know if anything does not work correctly.

[Jane]

Thanks Mike, I will give it a go this afternoon.

[Jane]

2018-09-27_080147.jpg (64.46 KiB) Viewed 11841 times

I got quite a few of the above, but I can't see any patten other than they were all png files, they open OK in FH, any ideas what I should look for, they all have Format of png in the format column in the original Project.

[tatewise]

I too have found an image file that produces that error status message.
It is produced by the Image:Save function in the imlua image processing library.
There does not appear to be any further explanation of that error message.

The odd _AREA: {...} values are the Plugin trick to use the existing crop & convert function with the cropping frame set to the file limits for Full frames.

As you say it only applies to a subset of files, and only to those that are originally NOT in JPG format..
In my case there are several PNG and GIF files that are OK, and one GIF file that imlua does not like.
It does not matter whether the image has a Part frame crop applied or not.

All is OK if you untick the option to Use JPEG file format for the exported image files.

I tried using IrfanView to make minor changes to the image and saving as a GIF but no success.
However, after converting it to a JPG file it was OK.

So unless I can find another way of altering the GIF file to satisfy imlua the only two options are to untick Use JPEG file format or convert those rogue files to JPG format and change the Link and Format in each FH Media record.

[tatewise]

I've given this Use JPEG file format... feature some more thought overnight.
Currently, it always excludes BMP files, because when developing the Plugin my BMP suffered that Image:Save error.
BUT maybe my BMP are just exceptions, and other BMP would convert OK.
Just like some PNG & GIF are exceptions, and others convert OK.

So, I am proposing to apply the Use JPEG file format... when chosen, to all non-JPEG image files initially.
If any such conversion encounters the Image:Save error, then the Plugin will revert to the original file type, and convert that.
Those files will be reported together at the end of the Plugin, probably in the Result Set.

If any file suffers the Image:Save error when using its original file type, then that will get reported as it does now.

I will also improve the odd _AREA: {0,0,99999,99999} value to say something like Full Frame.

[Jane]

Sounds good. I'll give it a go once you have had a chance to do it.

[tatewise]

Try proof of concept Export Gedcom File Plugin Version 3.6.2 Date 28 Sep 2018 ZIP file, so remember to unpack.
[EDIT: Attachment deleted as Plugin Version 3.7 now in Plugin Store.]

This implements my recent proposal to Use JPEG file format... where possible on all exported image files.
Otherwise it will use original file type.

Currently, there is no popup error message to say when JPEG format could not be applied.
BUT the final Result Set has leading entries to report such cases with the filename.
Those entries have: No. 0, Rule 0, Title Media Conversion, Action Use JPEG option error, etc.
The Text column provides the filename.

If it works correctly, then I can improve the error reporting.
Does it need a separate popup message to tell users to see the Result Set or just add a note in the usual completion Memo?

[Jane]

Thanks Mike, I think I worked out what the problem is caused by, it's when the png or gif is saved with transparency on. I suspect there is probably a call to turn off transparency before saving as a jpg. Anyway dropping back to save as the original format works fine.

[tatewise]

OK, that all sounds good, and the fallback to use original format is worth keeping.
I will look to see if the imlua has a way of altering transparency, and that would mostly eliminate the problem.

[tatewise]

I've had some success with using imlua to convert non-JPEG to JPEG image files.
I have some GIF and BMP files that do not convert using the Export Gedcom File Plugin.

I've written a conversion Plugin to experiment with imlua and found that my GIF and BMP files use a ColorSpace called MAP that JPEG does not support, so conversion fails.
After using imlua to ConvertColorSpaceNew(...) to RGB that JPEG supports, the conversion works.

There may be other image file attributes that prevent conversion to JPEG.
But they should also be correctable to get most, if not all, conversions to work.

PNG with Transparency in various formats converted to JPEG but the image was entirely black, so more work needed.
GIF with Transparency were OK.

The problem with this limited success is that there are no error messages regardless of whether the resulting JPEG image is good or bad, so the Plugin cannot determine when to revert to original file format.

Could you attach some sample files that fail to convert, so I can investigate them?

[tatewise]

After more investigation and experiments I have found an imlua conversion that seems to work for all image files I've tested.
That includes a mixture of BMP, GIF, TIF, and PNG files, some with Transparency set.
The only problem so far is that some conversions produce slight graining/pixelation.

Try attached AttributeImLuaTests Plugin Version 0.1 Date 30 Sep 2018.
[EDIT: Attachment deleted as incorporated into Export Gedcom File Plugin Version 3.7 now in Plugin Store.]

It prompts for a folder that you should have preloaded with image files to be converted to JPG files.

There are no progress or completion messages, but should produce an error message if the Plugin detects a fault.

The Plugin converts each image file, putting the output JPG in a similarly named file prefixed with a + sign.
e.g. Conversion of file TestFile.png becomes +TestFile.jpg

The Plugin will disregard all files whose name starts with + and any that are not image files.

[Jane]

I ran the test folder over my 1911 Census folder and it worked fine till it ran out of memory.

[tatewise]

Sorry about the memory error; my mistake. Forgot to Destroy image buffers on each loop.
That is corrected, and the Plugin also now just duplicates unconverted .jpeg files as well as .jpg files.
Try AttributeImLuaTests Plugin Version 0.2 Date 01 Oct 2018.
[EDIT: Attachment deleted as incorporated into Export Gedcom File Plugin Version 3.7 now in Plugin Store.]

I also now realise that the slight graining/pixelation 'problem' is actually due to the compression quantisation in converting from lossless PNG to lossy JPG with a typical 80% quality, so it is completely normal.

The Plugin works by converting the input image to OpenGL format and then saving in JPEG format.
The http://webserver2.tecgraf.puc-rio.br/im/ IM Imaging Toolkit Version 3.12 says under Representation > Reference > imImage > Conversion > Functions > imImageGetOpenGLData:

Returns an OpenGL compatible data buffer. Also returns the correspondent pixel format.
The memory allocated is stored in the attribute "GLDATA" with BYTE type. And it will exist while the image exists.
It can be cleared by setting the attribute to NULL.
MAP images are converted to RGB, and BINARY images are converted to GRAY. Alpha channel is considered and Transparency attributes are converted to Alpha channel. So calculate depth from glformat, not from image depth.

The JPEG format does not support an Alpha channel, so any Transparency settings get discarded.

[tatewise]

Jane, have you had a chance to checkout my test Plugin Version 0.2 Date 01 Oct 2018?

[Jane]

Looks promising, it ran through a folder full with out throwing any errors

[tatewise]

When you have time, can you check some output JPEG image files to ensure they are valid, and not all black or empty, especially if the input file has transparency settings, or any other unusual characteristics, or a rare image file type.

I found that some IM conversions I experimented with didn't report any errors, but simply didn't output image files correctly.